One particular point that will raise eyebrows is the continued advocacy of separate sites for mobile devices. There is an ongoing debate about the pros and cons of such an approach, brought to the fore by Neilsen’s post last February comparing Mobile Web 2009 with Desktop Web 1998, and concluding that a separate site is best. Many of us were not convinced, and as Henny Swan argued at the time:

It also hints at repeating the mistakes of desktop web design circa 1998 where we thought the answer was to design for one browser, use proprietary technology, build text only websites for disabled users…the list goes on. So let’s not make that same mistake and instead fast forward to one of the principles of good web design that dug us out of the dark hole of 1998: progressive enhancement.

Henny Swan: Progressive Enhancement for mobile

Henny described how a ‘one site fits all’ approach can be achieved using media queries, and it’s certainly a far more attractive solution than designing and maintaining separate sites.

But this all relates to websites in general, rather than specifically to Intranets, and I was interested to look closer at the suggestion of a separate mobile Intranet.

Intranet on the move?

Mobile Intranets – a unique case?

Intranets serve a very specific business purpose, and for a defined set of users, so the scope for delivering a useful mobile version is arguably better than with a public site:

1. You’ll have a far clearer idea of who would want to access a mobile version, and for what purpose.
2. You’ll also have a good idea of the devices being used to access the Intranet, assuming they are company-issue.
3. Finally, the potential advantages that a tailored mobile version could deliver to staff are tangible and might justify the time and effort required to build and maintain.

Neilsen points out a couple of potential problems – one being that most staff will already be in an office (and therefore presumably have desktop access) and the other being the possible lack of technical expertise at operating handheld devices. The first point is simply part of the business case – if you have a significant amount of staff needing Intranet access out of the office, then you have a compelling business case. The second point is a training issue – and in fact many companies might equally observe that some of their staff aren’t skilled enough to operate their desktop computer properly either. If the business case exists for such usage, either from a desktop or a mobile device, then training should be in place to support that. Neilsen also observes that devices are becoming far easier to use, reducing this risk.

Neilsen also points to a move towards “anytime, anyplace” access. This is certainly true of many large companies who are promoting flexible working options, and is likely to be a crucial element of any business case for creating a mobile-friendly Intranet.

Working on the move

So let’s assume we do want a separate mobile Intranet. What will it look like?

For a start, how do we access it? Will the user be required to log-in? That would seem sensible – an Intranet is, by its very nature, not for public consumption, and the risk of the employee’s mobile device being lost or stolen means that security must be considered paramount. Measures such as automatic time-outs might also be necessary, as well as preventing log-in details from being saved by the device.

Once logged in, what would we want to see? This is where a bit of research will prove invaluable. Find out what the key tasks are and make them easy to access. Accessing staff directories seems to be an obvious one, for example, as well as receiving any urgent news or alerts. Customisation would be ideal here, allowing people to compile a list of common tasks and links.

Opening documents

My organisation’s Intranet is probably fairly typical in that it has a massive amount of information available as downloads – PDFs, Word documents, Powerpoint presentations etc. Whilst some newer generation devices can handle these quite well, it’s important to remember that they can cause issues when downloading and opening (because of large file sizes, incompatible formats etc). As with any website, any key information should always be available as a web page as well as a download, and a company moving towards a mobile-friendly Intranet must keep this in mind.

Is your Intranet awash with downloads?

Apps

Neilsen mentions one team that developed a dedicated iPhone app, rather than building a separate site, to optimise the design for mobile users. This sounds like a perfect compromise, but only if you have full control over the devices that your staff are using, and only if those devices are advanced enough to support such apps. We’re not all lucky enough to get iPhones from our employers, so this may not be realistic for many, but the use of apps is nevertheless a good example of improving usability for mobile users.

Publishing from a distance?

As a web author for my organisation, I can see tremendous benefit in being able to not only access the Intranet on the move, but also to update the pages too. Mobile access to the publishing environment could be a killer feature, either via a browser-based interface or using a dedicated app. Again, the security risks of this are obvious, so measures would need to be in place (such as multiple log-ins or gated publishing requiring third-party approval). But the potential could be huge – especially in emergencies or out of office hours.

Standalone systems

One issue that may be harder to conquer is the fact that many Intranets are also a portal to numerous standalone systems and databases. Staff directories, forums, pay systems, HR processes, online forms, room bookings etc – these are very often delivered as separate products and making them available to a mobile device could be far trickier than simply re-formatting some webpages. Any business case would need to look at the practicalities of this and decide how crucial these additional systems are to an employee on the move.

Adaptability

One of the most convincing arguments against designing mobile-specific sites is that devices are constantly updating and advancing, and that there are very few universal standards to design to. Even if you know what devices your staff are using today, it could be that they are upgraded far sooner than your website will be. Any attempt to design a mobile-specific site would need to have sufficient adaptability to ensure that the next corporate upgrade of devices does not leave you with a useless mobile site. I’ve seen huge problems with companies designing Intranets to suit their dominant corporate browser version (for example, IE6) which then holds back any attempt to refresh that browser later on, in the fear that their sites will break (which, in the case of IE6-friendly sites, will almost certainly be the case).

Mobiles - evolving fast (image by True Blue Titan*)

Conclusion

For the reasons explored above, it’s more likely that a mobile Intranet will be a stripped-down version of its desktop self for reasons of practicality, rather than usability, although there is an argument for offering a tailored design to streamline the most common tasks undertaken by staff on the move. This is unlikely to be successful without significant investment of time and expertise, however, so a strong business case is crucial to put focus on what is to be achieved.

Failing that, designing your Intranet with mobile-specific styles, or at least adhering to common best practice and web standards, will help to ensure that anyone logging on whilst away from the desk will still get to what they want.

* Phone Evolution image is a derivative of a photograph by True Blue Titan, used under the Creative Commons licence

Browser sizes as an overlay

What this shows is that, for example:

• only 1% of users have to scroll to see all of the main banner on my site
• 80% can see the Latest News box in its entirety, without scrolling
• Half of users have to scroll to read the Good Causes section

That’s all very interesting, and Google cites a good example where a call to action on a page (in their case, a “download” button) was below the fold for 10% of users. However, the logic gets a little fuzzier when they state:

Using this visualization, Bruno confirmed that about 10% of users couldn’t see the download button without scrolling, and thus never noticed it.

Introducing Google Browser Size – Google Code Blog

Spot the error – the assumption that users will not notice things below the fold.

Thinking beyond the fold

This assumption doesn’t ring true with my experience of user testing, where people will almost always scroll if it is clear that more information exists below the fold. And I’m not alone in observing this. A recent article over at cxpartners talks about the myth of the page fold, describing how user testing revealed that users don’t actually mind scrolling:

People tell us that they don’t mind scrolling and the behaviour we see in user testing backs that up. We see that people are more than comfortable scrolling long, long pages to find what they are looking for. A quick snoop around the web will show you successful brands that are not worrying about the fold either.

The Myth of the page fold – cxpartners.co.uk

This is a really good example of how user testing can be used to prove (or disprove) dominant assumptions about user behaviour.

And there’s a wider issue here – that of separating content from presentation. We shouldn’t be wasting our time worrying about the minutiae of how web pages look, especially given that the rise of mobile browsing makes this pretty hard to do anyway. When you add user preferences such as increased text size, this becomes even harder, if not impossible, to truly account for.

With that said, I really like Google Browser Size, and think that what it does do well is remind us that there are so many variations out there that we simply can’t account for them all. By all means use it to identify a few quick wins (for example, an important call to action should be at the top anyway), but don’t get too hung up on making your site fit every shape and size of browser.

Horizontal scroll

It’s probably worth pointing out that when we say that users don’t mind scrolling, we usually just mean vertical scrolling (up and down). Horizontal scrolling is a different matter entirely, and in my experience users hate to have to scroll horizontally. There are some nice examples of how you might get away with it if part of the design (see Design Meltdown’s gallery of horizontal scrollers), but unintentional horizontal scrolling can drive users away in no time at all. Avoid inflicting this upon your users by designing to the lowest common width of your intended users, or (far better) implement a fluid-width design.

Accessify Forum

Today the Accessify Forum celebrates its sixth birthday. In that time we’ve seen over 60,000 posts, and membership currently stands at about 9,000. For a forum dedicated to web accessibility, I think that’s pretty good.

Perhaps the most endearing aspect of the forum is the wonderful debates we’ve seen over the years. As I wrote back in March, web accessibility relies upon discussion and debate to develop. There are often blurred lines between right and wrong, and real-world accessibility is far from binary. Only through honest debate can we arrive at anything close to the best answer to the questions that the subject poses.

Work is ongoing to improve the forum, with many changes already applied to improve the overall usability of the site. For me, though, one key thing which would make the forum better would be the presence of more users for whom the issues of web accessibility have a direct impact. We do have a small number of blind and visually impaired members, as well as members with a variety of other conditions, all of whom add tremendous value to the discussions and often report issues which surprise even the experts. But I often feel that we’re too heavily reliant on these few individuals for their opinions and experiences, and having a broader range of members would improve the discussions no end.

‘Real world’ experience

Accessibility testers know the immense value of getting feedback from a ‘real person’ facing ‘real problems’ with a website (as opposed to obsessing over code validation and automated testing, which can only tell you part of the story and which most decision makers don’t understand anyway). I myself have seen the horror on the faces of individuals when shown video of a user struggling with their site. The evidence that their website is discriminating against real people, due solely to the barriers which their website has put up, becomes undeniable. It’s a profound thing to watch, by all accounts epiphanous, and one which changes the way people think about the web and everyone’s right to access information.

As a moderator, I would naturally invite and encourage everyone to head over to Accessify Forum and sign up. But more urgently, I would ask anyone who feels comfortable to talk about their disabilities to head over there, perhaps offer a site critique or two, and bestow upon people the immeasurable value of your own experience. Perhaps you will provide the next epiphany to make the web that little bit more inclusive.

Happy Birthday Accessify Forum.

• WCAG guidelines are a good start, but don’t cover everything. User testing is vital to fill in the gaps.
• Many of our assumptions about how people use Assistive Technologies can be very wrong.
• It can be hard to locate disabled users for testing – Mark reports that whilst they have plenty of blind users willing to participate, users with other conditions can be less easy to track down. Users with conditions such as autism and Asperger’s syndrome, for example.
• Colleges and universities can provide good links to willing participants. Charities also, although they won’t give you contact details – they usually just put out notices in their publications, which can slow the process significantly.
• Many users do not use Assistive Technologies, per se, but still do things to make content more accessible to themselves. Some dyslexic users, for example, will cut and paste text into word processing software in order to modify the size, font etc.

[Edit] The presentation is now available on Slideshare.

Of the various questions that arose during the session, perhaps the most contentious was in relation to accessibility statements. What are they for and what should they include? One clear message is that they should not be too technical – most disabled users are unfamiliar with WCAG conformance or other technical terms. There is a conflict here, though, with WCAG 2.0′s suggestion of a technical statement of conformance in the form of a Conformance Claim. There’s also a clear difference between accessibility statements and the wider purpose of a Help section. I’ll be looking at this issue in greater depth soon, so stay tuned.

Another issue related to customisation of websites – specifically, the inclusion of widgets to resize text, change colour contrast etc. I’m personally against these in principle, as there is a significant lack of convention in how such functions are provided across different websites. Also, anyone needing larger text, for example, would be far better off learning how to increase the size themselves, using their browser. A final point, which Mark had observed himself during user testing, was that many users will not activate these functions even when they might benefit from them, simply because they do not want to bring attention to their condition in a public environment or at work.

Thanks again to Mark, Marzena and everyone else at User Vision for a very enjoyable event, not to mention the greatly appreciated breakfast and coffee, making the early start well worth it!

Future breakfast events

User Vision hope to put on more breakfast events in future, so head over to their Events section for more info (there’s even a handy RSS feed available).