Sweat the Big Stuff

As I was getting ready for bed last night, a phrase popped into my head.

It’s the small stuff that makes the difference.

It’s a true statement. In a lot of ways, the tiniest of details can make a huge difference between a good product and a great product. The way something feels can change how you interact with something. My Logitech MX620 wireless mouse feels infinitely better in the hand than a cheap Microsoft Basic Optical Mouse. You pay more, but the experience is better as well.

However, the small stuff wouldn’t matter if you don’t get the “big stuff” correct first. I don’t care how good the mouse feels in my hand if it can’t effectively track my movements. A cake with excellent frosting can taste terrible if the underlying cake is stale. A car can look awesome, but if it doesn’t have wheels it’s a huge paperweight on your front lawn.

What I’m basically saying is that before you can start fretting over the details you need to have your foundation in place. Sweat the big stuff and get that right, otherwise all of those small tweaks you make will be for nothing because you’ll still have a terrible product on your hands.

It will just look really good doing nothing.

Content Workflow Musings

One thing I am tasked with doing right now is coming up with a viable workflow for content creation at Martin Luther College. There are a couple of goals I am trying to keep in mind.

  • enable faculty/staff/students to create content for various sections of the website
  • create a system that allows staff to vet and proofread created content before it goes “live:
  • have the system not get in the way of posting information in a timely manner
  • everyone can use it and understand it

Not exactly the easiest things to work out. Plone provide a workflow mechanism, and I will be working within that so that all content can stay within Plone from start to finish. Granted, a lot of it will be pulled from print publications or written in Microsoft Word, but the idea is to get it into Plone and then work from there.

The main problem I am running up against in my own mind is balancing the need to vet/control the content and allow creators the sense of ownership for the content they create (getting it up in a timely manner). How much control should an editorial team exert on the content that goes up?

I don’t even pretend to have the answers right now, and a lot is going to change as I grow into this role, but I think an approach that is flexible enough to change based on the person who is creating the content and the area they are posting is probably needed.

I’ll try and give a few examples.

  • Someone creates a new page outlining the programs available at MLC. They submit it via Plone and it can either be posted directly to the site or merely submitted for approval. Considering it is main content for the college having to do with academic programs, I believe that submitting it for approval is the best course of action.
  • Graduate Studies has their own section of the website chronicling what is going on with the program along with links to various sources that might be of interest to the students. The head of the program creates the content for this area. I can’t help but think that he should be able to post directly to the area pertaining to his program.
  • Breaking news on the campus: a bear has just gotten a honey pot out of a tree! Awesome. Someone from PR writes up an article with a picture and wants to post it up as soon as possible. In this case, one of the few editors should be able to quickly vet the article and then post it directly from Plone. It could be the head of PR, webmaster for the school or whomever.

Those are just some thoughts on various situations. One about vital information, one about continually-updated information for program-specific students and another about speed. I don’t know what is right or wrong, and I’ll be changing my tune soon enough as I find out what actually works, but I really feel there needs to be flexibility and no hard-and-fast rules that can get in the way of both simplifying things and obfuscating them when the need is there for each.

The Return of Odysseus

After a long and arduous process over the past two months I finally purchased my development laptop. Oh, you thought this was going to be about Greek mythology? Sorry, I just happen to use Greek mythos for my computer and networking names and Odysseus has been the name of whatever laptop I currently have with me for a long, LONG time.

It was a longer process than I was hoping because I’m both very picky and very cheap (right now). Since purchasing a house, the available money for extra expenses hasn’t just dried up, it has also been fired in a kiln. However, that didn’t dispel the need for a mobile development machine and that is what Odysseus is going to be.

So, what did I get?

I knew that a Mac was out of the question (at least for a while), so that narrowed it down in one way and opened up Pandora’s Box of Windows-based machines in another. However, I was able to quickly narrow it down when the defining thing I needed was Linux-compatibility.

Quite simply, I can’t develop very effectively in Windows. I’m not sure what has happened since early 2005 and now, but my use of Mac OS X and various distributions of Linux has rewired many parts of my brain to just expect a bash-like command line for me to work with. So, I’ll be running the newest releases of Ubuntu for the time being or until something better shows up.

Now, back to the hardware (sorry for the diversion there). I narrowed it down to IBM/Lenovo and Dell as the two I was going to focus on. Keep in mind that I am looking at used machines and I like to be able to “toss around” my laptop a little bit as I move from place to place. With that in mind, I focused on the business-class of machines from both as well. So it was ultimately down to the Dell Latitude D-series and the IBM/Lenovo Thinkpad X/T series as well.

Spending a month or more looking around I finally fell onto a deal on an IBM/Lenovo Thinkpad T61 and decided to give it a shot. That’s what I’m currently typing this post on right now. I’m hoping to keep it around for a while and wear it out as my traveling companion so that I might be able to save up some money for something smaller and lighter in the future. For now, however, it does everything I need and runs Ubuntu 10.10 like a champ. Not too bad for under $250.

Content and Mission

I am currently in the middle of reading Clout, a book by Colleen Jones, and a sort-of-companion-book to Content Strategy for the Web by Kristina Halvorson. First, if you haven’t read these two books and work with web content at all, you should pick both of them up and read them. There is so much great stuff in both of them that I cannot possibly recommend them highly enough.

However, that’s not the point of this post. The point of this little post is to put down my current thoughts on content and mission and where they intersect. It came to me in the shower (where most of my decent ideas come), and I’m kind of ashamed that I didn’t have this in the forefront of my mind to start, but here I go.

To set the stage, my current job is to complete “revamp” the website for Martin Luther College. The college is not just from where I graduated, but also resides in the town I grew up in and provides pastors, teachers and staff ministers for the synod I am (and have been) a part of. To put it simply, I have a vested interest in the institution.

One request has been to include a Bible passage on the homepage (the new one). While a worthy goal, and something I hope to incorporate in some fashion, it got my brain working for the past couple of months and I never really understood why it was working. My mind tends to do that.

Finally, it hit me. The talk was about a specific piece of “content” on the homepage, but it never went any farther than that. People were so caught up in the minute details that they has missed the forest in front of them. The idea was to incorporate the mission of the college (to train people for the public ministry) onto the homepage. But, it stopped right there and no one talked about it any further. From that point forward all of the talk was of portraying us as “just another college.”

However, the mission should not stop as lip-service on the homepage (for anyone) and should permeate all of the content on every page to portray what makes you, you. This goes for a college, for a business, for a government agency and for you individually (and for me as well). The content and the mission are so vital and intertwined that to try and separate the two is both foolhardy and dangerous.

Do I have the answers? No, of course not, but I’ve at least calmed that part of my mind for a little while. Maybe I can devote some of that to solving some other issues.

Which browsers do you support?

I came across this older blog post today and it got me to thinking about which browsers you, as a web developer at the university level, support. The author had some nice graphs in there which listed which browsers he supports and to what extent he does.

I’m writing mostly to get my own thoughts down at this moment in time. I’ve recently been hunched over my own college’s analytics to make some determinations on how our website redesign is going to commence. So, I’ll just list off some general categories and what I’m doing within those categories.

Internet Explorer

Luckily, we are dropping IE6 this time around because its usage has dropped below 1% of all total traffic. That is not the ONLY reason for dropping it because IE6 also needs some annoying hacks to get things to work, encourages me not to use modern web technologies without providing an alternative, and would increase development time. IE7 is still there, rearing its ugly head for the time being, but its share is dropping as well and I can only hope that it will disappear within the next couple of years so that we can drop that too.

IE7, IE8 and IE9 will all be supported and I’ll be testing all three. IE8 is currently the default browser on campus but I am hoping to push IE9 through as soon as it is released. I would love to drop all of the older versions, but they are going to be around for a LONG time because Windows XP will only be able to be updated to IE8. I would encourage anyone who is stuck on XP to use either Firefox or Chrome to make things much faster.

IE7/8 will not, however, receive all of the graphical “candy” that some other browsers will. This mainly is due to the lack of CSS3 support on those browsers, but everything will still be accessible and looks good.

IE9 is going to be targeted to be as compatible with all of the candy as possible just to see how far I can push things. It should be fun.

Firefox

I will be trying to aim for Firefox as one of the standards for browsers (along with Chrome). Firefox is available on Linux, Mac and Windows so that way I can provide a comparable experience on all three platforms (same with Chrome). Firefox 4 is going to be an interesting beast, if they ever launch it, and I’ll do my best to support that browser as well. Not too much to say here other than Firefox 3.5+ will work.

Chrome/Safari/Webkit

I’m lumping the three of these together even though they are not the same browser, but the first two share the same rendering engine (Webkit). Chrome is available on Linux, Mac and Windows and is the second of my standard testbeds. I actually do all of my coding with Webkit browsers in mind first and then make tweaks from there to accommodate any oddities that arise. It has worked well in the past.

I’ll also be making sure that Safari 4+ on the Mac works as needed, even thought Safari 5+ will be officially supported. Anything newer and I will probably end up pushing you to another browser (more than likely Firefox for the older machines).

Mobile

One of my goals is to provide some kind of mobile experience for iOS and Android devices. Sadly, Windows Phone 7 will probably not make the cut nor will the newer Blackberry phones. I’m not sure what I am going to do about the older Blackberry devices because there are a great many of them still in use on campus by faculty/staff/administration, but they provide such a minuscule amount of traffic to the current site.

I need to look at either providing a m.mlc-wels.edu or looking into media queries to handle different devices. This is a longer-term project, but one I am excited about.

Conclusion

Main thing is that I’m shipping with IE7+, Firefox 3.5+, Chome 5+ and Safari 4+ support for the website when it will originally ship. The pairing down of needed versions is something I will continually try and do to cut back on code needed to support different browser versions.

With the upcoming rolling-release development cycle for Firefox (which Chrome already does), I’m hoping that it will push web standards farther ahead by incorporating them when they are finished instead of waiting for the next big release so that you can have more bullet points in a press release.