This whiteboard page derived from a "Calc performance" related discussion. It was concluded that progress bar drawing consumes a lot of time - so a few proposals were made (visual design, behavioral design). See also the discuson thread Performance improvements for calcs' sheet actions .
Specifications and Related Documents
UI Related Specifications
Human Interaction Guidelines (Progress Bars):
- GHIG: Gnome HIG, Progress Bars, especially Progress Bars in Statusbars
- WUXIG: Windows User Experience Interaction Guidelines, Progress Bars
- AHIG: Apple Human Interface Guidelines, Controls, Indicators
Collection of progress indicators: Matthias Müller Prove: Progress Indicators in OpenOffice.org (OOo Specification Project), October 2007
Progress Bar in Status Bar
Example for Writer loading a document (LibreOffice 3.3.2 on Ubuntu) ...
[ $ProgressText... OOOOOOOOOOOOOooooooooooooooooooooooooooooooooooooooooooooo ]
The progress bar spans the full width of the status bar. Symbols:
- [ = status bar area start
- $ProgressText = text explaining the current action
- ... = ellipsis (without space between $ProgressText and ellipsis according UITSG, required for such actions, may already be contained in $ProgressText)
- O = progress bar "done"
- o = progress bar "todo"
- ] = status bar area end
- Progress bar will be right-aligned (distance to the right like today)
- Width of the progress bar is 200px
- $ProgressText is right aligned to the progress bar (distance to the right like today)
[ $ProgressText... OOOOOooooooooo ]
Few Space: If the width of the status bar does not allow to show all items, then ...
- Reduce the width of the progress bar to to show the full text
- The minimum width of the progress bar is 50px
[ $ProgressText... OOoooooo ]
- Is there a need to define the behavior if there is even less space (very small status bar)? Currently, the status bar items are simply "cut off".
- Currently we remove all items in the status when a progress bar is being shown. Are there any actions that (theoretically) could be performed while an action performs (e.g. using the zoom slider during loading a document)?
- Position of the text: $ProgressText shall be placed to the left of the progress bar (GHIG, WUXIG)
- Size of the progress bar: The 200px are a rough guess what might be looking good - it is a bit larger then the zoom slider (approx 185px).
- Position of the progress bar:
- The position and size of the progress bar is always constant and thus predictable for the user (easier to guess the current progress). Furthermore, progress bars for subsequent items don't move the progress bars (e.g. Calc; first loading, then calculating the document).
- Enables to add (later) an abort button which position is always the same (at the right side)
- Note: It is accepted that the readability of the text is reduced, due to the different positions (length of the progress text varies)
- Some $ProgressText sometimes do omit the required ellipsis (this is wrong); should be checked! (UITSG)
- German: Some $ProgressText start with lower capitalization instead of Sentence Capitalization (WUXIG, AHIG)
- Mail thread started by Thorsten Behrens UX Progress bars - convey "this make take some time, dunno how long"
OpenOffice.org Issue Tracker:
- i#111905 - Save progress bar should remain until UI is enabled
- i#19986 - progress bar/indicator needed during data insert in Calc
- i#13402 - improve the open/save progress bar
LibreOffice Issue Tracker:
- tdf#32476 - No progress bar when opening password protected documents from WIN Explorer