First rule of design: Know your user.
Second rule of design: You (the designer) are not the user.
I think the general criticisms here are because this designer didn't follow these 2 basic rules.
Redesigning GitHub Repository Page
121–130 of 315 posts
Re: Redesigning GitHub Repository Page
#122"dated look" is not a problem. I never understood this. Why should every web page or operating system UI design change all the time? Why is it a bad thing that you finally know how to use it? Why?
Re: Redesigning GitHub Repository Page
#123> Commits often touch files for completely arbitrary reasons, so the last commit tells you almost nothing. I actually use this feature frequently. I bet others do too. If I wanted to see the commits list, I can just click the commits tab.
Ditto, I do too and wanted to put my vote in for it.
Wanted to see see if others did too.
If your commit history is messy, then you have a different problem.
Re: Redesigning GitHub Repository Page
#124No. I hate it. Especially the part when you're changing a design just because it's 'dated'. The two-level hierarchy split makes perfect sense for git metadata vs github repo metadata. It might not be sexy, but it makes technical sense. It works. Millions of people are used to it. There's other things to fix (like code review). Stop fucking around with things for no good reason.
I feel like this is a disproportionately angry response for what amounts to some play with the UI, and I think we should praise the author's willingness to share this publicly instead.
I can understand the irritability as the web is turned into shit by designers, so things that worked fine is now horrible to use because of unnecessary "redesign". I for sure can't mention a website redesign in recent years that made things better. Internet Archive, Gmail all turned into shit.
So when the few things left, that are not horrible and you depend on, are becoming target for "The Designer Treatment", you become angry.
Re: Redesigning GitHub Repository Page
#125This was an interesting take, but personally I think lands with something that misses the mark. I collaborate with my team in slack. I’m really using github to get to my files quickly, view history, or I jump to issues.
Any collaboration on github I would say is largely secondary (from my personal experience anyway). Nobody on my teams has ever been waiting on Github for any type of real-time activity, so even PRs review requests are generally communicated through some type of chat.
Personally I feel the author’s final design is also a step backward - while I realize things have been “cleaned up”, a horizontal menu with that many options is too many - and they are not of equal value. The existing division is helpful based on real life use - not the authors idea of what looks good. I don’t need menu items I rarely touch given the same importantance of the ones I use daily - I don’t want to even accidentally read them - it wastes my time. Also, how quickly does this need an alternative solution for narrower screens? Lastly, the authors design is looks to me just like stack overflow - I don’t think it’s fair to say it’s any more modern than githubs current design which has strong and consistent visual language I appreciate as a benchmark for how other products could look and feel. Github looks like GitHub in every part of GitHub, and for me at least, that’s a good thing.
Re: Redesigning GitHub Repository Page
#126oof, the curmudgeon is strong in the comments here and I think some perspective is required. 1) no one is actually implementing these changes; this is just a design exercise from someone who has no connection or influence with Github other than I presume being someone who uses it. My reading of this design work up is that it was just a fun exercise for someone with design skills; design kata if you will. 2) as a prog…
My reading of this design work up is that it was just a fun exercise for someone with design skills; design kata if you will.
Literally applying the bland "no borders, no contrast, white everywhere" trend cookie-cutter style is not what I'd call "design skills". Sadly there are very few actual good designers out there, but their work is easy to identify because they stand out in a good way. This one just looks like another "me too" redesign.
Re: Redesigning GitHub Repository Page
#127Design comes in three parts, at least, and I wonder if they should be done at different times, maybe even by different people:
(1) Wording. Consolidate "Create new file," "Upload files," and "Find files" into "Files: Create, Upload, Find." This is great. When you're in this zone, you are mercilessly paring down, pruning, merging.
(2) Layout. Do we need two levels of tabs? Should this go here or there? What things work well side by side? This is a relationship-analysis mood.
(3) Graphics. Borders, colors, gradients, etc. This is a creative mood, where you are building things up, giving them outline and skins.
If you just got done with Wording and then go to Graphics, you have this leftover pruning mentality. This might cause you to be overly minimalist in your graphic design, as this author was, in my opinion (and I'm a minimalist, who errs in the same way). I thought he did so great with the first 90% of the rewrite, and he echoed many of my thoughts when I'm working on something. But I agree with the rest of the people here who said he went too far in removing outlines and such that delineate components. It is a testament to Github's graphic design that it always looks fresh to me (but I agree a bit hard to navigate).
Re: Redesigning GitHub Repository Page
#128So here's what I suggest to the author: go to the "Issues" page for some project, and see the effect of this redesign. From my perspective: there's now a lot of useless tabs on the top (commits/branches/releases), the repository description will either take extra space OR will disappear and the tabs are going to shift. - Getting rid of icons: OK - Moving description over tabs: bad - Shuffling tabs around: bad - Diffe…
The vanity counters argument just seemed to me like the author really just doesn’t understand the site or the audience. Which is surprising because he is a dev. The metrics of stars is one thing, that’s a vanity option used by user for bookmarking and project maintainer’s popularity statistic. The fork option has dual functionality, forking the project or viewing all the other forks.
When it comes to Watch, that’s just being pedantic. Maybe non-developers expect to be shown the current state of something, but as a dev I feel that I would like that button to show the inverse, so I know what will happen when I press it. “Click Watch to Watch the repo!”. Two sides of the same coin maybe.
Re: Redesigning GitHub Repository Page
#129This seems much cleaner the overall design seems better, the only things I would change is the color scheme in this new design is very blue. I feel the mix of blue text and black icons used before was better
Re: Redesigning GitHub Repository Page
#130Earlier quoted context omitted.
I think the author describes the problem with the redesign the best: its noisy. Your point over how hierarchy helps programmers use GitHub feels lost on the designer. It feels as if they're designing for a different user.
That noise is the exact reason why I think the design over the years hasn’t strayed away as captured in the screenshots. One of my favorite parts of using GitHub is that the design is clean and easy to navigate. Throwing twenty widgets on there and cramming everything on top of each other adds clutter and distracts users from being able to visually navigate the page. I can’t speak for everyone, but given the chance,…
Strongly agree with this, and it's probably the biggest reason I don't use BitBucket unless I'm getting paid to.
The other big reason is that Bitbucket loads bunch of trackers and JavaScript from remote servers.