Clarify your vision and purpose. Then figure out how Twitter, Facebook, and other technologies can help push you forward. 

Too many people spend too much time trying to do too much with technology. Don’t get me wrong – I love technology (most of the time). I make my living from it. But we can often forget  that technology without purpose is pointless.

Technology is an extension of your vision and purpose; it isn’t about making technology your purpose. 

Stop. Figure out your big picture. Then take people there using every bit of energy you have. Oh, and use some technology to get you there when it makes sense.

1. What technology platform(s) does the firm use or require?

This may any of the following: Flash, PHP, Rails, Macromedia Dreamweaver/Contribute, or a custom content management system. Whenever possible, select the technologies that best match your church capabilities. No, not your current ministry capabilities, but your church – is your church highly technical or techie-light? The lighter you are, the easier the barrier to entry must be – no Flash, heavy programming requirements (or none at all), and plenty of reference materials for easy training. If they are trying to sell you an “all-on-one solution” and you can’t find at least 6 books at Amazon covering the technology, run away – you won’t be able to support it.

2. What is their process?

What is their process for taking you from brainstorming to prototype to templates to a full site? Do they help you brand your site, generate web site templates, and then stop? Or, do they migrate your content from your existing site into the new templates to help you get started faster? Do they have a project portal to track requests, post designs for review, and post work as it is being completed?

3. Do they have versioning and disaster recovery?

Hard drives crash. Work is lost. Bad weather happens. Does the firm make offsite backups, storing your project on a server in another state or on tape in a safe location? Do they version their work, in case they make a mistake and need to get back to yesterday’s work? If not, you could lose time, content, or both.

4. Who owns the original work?

If they used Photoshop, Illustrator, Flash, and other tools – who owns those files with all of the layers and markup? Do you get copies when they are done, or do they own it all? What if you want to modify one of the image buttons or graphics? What about when the marketing team wants to make a minor change to the wording in an image?

5. Do they offer training and support?

Will they help you get the rest of your team trained to use the new templates and technologies? Do they offer support for the first 90 days or more, to help you get some of the pages fixed that you may have messed up?

6. Do all of their sites look the same?

Some firms do original work once, then use the same set of graphics and web layouts for many customers. If they are focusing regionally, it is even worse when a potential visitor thinks you and another church are copies because your websites look exactly the same!

7. How many staff members do they have?

Things happen – they can lose a key designer or programmer. Someone can get sick, or need to take personal leave due to a sick relative. Can they bring in another staff member should something happen to your current team?

Take the time, interview several firms, and find the one that fits your timeline, design, and process. You are a steward of the money you spend on this, so you are accountable for the outcome. If done properly and with prayer, you can glorify God with a fresh design, bring new visitors into your church, and minister to those in need.

[tags]church web design[/tags]

I want to now introduce a new blog, specifically for technology enthusiasts – Tech Leadership. It is a blog focused on all that is software and IT, including management and leadership in a technical setting. So, come on over, take a look around (just remember, the paint is still fresh), and subscribe to engage in conversations that are fun and more technical in nature. I look forward to seeing you there!

For us, one area that makes me cringe is our check-in system. It’s not such a bad experience for families but we are doing a horrible job of capturing and entering data from our check-in that could be a huge help in generating reports.

For Tammy and others that are considering a check-in system, I’d like to offer up a few points before you go and implement an out-of-the-box or custom solution. These tips are based on my experience helping to implement three generations of check-in systems, both homegrown and commercial.

1. Honor the solution, not the technology by focusing on what you need, not what a solution offers. Often, it can be exciting to see all of those wonderful features and think that you need them all. Often, you don’t.
2. Members and visitors above reports and procedures – it’s about the user experience, not the reporting. There is nothing worse than a bad solution that produces reports, but deters visitors
3. Trainability above functionality – after the user experience comes the operator experience. Make sure that you can train your staff without expensive consultants or multi-day seminars – you will get more volunteers that way
4. Avoid data access excess – going into a solution is usually because you want better reports. Often, the solution forces you to put in more data than you can deal with and the process will bog down under the weight of the data. Go for simple over complex, as you’ll “file 13″ those reports you really wanted over time anyway – often for the most basic reports that tell you the most and are the easiest to generate
5. Security for the kids – if the solution doesn’t make the kids more secure by protecting them from out-of-favor relatives or walk-in strangers, don’t implement it

[tags]Church Management Systems, check-in kiosks, children’s checkin[/tags]

Power Trips
Know how power works and what to do when it fails: Scott Johnson and Tony Dye both discussed recently about issues with power. Scott has a podcast about when a techie becomes a manager that I was listening to today that covered the need to learn about power when becoming a VP of Dev, while Tony just experienced issues with a bad UPS and reminded us to test them once in a while and invest in good hardware that you trust.

Visitor Views
Having recently blogged about What if your Visitors Posted a Blog…, Kem Meyer’s recent post about How far would you go to see through the eyes of your guest? stood out in my blog reader. Of course, this caused Anthony Coopage to post a follow-up to Kem’s post, Seeing with Visitor’s Eyes.

[tags]electricity, church visitors, church leadership, river of news[/tags]

1. Pay closer attention as you drive into your church. If you are a staff member, this is critical for you, as you are used to the neighborhood. What works and what doesn’t? Is the signage easy to read? Do you have small signs in a 1 mile radius to guide your guests if they are unfamiliar with the areas?
2. Clean your palette – we are often used to the “taste” of our church, but if you “scrub your palette” once in a while, you may get to experience your church flavor again. What happens when the visitor pulls into the parking lot? Was it easy to find a place? Do they see smiles from the moment they see their first member? Are they welcomed with open arms, or is a program shoved in their face and they are told to hurry in? Are you treating them as kindly when they leave as when they arrive?
3. Bring a friend, asking for them to pay close attention and to give you an honest report afterward. Just be warned – it might hurt, but it may help you in the long run
4. Attend as an audience member by taking a day off, putting someone in charge to handle any issues, and just sit. If you have multiple services, attend one you normally miss to get a different feeling and to break those old habits.
5. Sit next to people you don’t know and get to know them – often, we sit next to those we know and forget that the visitor’s experience during the service

Remember: the visitor experience starts from the mile outside the parking lot as they arrive and completes a mile away from the building as they leave. Everything in between is fair game for them to critique – whether you know it or not.

[tags]church visitors, church leadership[/tags]

1. Write a wrapper script that cron will invoke, passing it the command line I really want to run as the rest of the arguments
2. Have the wrapper script run the actual command, capturing any standard output (STDOUT) or error output (STDERR)
3. If the actual command succeeds, print a success message, then the details of the run; if it failed, print a failed message and show the error output

Being a guy that writes Java during the day and aspires to write Ruby during the day, I decided to brush up a little on using Ruby to write scripts. The final script is called cronwrapper (original, huh?) and is available if you would like to use it or just want to see what I did: cronwrapper.rb

As a side effect of what I did, GMail’s feature to show the first few words of an email now shows me if it succeeded or failed, without me even having to open the email: Gmail view

Future improvements or changes you may want to make include: adding a syslog line to allow tools like Swatch to catch an error message and notify someone, suppress output on success, or send the email outside of cron with the output as an attachment rather than a plain text message.

BTW, I tested the script on Windows and Gentoo Linux and it works great on both platforms using Ruby 1.8.3.

Feedback and improvements welcome. Enjoy!

I saw a letter from a church recently detailing the new Wednesday night classes. It was a crowded page full of many offerings, but it communicated the facts. A few days later, I saw an e-mail from the same church detailing the new Wednesday night classes and it looked horrible and was hard to read. Upon closer inspection, it was evident that the text was probably copied from MS Word, directly into the e-mail.

That is something to keep in mind, especially if you use Outlook and the MS Word editor feature. Be kind when you send an email and use plain text or simple markup, a font that is easy to read, and lots of whitespace. Great stuff – check it out no matter if you are a technology ministry or not, as there are valuable lessons in email etiquette and some great reminders for us veterans as well.

Things I would have James fix in future releases:

1. Add better logging to the components – I had to rebuild a few components to get some better debugging. I’d love to see some better debugging lines in the components to assist in tracking events and component behavior. The good part is that the build environment is easy to use (Maven), and that he has a nice separation of concerns and easy-to-read build environment.
2. Some of the docs on the website are referencing the new package scheme since he was brought under Apache (org.apache.servicemix), while the latest release still uses the old package naming (org.servicemix). James may want to consider not rolling out the new docs under he releases the next version with the new package names
3. More detailed component documentation – the docs are pretty good, but I did have to go to the source to track behavior down, as well as dig into the third party docs for things like Rome (RSS/Atom support) to determine the constants for RSS vs. Atom. Going to the source is fine for me, as a full-time Java developer, but I believe his target audience for ServiceMix will be integrators that will not want to dig into the source.

Overall, I would recommend ServiceMix, and I plan to spend more time with it in the future on this project and other ideas that I have. Thanks James for the hard work!

‘grats Eric! I am looking forward to your presentation!