Usability Notes - by Chris Baker

Wireframes

A wireframe is a simple visual model of a website (or CD-ROM if you want!), It is produced by a very quick and cheap method so that it can be used early in a project, for example during requirements analysis It might be made using PowerPoint, Visio, or hand-drawn pages, or in HTML, Flash or a specialized wireframe software. Wireframes are excellent for discussions within the project team, and can also be used for paper prototyping and simple usability tests. They provide a model of the website that is easier to understand than, say, a flowchart or long descriptive document. Long Documents Send People To Sleep, but even a primitive model of the website can be excellent in flushing out misunderstandings and "unknown unknowns".

I often find that I need to explain why a wireframe makes no attempt at showing the visual design (colours, fonts, graphics). The point is that these will be agreed and added later (probably after some effort and cost, which we are trying to avoid while we hammer out the early ideas and find what is going to work). For the same reason, a wireframe often does not contain much actual website copy. The point of the wireframe is to focus on what key components should be on every page and how the pages should link together (it is often possible to get the wireframe to demonstrate the latter - for example, by hyperlinks between the pages).

It is worth thinking out exactly what you want to do with the wireframe (e.g. is it merely for the project team, or will it be used for usability testing and if so how?). Being able to explain how this very primitive-looking model fits into the design process is very helpful to reassure stakeholders that the final site will not look this bland and primitive!

As I mentioned, there are a number of tools that can be used. Since the idea is to produce something quickly and cheaply that can be easily changed when it has (helpfully) uncovered misunderstandings or problems, I think the key factor is to choose a tool you can use easily. In an interesting article HTML Wireframes and Prototypes: All Gain and No Pain, Julie Stanford makes a case for making a wireframe in HTML (she uses Dreamweaver). Comments on her article give opposing points of view about the pros and cons of using HTML - helpful stuff if you are trying to decide whether to give the HTML approach a try.  If you do want to give it a try, Julie gives a primer on how to prepare a wireframe using Dreamweaver (making a lot of use of HTML tables). As I say, I think the important thing is for someone close to the requirements analysis to be able to build it quickly and easily. So probably the  choice is as much dictated by tool familiarity as by anything else. Using HTML means that you have the option of actually using some of the wireframe code to make the real site - the pros and cons of this get an airing in the comments on Julie's article.

To show that even a very humble wireframe can be useful, check out this example in PowerPoint:

Download Wireframes.ppt

This wireframe is for a (fictitious) publisher’s website – AAD Publishing Limited, publishers of Arts, Architecture and Design books. For demonstration purposes (or because AAD is only a very small  publisher requiring only a simple site) it contains only a few pages. But hyperlinks allow you to move between them in a way that gives a reasonable impression of how the site will work. I would use a wireframe like this for early discussions in the project team, and perhaps for some quick informal usability tests on any sentient human being who doesn't run away too fast (e.g. co-workers, neighbours, spouse). Even a wireframe as primitive as this can be worthwhile to throw up questions about scope, navigation and usability such as:

• •What have the project team assumed the purpose of the site is? And are they right? What have they missed?
• •How can we keep the home page interesting? It may need frequent updating – who will do this and will it be sufficiently easy for them to load copy onto the site?
• •Should the 3 categories of Art, Architecture and Design (as shown in teh current wireframe) be further subdivided?
• •Decisions will be needed about the order in which things appear on the page – e.g. for the books is it latest publications first? Bestsellers first?
• •There is no way of searching the site – is that an omission?
• •How can a customer buy a book he or she sees on the site? Is there an order form to post to us? Do we want to offer online purchase (there is currently no shopping cart in the design – is that an omission)?. Including a shopping cart would of course introduce various issues about how to take and fulfill online orders (potentially a problem for a small publisher). Do we prefer simply to be an affiliate, (e.g. of Amazon), until it is clear how much business can be generated?

Not a bad crop of questions to get out of the half-hour or so it took me to make the wireframe.

Teleconference tools

I have come across some good tools and tips for teleconferences recently and this post collects up what I've found useful.

Dates times and telephones

The first problem of teleconferencing is of course to arrange the date and time. Many teleconferences are international affairs, introducing complications of different time zones and public holidays to the usual difficulties of arranging a meeting.

• To work out time zones, I find timeanddate.com's world clock very useful. You can set up a "personal world clock" - a web page that lists the  current time in the cities where you and your  contractors and collaborators work (London,  Washington DC and  New Delhi, say). There is also a useful  meeting planner - which tabulates the times to make it easier to see any overlaps in standard office hours. Tools like these are particularly useful in the spring and autumn when some countries change their clock and some don't - making it easy for someone to get the wrong time for the call.
• Proposing a call (or scheduling other work) during someone's public holidays is rarely popular. Bank-holidays.com have a site that lists all legal public and bank holidays worldwide. You can see data for this year for free, dates for other years for a fee. The site design is a bit over-busy with adverts, but worth what you pay to use it, eh?

I have recently been looking at a "web 2.0" tool that could be helpful: ScheduleOnce allows you to suggest meeting times, and post them to your colleagues in the form of a link to a web page. Colleagues can annotate these times as best, good or impossible, and can suggest alternatives. Everyone see the proposed times as if in their own time zone - so my 3pm suggestion appears to me as 3pm in London, but 10 am to my colleague in Washington DC. When everyone has posted their availabilities, ScheduleOnce  tabulates the results, making it easier to see who could do which date and time. The basic service (which is in beta) is currently free of charge.

I have taken to using Skype to conduct the teleconference itself, and found it good, bar some occasional technical hitches. To use this voice-over-internet service, I have needed to download Skype's (free-of-charge) software and buy a microphone/headphones headset I can plug into my PC. But the calls are much cheaper than when I used my standard telephone and telephone provider. Calls could be free of charge if I was calling other Skype users, rather than calling conventional telephone numbers. The headset is also an advantage in itself - it becomes tiring to hold a conventional telephone receiver during a long call, especially if one is also trying to take notes or the teleconference involves jointly viewing and discussing web pages or other on-screen stuff.

Conference call etiquette

So now the data and time are set up and we have telephony, how to manage the call itself? Teleconferences are a kind of meeting, and meetings have been with us so long that there is plenty of advice about. I recently came across some  good podcasts on this subject from Manager Tools:
Effective teleconferencing Part 1 of 2
Effective teleconferencing Part 2 of 2
Manager Tools also has a good podcast on taking notes.
(You can follow the links above to these podcasts or download all the  Manager Tools podcasts via the iTunes store).

To summarize some key points (from Manager Tools and elsewhere). As usual a lot of this sounds obvious, and is only worth repeating because people so often do it wrong?

1. Obvious but essential - make sure everyone knows who will call who, which numbers to call etc.. If possible have a backup way of contacting people if there are technical problems or last-minute delays.
   
2. Don't rely on agendas or other materials being received instantly by email (or any other means)- try to email them in good time so that everyone has all the papers they need.
3. A teleconference is a meeting and deserves proper attention. Insofar as you have the influence, influence people to concentrate on the call and not to fiddle with phones, Blackberries, papers, email or other distractions. Nor should they be trying to drive a car!
4. Good charing is even more important than in face-to-face meetings - quiet people are easily overlooked (or they may have put the call on mute and be doing their email...). The chair should specifically call on them to comment if they don't speak up, and ask for any further contributions before moving onto the next agenda item. Summarizing and recapitulating the outcome of each point reached can be crucial - especially if some participants may be handicapped by poor phone lines, doing business in a second language, not knowing all the jargon etc. Avoid groups of people (e.g. those in one office around a speakerphone)  devolving into a private sub-meeting. This can happen either accidentally (by using visual aids the others can't see; all speaking at once etc.), or deliberately (for example by having whispered side conversations or passing notes). 
5. Allow longer to get through the business than you would in a face-to-face meeting: people have to talk more to overcome the lack of visual interaction. There may be problems with poor quality phone lines or difficulty in understanding accents. There may be more need to summarize and recap the decisions reached to ensure everyone has understood. Manager Tools suggest allowing 15 mins for every substantive item on the agenda (as oppose to say 10 mins if it were a face to face meeting). No one will mind if items actually take less time than this! There is a cultural oddity here - I think it is changing, but I have met people who regard an hour-long teleconference as an unreasonably long call, but an hour-long face-to-face meeting as perfectly standard. Actually a teleconference ought to be saving time, as some of the parties will have avoided having to travel.
6. Make sure there are good notes, which are circulated promptly - ideally the note-taker should not also be charing the call or contributing a lot to the discussion. (that may be too much to do at once). Notes should feature all the decisions taken, and detail all the actions decided upon. They should be circulated as soon as practical after the call so that there is an opportunity to rectify any mistakes or misunderstandings. This is an especially important courtesty to participants who may have found the call difficult to follow (bad phone lines or other audibility problems, second language, jargon problems, masses of  detail) etc.

The NLM DTD

Yesterday I was at the ALPSP Technology Update meeting "A Standard XML Document Format: the case for the adoption of NLM DTD". I gave a talk entitled "NLM DTD in Archiving - a case study. It is the story of how we used the NLM DTD to produce the IMechE Proceedings Archive : You can download my PowerPoint presentation by clicking this link:
"Download NLM_DTD_archiving_IMechEProceedingsArchive2007.ppt .

All the speaker presentations are also available for download from the ALPSP website
It was an interesting meeting with a lively discussion, so I thought I would write up some notes.

By the way, I shall assume that readers have a reasonable idea what a DTD is, and only give a brief definition here (from the W3C tutorial on DTDs,) .

The purpose of a DTD (Document Type Definition) is to define the legal building blocks of an XML document. It defines the document structure with a list of legal elements and attributes.

Meanwhile, if you are a bit hazy on what XML is or how it differs from HTML or SGML, you are welcome to try my short paper, intended for publishers, called "What the Hell is XML?"
Download what_the_hell_is_xml.pdf

So now back to yesterday. I will try to pick out the themes that I found interesting. That will mean dodging about chronologically between what the speakers said, the panel discussion and discussions over lunch. Impediments such as lunch plates and my own pre- and post-speech hormone levels mean that my notes were not up to much - I welcome any corrections and additions!

Theme 1 - one reason why the NLM DTD is good

Bruce Rosenblum, (Inera, and one of the authors of the DTD), kicked off with a description of how it came to be. The first of my themes soon emerged: one of the reasons the DTD is such a success is that it was designed by reviewing publishers' DTDs that were available at the time. Therefore it incorporated and built on what publishers actually were doing and wanted to do, rather than some theoretical model of what they should do. The authors examined a wide range of journals of many subjects and so have been able to allow for many of the practical issues that  journals publishers need to deal with . Also, while it is "the NLM DTD" it is suitable for subject matter very different from the National Library of Medicine's interests. Therefore, as Geoff Builder (CrossRef) said in his Chair's remarks, there is a lot of publishing wisdom in the DTD. When Eamonn Neylon (British Standards Institute) came to speak, he commented that the NLM DTD had followed the ideal route to being a standard - it had built on best practice, then been adopted widely by its community, before going down the route to having a NISO number.

Theme 2 - whether and when to adapt it

Given the "publishing wisdom" already included, the second theme to emerge was whether and how publishers should modify the DTD. Geoff Builder went so far as to say that if you needed to modify the DTD, you should look at your methods (as you might well be doing something wrong).  Bruce's partially disagreed: his talk included material on how the DTD had been made easy to modify or extend if necessary - and some examples of people producing extensions for it . My own contribution was that I've found  it important to avoid uncontrolled tinkering with DTDs - sometimes  people are very tempted just to "fix" the DTD as a  workaround to whatever problem they have on their desk today. During the IMechE Archive project, we did sometimes encounter unexpected oddities in the content we were processing. Each time I found that I could go back to the NLM DTD and its excellent documentation and find a way (or several  possible ways) in which the problem could be accommodated WITHOUT bending the DTD out of shape. The DTD is beautifully built to anticipate these kinds of problems (in my experience). One example is the <custom-meta> element, which enables you to  include your own, self-defined metadata into the DTD if you need to. Obviously you then need to document or take other steps to ensure that you adopt the same approach next time the problem is encountered, and know what you have done. But look to see what the DTD can already do before wading in and editing it.

Theme 3 - QA

A third theme that emerged was that of QA. You should certainly check that your content  will "parse" (that is, check that it obeys all the rules in the DTD), but it would be  a misconception to believe that this in itself means that all is well. This is because parsing makes a very specific set of checks - it is possible to write a document that parses perfectly, but is full of errors that the DTD cannot catch. Geoff Builder had a (rather shocking)  anecdote about how some people behaved as if parsing the data was a game - he worked with a supplier whose data didn't parse. When one day it did, he was suspicious and inspected the XML . This revealed the reason - the supplier had faked things by "commenting out" the bits of the document that wouldn't parse.

The idea that the DTD is not a complete validation tool is somewhat counter-intuitive. During the panel discussion I was looking for an analogy that might be helpful, but it was not until later that  thought of one. Here it is. When considering contracting a company to do important work, you might undertake some due diligence checks. For example, you might find out whether the company has any legal cases pending, and you might do a Dun and Bradstreet credit check.  These checks are of course useful - you'd think carefully before getting involved with a company that had big money or legal problems - but they are not likely to be all that you would want to know. For example, you'd surely want to know about other things, including the competence and capacity of the company to do the work.

Eamonn Neylon's talk covered some of the automated tools available to supplement a check for parsing - he suggested that  publishers should used rule-based QA where possible, and employ tools such as these to do it. Of course some manual inspection would always have its place too (automated tools are good at fixing predictable errors - people are good at finding unexpected errors)

Theme 4 - how should publishers adopt it?

A fourth theme, emerging in the panel discussion, was how should publishers adopt the NLM DTD (and possibly XML too if they have not done so already).  Adopting the NLM DTD, rather than making your own was of course already a big time and money saver. Both Bruce Rosenblum and Bill Kasdorf (Apex CoVantage) had experience that trying to get authors to provide tagged content (e.g. by giving them MS Word templates) was an uncertain venture - success in getting the authors to comply was by no means guaranteed, even in the case of a very prestigious journal or when working with very technophilic authors. The panel agreed that talking to your suppliers - especially the typesetters - was a good first step. Typesetters might be able to offer XML at no or little additional page cost and were likely to be willing to spend time with a publisher to discuss and explain (in the interests of winning business, of course). Both Geoff Builder and Eamonn Neylon sounded a note of caution though - a lot of XML work these days is with databases and therefore many an XML expert knows about databases and may be unfamiliar with the different issues of working with text content. So check the expert's expertise. What kind of workers did a publisher need? We felt that a publisher didn't necessarily need a mega-technical person. It could be very helpful to have an enthusiastic and interested project manager or project leader to make sure things happen [indeed, this is the role I took in the IMechE Archive project, while it was clear that Professional Engineering Publishing staff should deal with ongoing XML issues, so as not to be permanently reliant on me for expertise].   Publishers obviously needed to make sure they understood the new part of their business, however. Mick Spencer (Professional Engineering Publishing), commented that he had been on exactly this journey - learning about XML largely by talking and working with suppliers  - and had found it possible to learn perfectly adequately in this way.

Nick Evans (ALPSP) asked what publishers should do with their legacy PDFs. The panel discussion drifted away from part of this - later I spoke to Nick and suggested that you could certainly use the NLM DTD to capture XML metadata for these older papers - you don't necessarily have to convert the full text into XML. In a way this was a bit like the position in my project with the IMechE Proceedings Archive - except that we started with paper, not even with PDF!

Tunneling under Disney

In an interesting closing set of closing remarks, Geoff Builder quoted  Yuri Rubinsky  (a well-known promoter of SGML, the predecessor to XML) as likening publishing to the "tunnels under Disneyland" (i.e. the support infrastructure, invisible to the user, which makes the whole enterprise work  ). I believe Geoff was quoting this passage:

"I saw a revealing photograph of Disneyland in a United Airlines magazine, a shot of Mickey Mouse -- who is enormous in real life -- talking to a street cleaning person in a very tall, very wide tunnel underneath Disney World. A complex network of tunnels is what lets the Peaceful Kingdom function as well as it does and why you never see Mickey or Minnie or Goofy or Donald ducking into a washroom or eating lunch. The analogy [with the systems needed by publishers and libraries] is pretty rich. The architecture of the tunnels is the same no matter what public facility they support. The services they provide are constant, and silent. They keep complications -- like transport vehicles and emergency personnel -- out of the visitors' way, while providing an underpinning to the whole operation.

On one level, publishing is like those tunnels, making available the attractions above ground with subterranean structures. But for me the most interesting aspects of the Disneyland tunnels are their dimensions and their materials and their layout. Why? Because they are completely consistent wherever they go. They're the same beneath a pirate ship and beneath a hotdog stand, providing the consistent system services below which support and enable the mad variety of extravaganza above."

Yuri Rubinsky, Electronic Texts The Day After Tomorrow

Geoff's point (I think) - is that publishers (as opposed to XML fans) need only to dive into the tunnels of XML DTDs, Near & Far diagrams, Schemas et. etc. only so far - to keep their Magic Kingdoms running well.

Er Geoff - does that make me Mickey Mouse :-) ?

[Note added 12 December 07: Geoff is planning another foray into the tunnels under Disneyland in the ALPSP update series - the details that the  ALPSP have circulated so far are:

ALPSP Half Day Technology Update: All Your Documents Belong to Us.  The Next Wave in Publishing Infrastructure

Date: Early July

Venue: To be confirmed

Chair: Geoff Bilder, CrossRef

In this Technology Update you will hear how as publishers consider revamping their online publishing infrastructures, they are increasingly looking to new technologies like XML databases, RDF triple stores and XML-aware full text indexing engines.

ALPSP will put more details on their website in 2008 - meanwhile they ssuggest that anyone interested either contacts them (info@alpsp.org) or monitors the ALPSP events guide for updates.]

Automated XML find and replacement

I recently needed to make a change to a lot of XML files. I found that HomeSite from Macromedia was good for this - it has  "extended search" and "extended replace" functions (both are on the Search menu). I used this to do a global find and replace on my files. Another useful aspect of this is that the software can do a global find and replace on files that are in a hierarchy of folders. If there is some organization you want to preserve, this saves you having to copy them all into one folder for editing and then re-create the right organization.

Gliffy - More online charting tools

Gliffy is an online charting tool that can make flowcharts, user interface mockups and many other kinds of diagram. It has many of the features of Visio or Smartdraw, but a limited account is available free (need to give an email address to register) , and a "premium account" is available currently at US$ 20 p.a. By comparison,  Visio costs about £140.

Diagrams can be exported as JPG, PNG or SVG, printed, shared online with collaborators, or made public for insertion into web pages or blogs - click this link to see a Gliffy diagram linked to this page That feature set is really all that a lot of users are going to need.

I think I would still prefer bubbl.us for working quickly (e.g. in a meeting), but Gliffy has a wider range of features that might be just what you need back at your desk - or indeed back at any desk that has an Internet-enabled computer.

The inevitable caveat: if you use Gliffy, you are of course transferring the issues of security and availability to Gliffy (as with any  web based tool).  You will need to make your own decision as to whether your drawings are being kept  securely enough for you, and how much trouble you would be in if the service became unavailable with your work on it.

Bubbl.us

Bubbl.us is a useful online tool that lets you quickly draw many kinds of charts for brainstorming and other purposes.

A project manager colleague of mine was recently speculating that the best project management tool of all was a flip chart and some sticky notes - the sticky notes (eg. Post-It notes) are labelled and stuck onto the paper, moved around and argued over and there may or may not be various arrows and lines to connect them. It is a quick way of doing various kinds of diagram that are useful for brainstorming - e.g. what is in or out of scope, how a website ought to be organised, what main tasks are in a project, what the steps are in a process, or many other options. The disadvantage comes in trying to read people's scrawled notes later (" 'don't sell plastic clothes' - huh?" ). And, although one quickly learns to photocopy the flip chart at the first opportunity, there is something uniquely dismaying about the sticky notes blowing away like autumn leaves if you carry the chart through a draft, or when unroll it back at the office. Scrabbling around after the strayed notes, you are left wondering which important part of the project is at risk of being forgotten.

"Bubbl.us " offers a neat online alternative - you can type onto bubbles that you can link up in various ways and move about as you wish. If you have created an account (currently free, requires that you give an email address) you can save your resulting drawings, and share then with colleagues who also have accounts. Printing out is currently a bit basic, but workable (you can print ot paper, and  could always print out as a PDF to have a permanent electronic version).

I find I like it a lot:   beyond a certain point you might wish to be using Visio or SmartDraw to produce a more finished looking chart (e.g. with a choice of shapes and colours), but either of these charting tools are not nice to use in quick-fire circumstances where you need to get ideas down fast, and are sufficiently expensive that you will readily find colleagues who don't have them.

The usual caveats of using a free online service apply: firstly, you have of course published your drawing somewhere, and although access to it is by username and password, there may not be much redress if someone sees it who shouldn't. And secondly, there may be little recourse if the site, and your precious diagram are unavailble one day. So you may not want to put your top secret plans there, or documetns that you care about keeping. However, most of the diagrams I find myself drawing are so cryptic and temporary that these risks are acceptable.

[Note added 20 March]: If you want to make more complex charts, but want a free/cheap web-based tool rather than investing in Visio or SmartDraw, you may be interested in my review of Gliffy

Colour analyzer tool

Juicy Studio have a useful tool for assessing whether designs have enough colour contrast. If you know the hex values of the colours in your scheme, their tool will try to decide whether the design would pass Guideline 2.2 of the Web Content Accessibility Guidelines 1.0.

If this interests you, you might also like my earlier posting about web colours.