Bugzilla – Full Text Bug Listing
| Summary: | [client] Flat layout style for repositories page | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | John Arthorne <john.arthorne> |
| Component: | Git | Assignee: | Szymon Brandys <Szymon.Brandys> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | antonm, john.arthorne, johnjbarton, ken_walker, simon_kaegi, susan, Szymon.Brandys, tomasz.zarna |
| Version: | 0.3 | ||
| Target Milestone: | 0.4 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 367188, 367297, 367400, 367404, 368425, 368429, 368440, 368540, 368541, 368699, 368711 | ||
| Bug Blocks: | 355496, 359875, 368712, 369711 | ||
| Attachments: | |||
|
Description
John Arthorne
Created attachment 204415 [details]
Screen shot illustrating wasted whitespace
A flatter layout sounds nice to me too. I think we tend to use trees because we are familiar with them. It's not a very effective use of space though. When I visit this page I have a tiny tree in the corner of the page and a lot of whitespace. Perhaps the "Repositories" link in the Orion header could be a drop-down menu where you immediately select an individual repository to view. We could then display the local and remote branch lists immediately with their corresponding actions available with a single click. (In reply to comment #2) > Perhaps the "Repositories" link in the Orion header could be a > drop-down menu where you immediately select an individual repository to view. On any page that shows content from a project, eg edit.html, the repository link could open the repro page with the project fully untwistied. Or more of the per-repro function could be on the status page. If I had |checkout| available on status I wouldn't need to visit repros very often in a day. (In reply to comment #3) > (In reply to comment #2) > > Perhaps the "Repositories" link in the Orion header could be a > > drop-down menu where you immediately select an individual repository to view. > > On any page that shows content from a project, eg edit.html, the repository > link could open the repro page with the project fully untwistied. Right. On the navigator page we could have 'Show Repo' next to 'Git Status' and 'Git Log' actions for folders/files. When it is clicked it would open the clones page and show just the selected repo. (In reply to comment #2) > A flatter layout sounds nice to me too. I think we tend to use trees because we > are familiar with them. It's not a very effective use of space though. When I > visit this page I have a tiny tree in the corner of the page and a lot of > whitespace. I also like the idea of flatter layout especially if we want to show just one repo. If we offered more layouts (including the flatter one), we could let users choose the one they prefer in their profiles or just directly on the page. (In reply to comment #4) > I also like the idea of flatter layout especially if we want to show just one > repo. If we offered more layouts (including the flatter one), we could let > users choose the one they prefer in their profiles or just directly on the > page. I would be in favor of the flatter "page per repo" and the tree would go away completely. The git clones page can then be just a simple flat list with links to the repos. If we still want to group things, I think we should just generate headings rather than use the tree. (Note also that in the navigator, you can click on any node of the tree to drill into a view of just that scope. That doesn't work in the git repo view, you are forced to expand, expand, expand (with none of it remembered).) Capturing more thoughts during RC3 testing. As part of the "flatter layout" effort I think we really need to step back and think about branch management and make sure that switching between branches is very seamless. (This affects more than just the repo page, we could also have branch switching in the git log page, similar to the eclipse.org view of our git repo). I was going to open a separate bug about branch management, but I think that while deciding what really belongs on the git "repositories" page, we need to think about the tasks that one would do here. Today the repositories page is heavily used because I *have* to come here to switch branches, see what branch I'm on, etc. If some of this function is added to an individual log page (switch branches that I'm viewing, make a branch active, etc.) then this page is more of a place for adding/removing repos, doing some management of remotes, branches, etc. There are related bugs describing tasks that are currently difficult or not implemented with respect to branching, that should be considered in the context of this bug. - In bug 361017, I had trouble figuring out how to refresh the list of branches for a repository. We might want to fetch the branch information whenever a page showing branches is loaded (like the eclipse.org git page) so that branch info is always up to date. It makes sense I'd have to reload a page to see the most current branches on a remote, but the tree structure of repo->remote->branch for some reason confused me as to where I'm supposed to fetch, and what the difference between fetch remote and fetch remote branch are. - In bug 350601, there was confusion about whether you can merge local branches. The active branch highlighting is subtle, and the presentation makes me think too much. All I have is a tooltip with words that mention selected branch vs. active branch and I have to think pretty hard about what is merging with what, or what is rebasing off what. If we end up with a page per repository, then this functionality would move to the individual repo page, and we need to make sure that the active branch presentation and rebase/merge functionality is much clearer... - Bug 349298 discusses a scenario that can't be done with the current repo page organization (ability to see remote branches from deleted remote, not sure how important this is, but worth revisiting) My previous comment is quite wordy, so I'm starting on a mockup for a repository/log page that would tackle branch management, and we could use the left hand side of the navigator to list repos and allow clone/init... (see bug 361856) Created attachment 205948 [details]
screenshot/mockup/brainstorming
brainstorming...
We could use the space for commands to show a brief info about the remote branch: * last update date and who did it * what is its base branch * is it behind it or is it ahead by a number of commits (comparing to local tracking branch or base branch) * has it been merged * link to a local tracking branch if exists (In reply to comment #9) > We could use the space for commands to show a brief info about the remote > branch: > * last update date and who did it > * what is its base branch > * is it behind it or is it ahead by a number of commits (comparing to local > tracking branch or base branch) > * has it been merged > * link to a local tracking branch if exists cool. Created attachment 208433 [details]
Flat layout Git repo page based on the Anton's stylesheet
I grabbed the css that Anton prepared and played with it a bit. I wonder what people think about this layout for the repo page.
Of course so far I have regular buttons instead of nice icons. The set of actions is also just an example. You can also see the screenshot here http://zaza.github.com/mockups/git-repository.png (In reply to comment #11) > Created attachment 208433 [details] > Flat layout Git repo page based on the Anton's stylesheet > > I grabbed the css that Anton prepared and played with it a bit. I wonder what > people think about this layout for the repo page. Trying to figure out the implied workflows here. I'm assuming that "see all repos" and "see full status" would lead to another page. Would "see all branches" and "see all tags" take me to another page? I don't see a way to switch branches easily, which has been one of the complaints. As for styling, I'm not sure if we want/need the big icons in this case. I can see for the plugin view how we might want to reserve room for plugin branding. Those puzzle piece icons are presumably different for each plugin. I'm in favor of the vertical breathing room, getting away from such "list" looking presentations, but we might just want a nice big repo name and detail without a lot of graphics noise if they aren't conveying anything. Same is true in the screenshot I posted. Lots of noise with icons that are all the same. another thought...does the stage/unstaged list provide enough value if you have to go to another page to see what the changes are? I suppose there's value in knowing you've done work on a branch....but I don't know that I would ever push "commit" without being able to double check the changes on each file... (In reply to comment #15) > another thought...does the stage/unstaged list provide enough value if you have > to go to another page to see what the changes are? I suppose there's value in > knowing you've done work on a branch....but I don't know that I would ever push > "commit" without being able to double check the changes on each file... It depends on what you show on the page. Each change could have a link to side-by-side compare view or when you hover on changes I could see a popup with diff. Maybe diff could be collapsed and just shown on demand. Suggestions are welcome. (In reply to comment #16) > (In reply to comment #15) > > another thought...does the stage/unstaged list provide enough value if you have > > to go to another page to see what the changes are? I suppose there's value in > > knowing you've done work on a branch....but I don't know that I would ever push > > "commit" without being able to double check the changes on each file... > > It depends on what you show on the page. Each change could have a link to > side-by-side compare view or when you hover on changes I could see a popup with > diff. Maybe diff could be collapsed and just shown on demand. Suggestions are > welcome. if we implement a diff view for commit page (https://bugs.eclipse.org/bugs/attachment.cgi?id=205932) maybe we could similarly allow expand of the diff in place in this section. I like the idea of the "summary sections" that lead to more detail, I think the challenge (fun?) is figuring out the most common tasks that people want so they wouldn't have to leave the page. So for me, being able to expand the diff in place might keep me on this page for small changes (one or two files). Overall I really like the direction. It would be interesting to see how it looks on a real world repository with many branches and tags. Like Susan I'm not sure the "Working Directory" section is needed here. If we show the full list of staged/unstaged files then I'll likely need to scroll down to get to the branch-related operations, which is the core purpose of this page. Maybe there could just be a small box with a summary of the working directory state ("3 unstaged files, 8 staged files") with a link to the status page for all the details. I agree with Susan that most often I want to view the diff when doing staging/unstaging operations. However it's useful to be aware of the working directory state when I'm about to do branch operations (merge/checkout/etc).
I mentioned on an earlier call, but I think any branch list should be sorted with most recently used at the top, with relative last modification time indicated in the info box ("last modified yesterday", "last modified in August, 2011", etc). Most repositories have many branches but I often only care about the ones I'm currently working in. We might also need a box to filter/search the branch/tag list for larger repos).
(In reply to comment #14) > (In reply to comment #11) > > Created attachment 208433 [details] [details] > > Flat layout Git repo page based on the Anton's stylesheet > > > > I grabbed the css that Anton prepared and played with it a bit. I wonder what > > people think about this layout for the repo page. > > Trying to figure out the implied workflows here. I'm assuming that "see all > repos" and "see full status" would lead to another page. Would "see all > branches" and "see all tags" take me to another page? That's right. For now I think that "Full status" would take us to the Status page, while "See Tags", "See branches" would just show tags or branches, like on http://git.eclipse.org/c/orion/org.eclipse.orion.client.git for example where we use '...' at the bottom of the list. > I don't see a way to switch branches easily, which has been one of the > complaints. What do you mean? There is checkout next to each branch. If you click it you will switch the branch. > As for styling, I'm not sure if we want/need the big icons in this case. I can > see for the plugin view how we might want to reserve room for plugin branding. > Those puzzle piece icons are presumably different for each plugin. I think that github also shows icons next to repositories, files and other items. They are smaller than those on my screenshot. I think that on such a landing page there wouldn't be lots of items to show. So I wouldn't worry about icons next to shown items. > I'm in favor of the vertical breathing room, getting away from such "list" > looking presentations, but we might just want a nice big repo name and detail > without a lot of graphics noise if they aren't conveying anything. Same is > true in the screenshot I posted. Lots of noise with icons that are all the > same. I'm not attached to these icons. I was just reusing the Anton's stylesheet that requires icons there. The list presentation is also driven by the stylesheet. (In reply to comment #19) > > I don't see a way to switch branches easily, which has been one of the > > complaints. > > What do you mean? There is checkout next to each branch. If you click it you > will switch the branch. One nice thing about the eclipse.org git view is the branch switching combo. I thought that If I had to go to another page to see a full list of branches, then I couldn't "switch to any branch" from this page, which would be handy. Maybe John's suggestion to sort branches would help with this, so that the ones I most likely need to switch between are already showing. If the "see all" links just expand the list in place on the page then that would help, too. Szymon and I are discussing icons in bug 364399. Just wanted to point out here that I don't think we should necessarily expose complicated/potentially destructive actions (like reset, rebase, etc.) as first level buttons. A couple of reasons: - don't want to make it easy for the user to mess up - in a view where there are different "models" and therefore various sets of actions on different objects, I think we want to carefully choose the 3-5 very common actions that are intended to be done here, perhaps some that are in the actions menu, and maybe some you have to go to the full page for (for example, the discussion of stage/unstage.) I don't think we want a presentation where "everything you can do to something" is elevated as a first level button there on the right hand side. another very minor point. Presumably the "add" button which is showing in the branches heading would be right justified to the end of the dotted line (like we do in the favorites pane). We are trying to right align the "section level" commands to make it consistent (so we will also clean this up in git-status, etc.) Created attachment 208648 [details]
mockup based on Szymon's prototype + some existing icons
I'm not sure that this screensnap is that interesting, but I built it in order to prototype various ways of rendering those buttons on the right. Thought I may as well attach it here.
one that uses icons/menu instead of buttons is shown in this attachment (on another bug). I don't think it's any better, we are probably going to want some command styling that uses text + icon, especially since we have so much room to play with. https://bugs.eclipse.org/bugs/attachment.cgi?id=208649 (In reply to comment #24) > one that uses icons/menu instead of buttons is shown in this attachment (on > another bug). I don't think it's any better, we are probably going to want some... Right. That's what I'm doing now. I'm going to release the first version of the page to the repo today. It won't be linked to other pages, but would allow Susan to work and tweak it a bit. Created attachment 208702 [details]
The current state of the page
I made the initial commit with the flat-layout repo page.
Created attachment 208723 [details]
The flat repo page with "button" style
The new "button" style looks very good. The issue is that all commands are rendered as buttons, no matter it is a href or non-href command. I think href commands should be still rendered as links, but I don't know if there is a way to do it now. I'll raise a bug for that.
The new repo page is linked to the Orion header now. Please raise new bugs for enhancements and fixes in this area. Created attachment 210025 [details]
screenshot of git-repositories page
Gee, is this how you wanted this page to look?
The page uses a similar layout as our new settings and plug-ins pages. If you see something wrong with this layout, raise a constructive comment, please. See also /settings/settings.html page, category Plugins. This is the same layout. Having a huge blank space in the middle, separating the buttons for an item from the name of the item is not usable. One has to exert a lot of mental effort to imagine a line all the way across the page to line up the buttons with the repo. The problem with previous soln was the repeated repeated layers of twisties and the missing link to navigation. The previous soln did have white space, but it was all where it belonged, on the RHS and bottom. The main point about the white space is simple: there is space for more critical links like direct navigation. (In reply to comment #32) > Having a huge blank space in the middle, separating the buttons for an item from > the name of the item is not usable. One has to exert a lot of mental effort to > imagine a line all the way across the page to line up the buttons with the repo. I opened a new bug for this, see Bug 369711. More comments; Bug 369762 - Repository page is confusing. |
