Bug 112233 - Properties tab buttons move when clicked
Summary: Properties tab buttons move when clicked
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Dialog
  Show dependency tree / graph
 
Reported: 2017-09-05 14:12 UTC by Elliotte Rusty Harold
Modified: 2018-06-26 07:49 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Attachments
after (36.23 KB, image/png)
2017-09-05 14:13 UTC, Elliotte Rusty Harold 		Details
before (41.19 KB, image/png)
2017-09-05 14:13 UTC, Elliotte Rusty Harold 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Elliotte Rusty Harold 2017-09-05 14:12:16 UTC 
Description:
See attached screenshots. The buttons in the document properties windows change position when clicked. Ie. click in the top row and the top and bottom rows swap.

This violates a fundamental principle of UI and impedes muscle memory. The selected button should change appearance (which it does) to indicate that it's selected but it should not move.  

Steps to Reproduce:
1. Open a document 
2. File > Properties...
3. Click any button in the top row

Actual Results:  
rows swap

Expected Results:
rows shouldn't swap.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Comment 1 Elliotte Rusty Harold 2017-09-05 14:13:36 UTC 
Created attachment 136031 [details]
after
Comment 2 Elliotte Rusty Harold 2017-09-05 14:13:54 UTC 
Created attachment 136032 [details]
before
Comment 3 Buovjaga 2017-09-10 15:34:50 UTC 
I guess they move because of wanting to keep the active tab immediately next to the content area.. It is a bit confusing. Let's ping UX.
Comment 4 V Stuart Foote 2017-09-10 16:46:15 UTC 
And what happens if you drag the Properties dialog wider?

The stacking of the tabs makes it seem as if they shift--they don't.  NAB
Comment 5 Buovjaga 2017-09-10 16:58:43 UTC 
Well, this tab-shifting behaviour is in all dialogs with enough tabs, like formatting etc.
Comment 6 Thomas Lendo 2017-09-10 17:59:56 UTC 
Seems to be a NOTABUG because it's worse usability to have tabs that are hanging "in the air" and not linked to the tab content. Is tab appearance not part of the OS design and not changeable by LibO?
Comment 7 Adolfo Jayme Barrientos 2017-09-11 06:42:28 UTC 
At least in Windows and Linux operating systems, when a dialog contains more tabs than its width allows, the active tab will always be displayed next to its container, and its row will shift to be below, or closest to you, of you can picture a literal stack of folder tabs. That is the metaphor, and it’s an expected behavior. During the ’90s, it used to be common for a tab strip to overflow by remaining in a single row but sliding (as Firefox does today), but this was abandoned because it hid the options from the user, hurting discoverability (not an issue for Firefox, where the tabs are actually the content the user explicitly opened).

This makes it a WONTFIX… Except that in 6.0, this dialog was made a little wider so that it can accomodate the tabs in a single row, so you won’t see two rows anymore.
Comment 8 hasan md mahamudul 2018-06-26 07:43:05 UTC Comment hidden (obsolete)
Comment 9 Akshya Kumar 2018-06-26 07:44:26 UTC Comment hidden (obsolete)
Comment 10 Akshya Kumar 2018-06-26 07:49:49 UTC Comment hidden (obsolete)