Re: [agile-usability] OT: Managing ToolBar Items, Menu Items and Contextual menu Items
- You could ask them what they prefer and go from there. That way you'll cover their needs without going overboard.
TimOn 3/1/07, Lacroix, Eric <Eric.Lacroix@...> wrote:
Does someone has ever has this kind of issue regarding the management of those items (ToolBar Items, Menu Items and Contextual menu Items) for a specific application. Right now we are using a really messing Excel Spread Sheet Into that sheet we have the fallowed columns (pers language):
· A unique identifier (EX: MNU001 );
· A Text Colum (EX: Tools);
· An Access key Colum (Ex: T)
· An Hint Colum whereever is applicable
· A Shorcut colum (Ex: Ctrl+G)
· An Image Colum if applicable
· The kind of editor requested (Ex: Button, Drop down, Edit Field…)
· And so on…
Right now have have several complain from several roles (Tech Writer, UseCase Writer, QC, Developper) about the usability of this kind of specification document.
Does someone could suggest me something?
Kei te kōrero tiki au. Kei te kōrero tiki koe. Ka kōrero tiki tāua. Kōrero ai tiki tāua.
- --- In email@example.com, "Tim Wright"
> You could ask them what they prefer and go from there. That way
> their needs without going overboard.I would step back and ask them and yourself, "why is this table there?
How will it be used? Who will use it?" Essentially, use the same
design process that you're using on the software for the table.
If you're using use cases, who will use the data in the table? How?
Why? What is the use case?
Then, based on how the contents of the (current) table will be used,
you can figure out the best representation for what currently is in
the table. Maybe, the best representation isn't a table. Or, maybe,
the thing to do is to have a primary representation that isn't a table
(say a wireframe with callouts), but you still want to have a
secondary representation that is a table for certain elements (say
Having taken the approach of what works / what doesn’t with our own spreadsheet I found the following:
Including the columns is still good (allows you to better see things like when you have repeated shortcuts, etc). Also beneficial when developing related products so that menu options are the same or similar when appropriate.
Displaying the menus in a visual way that also represents how they will appear in the interface is also good (like the one below). This example (from a spreadsheet) includes hotkeys and mnemonics as well as displaying what’s at what level in the menu.
Those that don’t care about the stuff in the columns can “hide” it and concentrate on what they might look like in the app.
Example Study Configuration…
Open Recent }
Graph as Template…
(Message over 64 KB, truncated)