Mobile Accessibility

There should be a web app for that!

Earlier today I tweeted

A bit disappointed to be finding that major media outlets like the BBC make apps instead of making website mobile browser compatible.

After that outburst I felt some explanation was called for. I also felt a campaign coming on. So here goes.

The Explanation

If you have an internet enabled smart phone, then you almost certainly have a mobile web browser. Mine’s an iPhone and the browser’s Safari. Android phones presumably come with a Chrome browser and I assume that Opera is quite popular on other platforms. All these browsers are based on the latest versions of their respective rendering engines and can do a pretty large subset of HTML5, CSS3, and JavaScript. State of the art in other words. This also means that they understand the CSS2 media type property and will therefore honour @media handheld to render a web page optimally for a small screen device.

But I hear you say, why is that important? Surely “there’s an app for that“! Well maybe there is, but consider this common scenario. You’re in your Twitter client on the mobile and you spot a link for an interesting news item on the BBC’s web site. What happens when you click the link? Does your Twitter client say “hey this guy’s got the BBC news app, we’ll use that to display this article”? No, it opens the browser either in the browser app or it uses the built-in browser to render the page in place.

And what gets rendered? The page as it would be rendered for a desktop or laptop machine, that’s what. A page designed to be displayed, in the case of the BBC, with a width of at least 976 pixels (I checked this dimension). A page for which its web designer has not considered accessibility on a screen with a of 480 pixels in landscape mode and only 320 pixels in upright mode.

Now the BBC news app is designed for the iPhone. It looks good and the navigation has been designed to work well on the smaller screen. It makes me wonder how many apps there are that are just customized browsers rather than accessible web sites designed to work well on hand held devices. I know that there are other reasons for having a customized app. Lack of flash on Apple devices forces content providers to provide an alternative. But even here, the widespread support of HTML5 video somewhat obviates even that need.

The Campaign: There Should be Webapp for That

I posit that Content providers should provide web sites that work well in normal browsers! Give us web apps that work better or provide more features by all means, but give us accessible access to the main website as well. (And let’s face it, that should include multimedia!) Let’s name and celebrate those that do and name and shame those that don’t.

Just to be fair, my own institution fails the test. It’s just about usable in landscape mode without zooming if you have very small fingers and very good eyesight. The same goes for the intranet, which we have control of, and the VLE which we don’t. Also, this blog, admittedly using a standard template, is not particularly accessible on the mobile.

With all that said here is the list of sites that I tried to get to from my Twitter client today that did and didn’t pass the accessibility test:

  • C- BBC News. Frankly unusable without zooming (and video and audio, which is flash, doesn’t work either). There is a free app that overcomes these issues but it’s not callable from another app.
  • A The Guardian. Excellent, recognizes your browser and redirects you automatically to No video or crosswords though! The USP for The Guardian app is off-line browsing and access to multimedia — but still not the crosswords!
  • D Scientific American. Looks like the standard web page and is unreadable in any orientation without zooming.
  • A+ YouTube … I know that there’s a standard app for YouTube, but with browser access, the web site redirects you automatically to the mobile version and videos work.
  • A+ uses @media to switch to a low resolution version as you’d expect!
  • A+ uses @media (and possibly JavaScript) to transparently switch to a low resolution version.
  • B Surprisingly, this is not optimized for viewing on the iPhone 3GS. Page does seem less cluttered than some sites surveyed, but small print is still too small. Perhaps it looks better on the higher resolution iPhone 4. Video is Quicktime MP4 so it works with Apple’s browser as you’d expect.
Perhaps you’d like to report your experiences in the comments or tweet a link with hashtag [#thereisawebappforthat](
**Does this matter?**
If you are throwing your hands up in the air in bemused horror at my pedantic uninformed ranting, let me tell you that *accessibility* is the **principle web design aim** that I drum into my students from year one. From now on, more and more of your audience will be accessing your site and web applications from mobile devices. They shouldn’t be forced to download an app, even a free app, to access your site or service.

My Social Networks: Optimal Sharing(?)

I’m thinking that I need to optimize my social network sharing strategy. Ideally, I’d like to reach the maximum number of people with the minimum effort and I think that I may have too many channels. There is also some duplication that I want to eliminate.

To achieve my aims, I think that I first need to analyze my sharing habits and who sees what I share. This might take several posts to untangle.

**Google Reader**
Let’s start with my primary sharing platform which is Google Reader (GReader).

Typically, I’ll read an article that I like and I’ll hit the “share” or the “share with comment” button. Items that I mark this way are immediately available in [Chris’s Shared Item]( page. They also automatically go to my 27 followers (most of whom I do not know!) and, I believe, to my Buzz network. In Buzz, I am following the same people I follow in GReader so I think that Buzz followers must automatically be people you follow in GReader. As I have only 7 followers in Buzz, but they appear in the list of my 27 GReader followers I assume that Buzz followers are a proper subset of my GReader followers.

In my feeds, I also get a group of articles from blogs that I follow using the Blogger FriendConnect widget. These folks seem to be in a completely separate social network and would have to follow this blog to see my posts. Unless they actually take the trouble to visit my [public Google profile]( and follow my public [GReader Atom sharing]( link, they are probably unaware that they’re part of my network and won’t see any promotion of their stuff that I might share via GReader.

(In fact it’s an interesting question, why, if Google wants to have a social network like Facebook, they have so many seemingly disconnected silos.)

From this analysis, it would seem that sharing via GReader is not particularly effective: I have 17 followers, 5 of whom I know and follow back.

That said, one presumes that people follow me on GReader because they want to read what I share. I’ve certainly picked up things earlier from my small GReader network than I would from Twitter. For example, this week’s Google Wave story broke from one of the people I’m following in GReader earlier than it did from the “official” media.

**Widening My Reach with FriendFeed**

Let’s say that sharing this way reaches the people, the inner circle perhaps, who I definitely would want to reach. What about the wider circle? Well, my GReader shared items get posted to [FriendFeed]( where I have 47 subscribers and 19 subscribees. (Friendfeed is one of my primary aggregators, so I will need to come back to it in a later post.) Assuming, without any detailed analysis, that my GReader followers and my Friendfeed subscribers are mutually exclusive, my primary sharing strategy reaches 64 people.
Can I change my sharing strategy to do better?

**Doing Better with Send To**

Short of leaving GReader itself, the only other sharing options I have are the “send to” destinations that GReader provides. In my case these are:

– Send to Friendfeed
– Send to Blog
– Send to Twitter
– Send to Facebook
– Send to Posterous
– Send to Delicious.

*Send to Friendfeed* is essentially redundant, as items that I share in GReader go to Friendfeed anyway and items shared exclusively with Friendfeed would not be shared with my GReader readers. With this insight, I should probably remove this option.
The others I will explore in later posts.
**To summarize this post**:
Sharing in GReader allows me to follow 23 key GReader and Buzz sharers, around 25 FriendConnect blogs, and of course the hundreds of RSS feeds that come into GReader every day. My sharing from this medium reaches 64 of my followers in both GReader and Friendfeed.
In the next post in this series, I’ll reflect on the *send to* options provided by GReader.
In the meantime dear reader, if you want to comment on your optimum sharing strategy, please use the comments.