New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pull Requests #20

Open
shana opened this Issue Jul 29, 2015 · 52 comments

Comments

9 participants
@shana
Collaborator

shana commented Jul 29, 2015

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

  • List Pull Requests
    • Filtering
  • Create Pull Request
    • Entry form for title, description and create button
    • Assigment
    • Commit list

PR Feature - Level 2

  • Create Pull Request
    • Commit detail (file changes list per commit)
    • File changes list (of the PR)
    • Diff of file change selected (from commit detail or PR changes detail), no special adornments

PR Feature - Level 3

  • Pull Request detail
    • Commit list
    • Commit detail (file changes list )
    • File changes list (of the PR)
    • Conversation list
    • Diff of file change (from commit detail or PR changes list)
      • Add comment on diff view line
      • See comments on diff view line
    • Merge PR
    • Close PR

Things to figure out

  • Need a way of assigning someone to a PR
  • Need a merge button somewhere
  • Sorting

Mockups

Pull Request List

pullrequestlistfiltering

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.

pullrequestcreation1
pullrequestcreation2
pullrequestcreation3

Pull Request Detail, alternate form with pull downs

pullrequestcommitlist1

pullrequestconversation1

@shana shana added the feature label Jul 29, 2015

@kevinsawicki

This comment has been minimized.

Show comment
Hide comment
Member

kevinsawicki commented Jul 30, 2015

@simurai

This comment has been minimized.

Show comment
Hide comment
@simurai

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:

pr

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?
Member

simurai commented Jul 31, 2015

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:

pr

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?
@shana

This comment has been minimized.

Show comment
Hide comment
Collaborator

shana commented Jul 31, 2015

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

shana Jul 31, 2015

Collaborator

actually, /cc @github/desktop for the 👀

Collaborator

shana commented Jul 31, 2015

actually, /cc @github/desktop for the 👀

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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 😄)

pullrequestsbutton

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.

Collaborator

shana commented Jul 31, 2015

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 😄)

pullrequestsbutton

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.

@simurai

This comment has been minimized.

Show comment
Hide comment
@simurai

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:

pr-2

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.

Member

simurai commented Aug 1, 2015

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:

pr-2

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.

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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 :-/

Collaborator

shana commented Aug 1, 2015

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 :-/

@simurai

This comment has been minimized.

Show comment
Hide comment
@simurai

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:

pr-3

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.

Member

simurai commented Aug 4, 2015

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:

pr-3

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.

@simurai

This comment has been minimized.

Show comment
Hide comment
@simurai

simurai Aug 5, 2015

Member

Need a way of assigning someone to a PR

How about under the branch picker:

screen shot 2015-08-05 at 12 53 39 pm

screen shot 2015-08-05 at 12 41 51 pm

Member

simurai commented Aug 5, 2015

Need a way of assigning someone to a PR

How about under the branch picker:

screen shot 2015-08-05 at 12 53 39 pm

screen shot 2015-08-05 at 12 41 51 pm

@simurai

This comment has been minimized.

Show comment
Hide comment
@simurai

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.

screen shot 2015-08-05 at 1 19 31 pm

Member

simurai commented Aug 5, 2015

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.

screen shot 2015-08-05 at 1 19 31 pm

@simurai

This comment has been minimized.

Show comment
Hide comment
@simurai

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:

pr-diff

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?

Member

simurai commented Aug 5, 2015

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:

pr-diff

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?

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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?

pullrequest-detail-simuari1

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.

Collaborator

shana commented Aug 5, 2015

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?

pullrequest-detail-simuari1

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.

@Haacked

This comment has been minimized.

Show comment
Hide comment
@Haacked

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.

Member

Haacked commented Aug 5, 2015

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.

@simurai

This comment has been minimized.

Show comment
Hide comment
@simurai

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.

Member

simurai commented Aug 6, 2015

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.

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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?)

Collaborator

shana commented Aug 10, 2015

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?)

@simurai

This comment has been minimized.

Show comment
Hide comment
@simurai

simurai Aug 11, 2015

Member

I would prefer not to have the merge button and comment box scrolling up along with the comments

👍 Yeah, I can see that could be annoying having to scroll them into view first.

how to let the user know that there's new comments

Green indicator dot? New comments would be green too:

screen shot 2015-08-11 at 3 37 04 pm

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:

screen shot 2015-08-11 at 1 48 12 pm

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:

screen shot 2015-08-11 at 1 56 34 pm

Some more random ideas to leave more room for scrolling:

  1. 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.
  2. 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.

screen shot 2015-08-11 at 11 47 16 am

Member

simurai commented Aug 11, 2015

I would prefer not to have the merge button and comment box scrolling up along with the comments

👍 Yeah, I can see that could be annoying having to scroll them into view first.

how to let the user know that there's new comments

Green indicator dot? New comments would be green too:

screen shot 2015-08-11 at 3 37 04 pm

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:

screen shot 2015-08-11 at 1 48 12 pm

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:

screen shot 2015-08-11 at 1 56 34 pm

Some more random ideas to leave more room for scrolling:

  1. 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.
  2. 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.

screen shot 2015-08-11 at 11 47 16 am

@shana shana added this to the 2.0 milestone Aug 13, 2015

@kevinsawicki

This comment has been minimized.

Show comment
Hide comment
Member

kevinsawicki commented Aug 24, 2015

@shana shana referenced this issue Sep 16, 2015

Merged

[wip] Pull Requests #92

14 of 19 tasks complete

@shana shana modified the milestones: 1.2 - Pull Requests (and more), 2.0 Sep 28, 2015

@ToMaHaWk

This comment has been minimized.

Show comment
Hide comment
@ToMaHaWk

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.
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.

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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?

Collaborator

shana commented Oct 9, 2015

@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?

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

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.

list pull requests

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:

list pull requests - expand details

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.

list pull requests - filters

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.

creating a new pr

You could specify which branch you want to merge into using the dropdown near the title field.

creating a new pr - select branch

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.

creating a new pr - assignee

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.

creating pr filter menu

Member

donokuda commented Feb 2, 2016

🎨 🎨 🎨 🎨 🎨

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.

list pull requests

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:

list pull requests - expand details

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.

list pull requests - filters

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.

creating a new pr

You could specify which branch you want to merge into using the dropdown near the title field.

creating a new pr - select branch

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.

creating a new pr - assignee

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.

creating pr filter menu

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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!

Collaborator

shana commented Feb 2, 2016

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!

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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?

Collaborator

shana commented Feb 2, 2016

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?

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

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 👀 with the font sizes: I've also been using 14 for the title and 12 for the details. I prefer staying close to the fonts natively used so our extension doesn't feel out of place.

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.

Member

donokuda commented Feb 2, 2016

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 👀 with the font sizes: I've also been using 14 for the title and 12 for the details. I prefer staying close to the fonts natively used so our extension doesn't feel out of place.

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.

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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?

Collaborator

shana commented Feb 2, 2016

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?

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

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.

Member

donokuda commented Feb 2, 2016

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.

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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?

Collaborator

shana commented Feb 2, 2016

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?

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

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 😸 🔁

Member

donokuda commented Feb 2, 2016

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 😸 🔁

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

donokuda Feb 3, 2016

Member

Here's a pass at a tooltip dropdown:

image

A quick breakdown of states:

image

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 👍 I can spec out any dimensions/colors as needed.

❗️ Side note - I changed the "Assignee" label from bold to regular since we're (edit: already) differentiating between the label and the selection by color. 😳

Member

donokuda commented Feb 3, 2016

Here's a pass at a tooltip dropdown:

image

A quick breakdown of states:

image

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 👍 I can spec out any dimensions/colors as needed.

❗️ Side note - I changed the "Assignee" label from bold to regular since we're (edit: already) differentiating between the label and the selection by color. 😳

@simurai

This comment has been minimized.

Show comment
Hide comment
@simurai

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.

Member

simurai commented Feb 3, 2016

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.

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

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.

Member

donokuda commented Feb 3, 2016

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.

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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?

Collaborator

shana commented Feb 3, 2016

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?

@alexangas

This comment has been minimized.

Show comment
Hide comment
@alexangas

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.

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.

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

shana Feb 3, 2016

Collaborator

@arangas Good point, one dropdown mixing two different intents might be confusing.

Collaborator

shana commented Feb 3, 2016

@arangas Good point, one dropdown mixing two different intents might be confusing.

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

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):

image

Maybe it makes sense to expose the action on the side when there is an assignee:

image

Member

donokuda commented Feb 4, 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.

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):

image

Maybe it makes sense to expose the action on the side when there is an assignee:

image

@alexangas

This comment has been minimized.

Show comment
Hide comment
@alexangas

alexangas Feb 4, 2016

@donokuda Good point, that would be better.

@donokuda Good point, that would be better.

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

donokuda Feb 4, 2016

Member

@arangas 👍 We should go with that pattern for the assignee. Thanks for the 👀 and the feedback!

Member

donokuda commented Feb 4, 2016

@arangas 👍 We should go with that pattern for the assignee. Thanks for the 👀 and the feedback!

@shiftkey

This comment has been minimized.

Show comment
Hide comment
@shiftkey

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 👍 with heading down this path.

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

Member

shiftkey commented Feb 4, 2016

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 👍 with heading down this path.

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

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

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:)

image

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?

Member

donokuda commented Feb 4, 2016

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:)

image

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?

@shiftkey

This comment has been minimized.

Show comment
Hide comment
@shiftkey

shiftkey Feb 4, 2016

Member

This is the one I was referring to earlier:

screen shot 2016-02-04 at 1 02 10 pm

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 👍 with me. And if this is a chance for us to give Desktop a bit of spruce up "for free" then let's see what we can do...

Member

shiftkey commented Feb 4, 2016

This is the one I was referring to earlier:

screen shot 2016-02-04 at 1 02 10 pm

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 👍 with me. And if this is a chance for us to give Desktop a bit of spruce up "for free" then let's see what we can do...

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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?)

Collaborator

shana commented Feb 4, 2016

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?)

@shana shana referenced this issue Feb 4, 2016

Open

LICENSE Picker #216

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

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?

image

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. 🚲 We can still adjust it so that follow the same type treatment ([bold] [subdued]) in my version

Member

donokuda commented Feb 4, 2016

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?

image

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. 🚲 We can still adjust it so that follow the same type treatment ([bold] [subdued]) in my version

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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.

Collaborator

shana commented Feb 4, 2016

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.

@shiftkey

This comment has been minimized.

Show comment
Hide comment
@shiftkey

shiftkey Feb 4, 2016

Member

@shana

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?

Member

shiftkey commented Feb 4, 2016

@shana

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?

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

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.

artboard 1

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:

image

(Also note the [edit: alignment] of the placeholder text and the list text)

Member

donokuda commented Feb 5, 2016

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.

artboard 1

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:

image

(Also note the [edit: alignment] of the placeholder text and the list text)

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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.

Collaborator

shana commented Feb 5, 2016

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.

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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!

Collaborator

shana commented Feb 5, 2016

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!

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

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.

Member

donokuda commented Feb 6, 2016

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.

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

donokuda Feb 8, 2016

Member

Noodled on some thoughts around the UX of listing changed files in the commit tab.

image

Clicking on a commit would expand the item and show the file list (per commit). Clicking again would collapse the item.

#20 (comment)

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:

image

If that's the case, we could toggle the list of files by clicking the counter on the side:

image

However, I'm concerned that this is a UX pattern not used anywhere else. Maybe we consider using a list dropdown instead?:

image

Also, we could truncate long directories and filenames and show the full path in a tooltip:

image

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.

Member

donokuda commented Feb 8, 2016

Noodled on some thoughts around the UX of listing changed files in the commit tab.

image

Clicking on a commit would expand the item and show the file list (per commit). Clicking again would collapse the item.

#20 (comment)

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:

image

If that's the case, we could toggle the list of files by clicking the counter on the side:

image

However, I'm concerned that this is a UX pattern not used anywhere else. Maybe we consider using a list dropdown instead?:

image

Also, we could truncate long directories and filenames and show the full path in a tooltip:

image

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.

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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.

👍 on the dropdown to show the file list, it's nice. Showing the individual diffs might not be the most common action when creating a PR, but it is when looking at existing PRs, and the views here are pretty much the same for either, so we can support it in the creation too.

Collaborator

shana commented Feb 8, 2016

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.

👍 on the dropdown to show the file list, it's nice. Showing the individual diffs might not be the most common action when creating a PR, but it is when looking at existing PRs, and the views here are pretty much the same for either, so we can support it in the creation too.

@donokuda

This comment has been minimized.

Show comment
Hide comment
@donokuda

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:

image

Member

donokuda commented Feb 8, 2016

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:

image

@shana shana referenced this issue Mar 1, 2016

Open

Publish releases #223

0 of 5 tasks complete

@shana shana referenced this issue May 26, 2016

Closed

Pull Requests v1: Tasks #326

27 of 31 tasks complete
@stevekennaird

This comment has been minimized.

Show comment
Hide comment
@stevekennaird

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?

@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?

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

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!

Collaborator

shana commented Sep 16, 2016

@stevekennaird Yup, we're working on it, just taking a more holistic, workflow approach to it. See #491 for some of that!

@shana shana added this to In Progress in Feature work planning Jan 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment