Working On It, Not In It

This keeps us busy, to be sure, but it is the best kind of busy imaginable. A continuous flow of technological challenges that, when solved, honor the name of Christ? Sign me up!

Twice a month we step out of the fray as a team and exercise the principal “Work on it, not in it.” We spend a few hours on Friday locked in a room together, sharing new discoveries, hashing through concerns, and grinding on ways to bring order to our collective work so that it doesn’t spiral into chaos.

A Common Set of Challenges

It was during these meetings that we were able to identify a common set of challenges that seemed to present themselves in the average web site project. Certain questions came to the surface over and over again. Things like:

• Is that font size too big or too small?
• Should we use proprietary software or open source?
• What size should the video be on a page?
• How tall or wide should a page be?
• How many pages should be designed, and to what detail?
• What are the preferred technologies to use?

The next step was pretty obvious.

The Solution: A Guide

We needed a guide! A standards document. Something to articulate our default position on the common decision points that our web projects face.

Ugh. A document? Really? Nobody likes large, unwieldy SOP/Process documents heaped upon them, especially not for creative projects. Would it be followed? Would it even be read? We discussed it and came up with these goals for our Web Design Standards document:

1. Must be quick/easy to read and under 2 pages or it will be more of a burden than a help.

2. Must honor the autonomy that empowers our ministries. Basically, avoid dogma if possible and be clear about our motives.

3. Must not read like it was born in 1994. Writing a document for designers that looks like a “TPS Report” is not going to encourage buy-in.

Very quickly we realized that we could not fit everything into 2 pages. So, the decision was made to split the guide into 2 documents. One to cover Design and one to cover Implementation (coding, technologies, deployment). We often sub-contract these parts out separately anyway, so the delineation was natural.

Today the web team would like to share with you the first document born of these efforts.

Download: North Point Ministries Web Design Standards (PDF)

Download: Source ZIP (Pages, DOC, PDF)

Feel free to use it for your ministry, pass it around, carve it up and swap out items as you see fit. If nothing else, use it to start a conversation. And if you do use it for one of your projects, let us know! Most importantly, if you noticed anything we missed, please share in the comments.

It’s challenging a lot of our staff and management to really ask the tough questions about how to best motivate employees and team members.

Here’s a video that explains some of the book, etc.

What is motivating your ministry and tech team?

Is it food? Is it money? Is it something else?

How would you be better suited to motivate?

Answering these questions can seriously change your work environment, for the better! And, I’d like to think that we’ve got a great work environment to begin with!

Add trying to coordinate a few crazy-busy people to drop blog posts can drive people over the edge…! So how can it be done? What’s our strategy?

Very simple: Create a Master Schedule, assign dates, and then commit.

It’s that simple really! What we’ve done is assign our team specific friday’s to blog and then we trust that person to write. It’s not too complicated and it really can work.

We also help each other out when we’re struggling to come up with topics (because not all of us are born-bloggers). We’re a team, remember?

Have you got a strategy for posting blog posts on your church’s properties? How’s that working out for you?

Every couple of months or so we get a request for embedding a video within an email. Our immediate reaction is to do a spit take (I think I actually did one once), so we wanted to let you know why this makes us shudder to think about. The answer will always be no, and here’s why:

1) There is the question of web standards and quality.
Wait, why are you talking about the “web?” This is about emails. Yes, yes, an email now-a-days is basically a un-glorified web page. I say un-glorified because, while it gives you the ability to have pictures and different colors and fonts and stuff, it doesn’t let you take advantage of 98% of the aspects of a web page. There are no css files, no forms, no includes, no jquery and NO EMBEDDING OF VIDEO.

On the web you can embed a video, and you can also set the option of having it auto-play or have the user click to play. At first thought, “autoplay’ sounds good - one less step the user has to take to enjoy your wonderful cinematic experience. Normally the less clicks the user has to take, the better. This is not true with video. Ask any web monkey what they think of “autoplay” and they will give you a look of horror and disgust (similar to asking about using comic sans on a page). Imagine opening up an email and suddenly having someone start talking to you. Better yet, take 3 out of 4 random spam emails from your spam folder and imagine them in video form. Not a pretty picture huh? So this is case #1 against the concept of embedding the video in an email.

2) Email is for text. Web pages are for multimedia.
45 years ago Email was originally created for the sending of text and the ATTACHMENT of multimedia (i.e. images/video). The web was created, and is used, to display text/images/video/flash/forms etc. That is why it was created and has evolved to what it is today. While still not standardized 100%, the web is pretty refined and we know that there are 4 commonly used browsers we can develop for (IE, Firefox, Safari, Chrome (sorry Opera and all Linux browsers)). This brings me to #3.

3) Your favorite email client is not everyone’s favorite.
Do you use Gmail? Yahoo? Hotmail? Eudora? Thunderbird? Apple Mail? I could go on. There are too many email clients that treat/render HTML incorrectly, if at all! Even if it displayed it properly, some clients block or send to spam emails that have too much code in them. Javascript? Nope, not in email. And for good reasons, too.

4) What about phones, Blackberrys, etc.
How many emails do you get a day that don’t look right? Those emails probably use images so imagine getting a video email. What do you see instead? Do you get a broken email that uses images as the fail-safe? How many broken emails do you get that don’t have text as a fail-safe? Insert can-of-worms here.

So to sum things up: Email is not the medium for this type of multimedia. While I understand the enthusiasm about sending an email with a video in it, I do not agree with trying to put a square peg in a round hole.

So, we created some Social Media Guidelines to help educate our staff about acceptable usage, etc.

You can take a look at our policy here.

Our team decided to celebrate Russell’s 40th birthday with a few items of necessity:

• Bi-focals
• Men’s depends
• A wheelchair
• Various items to make him more “comfortable” for his aging body
• A cane
• Ex-Lax
• and more!

Congrats on the big 40!

Some more shots after the jump… and a video!!!

Validation as a debugging tool
While contemporary Web browsers do an increasingly good job of parsing even the worst HTML “tag soup”, some errors are not always caught gracefully. Very often, different software on different platforms will not handle errors in a similar fashion, making it extremely difficult to apply style or layout consistently.

When surveyed, a large majority of Web professionals will state that validation errors is the first thing they will check whenever they run into a Web styling or scripting bug.

I know that we do this for new projects, It is a great starting point for trying to figure our why /new/ problems are occuring as well as just a great double check to your own code.

Validation as a future-proof quality check
Checking that a page “displays fine” in several contemporary browsers may be a reasonable insurance that the page will “work” today, but it does not guarantee that it will work tomorrow.

Validation is one of the simplest ways to check whether a page is built in accordance with Web standards, and provides one of the most reliable guarantee that future Web platforms will handle it as designed.
Validation is a /starting point/ to figure out bugs, If you can prove that your site is valid, you can also rule out a lot of possible problems with it and discover the actual problem with your site.

Validation eases maintenance
It is reasonable to consider that standards such as HTML and CSS are a form of “coding style” which is globally agreed upon. Creating Web pages or applications according to a widely accepted coding style makes them easier to maintain, even if the maintenance and evolution is performed by someone else.
I completely agree with this, If sites are coded with standards then /anyone/ can come in and update them with ease. Understanding that /you/ might not be the one in charge of the site within the next 2 or 5 years is key.

Validation helps teach good practices
yes, I think we’ve covered this by now.

Validation is a sign of professionalism
As of today, there is little or no certification for Web professionals, and only few universities teach Web technologies, leaving most Web-smiths to learn by themselves, with varied success. Seasoned, able professionals will take pride in creating Web content using semantic and well-formed markup, separation of style and content, etc. Validation can then be used as a quick check to determine whether the code is the clean work of a seasoned HTML author, or quickly hacked-together tag soup.

I feel weird about this one, but I agree with it. If you hire a development firm to… say… design and develop a new template/system for a significant web property that you own, you would expect the final product would validate!

So, what have we learned here?
Validate to check your code, its another pair of eyes which we all know is very useful in the IT world.
Validate as a leveling ground for bug tracking, if you know your code is properly formatted then you have a place to start with debugging user issues.
Validate as a statement of professionalism, consider your customer and think of them “secretly” checking the validity of your work and to their chagrin it validates! that gives you +1 internets!

Source: validator.w3.org

It’s probably because I’m over email newsletter systems; most of them just don’t work well and cross-browser and email client testing can be such a hassle.

But, it’s still a significant part of how we communicate to our congregation, partners, and organization. I don’t see it going away anytime soon.

So the only logical choice is making sure we have the most robust emailing system available. We’ve been using one such system, Constant Contact, and it’s done an ok job so far, but we’re always on the lookout for other systems to either compare or contrast feature sets and functionalities.

Do you have any recommendations? What does your ministry use?

This obviously complicates everything the moment we get in teams. To think that we even have the capacity to do anything productive without killing each other! But, we do.

So, as a result, not only do we need to be more cognizant of who we are individually (and how we can improve ourselves) but also our team. As a result, we’re going through Patrick Lencioni’s book The Five Disfunctions of a Team together!

I think it shall be grand. The first step in making things better is admitting that they need to get better! And, we can always do better.

So, how are you building up your web team? Are you guys going through anything together?