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