9 ms·

Refactoring GitHub's Design

282 points by ianstormtaylor 13y ago

dansingerman 13y ago
Is cloning a repo that rare? Isn't that kind of the point of GitHub?
- aeden 13y ago
  The point being that you do it once for a repo, and then never again (in most cases).
  - infogulch 13y ago
    The clone/interact ratio should be very small, and this design encourages that. What you want is people to clone some repos and interact with them a lot, not clone a bunch of repos and never look at them again. Emphasize the cloning/interaction interface at the same ratio that you want people to use the respective features.
    - tux1968 13y ago
      Why is that the goal? Many people are simply consumers, clone a repo and then all interaction with it is local via normal Git usage. This group may really be larger than any other group. It seems a mistake to make life harder for what might be the majority of users. That said, I much preferred the refactored design and its visual simplicity. It makes the new Github design look cluttered by comparison.
  - simonz05 13y ago
    oh well, I think it is common to clone quiet a few repositories per user. I know its one of the most frequent things I use github for at least. Copy url, git clone url to local.
  - masklinn 13y ago
    It is however one of the first thing you want to do, and an important part of using github. Much more so, as far as I'm concerned, than the ratio of various languages within the repository whose level of uselessness is only overtaken by the number of tags in the repo.
    - ricardobeat 13y ago
      99% of the time you'll just type `git clone gh:user/repo.git`, or copy from the URL bar.
      - bostonvaulter2 13y ago
        > 99% of the time you'll just type `git clone gh:user/repo.git`, or copy from the URL bar. No, that's what YOU do 99% of the time. Do you think that accurately reflects 99% of GitHub's users? I know it doesn't reflect what I do (and I am a developer).
    - grkvlt 13y ago
      Agree, the ability to clone the repository should be a highly available/easily discoverable action. It will generally be the next thing the user wants to do (perhaps after forking) on first visiting a repository... Also, the idea that he needs to change the clone URL box so that it can autofocus is wrong. In fact, his current workflow for cloning is flawed: > "my current workflow for cloning of double-click to select + cmd-c" He just needs to click _once_ on the button to the right of the URL, which has a 'copy to clipboard' tooltip pop-up. He even showed this icon in his UI wireframe sketch. Perhaps it isn't noticed much by people because developers may have flash turned off, which is the mechanism used by GitHub to access the clipboard? To be honest, I didn't know about the feature for a long time, and used to do the same thing - select URL then command-C to copy it - myself. It was actually something I found out about from the GitHub blog post about the recent re-design!
- nbouscal 13y ago
  My confusion is why people need a dialog to tell them what the url to clone is. It follows the exact same pattern every single time. I've never once used the 'Clone' button on GitHub, and don't understand why anyone other than new users ever would.
bretthopper 13y ago
I really like this. One of the changes not mentioned in the article was merging the file path into the repo name at the top. Since the file path ALWAYS starts with the repo name anyway, this makes a lot of sense and eliminates redundancy. It's a shame he didn't add the language colour bar into the final comparison screenshot. I thought that was one of the best changes. It's quite jarring where it is right now. edit: The one issue with this redesign is it clearly goes against a philosophy which GitHub has recently embraced: quickly seeing the status/overview of a repo. Moving the Commits, Branches, Tags, and Contributors from up top to the right sidebar definitely reduces some clutter, but it makes them much less of a focus. And I'm pretty sure this is something GitHub wouldn't want.
- ianstormtaylor 13y ago
  Wow good call don't know how I forgot that! Added it in now. That was one of my favorite simplifications :) I seriously love finding abstractions like that. Regarding the "seeing the status/overview of a repo" I completely understand, and I think it's a genius way forward for GitHub. I touched on that towards the end with the user-uploaded backgrounds. But basically, I left my version of the refactor at the stage right before adding in the repository's identity. After refactoring away all of the distracting elements, there's much more room to play with creating a really solid identity concept for repositories, instead of the hacked together one we see today.
- masklinn 13y ago
  As TFAA hints, the Branches and Tags counts don't provide any useful information, they're highly dependent on the author's coding and usage style and are orthogonal to any interesting information about both the repository itself and user engagement with the repository. Consider: Django has 38 branches and 41 tags, Rails has 25 branches and 183 tags, Symphony has 6 branches and 44 tags, Play has 4 branches and 48 tags, Flask has 15 branches and 16 tags. What did that tell you about them? Nothing. > It's a shame he didn't add the language colour bar into the final comparison screenshot. I thought that was one of the best changes. I thought not including it was an excellent choice: aside from providing a jarring dash of colour it is a complete waste of space, if you interact with the repository you probably know which language(s) it is coded in, and if you don't you probably don't care.
dreamdu5t 13y ago
I cannot fathom why such a visually jarring thick bar of color representing the languages used is the most prominent visual element on the page. It makes no sense. Especially when you consider that you already likely know the primary language the project you're looking at is written in.
- ldn_tech_exec1 13y ago
  totally agree, wtf. but regarding the rest of the design, I think its a huge improvement.
- imperialWicket 13y ago
  Totally agree. The only use I see is when you're simply searching for projects/solutions and you want to quickly ascertain popularity and language. That said, I'm not sure I'll remember the color-language relationships without a lot of work that I'm not interested in performing.
  - bostonvaulter2 13y ago
    I think there's a disconnect in the use case of you and the OP compared to some other people (like me). 90% of the time when I'm looking at a Github repo it's for a new project so things like language composition, number (or existence) of tags to download and clone URL are all very handy. Only 10% of the time am I looking at a project that I'm already intimately familiar with.
    - masklinn 13y ago
      > things like language composition, number (or existence) of tags [...] are all very handy Why? How? I just can't fathom what use they could be outside of pointless wankery.
- ics 13y ago
  What's funny is that I came back to this post specifically to ask where the language bar had gone... the last couple repos I looked at were "pure" so I didn't see the usual blocky bar– just a solid stripe that I didn't think twice about. If only we could swap perception, because I really want to see the language breakdown in repos. It's quite nice when you come across a project you've never heard of before and can see immediately whether it's 100% this or that, 50% shell, or whatever. Even projects you have heard of, it's nice to get the overview, especially if you're interested in contributing by, for example, rewriting certain parts in a higher or lower level language.
imperialWicket 13y ago
These are good notes. You can quibble over some of the specific details and their assigned importance, but generally they show great logical enhancements. To add to the language bar discussion - I rarely care about the languages in my own repositories (or repositories I'm watching or have starred). This is one of the new features that I enjoy for repository review, but if I'm in a repo I actually use, I rarely care about any of the data here (including commit numbers, tags, branches, contr.) Rather than moving this data about the page, I'd like to be able to remove it entirely based on circumstance or settings.
rlx0x 13y ago
I can't even see all repositories of a user, just the "most popular" the same with gist, no quick overview anymore. I really hate the recent changes and can only laugh at this pretentious bs article.
- dangrossman 13y ago
  Why is your criticism of the design changes thoughtful, but Ian's criticism of the design changes "pretentious bs"?
JCB_K 13y ago
Minor nitpick, it was Path who first started using the cover photo. Facebook did the same only a few months later, and then many other services followed.
- ianstormtaylor 13y ago
  Good call. Completely forgot Path started that... but that makes sense since they've got a lot of nice interface touches.
jbail 13y ago
This, like the iOS icon teardown post before it, are excellent. Tons of content. Well written. I have a question for Ian: How do you find time to do such in depth teardowns and UI refactors of other people's apps? Actually let me re-phrase that: How do you justify spending time on these blog posts instead of focusing on your own application? Maybe it's just a calculated cost you incur to get traffic? Even so, how did you determine this to be the highest value activity as a start up cofounder?
- rpicard 13y ago
  Not everything has to be a cost/value calculation. Sometimes you can just do things because you enjoy them.
  - davewasmer 13y ago
    Isn't that a cost/value calculation? :) You value some things because you enjoy them, more than you value other possible uses of that time.
- DanielRibeiro 13y ago
  Edawrd Tufte's teardown on iPhone design is also very good: http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=00036T http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0...
- ianstormtaylor 13y ago
  Doing the actual refactor was probably 25% of the time investment here. When I saw the GitHub launch post about the new UI I started having a few ideas about how it could be improved, so I started hacking on it in Photoshop. Usually these kinds of things just end up in a trash folder somewhere, but I was digging where it was going so I kept at it. As for writing the article, we actually like to encourage each other to write interesting articles on our personal blogs. One thing to keep in mind is that you'll be most productive when you're inspired to write, so if I get inspired to write something mid-day, unless there's a super important Segment.io deadline I'll just take a detour for an hour and write down my thoughts. And we try to remain open to each other doing that, instead of seeing it as "wasted" time. @calvinfo did the same with his recent article on Node's new streams too: http://calv.info/an-introduction-to-nodes-new-streams/ http://calv.info/an-introduction-to-nodes-new-streams/ — since they are timely topics we like to get them out as soon as possible. It's not without personal gain either, there are definitely traffic benefits, although I haven't looked into how much traffic actually gets from my own site to our Segment.io's site, let alone signs up. There are also hiring benefits I assume (we're only just starting to hire Javascript folks) from putting yourself out in the community. Mostly I just enjoy it, so I do it ;) I usually write these after 8pm or so when I switch from working on Segment.io to doing whatever else I want (half the time it's still working on Segment.io haha). I also wish more designers would write about this kind of stuff, so I like to do it myself too. I'd love to get more process information about how other startup designers think. I wouldn't worry too much about keeping it fresh... I had a long period of silence from October to March while I was head down on product. Although I did feel guilty about it the whole time...
sauravc 13y ago
"And at the same time, we can de-emphasize the branch switcher since it’s so rarely used." WRONG. This is why designers shouldn't be "redesigning" stuff they don't use. Branching and merging with ease is what makes distributed scm's so much better than the previous generation. Why would one want to de-emphasize this? And let's talk about what really used. Github is great for viewing code easily and making comments. So what did they do to the code view div in the latest redesign? They made it smaller! Unbelievable! So now I have to use a Chrome plugin to fix it: https://github.com/sauravc/github_wideload https://github.com/sauravc/github_wideload These "designers" aren't entirely to blame though. A lot of what the author suggested makes things better. Unfortunately, coders are a tough crowd to please.
- ianstormtaylor 13y ago
  Don't worry, I use it: https://github.com/ianstormtaylor https://github.com/ianstormtaylor
- encoderer 13y ago
  Hold on. I don't mean to pick apart your comment but since you started off with a big bold nasty "WRONG" I don't feel so bad. First, "branch and merging with ease" has nothing to do with "distributed SCM" tools. The branching model in Git is great of course but Mercurial for instance has a far different branching strategy. Bookmarks, which mimic Git branching, were added much later. Second, while I do a lot of branching in Git, that has nothing to do with the branch selector on the Github UI. Now, something that DOES, is the branch selector in the Pull Request screen which wasn't mentioned by the author but IMO should've been because that's the single worst part of the Github redesign.
  - danabramov 13y ago
    >Second, while I do a lot of branching in Git, that has nothing to do with the branch selector on the Github UI. My thoughts exactly.
  - duaneb 13y ago
    > First, "branch and merging with ease" has nothing to do with "distributed SCM" tools. Local branches tend to be a feature of distributed SCM tools, so I'd say you're wrong.
CatMtKing 13y ago
I'm very impressed by the result. His refactor looks great.
Demiurge 13y ago
I like the final refactor much better, I wish they just do it :)
tmzt 13y ago
Well got automatically switched to the new Github layout. I tried switch the Git URL to git protocol but was unable to do so. When I first saw github, the option of choosing ssh or git protocol, as well as http, helped to establish it's credentials as a company that "gets it" when it comes to technology. As developers that tends to be important to us because it suggests that other features are going to work the way we expect. I think the new design is lacking in a number of areas that the old design got exactly right. The git log tells you quickly when the last update was made, but without hiding the tree view too deeply. My preference would be for the features of the old design to be restored as best as possible, even keeping the new design as a whole. I would also like to see something like the Android application's interface, including the "news feed" like view added to the web interface.
joshmlewis 13y ago
This is an interesting example of a 're-design' that isn't all about new colors, graphics, and everything else but just a combining of elements, some more uniform styling, and just doing something that makes sense. This goes to show every redesign doesn't have to be fancy new colors and layouts, just thinking logically about everything you need. This also shows the importance of going beyond pretty colors into meaningful design.
beatboxrevival 13y ago
As a designer that codes, i'd really like to remove most of github's grayness. They seem to do a lot of excessive bordering and gray layers. You could remove almost all of it, without making the UI harder to use.
ricardobeat 13y ago
It's a nice improvement (specially with the huge language bar gone), and the header image would look great, but I still think the two-column layout is a step back. Right-hand menus are a bit weird, and it makes everything below "the fold" left-aligned, total waste of screen area.
jasonlotito 13y ago
As someone that uses GH enterprise more than GH proper, I'll address the changes here from that perspective. 1. Pushing the branch changer off to be so subtle hurts. I change branches, a lot. Browsing code and changing the branch is something I frequently do on GH. 2. Lack of clone url is annoying. If all I have to do is click Clone and that's it, then I can live with that. 3. Clown, Download, and Watch are too far down the screen. I usually have a big screen, but not always, and I have my monitors maximized. 4. The ordering of the links on the right are odd. I click Watch, Clone, and Download far more than Contributors. Still, the ordering is off. Pulse is at the top, but we start off with Code? With very little thought, I'd order them Code, Commits, Pull Requests, Issues, Branches & Tags, etc. 5. The Wiki link is hidden. It really should have a better place. While the rest of the links on the right relate directly to code at some level, the Wiki does not. It's documentation mostly. Being disregarded like it is, it should be removed. Either that, or found a better home. 6. Stars and Forks should be Star and Fork. They are labels for buttons that perform an action, not state. 7. Code, I assume, takes up a lot more space! Yay! 8. The top is clean, making it easy to see exactly where I'm at. These are just initial thoughts. Overall, the design is more open. I think for me, the layout of some of the interactions need to be thought out a bit more, and need to take into consideration more than just your basic free github user.
ajanuary 13y ago
It's worth noting a lot of the design decisions in the article are based on assertions about what is/isn't used. Which is fine - it makes reading through the design process more interesting and insightful. It would be interesting to compare that with actual usage statistics that one assumes github have (to one degree or another) and see if some of the differences in the design are due to flawed assumptions in the article.
- ianstormtaylor 13y ago
  Absolutely. I actually had a section about that but had to cut it since it was getting rambly :) There are even other business concerns that go beyond just usage statistics. For example, GitHub might see the Mac app as their future, for bringing git to people who aren't familiar with the command line, in which case it would make more sense to make the Clone in Mac button prominent. The other piece I cut was talking about how not only do advanced users only need certain features, but there are also features that only new users need, like walkthroughs and things. It gets really hard to visualize all of those decisions in a flat mockup. But yup I totally agree, trying to redesign an interface that you don't own is always going to be very hard and error-prone. Although GitHub is probably one the interfaces that most of us would have the most success with based on how heavily we use it.
jrochkind1 13y ago
I like seeing design critiques like this, especially when done from actual design experience, and with respect. But, I came to say: Is the branch lister/switcher really one of the least-used parts of github? It's one of the parts I use the most, actually!
josephlord 13y ago
Nice article and a very slightly opportunity for a couple of minor Github annoyances to come out of me. All of which I think apply both to the old and new design. Does it bug anyone else that the Github commit count tops out at 1000+ commits making it completely useless after that point? A repo last updated date would be more useful (I know I only have to scan the directory modified dates but a consolidated one would be nice). It would also be great if they could show the unmerged branches at the top of the branch selector and allow branches to be kept but marked as obselete so they weren't offered with the other unmerged branches but could be kept rather than completely deleted. My final wish would be for a couple of things bitbucket has in its diff views, namely side by side diffs and the option to show additional lines around the diff to give greater context. Bitbucket is sorely missing Githubs great network view though.
- quadratini 13y ago
  YES. 1000+ commits is so useless. Also I wanted to look at the commit history and it was entirely unobvious that you can click "1000+ commits".
w-m 13y ago
Here are the two sidebars (new github vs. Ians design) side by side: http://i.imgur.com/e2w6TkT.png http://i.imgur.com/e2w6TkT.png Ians: - got rid of the color indicator - got rid of the separation lines - is truncating the list - has three identical buttons where there were two - has more indirection. Cloning is autofocused for me, it takes one click+cmd-c. Also, when I'm scanning the page for a way to clone by URL, I'll find the actual URL much faster than the button that says "Clone". I like the general idea of the redesign, but I think it would make the sidebar much worse.
- sergeykish 13y ago
  Agree, hiding clone URLs arn't good. Links are already in scroll area. And "copy to clipboard" doesn't help, it requires Flash, which isn't good at all on Linux
reledi 13y ago
Thanks for blogging this. I like the overall changes of your refactor, but there are a few minor nitpicks: - Why did you change "Star" and "Fork" to "Stars" and "Forks"? The before and after have different meanings. - The colour bar is missing from your final design. You mentioned in a comment that you forgot to add it and then added it, but I still don't see it :). - The right side navigation section is prematurely cut off at "Settings". - Your "Clone" and "Download" buttons could use some more whitespace between the text and icon.
- ianstormtaylor 13y ago
  1. Ah yup that's true. The part of the "star" button that I was focused on was removing the "unstar" word since I find it really confusing. I'd rather use a depressed button to signify that I've starred something. But yup, removing the s's would be good. 2. Nope didn't forget it. My final design isn't "final", it's just at a point in the refactoring. The next step would be to figure out how to add in more of an identity to each repo. I tried to mention this towards the end of the article when talking about the background image idea. 3. It's hard to show in a flat mockup, but the idea for that would be that hovering it would have an animation that slightly dropped the divider down, and clicking would open it all the way. But it could totally be an over-optimization, in which case the 3-4 extra list items could just always be visible. 4. Ah, I just took the same style as GitHub. (Actually one of the cool parts of the refactor process was that GitHub's markup is so self-evident that lots of the pieces were made by just changing class names and then re-screenshotting the GitHub interface itself.)
JohnDotAwesome 13y ago
Great piece, but... One thing bothered me. He said it took a double click and cmd+c to copy? That's not true at all. Single click auto selects. I think the hiding the of the URL is kinda lame because the URL _was the design element_ for "clone" for so long. I see the URL and I know I can click it to select, CMD+C, paste it into my terminal. Ian certainly has some valid points, but in the end, I think he's not appreciating the full-range of use cases that everyone has. Github has a lot of different kinds of users. Enterprise development flows are a bit different than the open source ones. And those are the flows that bring in the money. Though, I'm sure they use Github enterprise, so maybe he does appreciate that use case as well.
Udo 13y ago
I like most of the ideas, but: Cloning a repository happens rarely, but in the old interface it was one of the first things on the page. Is it really happening so rarely? It's one of my primary interactions with a foreign repository. Am I atypical?
- przemoc 13y ago
  No, you're not atypical. If I want to look into some project closer (and that's why I'm searching or visiting particular github page in the first place, well, more often than not), then I copy git:// URL and download git repo. Real fiddling happens locally later.
  - bjeanes 13y ago
    GitHub's answer to this is "just copy the URL from your browser." It means using http(s) cloning which may or may not be desired, but from a UX perspective I think that it is neat.
- nsmartt 13y ago
  I don't think he means that it's rarely used so much as it's done rarely by the user. When visiting a project page, users likely won't need to clone as often as they'll need to do various other things on a page.
- naiquevin 13y ago
  I clone repos very often to browse the files in my editor so I didn't like the change initially (and I still don't like it very much) but then after getting used to it I felt that the clone-download section could be positioned above the right side menu which would also allow the menu to be aligned with the box that lists files and dirs. Anyway, I liked the article even though I am not a UI person
zobzu 13y ago
Reducing an interface until only the absolutely necessary elements remain is one of the most satisfying tasks in design. Now I understand the issue with design :P Now I think the GitHub redesign is okay - but i also think "absolutely" is too strong of a word. The "usual tasks" for "most people" should be part of the UI IMO. Many products go with "absolutely vital" and then the UI sux because you don't get the buttons u needed, in the name of simplicity.
philliphaydon 13y ago
For me, about 30% of the changes were bad choices. Its harder to navigate around now than it used to be. While the other 70% of the changes are great.
sgdesign 13y ago
I hate that language bar so much (I work on a lot of 100% JavaScript projects) that I installed Stylebot (http://stylebot.me http://stylebot.me) just to get rid of it.
btipling 13y ago
My opinion of GitHub's redesign from a user's point of view is that it has been difficult to adjust to the point it has made me angry and frustrated. The pull request UI change is a regression.
jimmaswell 13y ago
I really don't like the trend of simplified interfaces. I have absolutely no problem with interfaces with options and buttons all over the place. Is there any real productive purpose to changing interfaces when users are used to the old one and fine with it? I see it like forcing users to switch to dvorak. Anyone who spends a reasonably amount of typing can probably get a fine 100wps on qwerty, they might get slightly more if they spent a long time learning dvorak, but the marginal return wouldn't offset the benefit, because most of the time you're not typing at your full speed anyway - you're pausing between shorter bursts of typing to think of what to type, use your mouse, or something else.
- garysweaver 13y ago
  I think having fewer elements when they are unnecessary is a great idea, if it makes the interface easier to use. However, in this case, though I don't dislike GitHub's new interface, but the big colored line showing the percentage of different kinds of code in the project is really unnecessary and the color is distracting. But, other than a few minor things, I've not had a problem with the design changes, and I certainly didn't have the remorse that I had when I switched to the last major Facebook design overhaul early. And now I'm used to that also.
  - jimmaswell 13y ago
    The facebook design changes all tend to feel pointless and annoying, don't they? I've only used github for a week or so, so I'm not really attached to its interface, and I tend to only interact with it through the github client. On a bit of a tangent, the github client feels awkward and strange. For one thing, it doesn't follow the normal conventions of the OS I'm on. It doesn't even have a menu strip. I'd much rather make a new repo with file -> new repo, have push pull commit etc be in appropriate submenus on the menu strip, and so on, but this thing just throws stuff all over the place willy-nilly, sometimes I don't know if I'm even able to do something and it turns out I have to double-click, things like that. Committing and pushing with gitextensions from inside VS feels nicer. I really think interface design for desktop apps hit its peak a while ago before everyone was obsessed with stripping things down to the bone. Every update I see menu options and configurability widdled away from applications like Firefox, which is on the track to becoming the one-size-fits-all Chrome. If you want some evidence for that, hang around some channels on irc.mozilla.org. Another thing is that when I look at screenshots of youtube from a few years ago, it's astounding how much they got right back then that's gone now. The tracking bar has no place hovering over the video obscuring it, the five star system was great but had to be replaced with a binary yes/no, there was a button to start over instead of having to click on the start of the tracker bar, it goes on. I've used applications from the late 90s or around that period before. They were great. Menu strips were chuck full of stuff, buttons everywhere, just great design to me. Too many applications are being stripped of any useful feature that's not absolutely essential (or made to have the feature available only through obscure shortcuts / ini files / etc) and it's a development that I greatly disapprove of. I'd rather not have my Microsoft Word replaced with Google Docs.
djs070 13y ago
Is it just because I'm on iOS or have some of these suggestions been implemented on github?
calpaterson 13y ago
In this discussion he makes several assumptions like "we can de-emphasize the branch switcher since it’s so rarely used" and "The Clone in Mac button was a perfect example of an under-used feature" and "Cloning a repository happens rarely" all of which do not chime with my personal experience. Our disagreement is to be expected - no two people completely agree about an interface - but it is extremely disappointing that he makes no mention of testing on real users (or at the very least, speaking to them) in order to gauge whether these features really are unimportant. If you want to know the reason why so many site redesigns are unpopular with users, here it is: you didn't test them. I'm not trying to take this to absurd conclusions like "every change has to be tested" but the central idea of this guy is faulty: design of the user interface, like design of software, is NOT to be done by anyone in isolation. You need to involve real users in major changes before they happen. I hope Github ran user testing before they released these changes.
Heliosmaster 13y ago
Really nice insights on design. You might want to chat with the guys that make GitLab :)
rg3 13y ago
I really like the refactoring done here. Congratulations to the author. He did an excellent job, IMHO. There's one thing missing that I always wanted to have: put the contents of the README file _above_ the file listing. The truth is, many people in Github don't use the Pages feature and rely instead on the README being the main project page containing the description, instructions, etc. And sometimes you have to scroll a bit to get to that information. If the README was on top, the main project page at github.com would be given the importance many projects give it. Variations of this idea: let the code be on top but only after a single click to expand the repo contents, unless the project lacks a README file. In that case expand the repo contents directly.
- masklinn 13y ago
  That's what Bitbucket does (after a fashion, the default home page is actually called Overview and displays the readme at the repository root and below it a recent activity history for the repo)
zoowar 13y ago
I love to hate the "refactored design". If it's truly just "completely reorganized to emphasize the commonly used features," then it's just a theme. Let the user choose the theme, don't force it on them.
aristidb 13y ago
"Cloning a repository happens rarely, but in the old interface it was one of the first things on the page." No. It does not happen rarely. I do it all the time. (I realize that other commenters have expressed the same sentiment among other things, but for me this is the key element to emphasize.)
- Zigurd 13y ago
  I suspect the statistics on feature usage are slanted toward trivial repos that are being used like SVN, or that are not being used as part of a distributed workflow. "Important" doesn't mean "used by the majority of projects."
mekishizufu 13y ago
I think it is an improvement except for the right menu. The list is harder to parse and the order is just completely wrong. The four most important links (Code, PR, Issues and Wiki) should always be on the top of the list.
c0mpute 13y ago
Really well done. I think I was one of the few (perhaps?) who did not like the new redesign of github. I did not like the content above that red/color bar at all. It is that much real estate taken away from me to see the code/commits/documentation of the page. I often use last commit and all commits to compare and see what is going on. I also quickly switch branches on the UI to compare stuff. The current github just feels its a always one extra click or I am searching for something. Somehow it doesn't feel minimalistic at all. Ian's redesign makes it elegantly simple and minimalistic.

282 points by ianstormtaylor 13y ago

dansingerman 13y ago

Is cloning a repo that rare? Isn't that kind of the point of GitHub?

aeden 13y ago
The point being that you do it once for a repo, and then never again (in most cases).
- infogulch 13y ago
  The clone/interact ratio should be very small, and this design encourages that. What you want is people to clone some repos and interact with them a lot, not clone a bunch of repos and never look at them again. Emphasize the cloning/interaction interface at the same ratio that you want people to use the respective features.
  - tux1968 13y ago
    Why is that the goal? Many people are simply consumers, clone a repo and then all interaction with it is local via normal Git usage. This group may really be larger than any other group. It seems a mistake to make life harder for what might be the majority of users. That said, I much preferred the refactored design and its visual simplicity. It makes the new Github design look cluttered by comparison.
- simonz05 13y ago
  oh well, I think it is common to clone quiet a few repositories per user. I know its one of the most frequent things I use github for at least. Copy url, git clone url to local.
- masklinn 13y ago
  It is however one of the first thing you want to do, and an important part of using github. Much more so, as far as I'm concerned, than the ratio of various languages within the repository whose level of uselessness is only overtaken by the number of tags in the repo.
  - ricardobeat 13y ago
    99% of the time you'll just type `git clone gh:user/repo.git`, or copy from the URL bar.
    - bostonvaulter2 13y ago
      > 99% of the time you'll just type `git clone gh:user/repo.git`, or copy from the URL bar. No, that's what YOU do 99% of the time. Do you think that accurately reflects 99% of GitHub's users? I know it doesn't reflect what I do (and I am a developer).
  - grkvlt 13y ago
    Agree, the ability to clone the repository should be a highly available/easily discoverable action. It will generally be the next thing the user wants to do (perhaps after forking) on first visiting a repository... Also, the idea that he needs to change the clone URL box so that it can autofocus is wrong. In fact, his current workflow for cloning is flawed: > "my current workflow for cloning of double-click to select + cmd-c" He just needs to click _once_ on the button to the right of the URL, which has a 'copy to clipboard' tooltip pop-up. He even showed this icon in his UI wireframe sketch. Perhaps it isn't noticed much by people because developers may have flash turned off, which is the mechanism used by GitHub to access the clipboard? To be honest, I didn't know about the feature for a long time, and used to do the same thing - select URL then command-C to copy it - myself. It was actually something I found out about from the GitHub blog post about the recent re-design!
nbouscal 13y ago
My confusion is why people need a dialog to tell them what the url to clone is. It follows the exact same pattern every single time. I've never once used the 'Clone' button on GitHub, and don't understand why anyone other than new users ever would.

bretthopper 13y ago

I really like this. One of the changes not mentioned in the article was merging the file path into the repo name at the top. Since the file path ALWAYS starts with the repo name anyway, this makes a lot of sense and eliminates redundancy. It's a shame he didn't add the language colour bar into the final comparison screenshot. I thought that was one of the best changes. It's quite jarring where it is right now. edit: The one issue with this redesign is it clearly goes against a philosophy which GitHub has recently embraced: quickly seeing the status/overview of a repo. Moving the Commits, Branches, Tags, and Contributors from up top to the right sidebar definitely reduces some clutter, but it makes them much less of a focus. And I'm pretty sure this is something GitHub wouldn't want.

ianstormtaylor 13y ago
Wow good call don't know how I forgot that! Added it in now. That was one of my favorite simplifications :) I seriously love finding abstractions like that. Regarding the "seeing the status/overview of a repo" I completely understand, and I think it's a genius way forward for GitHub. I touched on that towards the end with the user-uploaded backgrounds. But basically, I left my version of the refactor at the stage right before adding in the repository's identity. After refactoring away all of the distracting elements, there's much more room to play with creating a really solid identity concept for repositories, instead of the hacked together one we see today.
masklinn 13y ago
As TFAA hints, the Branches and Tags counts don't provide any useful information, they're highly dependent on the author's coding and usage style and are orthogonal to any interesting information about both the repository itself and user engagement with the repository. Consider: Django has 38 branches and 41 tags, Rails has 25 branches and 183 tags, Symphony has 6 branches and 44 tags, Play has 4 branches and 48 tags, Flask has 15 branches and 16 tags. What did that tell you about them? Nothing. > It's a shame he didn't add the language colour bar into the final comparison screenshot. I thought that was one of the best changes. I thought not including it was an excellent choice: aside from providing a jarring dash of colour it is a complete waste of space, if you interact with the repository you probably know which language(s) it is coded in, and if you don't you probably don't care.

dreamdu5t 13y ago

I cannot fathom why such a visually jarring thick bar of color representing the languages used is the most prominent visual element on the page. It makes no sense. Especially when you consider that you already likely know the primary language the project you're looking at is written in.

ldn_tech_exec1 13y ago
totally agree, wtf. but regarding the rest of the design, I think its a huge improvement.
imperialWicket 13y ago
Totally agree. The only use I see is when you're simply searching for projects/solutions and you want to quickly ascertain popularity and language. That said, I'm not sure I'll remember the color-language relationships without a lot of work that I'm not interested in performing.
- bostonvaulter2 13y ago
  I think there's a disconnect in the use case of you and the OP compared to some other people (like me). 90% of the time when I'm looking at a Github repo it's for a new project so things like language composition, number (or existence) of tags to download and clone URL are all very handy. Only 10% of the time am I looking at a project that I'm already intimately familiar with.
  - masklinn 13y ago
    > things like language composition, number (or existence) of tags [...] are all very handy Why? How? I just can't fathom what use they could be outside of pointless wankery.
ics 13y ago
What's funny is that I came back to this post specifically to ask where the language bar had gone... the last couple repos I looked at were "pure" so I didn't see the usual blocky bar– just a solid stripe that I didn't think twice about. If only we could swap perception, because I really want to see the language breakdown in repos. It's quite nice when you come across a project you've never heard of before and can see immediately whether it's 100% this or that, 50% shell, or whatever. Even projects you have heard of, it's nice to get the overview, especially if you're interested in contributing by, for example, rewriting certain parts in a higher or lower level language.

imperialWicket 13y ago

These are good notes. You can quibble over some of the specific details and their assigned importance, but generally they show great logical enhancements. To add to the language bar discussion - I rarely care about the languages in my own repositories (or repositories I'm watching or have starred). This is one of the new features that I enjoy for repository review, but if I'm in a repo I actually use, I rarely care about any of the data here (including commit numbers, tags, branches, contr.) Rather than moving this data about the page, I'd like to be able to remove it entirely based on circumstance or settings.

rlx0x 13y ago

I can't even see all repositories of a user, just the "most popular" the same with gist, no quick overview anymore. I really hate the recent changes and can only laugh at this pretentious bs article.

dangrossman 13y ago
Why is your criticism of the design changes thoughtful, but Ian's criticism of the design changes "pretentious bs"?

JCB_K 13y ago

Minor nitpick, it was Path who first started using the cover photo. Facebook did the same only a few months later, and then many other services followed.

ianstormtaylor 13y ago
Good call. Completely forgot Path started that... but that makes sense since they've got a lot of nice interface touches.

jbail 13y ago

This, like the iOS icon teardown post before it, are excellent. Tons of content. Well written. I have a question for Ian: How do you find time to do such in depth teardowns and UI refactors of other people's apps? Actually let me re-phrase that: How do you justify spending time on these blog posts instead of focusing on your own application? Maybe it's just a calculated cost you incur to get traffic? Even so, how did you determine this to be the highest value activity as a start up cofounder?

rpicard 13y ago
Not everything has to be a cost/value calculation. Sometimes you can just do things because you enjoy them.
- davewasmer 13y ago
  Isn't that a cost/value calculation? :) You value some things because you enjoy them, more than you value other possible uses of that time.
DanielRibeiro 13y ago
Edawrd Tufte's teardown on iPhone design is also very good: http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=00036T http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0...
ianstormtaylor 13y ago
Doing the actual refactor was probably 25% of the time investment here. When I saw the GitHub launch post about the new UI I started having a few ideas about how it could be improved, so I started hacking on it in Photoshop. Usually these kinds of things just end up in a trash folder somewhere, but I was digging where it was going so I kept at it. As for writing the article, we actually like to encourage each other to write interesting articles on our personal blogs. One thing to keep in mind is that you'll be most productive when you're inspired to write, so if I get inspired to write something mid-day, unless there's a super important Segment.io deadline I'll just take a detour for an hour and write down my thoughts. And we try to remain open to each other doing that, instead of seeing it as "wasted" time. @calvinfo did the same with his recent article on Node's new streams too: http://calv.info/an-introduction-to-nodes-new-streams/ http://calv.info/an-introduction-to-nodes-new-streams/ — since they are timely topics we like to get them out as soon as possible. It's not without personal gain either, there are definitely traffic benefits, although I haven't looked into how much traffic actually gets from my own site to our Segment.io's site, let alone signs up. There are also hiring benefits I assume (we're only just starting to hire Javascript folks) from putting yourself out in the community. Mostly I just enjoy it, so I do it ;) I usually write these after 8pm or so when I switch from working on Segment.io to doing whatever else I want (half the time it's still working on Segment.io haha). I also wish more designers would write about this kind of stuff, so I like to do it myself too. I'd love to get more process information about how other startup designers think. I wouldn't worry too much about keeping it fresh... I had a long period of silence from October to March while I was head down on product. Although I did feel guilty about it the whole time...

sauravc 13y ago

"And at the same time, we can de-emphasize the branch switcher since it’s so rarely used." WRONG. This is why designers shouldn't be "redesigning" stuff they don't use. Branching and merging with ease is what makes distributed scm's so much better than the previous generation. Why would one want to de-emphasize this? And let's talk about what really used. Github is great for viewing code easily and making comments. So what did they do to the code view div in the latest redesign? They made it smaller! Unbelievable! So now I have to use a Chrome plugin to fix it: https://github.com/sauravc/github_wideload https://github.com/sauravc/github_wideload These "designers" aren't entirely to blame though. A lot of what the author suggested makes things better. Unfortunately, coders are a tough crowd to please.

ianstormtaylor 13y ago
Don't worry, I use it: https://github.com/ianstormtaylor https://github.com/ianstormtaylor
encoderer 13y ago
Hold on. I don't mean to pick apart your comment but since you started off with a big bold nasty "WRONG" I don't feel so bad. First, "branch and merging with ease" has nothing to do with "distributed SCM" tools. The branching model in Git is great of course but Mercurial for instance has a far different branching strategy. Bookmarks, which mimic Git branching, were added much later. Second, while I do a lot of branching in Git, that has nothing to do with the branch selector on the Github UI. Now, something that DOES, is the branch selector in the Pull Request screen which wasn't mentioned by the author but IMO should've been because that's the single worst part of the Github redesign.
- danabramov 13y ago
  >Second, while I do a lot of branching in Git, that has nothing to do with the branch selector on the Github UI. My thoughts exactly.
- duaneb 13y ago
  > First, "branch and merging with ease" has nothing to do with "distributed SCM" tools. Local branches tend to be a feature of distributed SCM tools, so I'd say you're wrong.

CatMtKing 13y ago

I'm very impressed by the result. His refactor looks great.

Demiurge 13y ago

I like the final refactor much better, I wish they just do it :)

tmzt 13y ago

Well got automatically switched to the new Github layout. I tried switch the Git URL to git protocol but was unable to do so. When I first saw github, the option of choosing ssh or git protocol, as well as http, helped to establish it's credentials as a company that "gets it" when it comes to technology. As developers that tends to be important to us because it suggests that other features are going to work the way we expect. I think the new design is lacking in a number of areas that the old design got exactly right. The git log tells you quickly when the last update was made, but without hiding the tree view too deeply. My preference would be for the features of the old design to be restored as best as possible, even keeping the new design as a whole. I would also like to see something like the Android application's interface, including the "news feed" like view added to the web interface.

joshmlewis 13y ago

This is an interesting example of a 're-design' that isn't all about new colors, graphics, and everything else but just a combining of elements, some more uniform styling, and just doing something that makes sense. This goes to show every redesign doesn't have to be fancy new colors and layouts, just thinking logically about everything you need. This also shows the importance of going beyond pretty colors into meaningful design.

beatboxrevival 13y ago

As a designer that codes, i'd really like to remove most of github's grayness. They seem to do a lot of excessive bordering and gray layers. You could remove almost all of it, without making the UI harder to use.

ricardobeat 13y ago

It's a nice improvement (specially with the huge language bar gone), and the header image would look great, but I still think the two-column layout is a step back. Right-hand menus are a bit weird, and it makes everything below "the fold" left-aligned, total waste of screen area.

jasonlotito 13y ago

As someone that uses GH enterprise more than GH proper, I'll address the changes here from that perspective. 1. Pushing the branch changer off to be so subtle hurts. I change branches, a lot. Browsing code and changing the branch is something I frequently do on GH. 2. Lack of clone url is annoying. If all I have to do is click Clone and that's it, then I can live with that. 3. Clown, Download, and Watch are too far down the screen. I usually have a big screen, but not always, and I have my monitors maximized. 4. The ordering of the links on the right are odd. I click Watch, Clone, and Download far more than Contributors. Still, the ordering is off. Pulse is at the top, but we start off with Code? With very little thought, I'd order them Code, Commits, Pull Requests, Issues, Branches & Tags, etc. 5. The Wiki link is hidden. It really should have a better place. While the rest of the links on the right relate directly to code at some level, the Wiki does not. It's documentation mostly. Being disregarded like it is, it should be removed. Either that, or found a better home. 6. Stars and Forks should be Star and Fork. They are labels for buttons that perform an action, not state. 7. Code, I assume, takes up a lot more space! Yay! 8. The top is clean, making it easy to see exactly where I'm at. These are just initial thoughts. Overall, the design is more open. I think for me, the layout of some of the interactions need to be thought out a bit more, and need to take into consideration more than just your basic free github user.

ajanuary 13y ago

It's worth noting a lot of the design decisions in the article are based on assertions about what is/isn't used. Which is fine - it makes reading through the design process more interesting and insightful. It would be interesting to compare that with actual usage statistics that one assumes github have (to one degree or another) and see if some of the differences in the design are due to flawed assumptions in the article.

ianstormtaylor 13y ago
Absolutely. I actually had a section about that but had to cut it since it was getting rambly :) There are even other business concerns that go beyond just usage statistics. For example, GitHub might see the Mac app as their future, for bringing git to people who aren't familiar with the command line, in which case it would make more sense to make the Clone in Mac button prominent. The other piece I cut was talking about how not only do advanced users only need certain features, but there are also features that only new users need, like walkthroughs and things. It gets really hard to visualize all of those decisions in a flat mockup. But yup I totally agree, trying to redesign an interface that you don't own is always going to be very hard and error-prone. Although GitHub is probably one the interfaces that most of us would have the most success with based on how heavily we use it.

jrochkind1 13y ago

I like seeing design critiques like this, especially when done from actual design experience, and with respect. But, I came to say: Is the branch lister/switcher really one of the least-used parts of github? It's one of the parts I use the most, actually!

josephlord 13y ago

Nice article and a very slightly opportunity for a couple of minor Github annoyances to come out of me. All of which I think apply both to the old and new design. Does it bug anyone else that the Github commit count tops out at 1000+ commits making it completely useless after that point? A repo last updated date would be more useful (I know I only have to scan the directory modified dates but a consolidated one would be nice). It would also be great if they could show the unmerged branches at the top of the branch selector and allow branches to be kept but marked as obselete so they weren't offered with the other unmerged branches but could be kept rather than completely deleted. My final wish would be for a couple of things bitbucket has in its diff views, namely side by side diffs and the option to show additional lines around the diff to give greater context. Bitbucket is sorely missing Githubs great network view though.

quadratini 13y ago
YES. 1000+ commits is so useless. Also I wanted to look at the commit history and it was entirely unobvious that you can click "1000+ commits".

w-m 13y ago

Here are the two sidebars (new github vs. Ians design) side by side: http://i.imgur.com/e2w6TkT.png http://i.imgur.com/e2w6TkT.png Ians: - got rid of the color indicator - got rid of the separation lines - is truncating the list - has three identical buttons where there were two - has more indirection. Cloning is autofocused for me, it takes one click+cmd-c. Also, when I'm scanning the page for a way to clone by URL, I'll find the actual URL much faster than the button that says "Clone". I like the general idea of the redesign, but I think it would make the sidebar much worse.

sergeykish 13y ago
Agree, hiding clone URLs arn't good. Links are already in scroll area. And "copy to clipboard" doesn't help, it requires Flash, which isn't good at all on Linux

reledi 13y ago

Thanks for blogging this. I like the overall changes of your refactor, but there are a few minor nitpicks: - Why did you change "Star" and "Fork" to "Stars" and "Forks"? The before and after have different meanings. - The colour bar is missing from your final design. You mentioned in a comment that you forgot to add it and then added it, but I still don't see it :). - The right side navigation section is prematurely cut off at "Settings". - Your "Clone" and "Download" buttons could use some more whitespace between the text and icon.

ianstormtaylor 13y ago
1. Ah yup that's true. The part of the "star" button that I was focused on was removing the "unstar" word since I find it really confusing. I'd rather use a depressed button to signify that I've starred something. But yup, removing the s's would be good. 2. Nope didn't forget it. My final design isn't "final", it's just at a point in the refactoring. The next step would be to figure out how to add in more of an identity to each repo. I tried to mention this towards the end of the article when talking about the background image idea. 3. It's hard to show in a flat mockup, but the idea for that would be that hovering it would have an animation that slightly dropped the divider down, and clicking would open it all the way. But it could totally be an over-optimization, in which case the 3-4 extra list items could just always be visible. 4. Ah, I just took the same style as GitHub. (Actually one of the cool parts of the refactor process was that GitHub's markup is so self-evident that lots of the pieces were made by just changing class names and then re-screenshotting the GitHub interface itself.)

JohnDotAwesome 13y ago

Great piece, but... One thing bothered me. He said it took a double click and cmd+c to copy? That's not true at all. Single click auto selects. I think the hiding the of the URL is kinda lame because the URL _was the design element_ for "clone" for so long. I see the URL and I know I can click it to select, CMD+C, paste it into my terminal. Ian certainly has some valid points, but in the end, I think he's not appreciating the full-range of use cases that everyone has. Github has a lot of different kinds of users. Enterprise development flows are a bit different than the open source ones. And those are the flows that bring in the money. Though, I'm sure they use Github enterprise, so maybe he does appreciate that use case as well.

Udo 13y ago

I like most of the ideas, but: Cloning a repository happens rarely, but in the old interface it was one of the first things on the page. Is it really happening so rarely? It's one of my primary interactions with a foreign repository. Am I atypical?

przemoc 13y ago
No, you're not atypical. If I want to look into some project closer (and that's why I'm searching or visiting particular github page in the first place, well, more often than not), then I copy git:// URL and download git repo. Real fiddling happens locally later.
- bjeanes 13y ago
  GitHub's answer to this is "just copy the URL from your browser." It means using http(s) cloning which may or may not be desired, but from a UX perspective I think that it is neat.
nsmartt 13y ago
I don't think he means that it's rarely used so much as it's done rarely by the user. When visiting a project page, users likely won't need to clone as often as they'll need to do various other things on a page.
naiquevin 13y ago
I clone repos very often to browse the files in my editor so I didn't like the change initially (and I still don't like it very much) but then after getting used to it I felt that the clone-download section could be positioned above the right side menu which would also allow the menu to be aligned with the box that lists files and dirs. Anyway, I liked the article even though I am not a UI person

zobzu 13y ago

Reducing an interface until only the absolutely necessary elements remain is one of the most satisfying tasks in design. Now I understand the issue with design :P Now I think the GitHub redesign is okay - but i also think "absolutely" is too strong of a word. The "usual tasks" for "most people" should be part of the UI IMO. Many products go with "absolutely vital" and then the UI sux because you don't get the buttons u needed, in the name of simplicity.

philliphaydon 13y ago

For me, about 30% of the changes were bad choices. Its harder to navigate around now than it used to be. While the other 70% of the changes are great.

sgdesign 13y ago

I hate that language bar so much (I work on a lot of 100% JavaScript projects) that I installed Stylebot (http://stylebot.me http://stylebot.me) just to get rid of it.

btipling 13y ago

My opinion of GitHub's redesign from a user's point of view is that it has been difficult to adjust to the point it has made me angry and frustrated. The pull request UI change is a regression.

jimmaswell 13y ago

I really don't like the trend of simplified interfaces. I have absolutely no problem with interfaces with options and buttons all over the place. Is there any real productive purpose to changing interfaces when users are used to the old one and fine with it? I see it like forcing users to switch to dvorak. Anyone who spends a reasonably amount of typing can probably get a fine 100wps on qwerty, they might get slightly more if they spent a long time learning dvorak, but the marginal return wouldn't offset the benefit, because most of the time you're not typing at your full speed anyway - you're pausing between shorter bursts of typing to think of what to type, use your mouse, or something else.

garysweaver 13y ago
I think having fewer elements when they are unnecessary is a great idea, if it makes the interface easier to use. However, in this case, though I don't dislike GitHub's new interface, but the big colored line showing the percentage of different kinds of code in the project is really unnecessary and the color is distracting. But, other than a few minor things, I've not had a problem with the design changes, and I certainly didn't have the remorse that I had when I switched to the last major Facebook design overhaul early. And now I'm used to that also.
- jimmaswell 13y ago
  The facebook design changes all tend to feel pointless and annoying, don't they? I've only used github for a week or so, so I'm not really attached to its interface, and I tend to only interact with it through the github client. On a bit of a tangent, the github client feels awkward and strange. For one thing, it doesn't follow the normal conventions of the OS I'm on. It doesn't even have a menu strip. I'd much rather make a new repo with file -> new repo, have push pull commit etc be in appropriate submenus on the menu strip, and so on, but this thing just throws stuff all over the place willy-nilly, sometimes I don't know if I'm even able to do something and it turns out I have to double-click, things like that. Committing and pushing with gitextensions from inside VS feels nicer. I really think interface design for desktop apps hit its peak a while ago before everyone was obsessed with stripping things down to the bone. Every update I see menu options and configurability widdled away from applications like Firefox, which is on the track to becoming the one-size-fits-all Chrome. If you want some evidence for that, hang around some channels on irc.mozilla.org. Another thing is that when I look at screenshots of youtube from a few years ago, it's astounding how much they got right back then that's gone now. The tracking bar has no place hovering over the video obscuring it, the five star system was great but had to be replaced with a binary yes/no, there was a button to start over instead of having to click on the start of the tracker bar, it goes on. I've used applications from the late 90s or around that period before. They were great. Menu strips were chuck full of stuff, buttons everywhere, just great design to me. Too many applications are being stripped of any useful feature that's not absolutely essential (or made to have the feature available only through obscure shortcuts / ini files / etc) and it's a development that I greatly disapprove of. I'd rather not have my Microsoft Word replaced with Google Docs.

djs070 13y ago

Is it just because I'm on iOS or have some of these suggestions been implemented on github?

calpaterson 13y ago

In this discussion he makes several assumptions like "we can de-emphasize the branch switcher since it’s so rarely used" and "The Clone in Mac button was a perfect example of an under-used feature" and "Cloning a repository happens rarely" all of which do not chime with my personal experience. Our disagreement is to be expected - no two people completely agree about an interface - but it is extremely disappointing that he makes no mention of testing on real users (or at the very least, speaking to them) in order to gauge whether these features really are unimportant. If you want to know the reason why so many site redesigns are unpopular with users, here it is: you didn't test them. I'm not trying to take this to absurd conclusions like "every change has to be tested" but the central idea of this guy is faulty: design of the user interface, like design of software, is NOT to be done by anyone in isolation. You need to involve real users in major changes before they happen. I hope Github ran user testing before they released these changes.

Heliosmaster 13y ago

Really nice insights on design. You might want to chat with the guys that make GitLab :)

rg3 13y ago

I really like the refactoring done here. Congratulations to the author. He did an excellent job, IMHO. There's one thing missing that I always wanted to have: put the contents of the README file _above_ the file listing. The truth is, many people in Github don't use the Pages feature and rely instead on the README being the main project page containing the description, instructions, etc. And sometimes you have to scroll a bit to get to that information. If the README was on top, the main project page at github.com would be given the importance many projects give it. Variations of this idea: let the code be on top but only after a single click to expand the repo contents, unless the project lacks a README file. In that case expand the repo contents directly.

masklinn 13y ago
That's what Bitbucket does (after a fashion, the default home page is actually called Overview and displays the readme at the repository root and below it a recent activity history for the repo)

zoowar 13y ago

I love to hate the "refactored design". If it's truly just "completely reorganized to emphasize the commonly used features," then it's just a theme. Let the user choose the theme, don't force it on them.

aristidb 13y ago

"Cloning a repository happens rarely, but in the old interface it was one of the first things on the page." No. It does not happen rarely. I do it all the time. (I realize that other commenters have expressed the same sentiment among other things, but for me this is the key element to emphasize.)

Zigurd 13y ago
I suspect the statistics on feature usage are slanted toward trivial repos that are being used like SVN, or that are not being used as part of a distributed workflow. "Important" doesn't mean "used by the majority of projects."

mekishizufu 13y ago

I think it is an improvement except for the right menu. The list is harder to parse and the order is just completely wrong. The four most important links (Code, PR, Issues and Wiki) should always be on the top of the list.

c0mpute 13y ago

Really well done. I think I was one of the few (perhaps?) who did not like the new redesign of github. I did not like the content above that red/color bar at all. It is that much real estate taken away from me to see the code/commits/documentation of the page. I often use last commit and all commits to compare and see what is going on. I also quickly switch branches on the UI to compare stuff. The current github just feels its a always one extra click or I am searching for something. Somehow it doesn't feel minimalistic at all. Ian's redesign makes it elegantly simple and minimalistic.