Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upPull Requests #20
Comments
shana
added
the
feature
label
Jul 29, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
/cc @github/atom |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
simurai
Jul 31, 2015
Member
Still debating whether to use tabs or dropdowns (for space conservation), but tabs do provide useful information.
If space allows it, tabs would be nice. Better for orientation and quicker to access the different sections. Maybe the tabs could do without the icons? I tried it out here:
Also added:
- Create + Merge PR button
- Build check + conflict status
- A way to go back to the PR list. Could be just the back buttons at the top. Or the bread crumbs. Or a "cancel" button?
If space allows it, tabs would be nice. Better for orientation and quicker to access the different sections. Maybe the tabs could do without the icons? I tried it out here:
Also added:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
/cc @Haacked @orderedlist |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
actually, /cc @github/desktop for the |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Jul 31, 2015
Collaborator
Thanks for this, looks great!
For reference, this is the UI we have currently on the Team Explorer tab (pane on the right side with yellow highlighted button). It's the main "page" that shows up when you click on the Team Explorer tab, and contains several navigation items (some or ours and some aren't). The Pull Requests navigation item is ours, and it's currently set to open up the pr page on the website. The plan is to use this navitem to open the PR feature in the GitHub pane. In the future, other features (like Issues) can be added to the GitHub pane (that's the plan, anyway
A way to go back to the PR list. Could be just the back buttons at the top. Or the bread crumbs. Or a "cancel" button?
The PR icon on the toolbar on top of the pane is meant to be used as a shortcut to go back to the main PR view (which would be the list with whatever filters have been set by the user). This is a UI pattern that some bits of VS are introducing (toolbar with icons that switch between features in one pane, with back and forward buttons to navigate between areas of a particular feature), but it's not very common, so not sure how easy it is for users to pick up. Breadcrumbs could work alongside that, they're definitely easier to understand.
|
Thanks for this, looks great! For reference, this is the UI we have currently on the Team Explorer tab (pane on the right side with yellow highlighted button). It's the main "page" that shows up when you click on the Team Explorer tab, and contains several navigation items (some or ours and some aren't). The Pull Requests navigation item is ours, and it's currently set to open up the pr page on the website. The plan is to use this navitem to open the PR feature in the GitHub pane. In the future, other features (like Issues) can be added to the GitHub pane (that's the plan, anyway
The PR icon on the toolbar on top of the pane is meant to be used as a shortcut to go back to the main PR view (which would be the list with whatever filters have been set by the user). This is a UI pattern that some bits of VS are introducing (toolbar with icons that switch between features in one pane, with back and forward buttons to navigate between areas of a particular feature), but it's not very common, so not sure how easy it is for users to pick up. Breadcrumbs could work alongside that, they're definitely easier to understand. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
simurai
Aug 1, 2015
Member
The PR icon on the toolbar on top of the pane is meant to be used as a shortcut to go back to the main PR view
I see. And yeah.. when there are more features like Issues, it will have its own icon up there.
I saw that other than the Team Explorer, it looks very close to GitHub for Windows. Like the login, clone and create repo popups. So here a version that is closer to that. Like the buttons have the circled checkmark:
Although not sure. That style works well when there is padding and white space available. But in that side panel where there is lots of stuff and that can be resized, those buttons get a bit lost.
I see. And yeah.. when there are more features like Issues, it will have its own icon up there. I saw that other than the Team Explorer, it looks very close to GitHub for Windows. Like the login, clone and create repo popups. So here a version that is closer to that. Like the buttons have the circled checkmark:
Although not sure. That style works well when there is padding and white space available. But in that side panel where there is lots of stuff and that can be resized, those buttons get a bit lost. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Aug 1, 2015
Collaborator
Although not sure. That style works well when there is padding and white
space available. But in that side panel where there is lots of stuff and
that can be resized, those buttons get a bit lost.I really like the PR status icon on this version, fits in much better than
the green-background one!
In terms of using the circular buttons, yes, these panes have different
size constraints that can make it hard to have that much padding. Not only
is it a problem with horizontal space, but vertical space is somewhat at a
premium too - the mockups were done on a big monitor, so even though I
didn't take them with VS on full screen, I still have a lot of vertical
space there, other users can have less space.
The panes are scrollable, but action buttons should be positioned so they
don't disappear off screen if scrolling is required, so people don't get
confused about how to do things. Any extra space that buttons take is less
space for other information and more potential for scrolling.
P.S.: let me know if my mockups PSD would be useful, I can send it to you.
P.P.S.: Also, I'm doing a road trip thing, which is why my replies are
somewhat slow, sorry about that :-/
In terms of using the circular buttons, yes, these panes have different The panes are scrollable, but action buttons should be positioned so they P.S.: let me know if my mockups PSD would be useful, I can send it to you. P.P.S.: Also, I'm doing a road trip thing, which is why my replies are |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
simurai
Aug 4, 2015
Member
but vertical space is somewhat at a premium too
Yeah, also saw that vertical space can get split up with another "Properties" panel. Ok, how about smaller "Windows" style buttons, but the merge button is green:
P.S.: let me know if my mockups PSD would be useful, I can send it to you.
So far I'm fine, thanks. I started to rebuild it in Sketch. The font rendering doesn't 100% match like in Windows, but should be close.
Yeah, also saw that vertical space can get split up with another "Properties" panel. Ok, how about smaller "Windows" style buttons, but the merge button is green:
So far I'm fine, thanks. I started to rebuild it in Sketch. The font rendering doesn't 100% match like in Windows, but should be close. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
simurai
Aug 5, 2015
Member
Need a way of assigning someone to a PR
How about under the branch picker:
How about under the branch picker:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
simurai
Aug 5, 2015
Member
Commit detail (file changes list per commit)
Clicking on a commit would expand the item and show the file list (per commit). Clicking again would collapse the item.
Clicking on a commit would expand the item and show the file list (per commit). Clicking again would collapse the item.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
simurai
Aug 5, 2015
Member
Diff of file change selected (from commit detail or PR changes detail), no special adornments
I guess selecting one of the changed files would open the code diff view in VisualStudio. Something like this:
Maybe the file list items need a selected state.
Diff of file change (from commit detail or PR changes list)
- Add comment on diff view line
- See comments on diff view line
Does VS allow to add/see comments inline in the diff view? Or do the comments need to be shown in the GitHub panel?
I guess selecting one of the changed files would open the code diff view in VisualStudio. Something like this:
Maybe the file list items need a selected state.
Does VS allow to add/see comments inline in the diff view? Or do the comments need to be shown in the GitHub panel? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Aug 5, 2015
Collaborator
For the merge button, I would probably dock the whole thing to the bottom of the panel, so comments get their own scrolling space. I was also thinking about having it always visible no matter which view you're looking at (commits, conversation or file changes), something like the screenshot below. I would love to be able to collapse the comment box so that it doesn't occupy so much space while just being there, and only expand when the user clicks on it, that could work nicely.What do you think?
I'm thinking that the merge button might need a confirmation of some sort, it's a destructive operation and users will certainly hit the button by mistake. Maybe built in to the button itself, so it requires two clicks (that way accidental clicks will be safe but users can still merge without going through extra popups).
I guess selecting one of the changed files would open the code diff view in VisualStudio.
Maybe the file list items need a selected state.
Yup, that's the plan. Any item in a file change list should be selectable and show the corresponding diff. The mockups I posted don't show it but I switch to a darker background for selected lines.
Does VS allow to add/see comments inline in the diff view? Or do the comments need to be shown in the GitHub panel?
The plan is to have comments inline, yes. Whether it's using the built-in diff view, or whether we do our own view with diff and inline comments, I'm not sure yet, but at the end, line comments should be showing up in the diff, like we do on the website.
|
For the merge button, I would probably dock the whole thing to the bottom of the panel, so comments get their own scrolling space. I was also thinking about having it always visible no matter which view you're looking at (commits, conversation or file changes), something like the screenshot below. I would love to be able to collapse the comment box so that it doesn't occupy so much space while just being there, and only expand when the user clicks on it, that could work nicely.What do you think?
I'm thinking that the merge button might need a confirmation of some sort, it's a destructive operation and users will certainly hit the button by mistake. Maybe built in to the button itself, so it requires two clicks (that way accidental clicks will be safe but users can still merge without going through extra popups).
Yup, that's the plan. Any item in a file change list should be selectable and show the corresponding diff. The mockups I posted don't show it but I switch to a darker background for selected lines.
The plan is to have comments inline, yes. Whether it's using the built-in diff view, or whether we do our own view with diff and inline comments, I'm not sure yet, but at the end, line comments should be showing up in the diff, like we do on the website. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Haacked
Aug 5, 2015
Member
I'm thinking that the merge button might need a confirmation of some sort
Yeah, we should do it the same way github.com does it where the button turns into a confirm merge button.
Yeah, we should do it the same way github.com does it where the button turns into a confirm merge button. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
simurai
Aug 6, 2015
Member
I was also thinking about having it (merge button) always visible no matter which view you're looking at
Was thinking that too, but then I wasn't sure anymore because it might be a good thing to have the merge button only after the last comment. It makes sure you're aware of any last minute changes. Otherwise you might miss a "ohh.. just noticed "something", I'll try to fix that." I wonder if there is a specific reason why the merge button on github.com is at the end of comments and not somehwere at the top or side bar?
I would love to be able to collapse the comment box so that it doesn't occupy so much space while just being there, and only expand when the user clicks on it, that could work nicely.
Yes, that would be nice. Maybe initially just have space for 2-3 lines.
Was thinking that too, but then I wasn't sure anymore because it might be a good thing to have the merge button only after the last comment. It makes sure you're aware of any last minute changes. Otherwise you might miss a "ohh.. just noticed "something", I'll try to fix that." I wonder if there is a specific reason why the merge button on github.com is at the end of comments and not somehwere at the top or side bar?
Yes, that would be nice. Maybe initially just have space for 2-3 lines. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Aug 10, 2015
Collaborator
I wonder if there is a specific reason why the merge button on github.com is at the end of comments and not somehwere at the top or side bar?
On the website there's many actionable contexts - a page contains general repo information, buttons to other areas, settings, links, etc etc - any button that acts on something specific needs to be close to that specific thing, and the central column on the website is where actions for the content go - so the merge button has to be in the center along with its comment box, and can't be on the sidebar. It could be above the comments, but then the reason you mentioned probably comes into play - you don't want people merging without reading all the comments.
I would prefer not to have the merge button and comment box scrolling up along with the comments, that's not something that happens normally in a native app and people will get confused (or won't find the thing because they will never remember to scroll, or they'll get a cut up comment box because things almost fit the screen but not quite). If there's a ton of comments I've already read, scrolling down all the way to the end is going to be a pain, too.
So there's two issues that need to be handled in the UI in a smart way - how to let the user know that there's new comments (possibly before letting them merge? automatically scrolling to the new comments and highlighting the background?), and how to easily navigate a potentially large list of comments (I'm already only showing the first line or two of a comment on the list, maybe that's enough? do we need more than just a scrollbar?)
On the website there's many actionable contexts - a page contains general repo information, buttons to other areas, settings, links, etc etc - any button that acts on something specific needs to be close to that specific thing, and the central column on the website is where actions for the content go - so the merge button has to be in the center along with its comment box, and can't be on the sidebar. It could be above the comments, but then the reason you mentioned probably comes into play - you don't want people merging without reading all the comments. I would prefer not to have the merge button and comment box scrolling up along with the comments, that's not something that happens normally in a native app and people will get confused (or won't find the thing because they will never remember to scroll, or they'll get a cut up comment box because things almost fit the screen but not quite). If there's a ton of comments I've already read, scrolling down all the way to the end is going to be a pain, too. So there's two issues that need to be handled in the UI in a smart way - how to let the user know that there's new comments (possibly before letting them merge? automatically scrolling to the new comments and highlighting the background?), and how to easily navigate a potentially large list of comments (I'm already only showing the first line or two of a comment on the list, maybe that's enough? do we need more than just a scrollbar?) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
simurai
Aug 11, 2015
Member
I would prefer not to have the merge button and comment box scrolling up along with the comments
how to let the user know that there's new comments
Green indicator dot? New comments would be green too:
how to easily navigate a potentially large list of comments (I'm already only showing the first line or two of a comment on the list, maybe that's enough? do we need more than just a scrollbar?)
Maybe some sort of limit still needs to be there? Just as a security in case there are thousands of comments. It could show the initial 100 and then you have to load more:
Or even with some pagination? Usually when I go to a PR (or issue) with a lot of comments, I'm most interested in the beginning and the end. The beginning because it explains the context of the PR. And then the end to see if the conversation is still active or if a conclusion is reached etc. Pagination would make it easier to skip the middle and go straight to the end of the list. Here just a simple dots version:
Some more random ideas to leave more room for scrolling:
- Like browsers on smartphones hide tool/address bar when scrolling down.. scrolling down on the comments would hide the merge button and comment input, leaving more room to read the comments. When scrolling stops or once reached the bottom, the merge button and comment input would appear again.
- Remove the "Comment" button. It would save some space. Submit is on [enter]. You could still do a line break with [shift + enter], but it's more for short single-paragraph comments.
2b. Or maybe better.. I think you've already mentioned it.. have a small comment input only, but then when focusing on it, the comment input (box) expands and also a comment button appears.
Green indicator dot? New comments would be green too:
Maybe some sort of limit still needs to be there? Just as a security in case there are thousands of comments. It could show the initial 100 and then you have to load more:
Or even with some pagination? Usually when I go to a PR (or issue) with a lot of comments, I'm most interested in the beginning and the end. The beginning because it explains the context of the PR. And then the end to see if the conversation is still active or if a conclusion is reached etc. Pagination would make it easier to skip the middle and go straight to the end of the list. Here just a simple dots version:
Some more random ideas to leave more room for scrolling:
2b. Or maybe better.. I think you've already mentioned it.. have a small comment input only, but then when focusing on it, the comment input (box) expands and also a comment button appears.
|
shana
added this to the
2.0 milestone
Aug 13, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
/cc @fabianperez |
shana
modified the milestones:
1.2 - Pull Requests (and more),
2.0
Sep 28, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ToMaHaWk
Oct 9, 2015
I am really interested in the way a PR is associated with an Issue. This is a painful process that can save us a lot of time if it's automated.
Ideally our team would like to be able to create a pull request and link to an issue from the same repo or a different repo.
We work on 2 repos at the same time i.e our solution consists of 2 projects and each one is it's own repo (think one for our app framework and one for the specific app we are building). Both repos can have issues. Most features require 2 pull requests to be submitted (changes are required both in the framework as well the app for any given feature) and they always link to the same issues. Since currently an issue can exist in one repo only this means that one of the pull requests will need to link an issue from a separate repo.
I'd really appreciate it if you took this suggestion under consideration.
P.S We use GitHub Enterprise.
ToMaHaWk
commented
Oct 9, 2015
|
I am really interested in the way a PR is associated with an Issue. This is a painful process that can save us a lot of time if it's automated. I'd really appreciate it if you took this suggestion under consideration. P.S We use GitHub Enterprise. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Oct 9, 2015
Collaborator
@ToMaHaWk What would you want automated when you link a PR with an issue on a different repo? Do you just want the mentions, or do you want it closed when the PR is merged?
|
@ToMaHaWk What would you want automated when you link a PR with an issue on a different repo? Do you just want the mentions, or do you want it closed when the PR is merged? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 2, 2016
Member
List of pull requests
Here's a mock-up listing opened and updated pull requests. Continuing what @simurai and @shana discussed earlier, we indicate new pull requests with a green dot next to the avatar of the author. Any pull requests with new comments or changes are indicated with a green dot next to the comments count.
You'll be able to view the details of each PR in Visual Studio once we implement that feature. In the meantime, clicking on the title of the pull request will open up it on GitHub.com in the browser.
Sometimes you'll want to see some details related to each pull request (such as assignee, labels, tasks, etc.) You can find those by toggling the details dropdown:
We'll sometimes want to filter our pull requests by what's opened or by assignee. You'll do that through the filter menus. Right now I only have opened, assignee, and author as filter options. If we want to include more, I'll need to think of a better layout to fit them.
Creating a new PR
You'll start creating a pull request by clicking the New Pull Request link and entering the title and description. Clicking on a commit underneath the form could bring you to the commit's detail in the built-in Visual Studio git client.
You could specify which branch you want to merge into using the dropdown near the title field.
Down the line, we'll want to be able to assign individuals to review a pull request. We'll do that through the Assignee selection.
The version above uses a simple menu. It would be interesting to see if it's possible to have a menu with the ability to filter people. This is especially for organizations and teams with dozens of members.
|
List of pull requests Here's a mock-up listing opened and updated pull requests. Continuing what @simurai and @shana discussed earlier, we indicate new pull requests with a green dot next to the avatar of the author. Any pull requests with new comments or changes are indicated with a green dot next to the comments count. You'll be able to view the details of each PR in Visual Studio once we implement that feature. In the meantime, clicking on the title of the pull request will open up it on GitHub.com in the browser.
Sometimes you'll want to see some details related to each pull request (such as assignee, labels, tasks, etc.) You can find those by toggling the details dropdown:
We'll sometimes want to filter our pull requests by what's opened or by assignee. You'll do that through the filter menus. Right now I only have
Creating a new PR You'll start creating a pull request by clicking the
You could specify which branch you want to merge into using the dropdown near the title field.
Down the line, we'll want to be able to assign individuals to review a pull request. We'll do that through the
The version above uses a simple menu. It would be interesting to see if it's possible to have a menu with the ability to filter people. This is especially for organizations and teams with dozens of members.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Feb 2, 2016
Collaborator
This is so awesome, I love it!
The version above uses a simple menu. It would be interesting to see if it's possible to have a menu with the ability to filter people. This is especially for organizations and teams with dozens of members.
Yup, definitely possible!
|
This is so awesome, I love it!
Yup, definitely possible! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Feb 2, 2016
Collaborator
So let's start with the PR list. Do we have a preferred font we want to use? Right now I'm using Segoe UI with a font size of 14 for the pr title.
The icon you're using for the comments is the comment_discussion octicon, right? What size should it be rendered at?
|
So let's start with the PR list. Do we have a preferred font we want to use? Right now I'm using Segoe UI with a font size of 14 for the pr title. The icon you're using for the comments is the comment_discussion octicon, right? What size should it be rendered at? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 2, 2016
Member
Yup, definitely possible!
Sweet! I can create a hi-fidelity mock for that UI component. I wasn't able to find a similar one in Visual Studio but I found noticed a similar pattern used in our desktop app.
So let's start with the PR list. Do we have a preferred font we want to use? Right now I'm using Segoe UI with a font size of 14 for the pr title.
Segoe UI is exactly what font I've been using. Excellent
The icon you're using for the comments is the comment_discussion octicon, right? What size should it be rendered at?
Yup! I've been using 16px for the Octicons as a minimum since the Octicons have optimized the vectors for that size.
Sweet! I can create a hi-fidelity mock for that UI component. I wasn't able to find a similar one in Visual Studio but I found noticed a similar pattern used in our desktop app.
Segoe UI is exactly what font I've been using. Excellent
Yup! I've been using 16px for the Octicons as a minimum since the Octicons have optimized the vectors for that size. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Feb 2, 2016
Collaborator
Yup! I've been using 16px for the Octicons as a minimum since the Octicons have optimized the vectors for that size.
Awesome! Do we have a set color for the green icon indicator? Right now I'm just setting it to "Green", is there a specific RGB that we use?
Also, the back and forward icons that I'm using on the toolbar don't look the same as the ones everywhere else in VS because I'm using a xaml vector while most of VS uses a bitmap. I'd really like to keep using the xaml (it scales nicely), but can't find ones that match the more slimmer icons VS uses (compare the back icon on the PR creation view toolbar with the one on the PR list view - the list view is my xaml icons while the creation view have icons I copy-pasted from VS screenshots iirc). Are we happy with the fatter xaml icons, or should we use octicons (which aren't round, if that matters), or create new ones?
Same with the refresh icon, actually. I don't think we have a refresh octicon and the one in the toolbar currently is a stub I found somewhere. Should we do our own?
Awesome! Do we have a set color for the green icon indicator? Right now I'm just setting it to "Green", is there a specific RGB that we use? Also, the back and forward icons that I'm using on the toolbar don't look the same as the ones everywhere else in VS because I'm using a xaml vector while most of VS uses a bitmap. I'd really like to keep using the xaml (it scales nicely), but can't find ones that match the more slimmer icons VS uses (compare the back icon on the PR creation view toolbar with the one on the PR list view - the list view is my xaml icons while the creation view have icons I copy-pasted from VS screenshots iirc). Are we happy with the fatter xaml icons, or should we use octicons (which aren't round, if that matters), or create new ones? Same with the refresh icon, actually. I don't think we have a refresh octicon and the one in the toolbar currently is a stub I found somewhere. Should we do our own? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 2, 2016
Member
Awesome! Do we have a set color for the green icon indicator? Right now I'm just setting it to "Green", is there a specific RGB that we use?
Let's use the colors specified in PrimerCSS. In this case for green, the RGB will be R: 108 G: 198 B: 68
I'd really like to keep using the xaml (it scales nicely), but can't find ones that match the more slimmer icons VS uses (compare the back icon on the PR creation view toolbar with the one on the PR list view - the list view is my xaml icons while the creation view have icons I copy-pasted from VS screenshots iirc). Are we happy with the fatter xaml icons, or should we use octicons (which aren't round, if that matters), or create new ones?
I like the idea of using our octicons whenever we can since they fit our branding and we have access to the vectors. However, would having differently styled navigation icons in the toolbar be jarring for Visual Studio users? Should we strive for interface consistency or brand consistency? I'm leaning towards brand but would love your thoughts on that matter.
Same with the refresh icon, actually. I don't think we have a refresh octicon and the one in the toolbar currently is a stub I found somewhere. Should we do our own?
I don't believe we have one. I'll check with the octicons team.
EDIT: in the meantime, feel free to use a stub and we can swap it out.
Let's use the colors specified in PrimerCSS. In this case for green, the RGB will be
I like the idea of using our octicons whenever we can since they fit our branding and we have access to the vectors. However, would having differently styled navigation icons in the toolbar be jarring for Visual Studio users? Should we strive for interface consistency or brand consistency? I'm leaning towards brand but would love your thoughts on that matter.
I don't believe we have one. I'll check with the octicons team. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Feb 2, 2016
Collaborator
I like the idea of using our octicons whenever we can since they fit our branding and we have access to the vectors. However, would having differently styled navigation icons in the toolbar be jarring for Visual Studio users? Should we strive for interface consistency or brand consistency? I'm leaning towards brand but would love your thoughts on that matter.
Great question - I honestly am not sure. I'm leaning towards the brand image myself, it would be nice to be distinctive in our own space. @Haacked, thoughts?
Great question - I honestly am not sure. I'm leaning towards the brand image myself, it would be nice to be distinctive in our own space. @Haacked, thoughts? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 2, 2016
Member
Great question - I honestly am not sure. I'm leaning towards the brand image myself, it would be nice to be distinctive in our own space. @Haacked, thoughts?
The answer to this will also inform the answer around the refresh icon
The answer to this will also inform the answer around the refresh icon |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 3, 2016
Member
Here's a pass at a tooltip dropdown:
A quick breakdown of states:
Filter would work close to how GitHub currently does:
- By default, your username is on top. Everyone else is listed in alphabetical order
- When you assign someone, their username is checked and is listed below your name
- Clear assignee option appears when someone is assigned
Would love a gut check on this direction, @simurai @shana. This direction is a bit custom to Visual Studio so I want to make sure it still feels like it fits at home. Also would like some insights into the engineering effort for custom UIs and balance nice-to-haves (aesthetics) with need-to-have (experience.)
If this is
|
Here's a pass at a tooltip dropdown:
A quick breakdown of states:
Filter would work close to how GitHub currently does:
Would love a gut check on this direction, @simurai @shana. This direction is a bit custom to Visual Studio so I want to make sure it still feels like it fits at home. Also would like some insights into the engineering effort for custom UIs and balance nice-to-haves (aesthetics) with need-to-have (experience.) If this is |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
simurai
Feb 3, 2016
Member
Looks great.
When you assign someone, their username is checked and is listed below your name
Would the "listed below your name" only be shown when re-opening the dropdown? Otherwise it might be confusing if a name disappears when you're scrolled to the bottom and select somebody.
|
Looks great.
Would the "listed below your name" only be shown when re-opening the dropdown? Otherwise it might be confusing if a name disappears when you're scrolled to the bottom and select somebody. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 3, 2016
Member
Would the "listed below your name" only be shown when re-opening the dropdown? Otherwise it might be confusing if a name disappears when you're scrolled to the bottom and select somebody.
Pretty much. I'm thinking that when a user is selected from the menu, the menu will close and the user will be selected. That way we won't have to reorder or maintain the position of the names.
Pretty much. I'm thinking that when a user is selected from the menu, the menu will close and the user will be selected. That way we won't have to reorder or maintain the position of the names. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Feb 3, 2016
Collaborator
I really like the look of these dropdowns. We're a bit constrained on what we can get away with UI-wise in the Team Explorer pane (because it's not a space we control), but in our own pane I'm all for creating our own look, and these dropdowns feel great. As a VS user, I don't find this design jarring at all.
@shiftkey @niik What do you feel, as VS users, about these latest mockups?
|
I really like the look of these dropdowns. We're a bit constrained on what we can get away with UI-wise in the Team Explorer pane (because it's not a space we control), but in our own pane I'm all for creating our own look, and these dropdowns feel great. As a VS user, I don't find this design jarring at all. @shiftkey @niik What do you feel, as VS users, about these latest mockups? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
alexangas
Feb 3, 2016
Sorry to butt in... Should "Clear assignee" be made a little more discoverable? The user is perhaps more likely to be in the mind frame of thinking about adding more assignees when using that drop-down, not removing them.
Another possibility might be to take that option out of the dialog and put something like a cross icon between the name and the drop-down icon? Like the common UI for removing tags.
alexangas
commented
Feb 3, 2016
|
Sorry to butt in... Should "Clear assignee" be made a little more discoverable? The user is perhaps more likely to be in the mind frame of thinking about adding more assignees when using that drop-down, not removing them. Another possibility might be to take that option out of the dialog and put something like a cross icon between the name and the drop-down icon? Like the common UI for removing tags. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Feb 3, 2016
Collaborator
@arangas Good point, one dropdown mixing two different intents might be confusing.
|
@arangas Good point, one dropdown mixing two different intents might be confusing. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 4, 2016
Member
Sorry to butt in... Should "Clear assignee" be made a little more discoverable? The user is perhaps more likely to be in the mind frame of thinking about adding more assignees when using that drop-down, not removing them.
Another possibility might be to take that option out of the dialog and put something like a cross icon between the name and the drop-down icon? Like the common UI for removing tags.
Good point. As far as I know, our API supports one assignee at a time, but I agree that it might be confusing to hide "Clear assignee" in the dropdown. I like the idea of using a tag-like UI, but I'm concerned about having two clickable targets fairly close to each other (especially if one of the actions is destructive by removing the assignee):
Maybe it makes sense to expose the action on the side when there is an assignee:
Good point. As far as I know, our API supports one assignee at a time, but I agree that it might be confusing to hide "Clear assignee" in the dropdown. I like the idea of using a tag-like UI, but I'm concerned about having two clickable targets fairly close to each other (especially if one of the actions is destructive by removing the assignee):
Maybe it makes sense to expose the action on the side when there is an assignee:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
alexangas
commented
Feb 4, 2016
|
@donokuda Good point, that would be better. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 4, 2016
Member
@arangas
|
@arangas |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shiftkey
Feb 4, 2016
Member
What do you feel, as VS users, about these latest mockups?
They feel familiar enough coming from dotcom, and should fit nicely into the VS experience so I'm
I couldn't find a good example of this unified search + listbox view already present in VS (some do one, or the other) but we use similar patterns in GitHub Desktop (for example, selecting an ignore template) so I'll go to war here to ensure we can do the same thing here
@niik might have some more UX insights as I think he was involved a bit with the initial extension work
They feel familiar enough coming from dotcom, and should fit nicely into the VS experience so I'm I couldn't find a good example of this unified search + listbox view already present in VS (some do one, or the other) but we use similar patterns in GitHub Desktop (for example, selecting an ignore template) so I'll go to war here to ensure we can do the same thing here @niik might have some more UX insights as I think he was involved a bit with the initial extension work |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 4, 2016
Member
I couldn't find a good example of this unified search + listbox view already present in VS (some do one, or the other) but we use similar patterns in GitHub Desktop (for example, selecting an ignore template) so I'll go to war here to ensure we can do the same thing here
Yeah, I also couldn't find an example of that in Visual Studio and wasn't sure if I overlooked something. The aesthetic deviates slightly away from GitHub desktop and is a little closer to dotcom, but here's a version closer to GHD for fun (the squares are placeholders for avatars:)
In retrospect, it makes more sense to make these GHD and GHfVS components similar so we can, at the very least, reuse code and designs between the two.
Thoughts?
Yeah, I also couldn't find an example of that in Visual Studio and wasn't sure if I overlooked something. The aesthetic deviates slightly away from GitHub desktop and is a little closer to dotcom, but here's a version closer to GHD for fun (the squares are placeholders for avatars:)
In retrospect, it makes more sense to make these GHD and GHfVS components similar so we can, at the very least, reuse code and designs between the two. Thoughts? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shiftkey
Feb 4, 2016
Member
This is the one I was referring to earlier:
In retrospect, it makes more sense to make these GHD and GHfVS components similar so we can, at the very least, reuse code and designs between the two.
More sharing of styles is totally
|
This is the one I was referring to earlier:
More sharing of styles is totally |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Feb 4, 2016
Collaborator
Yes, definitely let's align styles across our desktop products as much as possible ^_^
I really like this. I definitely have a soft spot for the [bold] [subdued] style of showing information.
@shiftkey Maybe it's a good idea for me to implement these new styles in a separate library? Right now I have a GitHub.UI and a GitHub.UI.Reactive (for technical reasons based on dependencies), which are slimmed down versions of what GHD has. But! We could avoid copy-pasting things across projects if stuff that we deem shareable would go into a separate library (GitHub.UI.Shared?)
|
Yes, definitely let's align styles across our desktop products as much as possible ^_^ I really like this. I definitely have a soft spot for the [bold] [subdued] style of showing information. @shiftkey Maybe it's a good idea for me to implement these new styles in a separate library? Right now I have a |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 4, 2016
Member
Yes, definitely let's align styles across our desktop products as much as possible ^_^
I also want to create a styleguide for us as a reference of what components we have, which should also help us prototype new features and flows... But that's a discussion outside of this issue
@shiftkey Maybe it's a good idea for me to implement these new styles in a separate library? Right now I have a GitHub.UI and a GitHub.UI.Reactive (for technical reasons based on dependencies), which are slimmed down versions of what GHD has. But! We could avoid copy-pasting things across projects if stuff that we deem shareable would go into a separate library (GitHub.UI.Shared?)
Love this idea too!
@shana What are your thoughts on the existing filter dropdown @shiftkey referenced?
I don't mean to continue bikeshedding this component but if we have something that already exists and we can extend, then I'd rather go that route.
I also want to create a styleguide for us as a reference of what components we have, which should also help us prototype new features and flows... But that's a discussion outside of this issue
Love this idea too! @shana What are your thoughts on the existing filter dropdown @shiftkey referenced?
I don't mean to continue bikeshedding this component but if we have something that already exists and we can extend, then I'd rather go that route. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Feb 4, 2016
Collaborator
I'm not a fan of the separator lines, to be honest. They clash with whatever happens to be in the background very easily. Also something about the left alignment of the entries and the filter text box is annoying my brain, for some reason.
With that said, they're two different boxes with two different purposes and amount of information, so I'm not sure I can compare them directly. I was going to, but refrained because one has single word entries while the other has avatars and multiple word entries, they fill up differently.
|
I'm not a fan of the separator lines, to be honest. They clash with whatever happens to be in the background very easily. Also something about the left alignment of the entries and the filter text box is annoying my brain, for some reason. With that said, they're two different boxes with two different purposes and amount of information, so I'm not sure I can compare them directly. I was going to, but refrained because one has single word entries while the other has avatars and multiple word entries, they fill up differently. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shiftkey
Feb 4, 2016
Member
Maybe it's a good idea for me to implement these new styles in a separate library? Right now I have a GitHub.UI and a GitHub.UI.Reactive (for technical reasons based on dependencies), which are slimmed down versions of what GHD has. But! We could avoid copy-pasting things across projects if stuff that we deem shareable would go into a separate library (GitHub.UI.Shared?)
Yep. Feel free to repurpose whatever from GHD, and I think a *.Shared is a good convention for us.
Also, I'm concerned about the lack of @niik in this thread. Maybe if I say his name three times he'll appear - @niik @niik @niik?
Yep. Feel free to repurpose whatever from GHD, and I think a Also, I'm concerned about the lack of @niik in this thread. Maybe if I say his name three times he'll appear - @niik @niik @niik? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 5, 2016
Member
Also something about the left alignment of the entries and the filter text box is annoying my brain, for some reason.
I'm willing to bet your brain really wants the placeholder text and the list text to align, but the list text is aligning with the input box instead.
With that said, they're two different boxes with two different purposes and amount of information, so I'm not sure I can compare them directly. I was going to, but refrained because one has single word entries while the other has avatars and multiple word entries, they fill up differently.
That's a good point. I was comparing them because of their similar UX around filtering in a list. But when I think about the content that could live in there, the filterable list without separator lines is more flexible for grouping content. A good example in GHD is the branch picker:
(Also note the [edit: alignment] of the placeholder text and the list text)
I'm willing to bet your brain really wants the placeholder text and the list text to align, but the list text is aligning with the input box instead.
That's a good point. I was comparing them because of their similar UX around filtering in a list. But when I think about the content that could live in there, the filterable list without separator lines is more flexible for grouping content. A good example in GHD is the branch picker:
(Also note the [edit: alignment] of the placeholder text and the list text) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Feb 5, 2016
Collaborator
Aaaaaaaahhh yes that's totally it. Messing up my brain so much!
Your list mockup and the GHD one are pretty close. The only difference is the alignment of the subdued text and the boldness of the other text. The boldness on your mockup matches what we already do in the Connect area to list repositories (because it's a thing MS also does). I find that the dates aligned to the right on the GHD branch picker work well, but in the case of the list of names mockup it works better having them aligned to the left next to the username. I have no problems making a variation on the GHD one for VS, but these are minor things, really, and I defer design decisions to the experts
One thing to consider is that we need a dark theme. VS ships with one by default and all the panes need to follow it, otherwise it'll look horrible. We can get away with the dialogs because they're not inside the VS UI, but we can't avoid it with panes.
|
Aaaaaaaahhh yes that's totally it. Messing up my brain so much! Your list mockup and the GHD one are pretty close. The only difference is the alignment of the subdued text and the boldness of the other text. The boldness on your mockup matches what we already do in the Connect area to list repositories (because it's a thing MS also does). I find that the dates aligned to the right on the GHD branch picker work well, but in the case of the list of names mockup it works better having them aligned to the left next to the username. I have no problems making a variation on the GHD one for VS, but these are minor things, really, and I defer design decisions to the experts One thing to consider is that we need a dark theme. VS ships with one by default and all the panes need to follow it, otherwise it'll look horrible. We can get away with the dialogs because they're not inside the VS UI, but we can't avoid it with panes. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Feb 5, 2016
Collaborator
But omg please let's match the left padding of the text to the inner padding of the filter box, that breaks me so much!
|
But omg please let's match the left padding of the text to the inner padding of the filter box, that breaks me so much! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 6, 2016
Member
I find that the dates aligned to the right on the GHD branch picker work well, but in the case of the list of names mockup it works better having them aligned to the left next to the username.
Agree. With the name right-aligned in the pop-up, if someone wanted to know a user's real name in the dropdown, their eye would have to jump to the right side. Plus we would end up hiding information when a user is selected.
One thing to consider is that we need a dark theme. VS ships with one by default and all the panes need to follow it, otherwise it'll look horrible. We can get away with the dialogs because they're not inside the VS UI, but we can't avoid it with panes.
Good call! This is also important as we think about using color to convey information.
Agree. With the name right-aligned in the pop-up, if someone wanted to know a user's real name in the dropdown, their eye would have to jump to the right side. Plus we would end up hiding information when a user is selected.
Good call! This is also important as we think about using color to convey information. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 8, 2016
Member
Noodled on some thoughts around the UX of listing changed files in the commit tab.
Clicking on a commit would expand the item and show the file list (per commit). Clicking again would collapse the item.
If we were to click on a commit, would the expected behavior be showing the file list or showing the details of the commit itself?
My expectation is that it would show the details of that commit in the team explorer, if possible:
If that's the case, we could toggle the list of files by clicking the counter on the side:
However, I'm concerned that this is a UX pattern not used anywhere else. Maybe we consider using a list dropdown instead?:
Also, we could truncate long directories and filenames and show the full path in a tooltip:
Clicking on the filename could open a diff view comparing the file, at that commit, to the target branch. However, I'm wondering if this is a common action when creating a PR.
|
Noodled on some thoughts around the UX of listing changed files in the commit tab.
If we were to click on a commit, would the expected behavior be showing the file list or showing the details of the commit itself? My expectation is that it would show the details of that commit in the team explorer, if possible:
If that's the case, we could toggle the list of files by clicking the counter on the side:
However, I'm concerned that this is a UX pattern not used anywhere else. Maybe we consider using a list dropdown instead?:
Also, we could truncate long directories and filenames and show the full path in a tooltip:
Clicking on the filename could open a diff view comparing the file, at that commit, to the target branch. However, I'm wondering if this is a common action when creating a PR. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Feb 8, 2016
Collaborator
Jumping to Team Explorer for the commit info view might be confusing - it jumps to a different pane, how is the user getting back to our pane (back doesn't work, the navigation is only between Team Explorer pages, not everything else)? Not sure I can actually load a specific commit information programmatically on Team Explorer, either. We might need to have a commit detail page to show this information.
|
Jumping to Team Explorer for the commit info view might be confusing - it jumps to a different pane, how is the user getting back to our pane (back doesn't work, the navigation is only between Team Explorer pages, not everything else)? Not sure I can actually load a specific commit information programmatically on Team Explorer, either. We might need to have a commit detail page to show this information. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
donokuda
Feb 8, 2016
Member
Jumping to Team Explorer for the commit info view might be confusing - it jumps to a different pane, how is the user getting back to our pane (back doesn't work, the navigation is only between Team Explorer pages, not everything else)?
Totally. I agree that jumping to a different pane doesn't make it clear where we came from and how to get back unless you look for very specific cues (such as the tabs changing.)
We might need to have a commit detail page to show this information.
I started a wireframe concept around this for our pane, keeping in mind that I'm making assumptions of what information is useful to show here:
Totally. I agree that jumping to a different pane doesn't make it clear where we came from and how to get back unless you look for very specific cues (such as the tabs changing.)
I started a wireframe concept around this for our pane, keeping in mind that I'm making assumptions of what information is useful to show here:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
stevekennaird
Sep 16, 2016
@shana just out of interest, do you think some form of 'PR Feature - Level 2' or 'PR Feature - Level 3' will be coming any time soon? Or is it an unknown at the moment?
stevekennaird
commented
Sep 16, 2016
|
@shana just out of interest, do you think some form of 'PR Feature - Level 2' or 'PR Feature - Level 3' will be coming any time soon? Or is it an unknown at the moment? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
shana
Sep 16, 2016
Collaborator
@stevekennaird Yup, we're working on it, just taking a more holistic, workflow approach to it. See #491 for some of that!
|
@stevekennaird Yup, we're working on it, just taking a more holistic, workflow approach to it. See #491 for some of that! |
shana commentedJul 29, 2015
•
edited
Edited 1 time
-
shana
edited Jan 31, 2017 (most recent)
Imported from github/VisualStudioInternal#428
So this is the broad list of things that go into PRs. I've set checkmarks on the bare minimum PR support without which there's probably no point in shipping. Any things that we wouldn't support initially would instead jump to the website to show the information, if possible.
PR Feature - Level 1
PR Feature - Level 2
PR Feature - Level 3
Things to figure out
Mockups
Pull Request List
Pull Request Creation / Detail
The pull request creation wouldn't have a Conversation tab because, well, it's a new PR, but viewing an existing PR would have it. Still debating whether to use tabs or dropdowns (for space conservation), but tabs do provide useful information.
Not seen in the mockups is the ability to see individual changes list per-commit, which is a very useful feature. Considering having the commit entry as a collapsible pane that shows a list of changed files in the same way as the PR file change list.
Pull Request Detail, alternate form with pull downs