Talk:Design/Whiteboards/Better command access

    From The Document Foundation Wiki

    A few questions/comments about the behaviour (Astron 2012-01-03T13:25:07 (CET))

    • How can the user keep the icons organised? (How) can separators be moved?
      • One thing I could imagine is always moving topical blocks of icons, for instance when moving bold, you'd also move italic and underline together with their separators. Same for superscript/subscript, undo/redo, cut/copy/paste/format paintbrush etc.
    Icon organization would still be done through the "Customize..." menu for now. Dragging to or from the overflow menu would only change the shown/hidden status. --Mirek2 2012-01-03T19:05:04 (CET)
    Dragging/dropping into a toolbar usually adds a command in a specific place in the toolbar. If d/d just toggles visibility and inserts the icon into a seemingly random place that won't make much sense to users (at least to me it doesn't). It would be easier to use tick boxes for that, then – that would look as before, though one line in a menu would now contain two commands: the command itself and a visibility toggle (hardly an ideal solution, I admit). --Astron 2012-01-04T11:03:26 (CET)
    It works like dragging a file into a folder: it doesn't matter what place you drag the icon to. The reasoning for this limitation is so that people don't reorder their toolbar commands by accidentally dragging and dropping icons when they only meant to click. --Mirek2 2012-01-11T00:10:48 (CET)
    A toolbar is different from a file manager view. A file manager view is a sorted list (by name, by type, by date, or by size). Toolbars on the other hand are custom lists that don't (and shouldn't) follow any such automatically constructed order – custom lists should be sortable by the user.
    Can you think about the move-blocks-of-items idea again, please? I really like it myself (sorry about my self-content here) and it should be pretty practical given that no one would really want to move Undo into a different place than Redo, for instance. It would actually be pretty easy to define what such a topical block is, too: everything that is between two separators (or beginning or end of the toolbar and another separator) --Astron
    Having read this again, I would say you're right. (Perhaps I misinterpreted the idea the first time I read it, or maybe I skipped over it by accident.) +1 --Mirek2 2012-02-04T21:52:02 (CET)
    • How can commands that don't come standard with the toolbar be added?
    Through the "Customize..." dialog. --Mirek2
    I see. --Astron 2012-01-04T11:03:26 (CET)
    Or perhaps, later on (separate from this proposal, once all commands have an icon), by drag-and-dropping from menus. --Mirek2 2012-02-04T21:52:02 (CET)
    • Should the Customise... dialogue remain unaffected?
    This proposal doesn't involve the Customize dialog, except perhaps it could include a "Show overflow menu" checkbox. --Mirek2
    For love of all things, no more configurables than we already have, please. --Astron 2012-01-04T11:03:26 (CET)
    How about having the overflow menu listed as a regular toolbar item at the bottom of the command list? --Mirek2 2012-01-11T00:10:48 (CET)
    Who would we include that item for (what's the target user)? I am really unsure if we need that. --Astron 2012-01-13T16:00:55 (CET)
    It would be there for people who would rather hide the ellipsis menu. I was merely asking if it might be a good idea -- not sure if it would be myself. --Mirek2 2012-02-04T21:52:02 (CET)
    • If yes, how can it be reached from the toolbar? (I believe that should be possible)
    Right-click, "Customize toolbar..." (like now) --Mirek2
    I see. --Astron 2012-01-04T11:03:26 (CET)
    • Can toolbars be locked? If yes, how?
      • A little lock next to the ellipsis icon?
    Right-click, "Lock toolbar position" (like now). As for a lock icon, locking a toolbar is such a trivial and seldom-used feature that it doesn't deserve a prominent position. We should strive to keep the user's focus on the document and not encourage him to fiddle with the interface much. As for a little icon, we should make LibO accessible for touch screens and shaky hands (some people can't click small targets). --Mirek2
    Agree with your reasoning. --Astron 2012-01-04T11:03:26 (CET)
    • How can toolbars be closed?
    Through the view menu or, again, the context menu. --Mirek2
    • What will the context menu of toolbars show (if there is one)?
    The same thing it does now: this proposal doesn't concern the context menu. --Mirek2
    Won't that lead to useless duplication of functionality and inconsistency (as we have the same visibility toggles in the context menu, but this time working differently). My proposal would be to remove the whole "Visible Buttons" menu from the context menu, then. --Astron 2012-01-04T11:03:26 (CET)
    I agree. --Mirek2 2012-01-11T00:10:48 (CET)
    • Will the menu remain open after dragging something in or out?
    Yes. --Mirek2
    Please add that to the spec – in fact, please add anything that seems useful in this discussion page (reasoning, too) to the spec. --Astron 2012-01-04T11:03:26 (CET)
    Done. --Mirek2 2012-01-11T00:10:48 (CET)
    Good! --Astron 2012-01-13T16:00:55 (CET)
    • How can the fact that you can drag and drop icons be made more obvious?
    We could show a tooltip with the text "Drag-and-drop icons from/to here to show/hide them in the toolbar." under the overflow menu. Or perhaps the simpler "Drag-and-drop icons to the toolbar to keep them there", hoping that it will occur to the user that he can do the reverse to undo this. --Mirek2
    How often/when exactly should we show that tooltip? (It might become annoying.) --Astron 2012-01-04T11:03:26 (CET)
    The tootip could have an "X" button on the right. --Mirek2 2012-01-11T00:10:48 (CET)
    So the behaviour would be: show it everytime the ellipsis menu is opened, until it is dismissed via the "X". Then never show it again. Yes?
    Yup. --Mirek2 2012-02-04T21:52:02 (CET)
    • Maybe the overflow menu doesn't even need to be a menu and could be more of a window (like Firefox's Customise... window)? (Is that going too far?)
    The primary function of the overflow menu is quick access to lesser-used commands, NOT customization of the toolbar. --Mirek2
    In hindsight, I see why that was a dumb proposal on my part... sorry. --Astron 2012-01-04T11:03:26 (CET)
    • Is the overflow menu important enough for the average user to warrant a full 26²/24²/22²/16² [1] px icon?
    I think so. Anyway, I'd like this menu to be as easy a target as the other icons are and to be accessible for tablet users. --Mirek2
    Fine. --Astron 2012-01-04T11:03:26 (CET)
    • It might be a good idea to define non-goals, e. g. (pick/amend what you find useful)
      • Change the context menu (I don't necessarily agree with that)
      • Make customization easier (if we put the "Customize..." item in the context menu/View menu only, we do make it harder to customize after all.
    Now that I think about it, changing the context menu should be part of the proposal -- at least removing the "Visible buttons" item. In the newest version of LibreOffice, "Customize..." already appears only under the context/View menu. --Mirek2 2012-01-11T00:10:48 (CET)
    Having "Customise.." in the toolbar's context menu does have some additional value: the appropriate toolbar is pre-selected already, so that duplication of the "Customize..." command makes sense to me. --Astron 2012-01-13T16:00:55 (CET)

    More Comments by Astron 2012-01-13T16:00:55 (CET)

    • How do we detect that the user wants to drag something?
      • Firefox uses a pretty clever mechanism to detect whether the user wants to detach a tab or just wants to reorder her tabs: if you drag the tab under the tab bar, Firefox detaches it; if you drag it onto a different place in the tab bar, Firefox inserts the tab there
      • Proposal: detect that a user wants to drag something only if he drags the cursor with the element out of the toolbar or if he drags it at least two icon lengths forward/backward. If we detect a drag, do one of these two things immediately:
    1. open the ellipsis menu
    2. show some sort of trash can sign (maybe there's a better icon) in place of the ellipsis menu icon (like in Gnome Shell)
    Yes to everything except the trash-can icon (having the icon change indicates that the function button has changed -- it hasn't). Perhaps we could make the ellipsis icon glow somehow or perhaps just increase the contrast so it's more noticeable. --Mirek2 2012-02-04T17:58:20 (CET)
    • How is the dragging visualised?
      • Proposal: show icon(s) at ~75% opacity, keep alpha channel information, so we don't have ugly white borders around the icons.
    +1 --Mirek2 2012-02-04T17:58:20 (CET)
    • IMHO, in the ellipsis menu, there should be a separator between the hidden items and the items that can't be shown because there's not enough space left in the toolbar. (Otherwise the situation might get confusing for users that want to drag something in the toolbar, when the toolbar can't hold it any more.)
      • Proposal: greyed-out entry with the text "Hidden Commands---------------" ("---" should be a solid line)
    OK. --Mirek2 2012-02-04T17:58:20 (CET)
    • Can you add two or three target users, please? Example:
      • Meredith is a secretary in a pharmaceutical company. She knows the office applications she uses fairly well and in her family she is regarded as a bit of a computer guru. Usually she writes letters, prepares speeches for executives etc. Occasionally, because of her reputation, co-workers ask her to edit technical documents with simple chemical formulas in them. For this, she needs to use the sub-script/super-script functionality that she otherwise doesn't access in her daily work.
      • More: (look under "imaginary users")