Sebastian Zartner wrote
I'd like to know what you mean by 'their own space'. Add a group header to the list? Two lists? completely separate editing UIs?
I was thinking about separate editing UIs, where, if you really want, you may have two separate lists. I'm not a big fan of a guides' list because I don't see a quick way to connect what I see in the list to what I have in the canvas and if I need to address a guide in the canvas the quicker way to work with that object is dobule-clicking on it, not opening a document wide dialog and looking for it in a huge list.
In general I expect a global UI to act on global options and not on single objecs, and single objects' UI not to affect global options (because it could be confusing as you may miss the boundary between local and global). Grids are global objects so a single central menù has sense. Guides are usually non global objects because each one has its own motivation and is contextualized. I feel this concept is enforced by the fact that guides are editable by the mouse while grids are not (and IMHO this is the correct behavior).
Sebastian Zartner wrote
For me it is a bit strange to find scripting, snapping, etc. in the same dialog as document meta data or the page format, which was one motivation for creating the blueprint.
I'm not disturbed by finding different configurations packed in the same interface provided they are well organized. The current tabbed UI where each "argument" has its own space is fine to me. I agree that users may look for the same piece of interface starting from other places so in this case it's a good idea to split the accesses into each single function addressed by the configuration UI. It all boils down to what you need to do: if you just need to change all guides' color because you have a blue background, you'll probably start from all in the UI that deals with guides. I usually prefer opening the document's options dialog just after creating a new document, sweeping all relevant configurations to set them to what I need and then start working in a globally already set environment. Would it be too hard to let users access the same configuration dialog both by its own from the tool and tabbed in the general document's options one?
Sebastian Zartner wrote
The main goal of the blueprint is to improve the UX by tightening the dialog up and moving the options to the places where they are rather expected, i.e. improve their discoverability.
As I tend to look for a global options dialog, for me splitting the configurations into many small independent dialogs would negatively impact discoverability. But, of course, we are all different so this could be the opposite for others. I still think that to really improve discoverability, different access points for the same dialog should be provided; just like how the same function can be triggered by a shortcut or by a toolbar menu entry or by a left-click contextual menu and so on.
Sebastian Zartner wrote
Unfortunately we don't have usage data, so we have to guess what options are used/changed frequently and which are not.
Regarding the Document Properties dialog I still suspect that the features there are very seldomly changed and are rather meant to be modified globally.
I won't base the decision on "most frequently used" or on usage data, but rather on which options usually need to be changed _while_ working on a document hence deserve a quick click access in the toolbars. I suppose that changing the page size is not an operation you commonly do back and forth while drawing so a toolbar button to set the page size would just be a space waste. OTOH, the same can be said about the two document's and program's options buttons which I don't feel a big urge to have there as their accesses in the File and Edit menus are enough (and removing them would be a start in fixing the missing icons bug in the front UI ;).
Please, take all I've written knowing that I'm not an UI expert (I'm only a U :).
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/UI-Rework-Document-Properties-dialog-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.