Musings of a university web strategist


Constructing a Mobile Website

This summer we are finally developing the mobile version of the UVM main website. When this project was in the initial planning phase, I imagined our mobile site to be a CSS-modified version of the main UVM website that fit better on mobile devices. In researching the project not only did I discover that mobile sites serve a different functions than our traditional web presence, but I also found that I needed to rethink my traditional approaches to web development.  Not only should the aesthetics of a mobile website be different but the organization and actual content needed to be retooled. Granted, we are not creating new content for the mobile site, but much of the project has involved determining which, how and how much of our current web content is included in our mobile site. Enter the work of our predecessors.

Selecting a Strategy

It has been a distinct advantage to be a “late follower” on the mobile front. In perusing other university web sites, it’s easy to see who has mastered the concept of delivering true mobile content and who put a mobile window dressing on their traditional site. Early on I became interested in the iMobileU community and the Kurogo Mobile Framework. The Framework provides the opportunity to rapidly develop a “true” mobile site driven by various feeds (XML, RSS, KML) and static HTML pages. It turns out that much of our key content (news, directory, calendar) needed only minor modification to be plugged into the framework and other content (courses, campus tour) was easily converted to feeds to drive other modules.

Selecting which content to focus our mobile site on has been remarkably easy. We already manage the web presentation of most the most appropriate mobile content, the only areas that we have not been able to tap into yet are Dining Menus and Shuttle Schedules. I am hoping we can build strategic partnerships to include this data soon.

Give Them What They Want

Mobile users want to use your site to quickly find information on the go. They may be looking to call someone on campus, the location of an event, information about a course, or simply  the latest news. Information should be current, streamlined,  easy to read on a small screen and interconnected. Our challenge will be to expand on our mobile offerings while maintaining this simplicity and ease of use. Luckily, the Kurogo Framework offers a great jumping off point in just that type of effort.


ReadSpeaker: accessibility boost or another annoying gadget?

In the past week I was contacted by two separate individuals regarding an online text to speech application called ReadSpeaker. For those unfamiliar with the product, ReadSpeaker is a commercial application which claims to improve web accessibility for visitors with “low literacy and reading skills, limited English proficiency, dyslexia or related disabilities and mild visual impairment.” While I can’t disprove their claim of accessibility enhancement, nor will I try to, I can’t help but doubt that such visitors will experience an substantially improved web experience if we implemented it across our site.

ReadSpeaker has an impressive client list including the US Library of Congress, Amnesty International and Ohio State University, but I had difficulty finding their implementations online. Nevertheless, I felt compelled to take a more in-depth look at the product and its possible benefits.

Outside of their own online marketing efforts, I did not find much discussion about these kind of tools. I did find one discussion on the AIM (Accessibility in Mind) website which brought up a couple of interesting points, but I failed to find a more thorough discussion of the pros and cons of embedded web text-to-speech gadgets.

Getting to root of truly accessible content

I can’t help but balk at the notion that we can substantially improve accessibility by applying some automated web gadget to all our pages. Wouldn’t our efforts be better spent sending content writers to a seminar or buying them a good book on writing for the web and creating a better web experience for everyone? Looking at established guidelines for improving cognitive website accessibility on websites, the emphasis is on writing simply and concisely. In other words, improve the content itself rather than the delivery method. It turns out that we have no deficiency of erudite individuals in the academy. As a result, much of our web content is rife with complexities that often baffles those of us with a solid command of the local langauge in written or spoken form. As a non-native-speaker of several languages myself I can attest to the fact that simply written text is many, many times easier to understand than normal speed spoken text, especially when that text contains complex grammatical structures.

Accessibility guidelines do mention providing multi-modality for web content. At first glance, ReadSpeaker might fulfill such a role, but despite impressive recent improvements in text-to-speech technology, automated recordings fall far short of providing the nuances real speech that might help individuals with low literacy skills or English proficiency. If audio (or video) is truly intended to offer an alternative way to perceive content, doesn’t that mean that the content itself should be altered to suit the medium? Most of us don’t use the same level or type of language when we speak as when we write, nor should we.

In a world increasingly infused with assistive technologies, it is good to remember that technology simply can’t always cure all our problems, even on the web…

Not to knock ReadSpeaker completely, I did enjoy listening to news stories on the United Press International website site courtesy of the tool. In this case, I can see its benefits for multi-tasking folks like myself…