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-tp4...
Sent from the Inkscape - Dev mailing list archive at
Nabble.com.