On Thu, 13 Nov 2003, T Ingham wrote:

Hello again all,

This memo will serve to be the genus for what I would eventually like to propose. I'm hoping for plenty of feedback from everyone to make this tool as useful as possible. The core concept is quite simple really, enumerate and visually explain all editable parameters of a given shape on the canvas in a single floating palette.

Please post this to Wiki, as that is a more suitable place for such well-thought-out proposals, and that will be easier to update. Also please post pointers to it here on this list periodically as it gets updated, to remind folks to continue review it.

1. Problem Although much work is being done to promote existing dialogs to the

status of sane players on the workspace front, there are still pitfalls in having all manner of oversized and disproportionate dialogs open on the screen. Namely is simple visual clutter. Having several windows open at once can cause both new users to become lost quickly, and more seasoned users wasting time fidgeting with dialogs to position them according to their wishes.

Agreed. The dialog situation is a frequently mentioned concern from new and potential users, and getting it wrangled and simplified would do a world of good.

A commentor on GnomeDesktop writes: "But, you've got to clean up the menus/interface - when the drawing starts it's really a mess and first impressions to users mean a lot. It really should open up a frame with menus across the top and toolbars whereever. While it was easy enough to create a new drawing - I couldn't figure out how to resize the page/drawing. These are the first things a user does so it should be there and be good. Compared to Karbon, the toolbar/menu thing is a mess. This should be relatively easy to fix and will go a long way to winning over users."

2. Accessibility concerns Using many dialogs, users that cannot or do not use the mouse are

asked to traverse 3 tiers of information to edit shape data outside the canvas. First they must achieve focus on a dialog ( ctrl+# ) , second they must select ( in some cases ) a tab containing the subset of data they wish to manipulate ( tab key? ) and third they must gain focus on the cell or control that allows them to make the edit ( tab key? ).

3. Solution Provide an additional ( or alternative depending on how you lean )

palette for editing shape properties that contains an hierarchical list of property groups and properties. This window would behave exactly as other palettes ( esc to focus canvas, enter to affect change ), but would centralize object properties in one dialog minimizing the memory cost to the user for keyboard shortcuts to open dialogs ( they would only need one, and we could make it an easy one, cmd+i // get info // ) Once the dialog has focus, the user could then use the arrow keys to locate the property they wish to edit and affect the change desired. While it may seem that we will lose the specificity of multiple dialogs, this interface would provide us with a more open method of combining property sets, and in the future it could be used as the basis for generating custom property dialogs per user utilizing xml documents to store dialog layout information.

In general this sounds like a good approach, although I'd really like to see an example. Please add an example when you post this to Wiki. Describe how this would work for the particular shapes already implemented, as well as ones that may be added in the future. Itemize a list of exactly what properties would be included. Perhaps create some mockups of this conglomerated dialog.

Also needed is a proposed rule for how to discriminate what should and should not be in this dialog box. Perhaps go through the current dialog boxes and identify which should be incorporated here, and which should not.

4. A few key points It appears that currently, you cannot enter a numerical value in the

float fields of the color dialog, is this intended behavior?

Wrong question. Is this the _expected_ behavior? If users need to have the capability of entering numerical values, then this should be submitted as a feature request, so it can be implemented as resources allow.

Users would be able to close tree paths in this new properties

palette that they might not use often, this allows the user to immediately improve their productivity when performing these types of edits.

Thanks for your time as always, I hope this stirs the pot a bit.

-Thomas

It'd be worthwhile to hear other people's thoughts on this proposal.

Bryce