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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
