Talk:Proposal by Andreas Schuderer
From Apache OpenOffice Wiki
Ideas:
- Include commands like "Reveal property XXXXX" in the set of invocable 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).
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.- 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.
- Extending on the previous idea, it would be best to combine those "tabs/TOC items" with the scrollbar. You would get an indexed scrollbar, so to speak. It would show the "tabs" exactly where their corresponding scroll position lies, giving better cues about their positions. You could click them directly to jump directly to their position. Or you can use the scrollbar just as you are used to it. Think "OOo 3.0 zoom slider with ticks for page width, etc., but with labels for those ticks"
- Advantages
- Saves space
- Unifies the discrete concepts of "scroll area" and "tabs/table of contents" into a simple, comprehensive, yet powerful concept: An indexed scroll bar.
- Will immediately be understood as a scroll bar and can be used as such. The indexing will make itself clear automatically through its spatial arrangement.
- Scroll bars are already understood, Tables of contents are understood.
- Faster to use than scroll bars or TOP-aligned TOC alone
- Combines benefits of scroll bars (continuency, spatial arrangement) with that of tabs (quickness)
- No need to highlight any "tabs" (as described in the previous idea). The scroll bar position will make clear where I am.
- Disadvantages
- Non-standard control: Difficult to implement on different platforms in a way so that every user recognizes it as a scrollbar.
- Conventional scrollbar position is to the right of the scroll area: This limits the ways in which this control can be used. If I want a right sidebar with the "tabs" to its left, the scrollbar will be positioned left of the scroll area, which would be unexpected to most users. To use it for the properties sidebar, we would have to make the choice: (a) Flout the scrollbar position convention, or (b) forfeit the advantage of having the "tabs" to the left, near the content area where they are quick to reach, or (c) position the sidebar to the right.
- Advantages
--Anjoschu 16:13, 10 July 2009 (UTC)
