Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 382044

Summary:

ergonomics of git status 2 - criss-cross applesauce

Product:

[ECD] Orion

Reporter:

Susan McCourt <susan>

Component:

Client

Assignee:

Project Inbox <orion.client-inbox>

Status:

RESOLVED WONTFIX

QA Contact:

Severity:

normal

Priority:

CC:

libingw

Version:

0.5

Target Milestone:

---

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
screenshot	none

Description Susan McCourt

2012-06-07 14:29:54 EDT

Opening this bug on "client" because it's really a general problem with the way we are placing actions, section controls, etc., but git status 2 is the concrete case right now.

The left/right positioning of the various commands and section controls create patterns where I am constantly moving my mouse left and right across the page. I feel like I'm traversing a ski hill. ;-)

It's a combination of a lot of little things, so let me try to describe the scenario.

I work in a 1600 pixel wide screen mode. I had a set of 4 changes and Simon was waiting on me to build RC1. So I was in a very paranoid "check every change" mode. Don't want to sneak a regression in. So I open git status 2 and see my 4 files. What I want to do is open and check each change carefully, and then close it as I'm happy. (Or perhaps stage as I go.)

1. Click left to open the first change.
2. Move far right to traverse each change using prev/next in the section controls or to scroll the compare widget and/or the browser page. Look at the code. I'm happy with the change.
3a. Move far left to choose the default action for stage. OR
3b. Move far left to collapse the widget. OR
3c. Move up to select the change and then up again to stage.

In 3b., sometimes I get tricked by the expand/collapse buttons on the section header and want to push them to collapse my change.
3c. is ergonomically the best choice, but selecting and staging while the widget is open is just not natural to me, I lose context when I do that, so I just tend to collapse.

So not only is there the criss-cross effect, but we have some inconsistencies in the way sections expand and the items expand, etc.
- with sections you can click on the section name and/or twistie
- the inner items force you to click on the twistie
- to a user the items look the same so why do they act different?
- expand all/collapse all are on the right, while twisties are on the left
- the expand/collapse icons use the +/- metaphor though we are using twisties

All this adds up to some cognitive dissonance that makes me have to think about it. I think a little "relaxing" and some shifting around of things could really help, as well as feedback:

- hit areas in sections and items could be similar. If I don't have to go all the way to the twistie that helps in step 1.
- perhaps some hover feedback so you know where expand/collapse is active
- perhaps default action placement should depend on the page/what the user is doing. Having stage on the right might make sense here because if you are staging one by one, chances are you are looking at the diff and already on the right.
- these sectional pages get long so we have to respect that the user might be on the right scrolling already

Comment 1 Susan McCourt

2012-06-07 14:38:08 EDT

Created attachment 217046 [details]
screenshot

Comment 2 Susan McCourt

2012-06-07 15:14:29 EDT

this idea might be overkill, but...

in the main toolbars on the pages, we put "view controls" such as pagination, or expand/collapse all, or prev/next on the right.  The idea is that you are already over there scrolling, so anything that is shifting your viewport is close at hand.

It seems like the twisties are the one place where we force you to the left to change your view.  And if you are expanding/collapsing sections or items to manage your view, you are probably scrolling too.

For section headers, I wonder about putting an expand collapse control somewhere on the right.  We could still keep the twistie, as it shows what state you are in, and it could still be active.   But maybe another place on the right you can click.  Having the whole header be active for expand/collapse had problems (bug 381753) because it was too easy to expand/collapse when you're trying to hit a command button.  So maybe an expand/collapse control on the right could help.  Perhaps for the inner items as well, an expand/collapse control.

This would at least let me stay in one place to do all my scrolling, expand, collapse, prev change/next change viewport stuff....

Comment 3 libing wang

2012-06-07 15:54:35 EDT

Apart from what Susan "complained" from a mouse user point of view, here is my workflow when I am checking all my changes before commit them.

1a. Open status page and click expandAll then click on the first row.
1b. Open status page and click on the first row and use right arrow key.
2. From now I never use mouse.
3. Use down arrow key to go to widget. 
4. Use right arrow key to go to the prev/next diff command.
5. Enter key to traverse diffs.
6. Use down arrow key twice to the next widget. repeat 4-5.
7. Use up key till I reach the top row again.
8a. Use shift+down key till I select all the rows
8b. collapse all and use mouse to select all.
9.Stage and commit.

Things I do not like from a heavy key user point of view.
1. When I switch to side by side from grid, I am losing the explorer's focus. 
2. would be nice if I can change&save on the fly when checking diffs.
3. Sometimes I need side by side view by default, specially when I change a block.

Comment 4 John Arthorne

2015-05-05 14:39:23 EDT

Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see:

https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html