The iPad won't suck...
Posted by Jesse Rodgers on January 28, 2010 at 10:52 PM
…but it will burn many hours of your work day talking about this enlarged iPod/iPhone. Everywhere I turn people are either making fun of it, dismissing it (passionately), or ready to pull out the credit card and buy one. What really gets me are this new group (to me) of people that think you need a half inch, desktop powerful, physical keyboard using device or it just isn’t good enough.
Here’s my position on the iPad the day after:
- It is a consumption device.
- It won’t burn your bits when you try and watch a movie on it.
- I sat in the coffee shop with morning with email, a web browser, and tweet deck open for 3 hrs—didn’t need my laptop for that.
- It isn’t expensive for the early adopters that will buy version 1
- It is a product release that had features dropped that didn’t meet the quality control requirements (think iPhone before the 3G)
- Developing apps for it will likely be awesome
- If I were a student, I would be beyond excited to have all my text books on that (hey higher ed, how many will be offering this to first years loaded with all their text books, notes, slides, podcasts, etc?)
I will admit my bias and say that a big iPod touch that can tether with my iPhone is all I really wanted. A full OS would have been nice but I am really excited to see how developers take advantage of the HTML 5 stuff that Safari supports.
Will it be for everyone? No. But I would bet their $50 billion company is safe for now.
Feeling Cynical about Web Accessibility and Standards?
Posted by Jesse Rodgers on March 24, 2009 at 08:52 AM
Shortly after I started working in the Higher Education web space (2001) I came across the brilliant post by Jeffrey Zeldman on A List Apart that lead down all sorts of paths towards web standards and accessibility. I wasn’t alone. I think many web folks that were dealing with the internet bubble bursting were inspired by Zeldman’s call to arms to change things and many had the time to explore the possibilities. I did what I could in my position to influence the University of Waterloo web space and in 2004 we had a XHTML/CSS layout that was clean and accessible which was finally let loose on campus in early 2005.
Things changed on campus and I spent more time on usability testing and meeting with the few students that relied on adaptive technology. I wasn’t put off by the fact only two people might notice the enhancements as I knew UW was doing the right thing by fixing things. However, all of the applications students and staff rely upon were not going to be fixed or changed with even the course management system saying it was section 508 compliant but that version was even less usable than the main user interface. A problem that I have observed is that accessibility laws or regulations seem to force people under the covers in the HTML to make things work in screen readers (sometimes) but people ignored how usable the content or the application actually is.
It gets stranger by the day, developers demand unit tests they can meet to make the app accessible but there aren’t any… I don’t think. Laws and guidelines just compound the problem by giving people a false sense of compliance. In the case of learning environments most aren’t even all that usable but golly gee they are 508 compliant. It starts to drain hope.
Blame technology or developers?
A developer most certainly should make browser based apps (HTML/JavaScript/CSS apps) ‘professional’ grade by using semantic HTML, unobtrusive JavaScript, and sensible colour contrasts. That checks off a lot boxes in terms of Search Engine Optimization, re-usable code, dealing with rendering fun, and accessibility. There are different ideas of what it takes to make a web app or page accessible however, and I am not sure a developer should kill a load of time on certain things (that change with the project) like zoomable layouts—especially when browsers are implementing features that make that time wasted.
I am not sure that is inline with that Derek brings up in his post When is the right time for accessibility? as I think some (or a lot) of the things that are generally seen as making HTML as ‘accessible’ really should be the responsibility of a different team of developers (mainly those that make web browsers). I don’t disagree with the strategy of implementing accessibility later based on need and I think Derek’s post offers a bit of an olive branch to developers. You shouldn’t be expected to be all that accessible until you actually know that (a) people will use your product and (b) knowing how people will use your product.
What is my problem?
Honestly I don’t know. Call it a long winter, annoying problems repeating themselves for years, and new experts making the same mistakes.
I started this post sometime after I saw the small torrent of comments about a JavaScript framework which was summed up in Drew’s post The Cost of Accessibility. Drew is on that fence of innovation needs to take into account the reality of the web browser right now and I am not sure I agree.
At the same time I got into a few insane conversations about making the new job system for co-op on campus accessible and IE6 isn’t dead (like we had hoped) for an important 5% of our user base. Our development process makes it insanely difficult to spend time testing, fixing, and tweaking for accessibility (application is hiding behind a VPN and has a few other features that make it hard to access outside of our network). We use jQuery wisely, CSS, and HTML to the browser. AJAX is sprinkled in parts but nothing should depend on it. For a first version that isn’t really ready for user testing it has some good fundamentals but someone pulled the ‘yes but you are missing x’ and I just got deflated.
The problem, in my mind, goes back to the way people think about accessibility. The whole issue is an Art not a Science and certainly not engineering. Engineers have left us with this problem, with HTML, a stateless browser, and a crippled feature set that forces hacks, short cuts, etc. They are doing their part, slowly. Code artists like Derek Featherstone and Drew McLellan help spread the word and lower the barriers through simplified approaches and keeping the dialogue going.
HTML 5 gives me hope even if the Engineers aren’t too quick to drop it in our browsers! I am not really cynical ;)
Do you still launch a website? Really?
Posted by Jesse Rodgers on February 02, 2009 at 10:41 AM
There has been a bit of a discussion in the uwebd list about when is the right time to launch a higher ed web site. Thinking that launch is for new sites and re-launch is for re-branding and something you do with care, my first reaction was “why would you launch a new higher web site?” There is still a tendency in higher education to launch new designs on the campus community from time to time and I think, in modern web time, that is nuts.
Think of the people that use your web site, how they use it, how long they have been using, and who the redesign is for? Are they the same people? Flipping the switch on large changes (navigation, content, etc) is, at an informed guess level, expensive. Every day users are disrupted, new users don’t notice, and the occasional student user likely will think a refresh gets in the way and ask why does their online course environment still suck when you obviously have time to make changes on this site?
Major website overalls on public sites are a waste of resources with little ROI
Here is a generalized version of redesign process in higher ed:
- Someone says ‘we need a fresh look’ (usually fueled by marketing folks or recruitment ‘studies’)
- Committee is formed to look at ‘revamping’ the home page
- 6-24 months pass with around a dozen people on a committee discussing designs
- assumptions are based on personal preferences about what people want to see on the web
- Someone brings up implementing or changing the CMS, another committee is formed to look at that in parallel
- ‘three’ designs are chosen, CMS’s are investigated
- In a perfect world usability studies occur
- In the practical world, ‘previews’ are given to key politically sensitive areas on campus
- After some news releases and committee discussions at various levels some last minute ‘additions’ to menus or content are made for the flavour of the month
- page is launched
- users freak out, some love it, some hate it, all have to learn the new navigation to get on with what they have to do online
- more additions are required for political reasons
Have I gone through this? Yes, twice in seven years. I changed jobs just before my third time came around. In the 15 years or so of a web presence for most schools I would imagine they have done this an average of 4 times with the range between 3 and 8.
This cycle plays out just about everywhere in higher education and I think it largely because we ask each other what we did and copy/tweak/repeat. My guess is that the investment into this type of cycle is around:
- at least 3 FTE of ~45K salaries initially
- into the dozens of FTE for campus wide change
- if you buy a CMS ~100-500K plus more FTE
There is also a cost in disrupting people’s work flows (staff tend to have click patterns to things they need everyday, moving that causes cardiac conditions to worsen), committee time, and the other things that don’t get done.
What do you get back on that investment? Nothing. I don’t believe for one second that students decide to go to a particular higher education institution because their website looked cool, modern, etc. If high school students say that they are just telling you what you want to hear (teenagers do that? really?). Finding the information they need about what it is like to go to school there, programs, the city, the cost, etc would influence them but not a picture of a researcher up to their waste in sludge (grad students that care already know who that it and what they do).
Incremental changes by design and invest in content: clear, concise, informative
I am not saying you should never freshen up your website. You most certainly should but it should never require a re-launch unless you re-branding or something significant. Slight changes to navigation, content, colours, etc can occur without throwing it all out and starting fresh. Your previous design can’t be that bad (if it is, replace it by all means) but it is likely looking pre-web 2.0 or worse, way overboard on web 2.0ness. So clean it up, design change, but don’t do a demolition unless you absolutely have to.
Take your experience with other websites. If you have to be there to find something do you care what it looks like? No. You only care if you can’t find the information you need or if Google didn’t get you to a quality source on the first search. Students, staff, faculty, friends, etc all come to a higher education website not to hang out but they come to find out specific information. If they can find it and it is readable and your site isn’t some over designed 10px paradise with animated gifs they will have a positive experience.
I do believe things like HTML 5 and Microformats places more focus on the content then the look as the content becomes more portable. More and more people do not see your content in a look and feel that you have 100% control over (you never had 100% control) so why focus on that? Make it so your content is structured properly and relevant. Search engines will like you more as will the people using them.
Update: Smashing posted an Article on Feb 3rd on what being clear and effective in communication on the web means. Facebook offers a great example of continuous improvement in design without relaunching anything (the new design was launched once but changed many times) over a period of 5 years
Where design efforts should be focused: on the tools students use everyday
…and that is a whole other blog post. Fact is that higher education rarely spends time on the experience in web based applications that students, staff, faculty must use everyday. Why is that? I have some thoughts that I will post later ;)