TaskToCal gives MS Outlook back its pants

 Satisfied Clients, UI  No Responses »
May 022012
 

I wonder whether the original designer of MS Outlook suffers the classic recurring nightmare of being out in public with no pants?

MS Outlook is missing a feature so blindingly obvious and necessary that it comes as a shock to find it’s not there:

Tasks with due dates don’t appear on the Calendar!

Really! Don’t believe me? Go check.

Yes, it’s true. As designed, the Calendar and the Tasks are two distinct subsystems… like room-mates locked into a permanent sulk… or the AD&D Brawl and Combat systems.

It’s frankly bizarre that a behemoth like Microsoft could put out a product with such an obvious omission. So, if the Outlook designer does have those nightmares, it’s probably because he or she is sufficiently forgetful to have genuinely gone to work sans-jeans!

"Call client" is actually a task...

Fortunately, there’s an independent software provider willing and able to hand you a pair of chinos to cover the shame of your particular Outlook installation…

TaskToCal syncs the MS Outlook calendar with the task list. Tinker in one place and the changes appear in the other.

Oddly, this little masterpiece didn’t require much documentation. However, I was glad to get the gig, especially because I got to make some suggestions about streamlining the UI text. I delivered my work as a Help and Manual project, and the client was very happy:

“Do you love writing software but you hate writing documentation? Then don’t burden yourself any longer. Ask Martin to do this job. The result is pragmatic and overwhelming at the same time. He does his work on time and delivers more than you expect.”

Drop me an email to see how I can help you with your documentation…

 

 Posted by at 12:44 pm

Kindle – a flicking fail

 UI  No Responses »
May 022012
 

I love my Kindle.

I can read it one-armed while cuddling a dozing child. I can catch up on classic out-of-print Science Fiction, without cramming the house with dusty books or spending a fortune.

I can even legally download the complete works of Edgar Rice Burroughs free from Project Gutenberg without spending a fortune on collectible paperbacks with rather too raunchy covers.

So, no, I’m not one of those people who laments the loss of the feel of the book, the smell of the paper. Give me content. Now!

Alas, when I say  I  love my Kindle, I really mean I love my ebooks.

Good reviews on cnet aside, the Kindle is very unlovable indeed.

Sure, we’re all used to the “Mac-rosoft” logic of menus and clickable links. We don’t need an Interface Metaphor anymore.

However, when a device is a replacement for Something Real, you’d think the designers would have thought through some use cases for the original.

I doubt the Amazon  designers did this. To be honest, I seriously doubt they  read books for pleasure.

How the Kindle matches up against use cases for a paperback book

Think about it. The two main use cases for a paperback  have to be:

  • Linear reading: I read one page, then I read the next. Sometimes I  back-up a page to check I read it right. Mostly, I just trundle through the text.
  • Flicking: Some books have maps, glossaries, dramatis personae and end notes. Others place their illustrations in one clump. I need to flick to them and then back to  the text.

Linear reading – yes, well done, the Amazon designers managed to remember a forward and back button. (Woot!)

Flicking…? With the exception of the way it handles end notes, the Kindle is a flicking fail.

Why the Kindle is a flicking fail

Flicking is all about  back-and- forward action - glance at Glossary, then back to the description of the battle.

How does this go with a Kindle?

I’m reading Six Months Without Sundays. What on earth is TRiM? OK. Let’s check the Glossary…

  1. Click the Menu Button…
    The menu opens.
    (I have lots of options, including tinkering with the  WiFi. However, I think I want Go to.. , which is handily highlighted.)
  2. Select Go To and hit the OK button.
    A panel appears offering me 6 standard destinations.
    (Hmm. “Table of Contents”, “Beginning”, “Page”, “Cover”, “End”, “Location”… But I want the Glossary. Is it in Locations… Oh, that just returns me to my place for no apparent reason! OK, I give in…)
  3.  Select Table of Contents.
    The ebook’s Table of Contents opens.
    (Finally! Now I just have to arrow down to the glossary.)
  4. Select Glossary and hit the OK button.
    A panel opens.
    (Do I want to “cancel”, “create note”, “full definition”, or “follow link”…?)
  5. Find the required information.
    (Oh, “TRiM” means “Trauma Risk Management”. Cool.)
  6. To return to your place, hit the Back button several times.
    (Great. Oh, hang on, what’s a “Gimpy”…?)

It takes four (4!) menu steps and many more clicks to get to the glossary. Once you’re back in the text, you have to do it all over again.

This is  rubbish! What were they thinking?

Yes, I could bookmark it, but: using a bookmark requires two navigation steps, and even more clicks; and consulting a glossary is a very routine expectation – I should not have to set it up myself.

Ways Kindle could be better for flicking

Assume we can’t add extra buttons, or get the Kindle to treat the Glossary like a dictionary and have the   definitions appear tool tips… what could we do to make it better at flicking?

Let’s mess with the buttons. Here they are:

Table of Contents button replaces Menu button

Going to the table of contents is a routine action! It shouldn’t be a roller-coaster adventure through a menu tree.

So let’s turn the  Menu button to a Table of Contents button. The table of contents screen can have an item on that leading to the other options.

Forward and Back arrows skip bookmarks, not chapters

At the moment the Forward and Back arrows work like the skip buttons on an MP3 player.  However, instead of skipping tracks, they skip chapters.

How often do readers navigate by chapters? Remember, the Kindle remembers your place; you don’t need to pick it up and go, “Hmmm. I was halfway through chapter seven…”

The arrows would be better used to skip between bookmarks.

It’s not rocket science!

Looking back up at my review, I am starting to wonder whether the Amazon designers thought they were designing an MP3 player, or that they wanted to make the Kindle like one. Or perhaps they saw the shape of the data – the chapter structure – and organized their UI around that. One way or another they missed an opportunity to produce something that really enhanced the reading experience.

It’s a pity because it’s not rocket science. They just needed to sit down with people who actually read books and look at how they use them.

(If you want some help in revising your UI, drop me an email.)

 Posted by at 11:21 am

FastMaint: UI design good enough to send a rocket into space

 Satisfied Clients, UI  No Responses »
Jan 092011
 

If you know me at all from my online presence, you’ll know I have a thing about good interface design.

I don’t mean the sort of fancy theoretical considerations they teach you in HCI courses. I mean just the basics:

  • Make the interface reflect its real world domain.
  • Keep navigation simple and consistent.

Late last year, I was lucky enough to work on documentation for a system that’s a good example of how to “do it right”.

FastMaint essentially turns your PC into the equivalent of a fully-staffed maintenance office. Not only does it handle work orders and the resulting workflow, among other things, it also tracks inventory, rostering, locations and equipment. It even warns you if you’re trying to do something impossible or unwise…

With so many different entities to manage, this could have been a horribly complex piece of software. However, the SMGlobal team managed to make the product so intuitive that even a deskbound techwriter such as myself quickly made sense of it.

They achieved this by putting in the hard work required to keep the interface consistent and convenient. Here’s an example:

 Locations and Equipment

  • If you’re a maintenance professional, then all this should make sense to you, even if this is the first time you’ve seen FastMaint!
  • If you’re looking at an entity or list of entities – here, equipment located in a building – then there’s a button to create or add a new one.

In short, you – the user – can concentrate on the task in hand, without wasting brain space on the software.

All this may not be rocket science, but it requires the sort of thoroughness you associate with building an actual rocket:

  • Somebody must have gone to the trouble of learning the terminology used in maintenance departments, then made sure that the screens reflected it. (This probably meant acting as a sharp-eyed gatekeeper whenever developers became “creative”.)
  • Somebody else had to slog through the UI, putting in all those buttons, creating all those editors…

When they graduate from college, most young coders dream of wrestling with algorithms and architectures, not putting in the kind of meticulous effort on display here. However, if this were a launch vehicle, then I’d cheerfully ride it to the stars.

If you don’t believe me, download the application and take a look for yourself.

If you do that, you’ll also see my streamlined documentation that builds on the application’s ease-of-use.

It’s usually harder to cut, rather than expand, text, and there’s always the fear of leaving out Something Important.

However, my contact at SMGlobal, Sanjay Murthi, pronounced himself

…happy that you have been able to reorganize and simplify the help documentation.

So, I like to think I’ve turned out an online help worthy of the product.

 Posted by at 1:58 pm

Not rocket science: Six ways to improve your UI…

 all, Tips, UI  No Responses »
Oct 202007
 

It’s not rocket science!Good UI design isn’t easy. Even the big boys get it wrong. It would be great if everybody had time to do a proper job of UI design. But the reality is that most of you guys are like me; “bootstrapping” in some corner of your home, using your enthusiasm and drive to turn your calender into a fractal time-line, and getting things done in the invisible squiggly bits.

To an extent, if the software does what the user wants, then a UI only has to be “good enough.”

However, there are one or two seemingly trivial UI oversights which – I think – can create a kind of mental friction… eating away at your user’s sense of certainty and security, leading them to make errors, or suspect errors.

Let me propose, as a rule of the thumb, that if it’s hard to document, then it’s probably also harder than necessary for a user to understand.

So, things which bug me  – your humble techwriter-for-hire - probably also bug your u$er. (And – if you’re not my client, please remember that I might well be your user… or would be, if your interface didn’t put me off .)

Here are six ways to avoid the most common UI issues. None of them are rocket science!

  1. Name everything, including any groups of fields and lists. This makes it easier to describe the interface, and avoids sentences such as “Select a format (lower right group of fields), then, in the green list, select a file”.  It also makes the interface less intimidating for the new user.
  2. Use names consistently throughout. If you call a spade a “spade”, don’t then call it an “implement”, and then a “digging tool”. A User Interface is not the place for elegant repetition, because it’s very easy to confuse synonyms with parent categories.
    In other words, the user may wonder whether perhaps the entity SPADE is a subset of “DIGGING TOOL”, itself a subset of “IMPLEMENT”. (And God-forbid you do then decide to add more entities, and forget to rationalise your terminology.) Get a lexicon dude, and stick to it!
  3. Avoid …. like … -  You know what I mean? Those “friendly” fill-in-the-blanks sentence/field combos. They do look friendly, but what entities and parameters is the user dealing with? There’s nothing to hang the information on.
    Also, these are potentially (your) murder for non-native speakers. Which is easier to translate, a complex sentence, or a table of fields and noun field labels? How would the resulting support call go?
  4. Not a wizard?If it’s not a wizard, don’t pretend it is one! Repeat after me, “Wizards don’t need documenting. Wizards are linear.“ 
    If you have a complex set of options, don’t present them in a one-way fashion; users often want to go back to confirm their choices before pressing OK!
    Also, imagine a support call where you want to check their settings… 
  5. If it looks a bit like a standard office application, make it work like one! I know you think you’ve written a clever time-management system, but to the user it’s either a calendar or a special spreadsheet, and they’ll expect it to be organised as such.
  6. Don’t reinvent the wheel! Be honest – is your feature so very unique that no interface element created in the last ten years could handle it?
 Posted by at 10:34 pm
© 2012 Documentation Doctor Suffusion theme by Sayontan Sinha