Talk:Proposal by Andreas Schuderer
From Apache OpenOffice Wiki
Ideas:
- Include commands "Reveal property XXXXX" in the set of invokable keyboard commands. These commands will behave analogous to the "hyperlinks" in the Activity Guides (see the corresponding section for a detailed description of their property revealing behavior): Just selecting the command (not yet executing it -- remember you can step through a list of suggestions using the arrow keys) temporarily reveals the property in the sidebar. If the command invocation is cancelled at that point (e.g. by typing gibberish or hitting Esc), the properties sidebar is returned to its previous state (important!). If (and only if) the command is actually executed, the state of the sidebar stays the same, i.e. the property stays revealed (and is temporarily highlighted). (I've not yet made up my mind whether the property's control element (widget) should also get input focus. This might provide an efficiency/accessibility benefit. The Activity Guide "hyperlinks" should always behave analogous, so if the command puts input focus on the corresponding control, so should the Activity Guide "hyperlinks".
- In the properties sidebar, use something like vertical "tabs"[1] in addition to behaviour described in the proposal. That is, leave the free scrolling and collapsable groups in place, but additionally provide a row of vertical "tabs" at the side of the sidebar, which act as bookmarks/hyperlinks to the scroll position. Those "tabs" are thus essentially a linked, always-visible "table of contents". They augment a possible shortcoming of the scrolling approach: You benefit from your muscle memory! With free scrolling (which is still possible), the current vertical position of an element may vary between uses. Now, you can click on a "tab" (always same position), and then click on an element (always same position after clicking this tab). This improves gesture-forming. But it's still important to retain the free scrolling. Providing a quicker way to access functionality does not mean chopping it up into discrete chunks (where the user has to click through multiple tabs to find what they are looking for).
- When the user clicks on the vertical tab, the sidebar smoothly scrolls to the corresponding position. So, they're really just shortcuts to a particular scroll position.
- Scolling is animated (500-1000ms) so the user sees whether the position is above or below the current position, and gets an idea of how far away it is located.
- The "tab" bar should be located on the inside of the properties bar, to provide quick access when coming from the content area.
- The "tab" that corresponds to the current position is highlighted. That means that when clicking a "tab", you don't just scroll to the corresponding position but the "tab" is also highlighted, indicating where we now are (analogous to tabs as we know them). But highlighting is also kept up-to-date when scrolling with the scroll wheel or scroll bar. Simply put, "tab" highlighting always the current position. The rule for determining which "tab" to highlight is: Starting at the vertical middle of the sidebar, search upwards and take the first "tab" bookmark position you find. This is the tab that should be highlighted.
[1] I'm enclosing "tab" in quotes because they don't entail showing/hiding stuff like tabs usually do, but essentially just provide a quick way to scroll the sidebar to the corresponding position.
--Anjoschu 11:44, 10 July 2009 (UTC)
