Stuff and nonsense

I just posted this to my UI design class discussion board:

Awe-inspiring info design...though the current menu is now only 6 pages :(

"Two years ago, Calvin Trillin wrote an article for the New Yorker about Shopsin's, an eccentric eatery in the West Village with about 9 billion menu items… Shopsin's has moved to another Village location since the article came out, but they've still got that big old menu. If you dare, feast your eyes on a tour de force of outsider information design, all 11 pages of the Shopsin's General Store menu…" http://www.kottke.org/04/08/shopsins-menu

via xblog

This link, however, will NEVER find its way to Blackboard (turn the volume up REAL LOUD):

http://www.rathergood.com/moon_song/

Prototyping; GUIdebook

Found some interesting or otherwise time-passable things on the web related to prototyping and our discussion on Wednesday. A List Apart runs deep-dish articles on web design. This article shows how paper is good for tabbed interfaces, widgets, and usability testing. He also suggests keeping a glue stick handy.

Pen-based low-fi vs hi-fi; use while keeping the above paper prototypes in mind.

  • Sketching with a Sharpie - (37signals) - "Ballpoints and fine tips just don’t fill the page like a Sharpie does. Fine tips invite you to draw while Sharpies invite you to just to get your concepts out into big bold shapes and lines. When you sketch with a thin tip you tend to draw at a higher resolution and worry a bit too much about making things look good. Sharpies encourage you to ignore details early on."

A neat idea if you want to keep your prototypes looking rough.

  • Napkin Look & Feel - "The Napkin Look & Feel is a pluggable Java look and feel that looks like it was scrawled on a napkin. ... Often when people see a GUI mock-up, or a complete GUI without full functionality, they assume that the code behind it is working. ... So the idea is to create a complete look and feel that can be used while the thing is not done which will convey an emotional message to match the rational one. As pieces of the work are done, the GUI for those pieces can be switched to use the "formal" (final) look and feel, allowing someone looking at demos over time to see the progress of the entire system reflected in the expression of the GUI."

This is a really good post that links to Napkin and other sources to express what we heard in class, namely, the more "done" the prototype looks, the more finished the client expects the entire application it to.

The SILK project grew out of someone's dissertation research. The current public release of Denim runs on Mac, Win, and *nix.

  • DUB - DENIM and SILK - Research - "Through a study of web site design practice, we observed that web site designers design sites at different levels of refinement -- site map, storyboard, and individual page -- and that designers sketch at all levels during the early stages of design. However, existing web design tools do not support these tasks very well. Informed by these observations, we created DENIM, a system that helps web site designers in the early stages of design. DENIM supports sketching input, allows design at different refinement levels, and unifies the levels through zooming."

Referred to in the List Apart article, this is a neat site that shows the evolution of OS and application GUIs from their inception to today. It has sections for splash screens, icons, the tutorials that were included to help us learn how to click with a mouse, and a timeline showing the slow progress of GUIs from the Lisa and GEOS on up to Leopard. The site appears to have run out of gas around 2005 or so. I have personal experience of GEOS (Commodore 64 & PC), Amiga, DOS 3-5, Windows 3.x, Mac (mid-80s-early 90s), and OS/2.

Links: file-naming conventions

I remember reading a columnist in one of the Ziff-Davis mags, back in the mid-90s, lamenting the busting of the old 8.3 file-naming conventions that DOS imposed. With the new Win95 long filenames-with-spaces convention, he predicted that people would actually lose more files than find them again. He used as an example their production process, in which every directory name and every character in a filename carried a specific meaning in the workflow. That kind of discipline ensured that everyone knew what state the files were in. With longer filenames, he was afraid that users would be mainly writing reminders to themselves rather than helping out the next worker on the production line.

Reading the identifiers article reminded me of a 43folders.com blog posting, and that led me to other postings related to how folks name files. The people commenting are mainly graphic designers and web designers, whose work involves tracking lots of little individual files that collectively make up a single job.


This is from the developers' point of view. Read the original post but skim the comments to get an idea of what developers have to consider when creating files the users will depend on. The Old Joel on Software Forum - Restrictions on # of files in a Windows Directory?

E: if it is problematic to have several thousand separate directory entries in one directory, I could envision a directory structure in which the all user IDs ending in '0' go to a directory called c:\userdata\0, user IDs ending in '1' go to a directory called c:\userdata\1, etc. Or use more digits from the end of the user ID for greater granularity: c:\userdata\000, c:\userdata\001, etc.

Vox Populi: Best practices for file naming | 43 Folders

But, just so I don’t lose you, do give me your best tips in comments: What are your favorite current conventions for naming files? How does your team show iterations and versions? Do you rely more on Folder organization than file names in your work? How have Spotlight, Quicksilver, and the like changed the way you think about this stuff?

My god, there are 86 comments on this thread and many of them are detailed and illustrated....

...and then Lifehacker.com gets in on the fun. There are some some commenters who say "don't include the date in the filename" as that info is already captured with the file and you can sort on that info in most file managers. I include the date because I often share my documents with others and the date in the filename is the quickest way for them to discern whether they have the latest copy. Ask the Readers: Filing naming conventions? Another very long posting that inspired the 43folders post above. It's interesting to note that, for designers, they all have certain types of info they want captured in the filename, such as the client name and draft iteration. But where they put that info depends, probably, on who set up the system first, tradition, etc. What Do I Know - File Naming / Organization Methods?

Only 4 comments in this one, but they have good detail and pretty much mirror the other postings. Read this one to get a flavor of the longer screeds. File Naming and Archiving | 43 Folders

A single post detailing another designer's setup at his workplace. Use a boilerplate folder setup and consistent, meaningful names | 43 Folders

Drafting scenarios and stories

This post discusses the following readings:

  • Gruen, D., Rauch, T., Redpath, S., & Ruettinger, S. (2002). The use of stories in user experience design. International Journal of Human-Computer Interaction, 14(3&4), 503-534.
  • Head, A. J. (2003). Personas: setting the stage for building usable information sites. Online, 27(4), 14-21.

<<In class, we wrote sample story/scenarios, and I refer to a great story written by a classmate about a guy at a party who is covertly listening to his music while grudgingly assisting his wife with hosting a house party.>>

I thought the story about the guy at the party trying to hide the earphone was great--it worked as a complete vignette, the character had a secret (which puts the reader on his side), and it has a nice curlicue at the end. It's complete in itself but could fit nicely inside a larger story about this character.

OK, now *that* I would consider a story, more so than the scenarios we read in the IBMers' paper.

I've been writing short stories off and on since college and did a couple of NaNoWriMo stints, so here's what I think about the narrative devices used to create stories that could be used for scenarios.

CHARACTERS. Some of the best ways to create a character include starting with an archetype (the Scrooge type, the strong and silent type, the talkative type, the Type A type), someone you know, or a fictional character you know really well. As you write and spend time with the character, you'll get to know them better and their own personality emerges, especially as you put them in difficult situations.

You can create an amalgam character or persona, but one person that has many different kinds of tags (like the primary persona in the Personas article we read) can seem a little unreal to me, very manufactured. At that point, I think you're checking stuff off a list rather than creating an imaginary character that *seems* real, which is the goal of fiction. I'd suggest starting simple and then adding stuff as it feels right.

One of the age-old questions to ask about a character to get your imagination primed, is to ask yourself what the character eats for breakfast. This is also a good opening question to loosen up interview subjects, BTW.

PLOT. The IBMers don't talk about the mechanics of plotting, which is one of the toughest jobs in story-writing. A story's theme is what the story's about; the story's plot is this happened, then that happened, then this other thing happened.

Samuel R. Delany has a technique he calls "thickening the plot," in which the writer describes the setting in detail and gets the character interacting with it. So in the party story, we see the character moving around the house, taking things to the kitchen, anything to disengage himself from the party. People trying to talk to him, him turning to hide the earpiece, all help to thicken the plot and ratchet the tension that he'll be discovered.

RACHETING THE TENSION. In the party story, the tension is, "Will he be discovered?" There's no such tension in the IBM stories because, really, what's at stake for the characters? Nothing much. Particularly, that last story iteration they did was all Star Trek technobabble, there were too many characters (so no one person a reader could care about), and there was really no tension or emotion. (I'd say this is a danger of stories in the IBM method, in which lots of people start using the story as a dumping ground for their ideas and you start losing the main thread.)

But tugging on heartstrings isn't what scenarios are supposed to do; they're mainly of use to engage your imagination so you see the whole problem space, not just a little piece of it. (The other advantage being they get the picture and expectations from inside your head into someone else's head.)

The best IBM story was the one where the guy was installing software at 3 a.m. because the workers would be coming to do their jobs in a few hours. A ticking-bomb deadline is tried and true. I'd say that even the Madeline scenario <<a scenario provided by the professor, of someone using a health-care information system>> could use a ticking-bomb urgency, if the waiting room is crowded, people are being processed quickly, and the subject needs to hurry up so he can get back to work.

GOALS AND OBSTACLES. This is plot. An interesting character in an interesting situation creates the plot naturally without too much intervention. In the case of scenarios, we could introduce massive power failures, ice storms, zombies, etc. but they don't really help us with our purpose, which is to design a good user experience. (Another case where stories diverge from scenarios.) I would call scenarios not stories but soap operas: just one damn thing after another, until the fadeout.

That said, yes, the protagonist wants something and is frustrated by a stupid UI, a deadline, ice storm, zombies, etc. which means that something has to be at stake for him or her, and there have to be consequences for failure. In the party story, the husband gambled with multiple consequences of being discovered, which is what made it entertaining (another difference from scenarios: scenarios don't have to be entertaining, though they're more fun to read if they are). In the Madeline scenario, what are the consequences of not understanding the UI? Will I feel sorry for that character if they can't get the video working?

Here endeth another of my verbose postings. Carry on.

Article critiques: scenarios, stories

This post discusses the following readings:

  • Go, K., & Carroll, J.M. (2004). The blind men and the elephant: Views of scenario-based system design. interactions, 11(6), 44-53.
  • Gruen, D., Rauch, T., Redpath, S., & Ruettinger, S. (2002). The use of stories in user experience design. International Journal of Human-Computer Interaction, 14(3&4), 503-534.

I thought the best thing about the Go and Carroll article was their listing of differences between scenarios and specifications (though it would have worked better as a table than as text) and their review of the literature surrounding the techniques. I also liked the breakdown of strategy/requirements/HCI planning to year/day/moments. Apart from those squibs, I thought the article was unbelievably dry and unimaginative (which is odd, considering they're talking about the importance of imagination in creating scenarios); for one thing, they introduce the "blind men and the elephant" story in the lead without following it up in the rest of the article. Do scenarios help us see the elephant? Or do they only show us pieces? By the end of the article, we don't know and the authors haven't told us. (I wonder if the editor made them tack it on.)

The Gruen, et al., article by the IBMers I thought was more interesting and meaty; they seemed really in love with their new tool which seemed to have united disparate stakeholders within IBM as well as their clients. I also thought it was interesting how the stories could be decomposed for other audiences as well, down to the design, marketing, and documentation materials. They don't attempt to speculate as to *why* they think stories unite audiences with differing needs, but I'd guess that we're simply trained, from childhood onward, to think in terms of linear narrative. A page of prose describing someone solving a problem is easier to read and understand than a functional specification document, which requires a specialist to draft. Stories don't require specialists.

Their descriptions of its use made it seem like a silver bullet, and I would have liked to know what, if any, limitations they encountered. How do they control their stories, to keep them from becoming distended or unbalanced when descriptions get too specific?

I'd also say that what they're calling stories are not stories, but extended scenarios that use narrative devices like character, setting, plot, etc. The chief characteristic of a story is that the character is different at the end of the story than at the beginning. Their example scenarios don't have that quality; they're more like Star Trek problem stories: Picard is trapped on the holodeck--how do we get him out? No character in such stories really learns about himself or his life. The interest is mainly in seeing people spew technobabble and race against the clock.

Likewise, the IBM scenarios attempt to trap someone in a problem and watch them squirm to get out. The interest is in watching this particular character squirm (would a different character behave differently in the same situation?) and noting the details of what they do to solve their problem.

Keeping Found Things Found

A web site focused on collecting and managing personal information, from the U of Washington I-School, with some help from Msft. I haven't compared their publications list with our syllabus to see if there's any overlap. Keeping Found Things Found "The classic problem of information retrieval, simply put, is to help people find the relatively small number of things they are looking for (books, articles, web pages, CDs, etc.) from a very large set of possibilities. This classic problem has been studied in many variations and has been addressed through a rich diversity of information retrieval tools and techniques.

A follow-on problem also exists which has received relatively less study: once found, how are things organized for re-access and re-use later on? "

How is it possible? More on email

The readings that prompted these postings were:

Lehikoinen, Juha, Antti Aaltonen, Pertti Huuskonen, and Ilkka Salminen. Personal Content Experience: Managing Digital Life in the Mobile Age. Chichester, England: John Wiley, 2007. [48-51, 84-94, 127-157]

Whittaker, Steve, and Candace Sidner. "Email Overload: Exploring Personal Information Management of Email." Paper presented at the Conference on Human Factors and Computing Systems, Vancouver, British Columbia, Canada, April 13-18, 1996, 276-283.

The following response was to a question about whether a high number of emails are seen as a sign of prestige or importance.

Both of my managers receive upwards of 50-100 emails a day, depending on the crisis du jour. It's more a sign that their world is probably wider than mine and that they have more responsibilities (and more corporate spam to filter out). Both would love to have fewer emails to plow through; sometimes the job feels like it's managing email rather than getting work done.

Piles of unprocessed emails stresses both of them out. So it's not a badge of manhood for them.

One of my managers has been there for 10+ years, and he's a filer; his folder hierarchy is like baroque stained-glass in its intricacy. But for our clients and others on the team who don't file, they know that he *does* file; hence, he's usually the go-to guy for "do you have a copy of that email?" His ability to file and find stuff means they don't have to (and he now has this reputation to live up to, so that adds to his stress). [Update: after backing up his emails to a CD, he deleted about 10,000 emails from his account, some dating back to 2004. And remember, he deleted lots of email too.]

I remember reading somewhere that our brains have a 'doing' function and a 'thinking' function. The trick is, that they don't work at the same time. Reacting to email is a satisfying 'doing' activity, so most people probably don't think too much about how to file something so they can find it later; they're too concerned with taking care of business now. Sometimes we'll think ahead and plan an elaborate system to process our emails, but when we start doing it, the system is awkward or cumbersome; I'd class making folders and filing as a system that some people find cumbersome.

Another part of the issue may be the just-in-case vs just-in-time mentality. A lot of us filers and packrats like to hold on to things just in case we'll need them; but 80% of our files are never seen again. 20% I'll access regularly, but that 20% is different for every user, which is why filing still winds up becoming a personal matter, even in a business setting.

I wonder if things would be different if we asked people to create their own filing systems as if someone else would be using them next year. Would they then take a little more time to create folders, to make life a little easier for the next person? They may be able to create just enough metadata for us to get by.


In what ways are your own personal information management practices similar to or different from those described in the two readings?I'm one of those unfortunates who believes there must be one true way to do anything; as a result, I keep shifting things around and never have a stable setup. My wife, OTOH, doesn't seem to have this problem.re email: My email strategies for work and personal are different. In general, I'm more organized than the article subjects, partly because my role in the team is be the unofficial archivist and because experience with our customers has shown that I'm better at keeping these records than they are.

At work, my strategies shift and vary based on the work I'm doing and the tools I'm using. I used Outlook differently from Lotus Notes, for example. In general, I find myself dumbing down the email interfaces so they're as simple to use as possible. I tend to create folders for each project I'm involved with and emails go there. Because we have storage restrictions, I will archive emails (usually emails with big attachments) to a separate database on my hard drive; I have an agent set up to archive mails over 6 months old. For the database on my hard drive, I have full-text indexing turned on as this lets me search inside PDFs, Word files, etc. (Can't do this with my active email database.)

After attempting to segregate mails by project AND fiscal year, I decided last year to keep all project-related emails in one project folder and be done with it. (Notes lets you keep a file in more than one folder, basically a shortcut to the email, but I rarely use that.) I rarely think about metadata or context; like the article subjects, I'm concerned with the next deadline or commitment and long-term storage and access isn't part of my everyday thinking.

We've found that it's best after a project is over or some disaster has happened, to draft a Word file that summarizes the incident, what we did, our rationale, important facts, etc. It helps to draw everything together in one place in a coherent narrative. Often, important meetings or phone calls are not documented elsewhere, and they sometimes need to be captured. I then email it to as many people as request to see it (safety in numbers; in case I delete my copy, someone else may have it); I also save it to our Notes document database on the network where it's backed up and available for others to see.

[Aside: It strikes me that the Notes article is all about jumbled collections of individual items--call them 'words.' The Symbian developers are creating a framework to turn individual words into 'phrases' with simple grammar -- "is part of," "was taken on," "is used by," and so on. But there's no technological way to turn those phrases into any meaningful sentences or a narrative, except in the mind of the user.]

My personal mail is kept in Gmail, with minimal labels (I don't use multiple tags). I find the searches powerful enough that I only use labels for short-term personal projects.

Previously, I used Yahoo mail for several years; I archived all of that mail to my hard drive in 2006, and have gone back to it less than 10 times, I'd say. I just haven't needed to. I use Copernic Desktop Search to scour files for keywords if I can't find a particular document.

My files are organized primarily by directory name, but I have duplicates that have built up over time, and haven't figured out a strategy to deal with them. I depend on the directory and file names to provide whatever context I need to figure out what they are. I may append keywords to filenames, but not often.

My photos are organized in directory folders by year, then by month, then by subjects. Music files are organized in directory folders by genre, artist, etc. I don't really trust Picasa or iTunes or MediaMonkey to organize these things for me because their organization tends to be proprietary and require much organizational fiddling by myself, whereas they can all read the files in my directories, which I can arrange once and then forget about it.

I tend to think hierarchically and alphabetically, so that's how I tend to arrange my files on disk; I fall back to Copernic when I just can't find it by scanning folder and file names.

More on email overload

Yet more reaction to this article:

Whittaker, Steve, and Candace Sidner. "Email Overload: Exploring Personal Information Management of Email." Paper presented at the Conference on Human Factors and Computing Systems, Vancouver, British Columbia, Canada, April 13-18, 1996, 276-283.

From a records management POV, I had these thoughts:

  • People are so overwhelmed when they're in the thick of their email, that they can't discern an immediate difference between the ephemeral and the archive-worthy. (This is even though they describe their jobs as mostly managing email.) For this reason also, we can't depend on them to prune their stash of mails.
  • If the users can't categorize their mails so they can locate them, then records managers will have even less success at helping anyone find them later.
  • If we're faced with having to archive everything, then nothing is of value. You can't find the needle if you keep adding hay to the stack.
  • If we establish retention policies, then we're the only ones who will follow them. I perceive these users as being so busy, that they will think of archiving as someone else's job. They already have too much work to do.
  • The article doesn't address the issue of file attachments (I use Gmail for file storage as much as for communication) or of the corporation owning your email. File attachments are as important as emails these days.
  • Again, it's not mentioned, but users are more likely to hear from corporate IT that their inboxes are taking up too much storage space and that's when they have to purge. At [previous workplaces], we took training now and then on retaining records, but you hear more often that you need to trim down your mailbox size.

Other stray thoughts and babblements:

  • This article was written over 10 years ago, and I wonder what biases or expectations the authors and the users brought to the topic of email and email programs. What were they expecting email programs to do for them?
  • Having used Lotus Notes at various jobs since about 1995 or so, I can testify that its general yuckiness contributed mightily to the users' problems. Although Notes has added buttons to let you copy a mail into a calendar or to-do entry, those are areas of Notes that users I've worked with know very little about, like the Journal or To Do areas. You can make Notes remind you to do things regarding your mail or tasks arising from it, but it requires you to click buttons and takes you away from the inbox, which seems to be everyone's home base. When people leave the inbox pane, Notes is a lot more forbidding and cold, with toolbars and commands appearing that don't have anything to do with email. (Which makes sense--Notes is a document database program with an apparently sophisticated macro programming language, and these toolbars and commands help with database and record manipulation; an email is just another document in the database to Notes, but that's not how users see an email record. I read somewhere that the original developers built the email app originally just to show what could be done with the language; but it turned out that customers wanted emails more than the databases.)
  • That said, Notes STILL doesn't have a threaded message feature as Outlook does and it regularly frustrates me. Add to this annoyance the extra one that [my workplace's] Notes team has turned off full-text indexing, so searches are slow and incomplete, and you can't search within file attachments. I can't say enough bad things about Notes.
  • It would be easy to blame the users for not managing their emails, but the problem also lies with the app developers who either don't listen or are unable to accommodate technical improvements that might make life a little easier for their users.
  • I think these users were not taught good work habits, basically, and probably expected Notes to do the thinking about their work for them (there I go, blaming the user). I doubt any of them had 90 voicemails just sitting there, yet they'd have twice that many emails just sitting there. What is it about the email UI or the promise of email that makes people think their work is done?

On the subject of Gmail Overload, here are two links to how a PR guy uses Gmail as the center of his information universe. These postings include links to other articles in the series where he contorts Gmail into painful positions.

Micro Persuasion: Turn Gmail Into Your Personal Nerve Center http://www.micropersuasion.com/2007/02/transform_gmail.html

Micro Persuasion: How to Use Gmail as a Business Diary and More Tips http://www.micropersuasion.com/2007/04/a_few_weeks_bac.html

This link is to a guy who thought email was great and now thinks it's bad. THE WORLD QUESTION CENTER http://www.edge.org/q2008/q08_print.html#pollack