Thursday, June 24, 2010

ChMS - Checkin Q&A

My last post has sparked a few questions that I thought were worth answering regarding some of the decision making on our kiosks.

First up:

I just read your 22 page essay on your check in build process. Did you give any thought to RF wireless keyboards? That would reduce the cabling spaghetti in the cabinet. The down side is batteries and the keyboard might disappear. I would hope that last problem wouldn't be a big problem in a church.

---

Thankfully the cabling in the cabinet is not a huge issue, but there are three very good reasons why we chose the keyboards we did over something RF:

(1) This was the smallest usable keyboard + mouse that we could find. It had to be very thin to fit on the hideaway tray.

(2) Cables are more reliable than RF, no lost connections and such.

(3) Batteries are another maintenance and cost item.

---

Next up:

Joel - just read through the PDF on your blog about your kiosk system - or at least the Mac mini versions... just curious why you chose to hook up the printers as ethernet printers (which required buying a switch) instead of just using USB? and for that matter - why did you go with a wired network connection?

if you were starting over today do you think you'd still go with the Mac minis or would you just use iPads? (especially since the new minis cost $100 more.)

---

The printers are network printers connected to the windows servers, not local printers to the workstation. Since its 100% browser based and not OS specific this was the best way to make it work. Much faster and more stable than USB printer sharing on the minis. I have huge crowds of people using these things in short periods of time, and being rock solid is the single most important factor.

Wired network connections are more reliable than wireless, and I don't have as a single point of failure a wireless hub, I have a very nice POE Ethernet Switch. Since they have to be plugged into power anyway, a second cable is not a big deal.

As for today, I would still build this as is for our main campus, but we are using iPads for checkin at our second campus because an iPad + Network printer = $1100 or so instead of the $2500 these kiosks cost each. There is a downside though. The iPad requires a volunteer for every station. We generally have about eight checkin kiosks running with two or three volunteers. The kiosks do not have to be manned. If i left ipads out on a table for people to use for checkin, we would be replacing a lot of iPads that mysteriously disappeared...

---

The iPad checkin for the second campus has been built and tested, but we aren't "live" with it yet because I am waiting for the budget approval from the campus lead to buy the equipment to make it happen. Still, it's a pretty slick solution. I'll share that in another post.

Joel

Wednesday, June 23, 2010

ChMS - Implementing Checkin

If you follow this blog, you know that we implemented check-in at HDC last summer. In the fall I wrote up a long document explaining our process, as well as detailing the design and construction details for our kiosks. I realized today as I went to point someone to it that I never actually posted it here. Please click on the link below to read the PDF on how we implemented check-in at HDC.

Implementing Check-In

Recently we paid for a secret shopper firm to come to our campus and evaluate HDC. We received very high marks on children's check-in, and perfect marks on check-out. This is in stark contrast to the last time they came to our campus when we got hammered on both of these points. All in all children's check-in has been an amazing success and is one of the best projects the IT department has been involved in.

Joel

Wednesday, June 16, 2010

Developer Roundtable 2010 Day 2

Day one was about the community and what we (collectively) are working on. Day two was focused on Arena and what we, the community, think they should be working on.

First off, props to Arena for involving us in this. It's not about saying "this is what I need, vote for me!" it's about the developer churches considering the needs of the community as a whole, and looking at what should be the highest priority.

Mike Gold is introducing a new development process known as SCRUM. The point of the scrum process is to distill requests down to concise stories that can be accomplished in a reasonable amount of time. After a week of planning, the developers are given three solid weeks to code and burn through the backlog, at the end of which there is a measurable product. During that time the scope is not allowed to change, and the purpose of this methodology is to produce a continual re-evaluation of development priorities while allowing important things to be produced quickly.

One key aspect of all of this is organizational. The scrum team also involves dedicated QA people, so they are testing during the development process and are committed to the same deadlines. Thus, at the end of the scrum the items should actually be ready to ship, rather than just sent over to QA for aging. Another key is that bug fixes have a completely different team, one that uses the scrum process as well. By separating out product development and bug fixes the development team isn't continually interrupted with high priority projects (because bug fixes always should be high priority) and the bug fixes can be patched and released faster.

For day two of the roundtable we as developer churches participated in what is known as the Sprint Planning Meeting. We looked over the product backlog, added items that were of importance to us, and then prioritized that backlog. From here Mike Gold and his team will schedule the scrum and kick it off, I assume next week.

I cannot stress how incredibly empowering it is to be sitting at the table with the other developer churches having direct influence on the development priorities of a software product. Obviously our decisions aren't the only ones that matter, but having a seat at the table for this discussion is simply huge. I can't think of another product that is so directly in touch with it's customer's needs.

At the end of the day we (the group, not HDC) had five items that will be placed into the first sprint, and should be in the next release of Arena.

Daniel and I left at 4pm and headed to the airport to catch our 6:45 flight, which departed at approximately 11:30pm... Needless to say, that made for a very, very, very long day. I am completely exhausted. But the roundtable was 100% worth attending, and one of the really great things about being an Arena developer church.

Joel

Monday, June 14, 2010

Developer Roundtable 2010 Day 1

As part of the Arena developer churches program we are invited each year to the Arena Developer Roundtable. Last year we heard from CCV about their fork of the code to allow them to develop features without being concerned about the business case for their development priorities etc. One of my concerns was that without a church involved in the development of the core that Arena could lose their focus, but we waited to see what would happen.

This year is different, but in a good way. Jon and David are not here in person, although they have been following the live feed. It's a bummer not having them here, they have become friends over the last nearly two years. THe biggest change with Arena is not the loss of Jon and David (they aren't gone, just not as involved as they used to be), although that is a significant loss, but rather the addition of Mike Gold. Mike came from Willow Creek, and brings a level of enthusiasm and professionalism to the whole development process that is incredible.

Today Mike lead us through an introduction to the SCRUM process of development, something that he is implementing at Arena. What is really, really, really cool is that we are part of that process tomorrow. As stakeholders, we are working with Mike Gold, Mark White, Jeff Maddox and the other Arena guys to narrow down and refine the development priorities for Arena tomorrow. This is exactly why we come to the roundtable: To have input into the future direction of Arena.

We also shared the CCCEV / HDC check-in suite, which is a full featured windows free alternative to the official check-in solution. We demoed check-in on the iPad, as well as using an iPad as a number display for parents in a service, and showed our solution for multi-site network in a box. We also showed a module that Daniel wrote to export any dataset in Arena to a .kml file for display and analysis in google earth.

Trey from Brookwood Church showed their members portal, and its very awesome integration of "contact us" and assignments, allowing people to sign in and initiate staff followup. Several other people showed stuff they had been working on as well, and then in a huge surprise, Scott from Watermark Church showed us their ShadeTree implementation via Skype. Scott is not here but has been participating on the developer IRC and watching and listening to the feed that Mike Gold setup. ShadeTree is a very cool spiritual formation app that also includes a very nice members portal and social networking features. I like ShadeTree a lot, and it already looks better than the Arena public portals in a lot of ways, but I think for us our preference is to keep things as tightly integrated with Arena as possible, and that means not using ShadeTree for group management, even though it's pretty good at it. But the spiritual formation aspects are really exciting, and I am looking forward to making that happen at HDC.

Finally at 6 we called it a day and headed off to dinner. After dinner we moved to the lobby where we are sitting now, discussing Arena, coding, comparing notes and just hanging out together. Day one has been great so far, and it's not over.

Joel