Re: Nautilus Sidebar

[Havoc Pennington <hp redhat com>]

Hi,

Who wrote:
> I eagerly await any feedback you have relating to the idea itself, the
> feasibility of the way I suggested doing it, or anything else related
> to this.

Since you asked :-P I think you could spend more time on some useful 
exercises that we're calling "define, research, ideate, prototype" at 
Red Hat, but if you don't like those names you could call them something 
else... but they are still useful ;-)

Here's my attempt to write it down:
 http://developer.mugshot.org/wiki/Design_Thinking

These aren't original ideas on my part - the "7 steps" version is from 
the Red Hat "brand communications + design" group and several Red Hat 
teams are using it, and you can find many different versions of it in 
the "bibliography" list at the bottom of the wiki page. The specifics 
aren't really the point.

You've got some good research notes on existing solutions on your 
sidebar page already, that's a good start.

Here are some more specifics about how this could apply to your project:

1. define - what problem are you trying to solve for which audience? or 
pick a short list of problems for specific audiences, if you can't 
choose. but it's very helpful to come up with something(s) specific for 
the first iteration.

I think this thread and your page could benefit from breaking apart some 
of the specifics here... e.g. maybe one of your items is RSS reading, 
and another is a set of specific actions on files, another is [whatever]

The problems don't necessarily all have the same solution... maybe some 
are best done with a sidebar, some best done in other ways. It's 
important to define the goal in terms of user needs/desires, not any 
particular solution.

2. research - you have some good notes on historical sidebar stuff, but 
say you step back to define the problems more specifically, can you then 
research non-sidebar solutions to those? e.g. are there other ways 
people already read RSS or do the file operations? can you learn 
generally about the users in question and what their highest priorities 
are? If the problem is low usability, is there some quick hallway user 
testing you could do to confirm that there's a problem and exactly where 
it is? Maybe look at some of those videos Novell made?

I would keep some separate research notes for each specific benefit to 
specific audience defined earlier. It's a useful discipline to keep the 
process and the info organized around specific benefit to specific 
audience, rather than around proposed solution (such as a sidebar).

3. ideate - set aside the sidebar solution for 45 minutes, grab a couple 
friends, and just try to whiteboard out the wackiest ideas you can think 
of - number the ideas - try to get as many proposals as possible. Think 
about separate apps, about nautilus features, about panel features, 
about anything you can come up with. The goal is to have some more good 
options in addition to the sidebar - ideally some of them are even 
all-new untried concepts.

To work this has to be a wacky idea session, think toys and post-it 
notes, not a discussion or debate ...

Disciplined brainstorming alone can work too, e.g. techniques like 
drawing a free-association mind map on a piece of paper.

4. prototype - you'll start doing rough sketches while brainstorming, 
continue that. Get a little more detailed. Pick some of the best ideas 
you have and draw (it can be ugly) what they would look like and kind of 
walk through how someone would use the interface to solve the problem 
you defined back in 1).

If you have trouble doing multiple different prototypes, try and get a 
friend or someone else to draw their own version. Right after 
brainstorming, suggest that everyone spend 15 minutes drawing a 
storyboard, then get back together. (You'll quickly find that two people 
talking about "the same thing" will draw the specifics in a very 
different way.)

Ideally, bounce the prototype off some of the users it's supposed to be 
designed for. See what they think.

Look at merging the best of different prototypes you come up with.

Switch to a code prototype when you feel ready, but have the goal of 
"roughly working" within a pretty short time, get to something you can 
try out.


Throughout all this try to keep an open mind - be willing to decide a 
problem doesn't need solving, or that the solution is in Firefox instead 
of GNOME, or whatever...

It doesn't have to take more than a few hours for a first cut. It's not 
supposed to be hard, just a little discipline to focus the thinking.

You can think of the steps as ways to focus thinking in particular ways:

 define -   be sure you focus on specific needs/desires of specific
            people instead of technologies - nails not hammers
 research - be sure you check in with reality for inspiration and
            validation - keep speculation to a minimum
 ideate -   be sure you give yourself lots of options, including
            brand new ideas - don't assume the set of choices is
            already known
 prototype - be sure you are thinking concretely about real designs, and
            not abstractly about concepts

Havoc