Chapter and Verse Blog

The rise of the mobile device has changed the way that people are accessing, viewing and interacting with websites. With a increasingly larger number of people accessing the web from a mobile device — around 28% of internet usage in the UK is from a smartphone (set to increase with the introduction of 4G) — there have been three different strategies emerge to ensure that those accessing a site ‘on the go’ are receiving as high-quality an experience as those using a computer.

These three options are:

1. Mobile Stylesheet (‘Responsive Design’)
2. Mobile Optimisation
3. Mobile Application (‘App’)

All three have pros and cons that need to be weighed up to choose the right solution for your site.

Mobile Stylesheet (‘Responsive Design’)

Responsive design applies a new stylesheet (CSS) over the top of the current site. The site then reacts to the size of the browser window the site is being viewed on to display only the most important information, avoiding having to zoom into a page to select the right option.

Advantages

• Quick to create
• Easy to implement
• Widely Used (Google’s preferred solution)
• Superior User Experience
• Single URL

Disadvantages

• Does not strip out large files (can cause longer loading times)
• Users can only complete transactions whilst connected to the web (Wi-Fi, 3G, 4G)
• Forced compromise — have to consider both responsive and full site in design process

A mobile stylesheet is recommended for those for whom accessibility and speed is a high priority. The single URL also helps strengthen SEO ratings, and also means that any content updated on the full site doesn’t then have to be replicated on a mobile site.

Mobile Optimisation

Mobile optimisation requires a different site of HTML templates to be built and styled. These will then be shown every time the site is accessed from a mobile browser. As it uses a different set of templates, the site also has its own URL — typically beginning with m. — and strips down the content to only the most necessary.

Advantages

• Ideal for activity based websites (Facebook uses it) and site with transactional functions
• Faster loading times
• Stores offline activity, and then uploads it next time a connection to the web is established

Disadvantages

• Intensive to implement, especially if customised on a per client basis
• Different URL – although you can redirect

Again, the optimisation option is recommended for those who place high value on accessibility. Due to its nature it is suited to sites where people may want to engage in more activity and transaction based functions, and the advantage of storing data and allowing people to work offline adds to this.

Mobile Application (‘App’)

A piece of software native to the mobile device, an app recreates the website in a format which users can then download onto their device. Apps come into their own when handling a large amount of transactional activity — such as banking, retail and blogging/social media.

Because of the variables from device to device it is always going to require more financial and resource investment to design, build and test an app than other solutions. The regular release of mobile operating system updates also makes ongoing maintenance an issue — an app will need regular updates in order to work on every software version.

Advantages

• Ideal for transaction based web services
• Doesn’t not require a connection to the web to do things
• Can provide an additional source of revenue
• Can store details to avoid having to re enter

Disadvantages

• Longer development times
• Requires extra resource for supporting and updating different versions
• Stores user details – may pose a security risk should the user lose their phone

An app is the recommended solution if the user needs to participate in a lot of transaction and interaction. The strong integration with the other functionality of the device means that users can take advantage of ‘tap to call’ functionality in the app, or storing information in the calendar.

Guest post by James Ash, Marketing Executive

Nearly two months after the Health and Social Care Bill was finally passed, we are just beginning to see the effects of some of its provisions on the NHS. The latest reforms are hardly as popular as the late Steve Jobs, but embracing his technology could have been the method of by which Andrew Lansley aimed to improve efficiency—rather than cutting important services.

Earlier this month, it was announced that the majority of clinicians at Bradford Teaching Hospitals NHS Foundation Trust will be given iPads in order to access its patients’ electronic records. A move such as this gives the clinicians instant access to vital information when they need it most. No longer will records need to be noted down and laboriously typed up; instead, doctors will be able to scann and save or edit them directly in the new software. Bradford seem to be leading the way as Brighton and Sussex University Hospitals NHS Trust, for example, have only just recently signed a deal with Alert Life Sciences Computing for a full Electronic Patient Record System.

Bradford’s new plan to access these records on-the-go may take some staff training and time to adapt to, but this will ultimately improve efficiency whilst retaining vital front-line staff. An important return on the investment is that clinicians will be able to spend more time helping patients, and less time doing paperwork. If you want to be cynical, you could say that embracing mobile technology, such as a tablet device, will allow a hospital to get more work and effective care from its staff for the same salary. Importantly, there is no need to increase the clinicians’ responsibilities—the technology simply helps them to do their jobs even better.

The same can be said for non-clinical staff, too. In the age of Web 2.0, more and more information is firstly managed digitally rather than physically, and secondly, online. Many NHS organisations have their own staff intranet to improve the sharing of information, but there are other alternatives out there. Membership management systems are available, as well as simple file storage spaces like Google Drive or Dropbox.

If the NHS is able to embrace these technologies that many of its staff members love using in their private lives, then their experience with efficiency and staff buy-in will improve. As with any organisation, for the NHS to develop, evolve and ultimately progress, it must be able to adapt to the changing uses and benefits of existing and emerging technologies.

Guest post by Chris Mounsey, Product Manager

Some of our readers may have heard of the exciting possibilities offered by HTML5, particularly in the area of native audio and video playback.

The idea is that we will no longer have to rely on plugins—such as Adobe Flash (currently the most widespread), Windows Media Player or Apple Quicktime—to be immersed in the wonderful world of online multimedia.

The problem is that, like many great ideas, the devil is in the details—or, in this case, the war between a number of different codecs.

Despite the fact that it is necessary for me to get a little technical in places, I hope that by the end of this (admittedly slightly lengthy) post, you will have a decent understanding of the problems facing HTML5 media playback.

Not only will this impress your friends (possibly), but it will also enable you to appreciate the good news nestling at the end of this small essay...

Background

Without trying to be too techie, playing video on the web depends on two main elements:

1. the codec under which the video file was compressed (or encoded), and
2. the container used to bring all of the elements (e.g. video and audio) together.

The benefits of the latter very much depend on the format of the former.

Benefits

The HTML5 <video> tag provides a standardised container for playing video codecs, and for providing various controls, e.g. play, pause, etc. And, of course, the audio tag does the same for sounds.

Up until now, publishers have had to use Flash containers—which, of course, require Adobe’s Flash plugin. Flash is near ubiquitous on modern computers but the inaccessibility of many Flash players—combined with some rather serious security bugs and the plugin’s large appetite for memory—has made it a less than ideal solution.

Not only this, but the code for embedding an HTML5 video is very simple, e.g. <video src="someclip.mp4" controls /> embeds your video and delivers standard controls.

Whereas embedding a Flash video requires something more like this:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0" width="400" height="300" id="movie" align=""><param name="movie" value="movie.swf""><embed src="movie.swf" quality="high" width="400" height="300" name="movie" align="" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer"></object>

Ugh.

Anyway, the HTML5 video tag is supported in all modern browsers—Safari, Firefox, Chrome, and IE9+—but, unfortunately, we have been largely unable to take advantage of this.

Why?

Because of a fight between browser vendors over the codecs.

Codecs

Over time, a number of video codecs have been developed for use on the web.

1. Ogg Theora is generally acknowledged to deliver pretty poor quality video, but it is open-source.
2. H.264 (or MP4) was developed by the MPEG LA organisation (which includes a number of hardware and software corporations, and which also developed MP3) and delivers very high-quality video with decent compression.
3. WebM is a Google-sponsored open source codec, the quality of which is rather better than Ogg.

Browsers

Broadly speaking, what has happened is this...

The Mozilla Foundation—which develops Firefox—is immensely committed to open source codebases and, as such, refused to adopt H.264; instead, they relied on Ogg Theora (in the early days) but their browsers will now also play WebM.

Apple enthusiastically embraced H.264—believing (rightly, in my opinion) that it delivered the best experience for its customers. Any videos you buy or rent from iTunes are delivered in H.264 format (as are most DVD movies for that matter). Further, since iOS devices (i.e. iPhones and iPads) do not have Flash, H.264 embedded in the <video> tag is the way of delivering web video to these devices.

Google Chrome supported both Ogg and H.264; however, a couple of years ago, the company stated that they would, in future, only support Ogg and WebM.

Until IE9, Microsoft's browsers simply did not support the <video> tag at all: IE9, however, supports all of the above formats.

In other words, in order to be able to deliver HTML5 video to all compatible browsers, you would have to encode your video at least twice—once as H.264 and once as WebM (or, possibly, Ogg)—upload both versions to your website, and link to both versions when embedding it in your page.

And you would still have to provide a Flash fallback to cater for older browsers.

HTML5 video and VerseOne CMS

That was the state of play at the time that the VerseOne Development team decided to develop the standard media player in VerseOne CMS (back around June 2011).

Believing that our customers—not usually technical—would not want to encode, upload and embed two video formats, we decided on the following course of action.

1. The media player would support embedded Flash videos (as before).
2. Users could also upload H.264 (or MP4) format files too. When these were embedded into the page, the system would detect what browser viewers were using.
   • Those using IE9, Chrome or Safari (on Mac or Windows) will be served the HTML5 <video> version. And, critically, those using iPhones and iPads are able to view the videos using the HTML5 <video> tag.
   • All other browsers would be provided with a Flash container.

This last catered (in theory) for mobile phones running Android or Windows since Adobe were working on—and had (sort of) delivered—a Flash plugin for mobile devices.

Unfortunately, this always ran pretty poorly on low-power mobiles and Adobe cancelled that project in January 2012.

(As a result, we will be revisiting our policy for these devices.)

The Good News

So, we currently have two browsers that support HTML5 video: IE9 and Safari (including Mobile Safari).

And, despite their announcement a couple of years ago, Google have not dropped support for H.264 in Chrome—nor do they show any sign of actually doing so.

So that leaves Firefox and the Mozilla Foundation. It's just one browser, but Firefox now is used by about 25% of web users—a significant number of people to leave out in the cold. (By comparison, IE now has around 35%, Chrome 20% and Safari of all flavours 12%.)

So, we welcome the news that the Mozilla Foundation is finally debating enabling support for H.264. Provided that Mozilla push ahead,  all of the major browsers will shortly support the H.264 codec.

We can then provide a reliable, standards-based recommendation to our customers as regards their video options, i.e. that they should encode their video as H.264 MP4 files (as they should currently do if they wish to deliver to iOS devices).

We can modify our media player to serve video via the HTML5 <video> tag, and support more platforms and more systems (whilst still providing the Flash fallback for less capable browsers).

Conclusion

This will remove a thoroughly thorny problem for us (and for our users) and allow the industry to move forward in providing an excellent, standardised and flexible delivery method for video on the web.

by Penny Everett, VerseOne Accessibility Specialist

Last week the free email newsletter (E-Access Bulletin) on access to digital technologies by people with disabilities* published the following:

"The UK's largest supermarket chain has said it is taking seriously the concerns raised about the inaccessibility of its new smartphone app, and is to work with the RNIB to improve the situation."

A visually impaired user found that when she went to order her shopping using Tesco's new app, the screen reader on her iPhone said the same thing for every item. This meant that the new app was totally inaccessible for her.

The initial response of Tesco's customer service was to admit that they knew the app was inaccessible, and they were unable to refer the visually impaired user to anyone else within the organisation.

Eventually, after E-Access Bulletin contacted them, Tesco said they were taking the concerns seriously and would need to build and test and amendments to the application, which would take time to complete.

The visually impaired user pointed out that a large organisation couldn't defend themselves by saying they did not have enough resources. She went on to say:

"Ultimately it is a question of leadership. The bottom line is I feel as if I've been treated less favourably for reasons of my disability. It doesn't feel like it's been taken seriously from the top down—it doesn't feel like the decision-maker has taken an inclusive approach, so why should customer service?"

Could the same be said in your organisation? Are the decision-makers aware of the implications of the Equality Act 2010 in relation to services such as websites or mobile phone applications?

*Read the full article by E-access Bulletin, which is published by Headstar: http://www.headstar.com/eablive/?p=672.