Wednesday, August 27, 2008

More on broken metaphors

In my last post I talked a bit about how it's our fault as programmers if users are confused by the user interface metaphors we use. We do use a lot of metaphors in programming, and mangle and mix most of them. Last post it was using "print screen" as a metaphor for copying the screen rather than as a literal command to print the screen. Users are understandably dumbfounded by the nonsensical nature of this design choice.

Here's another example of a broken metaphor. Think about cutting and pasting in real life. Anybody who worked on a school newspaper or yearbook in the pre-computer age knows exactly how this works. You use your scissors to clip text from galley proofs, or photos, or whatever. You do a lot of cutting, then paste things back in to your new document with a little jar of rubber cement and a brush (just like the icon!). The resulting document is photoset and printed. But that's not how Windows works.

Microsoft broke the cut/paste metaphor in Windows by only allowing one item at a time on the clipboard. As of Vista it's still broken, though programs like Yankee Clipper fix it. A useful application of the otherwise mostly useless animation in Vista would have been to animate the cutting process, so that Ctrl-X results in the text moving and shrinking onto a clipboard System Tray icon, which would hold multiple clipboard entries. This would advertise the new clipboard functionality, but they didn't do it, nor did they add the new functionality to advertise; and for the life of me I can't figure out why.

(In other cases Windows does do such animations, as in closing a window, but even that's ever so slightly broken. The window will shrink to the default location of the taskbar - at the bottom of the screen - even if your taskbar has been relocated to the top or side of the screen. If you've moved the taskbar and the animation ceases to be helpful... it's just misleading. It's a good idea with mediocre execution.)

Microsoft further breaks the cut/paste metaphor in Office. There's a Clipboard, but it's not the Windows clipboard, and it's somewhat broken even in the most recent builds of Office 2007. For instance, cutting and pasting isn't at all consistent. In Word, when you cut the text disappears from the document and appears in the clipboard. In Excel, cutting a cell copies the cell, but it doesn't disappear from the spreadsheet. Instead, Excel puts an animated border around the cell. This looks exactly as if you've simply copied the cell, and you don't know the difference until you try to paste it back in. Microsoft managed to ignore very simple rules... cutting removes the item. Copying does not. If the Microsoft Office team can't keep the rules straight in their own heads, is it any wonder that the users can't? (By way of contrast, Calc does cut and paste right, so I don't think there's a technical reason why it's broken in Excel.) And it's absolutely inexplicable why MS Office needs its own clipboard manager, when something like Yankee Clipper does the same job for the entire operating system, which should be providing the functionality without an extension at all.

These are the kinds of things that confuse users and generate support calls. The very same support calls that are often used to illustrate "stupid users", who are so ironically labeled only because they expect the metaphor to be logically applied, whereas the software designers and support technicians do not.

UI Metaphors and Floundering Users IT support workers.

In the "Shark Bait" forum of ComputerWorld I found this interesting item:
Submitted by: jeitzen – Mon, 08/25/2008 – 08:45

Got in this morning and found a message waiting for me in the support inbox.

When I push the print screen button on my keyboard to get a screen print to attach to a document, the print screen never prints. Please advise
Thank you

Like I said classic! This user is also a frequent visitor to the support inbox. I am sure she came to my desk, thats her MO. Send a request and walk over 3 minutes later to see if I got it.

Many of the responses were of the obligatory head-shaking "tsk tsk... isn't that user so stupid" variety. Here's one that caught my attention, from a user called "KirkW":

"When I push the print screen button on my keyboard to get a screen print to attach to a document, the print screen never prints."

What exactly did she expect to happen? It almost sounds like she's doing it right - press 'PrtSc' to get a copy of the screen to attach to a document. By why does she expect it to print out? And how was she going to a attach a printout to her document? Perhaps scan it in? (Don't laugh - it's been done). Or is she going to 'attach' the screen-shot to her printed document with a stapler?

Either the attached screen shots are not appearing when she prints the final document, or she's trying to paste a screen-shot and it's not showing up. Or she's as confused as her e-mail suggests. If it were me, I'd pay her a visit and ask her to show me what she's trying to do.

To answer KirkW's question, what she most likely expected to happen is that pressing "Print Screen" would print the screen. And she most likely expects that because the button is labeled "Print Screen". Then YES... she would take that printed screen and attach it to a document that she had printed separately, by means of what we call a "paper clip" or "staple"; which -- contrary to many assumptions -- are still readily available in all office supply stores, and not at all obsolete. Note that when she attaches the hard copy to the document there are NO quotes around the word "attach"... because that's the actual meaning of the word!

Once upon a time paper clips were not dancing animations, or iconic representations of virtual actions, but rather useful items in the physical world. That is still the case to most non-IT business users.

Sadly, the blinders of IT often cause support workers to assume confusion or stupidity on the part of the office staff when neither exists. The woman made a reasonable complaint. The only people confused and ignorant with regard to this story are 1. the programmers who changed the function of the print screen key to do something other than print the screen, 2. the hardware designers who neglected to rename the key to "Screen Capture", and 3. support workers who find it inconceivable that the word "attach" may refer to a physical act and "document" a physical object.

KirkW's final sentence is right on the money, because if he were to actually visit the user he'd likely shake his head at his own assumptions and never, ever mention them to his co-workers lest they embarrass him. As well, he can feel greatly relieved that business users don't maintain websites on which to post stories of "IT retards" who don't even know what a paperclip is for. (No offense to jeitzen or KirkW, but the users would be far more justified than they in doing exactly that.)

The point being this: when we design systems we should not break the metaphors we chose to make the job easier. And we certainly shouldn't forget where they came from. The "paste" icon refers to actual paste. The "cut" icon represents a pair of scissors. When dealing with users we need to remember that those items should operate in some way similar to the physical object... any differences should be logical and appropriate to the context of computing, or we've broken the metaphor. In the case of something like "Print Screen" (or PrtScn, or PrtSc, depending on your keyboard), the act of printing is a computer function, and it's entirely reasonable to suppose that the button should do exactly what it says. Yet it doesn't. That's not the fault of the user, it's the fault of designers, programmers, and engineers who all worked to intentionally break the metaphor... who conspired to be stupid. And it's the fault of support staff who deliberately join the conspiracy and perpetuate it.

That's worth thinking about. It's usually the case that when our users are confused it's our fault. We need to take more care in designing systems that are intuitive. When we see users consistently coming to the wrong conclusions, we need to change the system so that they consistently come to the right ones.

When metaphors get in the way it's better to discard them entirely. When IT support workers get in the way, it's better to re-educate them. So here's today's lesson:
  1. Don't laugh at your users when you are being an idiot.
  2. Don't post proof of your idiocy on Shark Bait.
  3. Instead, listen to the users and either fix the problem (if you're in a position to do so) or educate them (which you're certainly in a position to do).

Friday, August 15, 2008

So what's been going on?

I've been EXTREMELY busy. Unfortunately, I haven't been busy with VIC CRM... I've had some bills to pay. As for details, you're not getting any. But I expect to be able to have a nice update for VIC CRM by Halloween.

For now, I've done a bit of a bug fix for some annoying errors with VIC's email.

WARNING: This is for Lotus geeks. For everyone else, I'm putting together some new templates.

Here's a file to patch the Cratchit Email script library.

Download CratchitEmailLibrary.lss

And here's what it fixes:
  1. Reply without History: there was an error replying without history. A data type issue was issued when attempting to insert the signature. It didn't affect anything but the signature; nevertheless it was annoying.
  2. Reply with History: replying with history kept the cc: fields, but replaced the SendTo: field with the From: field. This was wrong, as it assumed that you are the only recipient. It now preserves the original recipients and pre-pends the list with the previous sender.
  3. Forward: This is a re-write of the forwarding function, and is much more stable, consistent, and nice looking. Also, a bug in the Shared Action was causing multiple forward documents to be created.
How to update:
  1. Save CratchitEmailLibrary.lss to a temporary location on your hard drive.
  2. Open the VIC configuration database template (vic_config.ntf) in Designer.
  3. Edit the Script Library called CratchitEmailLibrary. Using File|Import... import CratchitEmailLibrary.lss. Reply "Yes to All" when asked if you want to overwrite the existing code. Save the script library.
  4. Edit the Shared Action called "Reply\Forward" in the VIC Journal template (vic_journal.ntf). Erase the entire contents of the Initialize subroutine.
Here's another small enhancement for the next release that you can apply now:
I didn't like the Contact column in the mail views. So while you're in the VIC Journal template, you can replace it with the following:
var3:=@If(@Trim(var2)="";"=No Contact=";var2);
This should replace the Contact formula in all Views having "Mail" in the title. It will give a better display of the sender for those emails that were imported into the Journal without being associated with an existing account.

Then delete all of your personal Views from the VIC Journal and refresh the design of your Journal template, then your Journal. That's it.

It doesn't look like much of a change, but it makes a big difference in usability.