Community
Participate
Working Groups
I'm preparing for a demo and am finding this page does not demo particularly well at lower resolution. In particular we have to pull the slider over to the left to show a compare and this cuts the log up. To do a fetch/merge I have to know the button is down lower and scroll to it. Is there another layout we could use that doesn't force us to scroll around and use sliders as much.
(In reply to comment #0) > I'm preparing for a demo and am finding this page does not demo particularly > well at lower resolution. In particular we have to pull the slider over to the > left to show a compare and this cuts the log up. To do a fetch/merge I have to > know the button is down lower and scroll to it. > > Is there another layout we could use that doesn't force us to scroll around and > use sliders as much. We had similar discussion in bug 336116(comment 16). Option 1 : split left pane into two sub panes , where top pane represents unstaged , staged and commit divs and bottom pane represents the two mini logs(most possible in 0.2 but the commit div may not be visible without scrolling) Option 2 : split left pane into 3 sub panes.Top: unstaged and staged . Middle: commit. Bottom : mini logs. Option 3: Make unstaged and staged divs collapsable.
I don't see how splitting into more panes solves Simon's problem - he complained about having to scroll horizontally, or having to move the slider horizontally. Looking at the page with my "demo presenter" hat on, I would propose adding a button to the header of the red/green compare editor. Clicking this button would open the current comparison in side-by-side mode. This would be the simplest incremental change that improves the demo flow substantially. The reason why it would improve the demo flow is that you want to show the red/green compare editor anyway first (for the show effect), and then you can show the side-by-side one without having to scroll horizontally.
Maybe too radical for 0.2, but I'm wondering how it would play if mini-logs were positioned where the compare is, and compare was below. Then you are looking left to right for all the stage/push/merge stuff and looking down when comparing. The trick is making sure you can still select for compare...
(In reply to comment #3) > Maybe too radical for 0.2, but I'm wondering how it would play if mini-logs > were positioned where the compare is, and compare was below. Yes, too radical for my taste :-) The current layout is not problematic if you have a big enough screen, we just need something that improves the demo scenario on 1024x768.
(In reply to comment #2) > I don't see how splitting into more panes solves Simon's problem - he > complained about having to scroll horizontally, or having to move the slider > horizontally. > Actually this applies to the second concern Simon mentioned: "To do a fetch/merge I have to know the button is down lower and scroll to it." I was thinking about "always showing these button no matter how big the stage file list is".
(In reply to comment #5) > Actually this applies to the second concern Simon mentioned: > "To do a fetch/merge I have to know the button is down lower and scroll to it." I am not convinced - if you haven't scrolled down to see the mini logs, you shouldn't be clicking on push or merge buttons anyway, since then you would be doing something blindly. I believe that these actions belong close to where the recent commit history is displayed.
I find the current layout a bit cumbersome even at higher resolution. If I want to see the individual item commands, I have to make the diff small enough that it's not that interesting. So I'm still wondering about top/bottom split for diffs. Linda also commented that it's not clear that "commit" goes with "Staged." She suggested a closer visual grouping. But that got me thinking...We should just have commit as a command on the section heading for "staged" and a slideout could open for commit text, etc.? I'll post a couple screenshot/mockups...just moving some stuff around
Created attachment 210342 [details] screenshot/mockup/brainstorming this shows a top/bottom split Other changes I thought could simplify any layout: - show only one log and let user switch between local and remote - note use of "as of xxx" text rather than "recent"...there is another bug about recent being misleading - commit text doesn't show until you push "commit" and then it appears - amend is moved to the local log and you get a slideout with commit text/author info (not sure about this). We shouldn't do blind amends so I don't see having amend by the "commit" it seems like it should be by the local log. - some fonts, etc. changed. Note we haven't closed on command links vs. buttons. Here I use text for buttons with underline for links
the screenshot/mockup is 1024 x 768.
(In reply to comment #9) > the screenshot/mockup is 1024 x 768. The screen shot makes total sense to me. Just two more things: The top part will have a vertical splitter? Do we keep 5 commits in the mini log or more ?
(In reply to comment #10) > (In reply to comment #9) > > the screenshot/mockup is 1024 x 768. > > The screen shot makes total sense to me. > Just two more things: > The top part will have a vertical splitter? > Do we keep 5 commits in the mini log or more ? I was thinking it was a splitter. Not sure about the size of the mini-log. On the one hand, it seems like we might as well show as much as we can based on the stage/unstage list. No use having blank space. On the other hand, if only one file changed in the stage/unstage, we may want a minimum number of commits, say, 3??? I'm hoping to get Linda (visual designer) to make further suggestions via mockups but I was curious what folks thought of the overall idea. Especially...does anyone consistently use local/remote mini logs such that the idea of making them switchable is a bad one? Also...Libing. There is some infrastructure you'll need for us to make the "push commit and get the edit box" work well in the command framework. That is bug 367220. Ideally you should not have to do too much custom work, I'd like to make sure a "local slideout" does well for you. So we can work on this together. I'll make this bug dependent on the slideout one.
(In reply to comment #11) > Not sure about the size of the mini-log. On the one hand, it seems like we > might as well show as much as we can based on the stage/unstage list. No use > having blank space. On the other hand, if only one file changed in the > stage/unstage, we may want a minimum number of commits, say, 3??? So...to be clear...i would think we would *not* have scroll bars in the log, we'd just render whatever would fit and then clip. Then the user can go to the log page for full log. So I don't know if it's practical to lay it out as "3 commits minimum" but we could css a minimum height that would typically show 3 commits (but if there is a super long message or something, it may be less.)
I chatted with Susan a bit about the git-status page. This is what we seem to do before committing changes. 1) Click a change 2) Go to the tray, scroll through changes 3) Go back to the list of changes and stage the change 4) If there are more changes, click another change, go to (1) 5) When all changes are staged, go to the commit dialog and commit Instead of wandering across the page, I would suggest the following: Show inline compare views vertically per each change in the status. It would be useful if compare views could be collapsible/expandible, then we could for instance expand the first one or just those for text files only. There is a separate bug for collapsible/expandible inline compare views. Each change would have "stage"/"unstage" next to the editor. So once you review the change you can just click it and scroll to another change. "commit" would be a command in the main toolbar enabled when anything on the page is staged. When clicked, the commit popup would slide out. So you could commit no matter where on the page you are. I think that the commit dialog could show the list of files that will be committed, but I'm not strongly attached to it. I would use just one log as on the repo page instead of two. I would place it at the end since this is the least important thing on the page IMO. A side navigation panel would be used to show all sections e.g. changes with editors and the minilog. So you could easily switch between changes or the log using the panel. The side panel would also decorate changes that are staged. Each change name on the status page would be a link. When clicked, it would open the status page, showing just this one change from the status. Then you could also see Next/Prev navigation buttons to navigate through changes in the status. Of course you would also have "commit" action there. I think this model will make it easy to work with changes using both mouse and keyboard. I can try to draw a mockup, if this is not clear...
(In reply to comment #11) > > The screen shot makes total sense to me. > > Just two more things: > > The top part will have a vertical splitter? > > Do we keep 5 commits in the mini log or more ? > > I was thinking it was a splitter. > Not sure about the size of the mini-log. On the one hand, it seems like we > might as well show as much as we can based on the stage/unstage list. > no use having blank space. I think it is a matter of the top pane's height. If there are 100 files changes, you will need scroll bar in the top-left div anyway. >On the other hand, if only one file changed in the > stage/unstage, we may want a minimum number of commits, say, 3??? I think we need a clear visual design then we can decide the size of mini log. E.g. when user makes the top pane bigger, do we chase up to increase minilog size? > I'm hoping to get Linda (visual designer) to make further suggestions via > mockups but I was curious what folks thought of the overall idea. > > Especially...does anyone consistently use local/remote mini logs such that the > idea of making them switchable is a bad one? > > Also...Libing. There is some infrastructure you'll need for us to make the > "push commit and get the edit box" work well in the command framework. That is > bug 367220. Ideally you should not have to do too much custom work, I'd like > to make sure a "local slideout" does well for you. So we can work on this > together. I'll make this bug dependent on the slideout one. Yes. I will follow on that.
(In reply to comment #13) > I chatted with Susan a bit about the git-status page. This is what we seem to > do before committing changes. > 1) Click a change > 2) Go to the tray, scroll through changes > 3) Go back to the list of changes and stage the change > 4) If there are more changes, click another change, go to (1) > 5) When all changes are staged, go to the commit dialog and commit > > Instead of wandering across the page, I would suggest the following: > > Show inline compare views vertically per each change in the status. It would be > useful if compare views could be collapsible/expandible, then we could for > instance expand the first one or just those for text files only. There is a > separate bug for collapsible/expandible inline compare views. > > Each change would have "stage"/"unstage" next to the editor. So once you review > the change you can just click it and scroll to another change. > > "commit" would be a command in the main toolbar enabled when anything on the > page is staged. When clicked, the commit popup would slide out. So you could > commit no matter where on the page you are. I think that the commit dialog > could show the list of files that will be committed, but I'm not strongly > attached to it. > > I would use just one log as on the repo page instead of two. I would place it > at the end since this is the least important thing on the page IMO. > > A side navigation panel would be used to show all sections e.g. changes with > editors and the minilog. So you could easily switch between changes or the log > using the panel. The side panel would also decorate changes that are staged. > > Each change name on the status page would be a link. When clicked, it would > open the status page, showing just this one change from the status. Then you > could also see Next/Prev navigation buttons to navigate through changes in the > status. > Of course you would also have "commit" action there. > > I think this model will make it easy to work with changes using both mouse and > keyboard. > > I can try to draw a mockup, if this is not clear...
(In reply to comment #13) > Each change name on the status page would be a link. When clicked, it would open > the status page, showing just this one change from the status. Then you could > also see Next/Prev navigation buttons to navigate through changes in the status. > Of course you would also have "commit" action there. Something just came to my mind. The status page showing one change could use side-by-side compare editor in opposite to the full git status page using inline views. It would allow to change file while reviewing changes using Next/Prev navigation. BTW there is also a bug against inline compare widget to support modes i.e. switching from one view to side-by-side mode. It would allow to switch inline views to side-by-side editor on the full status page (showing all changes).
An idea from jjb in bug 370893 is that the user could create a new branch at commit time. So that if I forgot to create a topic branch, I could do so at commit time. So regardless of page layout, the commit action could cause a slideout or dialog in which the user could: - change committer/author - amend the previous commit - choose a new branch for the commit
From bug 372802 (jjb) The stage buttons on git-status are not flush to the selections. This has a big impact because this UI is 'compound-action'. First you select all of the commits with the little box, then you unselect some and finally stage them all. To accomplish this the user is moving from button to button. Each move takes time dependent on the button size and distance (Fitt's law). Moving the Stage button to the far right makes the operation take even more time --- For some reason I cannot pinpoint, it's now much harder to notice when files are unstaged versus staged. I find myself trying to type a commit message, only to realize that the files are not staged.
Created attachment 213019 [details] cut and paste mockup Here's a mockup where git status looks a little more like git commit. The main thing is that all content is stacked vertically (no splitters). What would be needed for this to work is a navigation whereby I can select on a stage or unstaged change and immediately scroll down to the diff. I would also need a way to get back up to the list or the logs. See also the discussion in bug 368848. This doesn't really help with some of jjb's latest comments (movement to the right, etc.). But perhaps we could work with those issues in a consistent way across git status, git commit, git repo
(In reply to comment #19) > Created attachment 213019 [details] > cut and paste mockup > > Here's a mockup where git status looks a little more like git commit. The main > thing is that all content is stacked vertically (no splitters). What would be > needed for this to work is a navigation whereby I can select on a stage or > unstaged change and immediately scroll down to the diff. I would also need a > way to get back up to the list or the logs. > > See also the discussion in bug 368848. > > This doesn't really help with some of jjb's latest comments (movement to the > right, etc.). But perhaps we could work with those issues in a consistent way > across git status, git commit, git repo The mockup looks good to me in general. Some questions: 1. Do we want a collapse all and expand all to the compare view? 2. The next/previous diff commands(will have char diff command in the near future) are rendered in the header of the section. I would expect that will be part of the compare widget. The header part is apparently not part of the compare widget. 3. Do we want to show all the char diffs or just for the current diff block?
I think we could use the same widget for incoming/outgoing commits on both git status and commit pages. Libing, if you want, I could start working on the new git status page layout and check if something I made for git commit and repo pages can be made in a more general way.
Szymon, Libing, and I talked about this (among other things) today. Szymon's going to take a pass at this, as an alternate page so that we can start iterating it and comparing it with the current page.
One thing I've been meaning to point out about the mockup: notice that the diffs themselves are sections, rather than having a section called "Diffs" and then a bunch of compare widgets. Makes sense to me that each diff *is* a section since that's how we want to navigate, and there's no action that a user would take on all the diffs. I would think we would do the same in the git commit page.
Created attachment 214454 [details] Skeleton for the new page If you want to see it, just replace git-status.html with git-status2.html. It shows the status, but commands are not hooked in yet. It needs more refactoring, so I'll do it as the next step.
Sorry but I think this is the wrong direction. The current git-status page has the best design of any Orion page and thus should be the last one to be changed. Aligning the buttons on the left *and* right sides has terrible ergonomics. The log summary provides critical context information for formulating commit message.
The log isn't going anywhere (see mockup and remarks in comment 19). I think it's reasonable that git status and git commit should be similar, and the overall layout that lets you see the commits in full width I think is an improvement. We do need to address the ergonomic issues for section commands and per item commands in sections, but I think this is something we'd look at across the board and try to improve all pages at once vs. not evolving git status. This is still evolving. For this to work well, I think, we really need to get that navigation between commits and the summary list of commits working really smoothly.
attachment 215554 [details] illustrates the work in progress. Diffs are moved to staged/unstaged sections and may be opened using twisties. There are still issues with the navigator vs. compare widget. The discussion is in Bug 379237.
The new page is linked to Orion. You can still switch to the old status page by changing git-status2.html to git-status.html in the page url.
Marking FIXED.
(In reply to comment #25) > Sorry but I think this is the wrong direction. I just tried git-status2 and have to say I agree with jjb. If you want to keep experimenting in the current direction, may I ask that you try to get rid of as many twisties as possible? They are really hard to hit with the mouse if collapsed. Also, are you planning to make the page keyboard-usable? I tried using the arrow keys but had no luck. Btw, the old git-status.html page seems to be broken on orion.eclipse.org right now, I see "TypeError" in the console.
Would an expand all help, Boris? Or just bigger hit areas ( or both ). (In reply to comment #30) > (In reply to comment #25) > > Sorry but I think this is the wrong direction. > > I just tried git-status2 and have to say I agree with jjb. If you want to keep > experimenting in the current direction, may I ask that you try to get rid of as > many twisties as possible? They are really hard to hit with the mouse if > collapsed. Also, are you planning to make the page keyboard-usable? I tried > using the arrow keys but had no luck. > > Btw, the old git-status.html page seems to be broken on orion.eclipse.org right > now, I see "TypeError" in the console.
For example, you could remove the twisties for the top-level sections (Unstaged, Staged, Commits). Why would I want to collapse these sections? For each file under Staged and Unstaged, I would then need an easy way to show and hide the diff. It may make sense to just insert a complete unified diff for each one (with equal lines omitted), i.e. without a scrollbar. But overall, I think incremental improvements to the "old" status page to address the original problems would have been better than this redesign.
(In reply to comment #30) > (In reply to comment #25) > > Sorry but I think this is the wrong direction. > Also, are you planning to make the page keyboard-usable? I tried > using the arrow keys but had no luck. You should be able to use up/down arrows to traverse file rows in stage/unstage areas. You cant traverse on "compare widget" row yet, which is addressed in Bug 380421. > > Btw, the old git-status.html page seems to be broken on orion.eclipse.org right > now, I see "TypeError" in the console. I tried the latest code, seems it works.
