On 30 May 2016 at 16:30, LucaDC <dicappello@...2144...> wrote:
Personally I find a very bad idea having a list where both my one or
(usually
at most) two grids are listed together with tens of guides because it would
be really hard to find them if that's what I'm looking for.
Just give grids and guides each their own space because if they have the
same main purpose (snapping) they still are different tools with different
characteristics.
I was thinking about that, too. The easiest solution would be to sort
them alphabetically by their ID (which probably isn't changed by hand,
normally), so guides and grids would be grouped that way. But of
course there are advanced ways to do that. 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?
On 30 May 2016 at 16:59, LucaDC <dicappello@...2144...> wrote:
Personally I find convenient having a single place where all
specific
document options are grouped because in this way they can be better spotted,
understood and controlled.
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 agree that having them near where they are used could be convenient
too
and for this I'm not against having different access points to the same
option.
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.
On 30 May 2016 at 17:08, LucaDC <dicappello@...2144...> wrote:
My opinion is that toolbars are good for frequent actions, where you
really
need to have a rapid access.
Personally I don't spend so much time playing with snapping's internal
options so I don't like the idea of having them take some of the already
little space still available in the GUI.
Not a good argument but the main toolbar besides the snap toolbar
would still be longer. But I agree with you that the snapping toolbar
is already very crowded and that the toolbars should only contain the
commonly used options (or hide the less frequently used ones by
default).
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. So, against my previous statement, I think it would
be better to move them to the other snapping settings in the global
Preferences dialog or just remove them if they are not used at all.
As I said before, I'd expect the snapping mechanisms to be smart
enough (what they IMO mostly already are) that those options are not
needed.
Sebastian