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.

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.

This year we did something special for our staff. I wanted to hang one of these up in front of our copiers and printers, but a very wise person advised against it.

Therefore, we altered our internal DNS to point all traffic to social media sites to a custom internal site straight outta the 90’s. There were about 18 domains total that we redirected, including the usual suspects like twitter, facebook, etc. We kept it up for about four hours and then took it down.

Also (to make it seem like this post is helpful in some way) we set up Casper to run the dscacheutil -flushcache command on everyone’s computer to ensure that people could resume their social media activities as quickly as possible. Anyway, here is a video of it in action.

In a perfect world all company documents would be stored on a centralized file server/intranet that is backed up, easily restored and safe. Does this sound like your environment?

Yeah mine neither.

People keep them, in our case, on their laptops, so we have to provide a way to backup this data. For the longest time, we used an OS X server, and the mobile home directory sync service to “accomplish” this. It was a disaster; we had lots of problems with lost files, corrupt files, and people just not backing up.

Then Time Machine came out, and someone had a great idea…

“Why don’t we just buy hard drives for everyone?”

So, that’s what we did, and it’s what we do to this day. When you start working with North Point, you are given a 500 GB external hard drive, and we configure Time Machine to backup for you. We don’t provide bus powered drives, hoping this will dissuade people from taking them home, and if a user needs something bigger than 500GB, we are usually able to accommodate.

Since we use Casper Suite for our software deployment and inventory management, we asked them to provide a mechanism to tell us Time Machine’s last backup date. This enables us to pull a report and visit those users whose Time Machine is either broken, mis-configured, or just not turned on.

While this may seem like killing a gnat with a shotgun to some people, it makes total sense to us. Buying these external, non bus powered drives in bulk is more reasonable than you might think. The hard drives are rotated/re-purchased every three years just like our laptops, so we just bundle it with the total cost of the laptop. Also, it prevents us from having to buy big bad storage arrays to store all of the data. Additionally, it saves us the time/money to keep a storage array up and running and backed up to tape. Granted, it also doesn’t give us the same peace of mind an enterprise backup system would provide, but this is something we have been comfortable with for now in this area.

What are you using to backup your end users laptops/desktops?

As has been mentioned previously on this blog, we are big fans of the Apple platform. Ask 15 people across North Point why this is, and you will likely get 15 different answers. However, from an IT perspective there are two main reasons:

1. It puts lots of creativity into the hands of our users. Sure, you could accomplish this with a Windows machine as well, but not with out of the box software. We put a very high value on creativity around here, so the more that’s available to the fingertips of our users with minimal additional cost, the better.
2. Viruses, Adware, and Malware oh my.

I am sure you all have your arguments with me on this topic. So, don’t take it from me, take it from the Enterprise Desktop Alliance. And as always, feel free to disagree with me by commenting below!!

This post is a long time in the making, but a recent article from Google renewed my passion for the topic, so I thought I would share our journey into the clouds with you.

Step back with me, way back to 2002, when I began my employment here at North Point. At that time all of our email was handled through a Mac clone running EIMS. People only used POP on this bad boy, so all email was contained within the individual Entourage databases of our users. If this doesn’t strike fear in your heart, then you might be reading the wrong blog.  On top of this, there was no real contact or calendar sharing to speak of.  And to make matters even worse, we were (and still are) an all-Mac shop on the end user side. So to move to something like exchange was a very difficult idea for us to swallow.

We went on like this for the next 4 years until…one day…. we hired…a windows guy to run our IT department….

dum dum dum…..

Fear not though… we quickly assimilated him into our undying devotion to the Apple platform. This turned out to be great because he had the best of both worlds. He had the experience of the real world, and the love of the pretty one. So, we began our search for a replacement of EIMS.

Fast forward a few years to the end of 2007 when a friend of mine asked an alarmingly simple question, “Why don’t you guys use Google Apps? Its free?” What?!? I did a double take to make sure he was serious. After I casually blew him off, I quickly ran back to my desk to ponder the idea. Eventually, we set up a test domain, added some key users in the ministry, and quickly fell in love. Here’s why:

1. It democratizes technology: people only use what they need of Google apps. They don’t have to wait on the IT department for upgrades and feature additions.
2. They have more cash than me: they can provide backups and D/R sites that I will never be able to afford.
3. No infrastructure required: need I say more?
   
4. Its free: as in the First Amendment.
5. Spam filtering: it’s by Postini/Google, and it is awesome and crazy cheap for NPO’s. This also provides us with 1 year of email archiving.

There are many other reasons but these are the big five as I see them.

Over the next year or so, we migrated all of our users from Entourage POP to Mail.app/gmail/imap. We migrated all of their calendars to Google and provided training sessions of about 10-15 people per session until everyone was migrated.

As with any major move, we had many challenges.

• Google has not been the greatest customer service organization. Getting in touch with someone when a real issue arises has its problems.
• We are one big organization with many parts (campuses, and domain names), and Google apps only gives you one domain for everything to fall under. However, they also allow you to have alias domains. So, we created a parent domain to configure everything, and we set everyone’s default alias/domain to the campus/domain where they work.
• We had to develop our own training materials and migration plans. I only mention this because since then Google has created a deployment center for this. I highly recommend it.

The move to Google apps has been an overwhelmingly positive experience for us. As Google continues to shore up current features and add awesome new ones, it only gets better. The only problem we are having these days is how to get all this new information into the hands of the users that want/need it. Despite everything though, I would much rather have this problem than sending emails to my users about my exchange server being down.

Disclaimer: We were a bit unique with our move in that we went from nothing to something amazing. Most people already have Exchange, so moving to  Google apps may be a little more difficult for them because it may not solve all problems. Furthermore, your users already have certain expectations of a product that mine did not. Here is a great source of information on this point. http://citrt.pbworks.com/Google-Apps-Pros-Cons-Other

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