The business case for SaaS (Software as a Service)

Intellect’s SaaS group has published recently a paper called “The business case for Software as a Service“. The paper lays out the technical and cost benefits of SaaS, together with checklists covering selection criteria, legal considerations and comparisons of SaaS applications to traditional in-house systems.

Cherryleaf made some minor contributions to this paper – so minor we didn’t think they merited our listing as contributors to this paper (a mistake in hindsight).

The report states, SaaS applications are generally easy to use and don’t require a great deal of training and online Help. So why is this?

In part, it’s because:

1. SaaS applications are newly developed applications. This means the developers have been able to build upon the recent developments in usability, when they’ve developed the application.

2. SaaS products typically deal with familiar business tasks, such as finance and sales prospecting. Where a SaaS application does try to explain new concepts or tasks (viz. Google Wave), users can still find they struggle to use the application.

3. SaaS applications can be fixed quickly and are usually subject to continuous improvement. Pilot programmes can be much smaller and quicker to conduct. SaaS applications can be measured and tested more easily, using Web Analytics. 

See also: Cherryleaf’s Developing Help for Web-based applications and SaaS services.

Hopefully, the checklists in the paper will serve as good guides and help you navigate the hype that currently surrounds SaaS and avoid any pitfalls.

Study shows people use search to learn as well as to find facts

Researchers at Penn State University are claiming people don’t just use Search Engines to find facts - mostly, they’re using them to learn.

Could this influence the way in which e-learning courseware is developed in the future?

The researchers sought to discover the cognitive processes underlying searching. They examined the search habits of 72 participants while conducting a total of 426 searching tasks.

They found that search engines are primarily used for fact checking users’ own internal knowledge, meaning that they are part of the learning process rather than simply a source for information. They also found that people’s learning styles can affect how they use search engines.

See Penn State Press Release. (Thanks BoingBoing.net)

Google Chrome OS Help – What will it be like?

Techcrunch has reported on an early glimpse of Google’s upcoming Operating System, Chrome OS. So, you are no doubt asking, will Chrome OS come with online Help? Will it be initiated in a similar way to Help in Windows or by some sort of new means?

From the screen shots on the Techcrunch site, it appears, yes,  there will be online Help. It will be initiated by clicking on a ? button in the top right hand corner. In short, it appears Google will be sticking to standard User Interface conventions. What’s unclear is whether the Help pages will be stored locally on the machine or “in the cloud”.

Is the future of education also the future of technical communication?

I stumbled across another great video of Michael Wesch talking about the issues facing educationalists.  Many of the problems they face are the same as those faced by people involved in producing user assistance.

The video is here

Dubbed “the explainer” by popular geek publication Wired because of his viral YouTube video that summarizes Web 2.0 in under five minutes, cultural anthropologist Michael Wesch brought his Web 2.0 wisdom to the University of Manitoba on June 17 (see video above).

During his presentation, the Kansas State University professor breaks down his attempts to integrate Facebook, Netvibes, Diigo, Google Apps, Jott, Twitter, and other emerging technologies to create an education portal of the future.

I particularly liked these slides:
 

He argued these beliefs were no longer correct,(apart from the first statement).





It’s possible the solutions for the future of education will also be relevant for the future of user assistance. Whether it answers all the questions remains to be seen.

The “Google or Death?” choice for technical authors

July’s edition of Science magazine includes a study that shows scientific researchers are now more inclined to get their information from the Web (specifically, “quick and dirty” searches in Google) than from specialist scientific resources.

If scientists are focusing on only a tiny bit of research – the bits served up by Google – what are typical users doing?  Also, what does this mean for organisations whose user documentation or online Help is not available on the Web?

In the abstract for Electronic Publication and the Narrowing of Science and Scholarship  James A. Evans (from the Department of Sociology, University of Chicago) states:

” I show that as more journal issues came online, the articles referenced tended to be more recent, fewer journals and articles were cited, and more of those citations were to fewer journals and articles. ”

 “Searching online is more efficient and following hyperlinks quickly puts researchers in touch with prevailing opinion, but this may accelerate consensus and narrow the range of findings and ideas built upon.”

Evans’s research backs up JD Bernal’s concept of scientific information having a “half-life” :  with researchers citing fewer journals in favour of more recent articles, papers peak (in use and citation) and then decline, regardless of their usefulness.

This also suggests another consideration when publishing static content, such as user documentation: how do you keep it fresh and found?

What should you include in your user documentation?

Technical authors are faced with limited time and resources, so they often are faced with the dilemma as to what to include and what to leave out of their user documentation. You may ask, if 80% read only 20% of the content, is there any value in documenting the rest?

Technical Authors are often great advocates of doing away with what doesn’t add value in documentation. However, in an article “How normal is normal?“, John Casti explains why extreme events like a killer hurricane occur far more often than we think.

So does this mean that your rare and unusual topics in documents do need to described, after all?

Casti discovered there was greater likelihood to extreme values than we’d expect from bell-shaped, normal distributions:

“Just as with the meltdown of the global financial system, the normal distribution dramatically underestimates the likelihood of unlikely events. Such events follow a different type of probability curve informally termed a “fat-tailed” distribution.”

Indeed, he states Pareto’s (80-20) principle is closely related to fat-tailed distributions:

“In a normal bookshop, there might be around 100,000 titles on the shelves of which 80 per cent don’t sell a single copy during the course of a month. Here the 80-20 Rule prevails. Now consider amazon.com, which has nearly four million titles available, or perhaps an online music site like iTunes, and ask how many of the titles they have available sell at least one copy in a month’s time. The answer is not 20 per cent or 50 per cent or even 80 per cent. It’s a staggering 98 per cent! Nearly every single title gets some action nearly every single month.”

There are also implications regarding information architecture and site navigation in Casti’s article:

“What’s needed, (Chris Anderson) he says, is for there to be a functioning way to drive demand for those niche products out near the end of tail. First you need a ‘head’, consisting of a relatively small number of hits. Then comes a tail of many niche volumes, the kind only the author, his mother and a small band of fanatics and connoisseurs could ever love. So there must be not only a huge inventory of products, but also a way to direct prospective customers from the head to the tail by means of suggestions, background profiles from past purchases and all the other things a place like amazon.com does to match readers with the books they really want.”

So does this mean that users navigate to the “niche” topics via the popular “head” topics? Do you need a “head topic” to bring the users in, with a filtering and suggested topics mechanism to direct them to niche topics, to service any customer’s wishes?

I’m not aware of any user assistance-related usability studies that have looked into this. Perhaps there is, as Casti claims, “a lot more going on out on the ‘fringe’ than we ever imagined”. As more content is published online, and more Web analytics-derived statistics becomes available to Publications Managers, then perhaps we’ll find out.