
Redesigning GitHub Repository Page - kirushik
http://tonsky.me/blog/github-redesign/
======
scott_s
_> If you are a programmer, you might be surprised but other people normally
don’t like hierarchies. Nested structures are hard to grasp, remember,
navigate, and grouping is very often non-intuitive. Nested tabs are one of the
worst UI patterns out there._

GitHub is primarily a development tool, so it should be designed for
developers. Hierarchies align very well with development tasks, so it's
natural to use them for development tools. That other people don't grasp them
is not relevant for GitHub.

Also, the three most common navigation tasks I do are "go to the code", "go to
the issues" and "go to the pull requests." Those are also the first three tabs
at the top of the hierarchy. I don't think that's an accident; I think the
designers at GitHub designed the layout so that the most common tasks are on
top and first. In other words, they designed GitHub like a tool, not a normal
webpage.

With this redesign, I'm going to constantly have to find the "Issues" and
"Pull Requests" tabs among a sea of others. That's not good usability.

I've thought that maybe the markdownified README should be flipped up on top,
but even that I think is counter-productive. When I'm working with a GitHub
project, I commonly want to load up the page and navigate to some files. If
not, it's usually not much scrolling to get down to the README. But READMEs
can be quite long (which is a good thing), and it would sometimes be a pain to
always scroll past them to get to the files. The better solution for that is a
good project page.

~~~
grblovrflowerrr
I think the two natures of Github as a tool for software development and
Github as a social coding site are often at odds. Some ways this could be
reconciled:

\- greater end user customization of the UI layout

\- an option to enter a different UI(contributor UI) for repositories you
contribute to/own

\- make the contributor UI an enhancement on top of the current UI(perhaps a
new darker tab bar)

\- related to the above, separating out the discovery part into a separate app

In general, I am in favor of greater customizeability in my professional
tools, especially something I use as much as Github. I think one reason we as
software developers don’t add a lot of end user customizability to our UIs
though, is that it adds a ton of complexity to the UI code. This suggests
there is opportunity to explore new UI development paradigms and libraries
that have end user customizability as a primary concern, instead of a bolted
on after thought. I’m curious if anyone is working on such a project.

~~~
tedunangst
GitHub should go full MySpace, completely custom css per project.

~~~
drusepth
Considering:

1) Most GitHub users are more tech-savvy (and often more CSS-savvy) than your
average MySpace users, and 2) Most GitHub users put a lot of value in their
repo pages,

this actually seems like it wouldn't _inherently_ be the worst idea, assuming
the proper precautions were in place versus bad actors. Allowing each org to
fully customize their git repo almost encroaches upon (or replaces?) project
websites, which already has some overlap with README files (which aren't
currently prioritized). Kill two birds with one stone by giving developers
what to prioritize on their repos?

~~~
johannes1234321
There is lots of value for me in the fact that all those project pages look
alike. I can easily go to any project and immediately know where to look and
click. This is useful for doing technical evaluation of projects. On Myspace
the goal was to show individuality and creativity. GitHub is about the code.

------
userbinator
_But maybe it’s time to fresh it up a little? Get rid of gradients, dirty
washed-out colors, unnecessary separators, add a little more air._

No, no, _no_ , _NO!!!11_ I've had it with these "sea of floating text on an
expanse of white" redesigns, seeing yet another one follow this mindless trend
just disgusts me thoroughly. The lines, subtle gradients, and other
affordances of the old design serve to organise and direct your eyes into the
appropriate sections; without them, everything blends together into a jumbled
mess and it almost looks like the stylesheet didn't load fully.

 _If you feel disoriented, give it a minute._

I've had to put up with such redesigns for literally _years_ now (I don't
remember when the trend started --- mid 2010s?) and I don't feel them getting
any better --- and eventually get around to making a user stylesheet to make
them look better than they used to.

In contrast to the article this is one of the very few redesigns of a site
which I actually would like (not mine, previously discussed at
[https://news.ycombinator.com/item?id=17242367](https://news.ycombinator.com/item?id=17242367)):
[https://pbs.twimg.com/media/De17PIKXUAE27W6.jpg:large](https://pbs.twimg.com/media/De17PIKXUAE27W6.jpg:large)

 _If you know someone at Github, send them a link to this article. Maybe
someone there will like my ideas and eventually get to implement them_

Hopefully not. "Don't make me get out the custom stylesheet editor..."

~~~
jonnycomputer
I thought some of his suggestions were pretty decent. But then he just threw
everything away by mucking around in the Code, I mean Overview tab. His last
design, without the guiding lines, make it look like jumbled shit pie.

~~~
yxhuvud
I wouldn't mind seeing the latest commit history there, but the stats are
totally out of place.

~~~
vor0nwe
Agree; though even before the latest commit history, I’d much prefer the
README to be hoisted up there, so it’s at least visible when I first visit a
repo.

------
abhchand
First half of the article that redesigns the navigation is actually pretty
good. It got me hooked and i find it valuable.

When they started touching the content, I got a lot more hesitant.

1\. I can't articulate _why_ , but honestly it's extremely useful to see the
last commit message on each file. It gives me a sense of which files have
changed and if my changes are still the latest ones. It's not foolproof, but
it doesn't have to be. It's more psychological but still necessary in a
comforting sense.

2\. Second, the reason github was successful is because unlike other
repository UI's, it showed the code front and center. Nobody wants to look at
a commit log, which is the approach that most other repositories used to take.
Github cleverly realized that people want to jump right into the code or
better yet understand the code, so they showed the file browser and a README.
That pattern seems so obvious to us now but it wasn't always. It's kind of
laughable that the article focused so much on design but failed to get the
core of that idea.

~~~
superfrank
Yeah, I was totally with the author for steps 1-7, but I have problems with
the last four steps.

Personally, I think step 9 shows exactly where the author is a bit out of
touch. He seems to see GitHub as a sort of code social media site where
statistics about the repository are just as valuable as the code itself. In
some cases (especially open source), I can see that being kind of true, but I
think GitHub gets far more use as a private internal collaboration tool in the
work place. In that case, the code itself is far more valuable than anything
else and deserves the majority of the screen space.

~~~
henryfjordan
I think, even as an internal collaboration tool, the faces of who has been
touching a repo recently are very valuable. Who do I go to for help, or to get
a PR approved, or to request a new feature?

~~~
zwkrt
Look at last commit, look up username, email. Where did their face come into
it?

------
JoshTriplett
Half of this works well; some of the redesign of tabs, the elimination of
icons, and similar changes look great.

On the other hand, showing the last commit and change time for each file is
_useful_. Where is that information now? It's in a linear commit list, which
is helpful for different purposes ("when was the repo last updated and what's
up?") but doesn't serve the original purposes as well ("when was this file
updated?"). At the very least, the last-changed date would help.

Shoving statistics over on the right-hand side makes the page much more
crowded; expanding the space available for files and commits would work
better. Notice how the commit list has messages truncated; 70-to-80-character
commit messages ought to fit comfortably there.

Where does the README appear, here? That tends to be the first thing I'm
looking for in a new project, and it doesn't look like this redesign took that
into account at all.

The new extra-busy tab bar makes it harder to get at the things you use every
day: issues and pull requests.

~~~
dcosson
I was half onboard with his reasoning to remove the commit messages. But then
I realized, they're only useless if they're bad commit messages. Especially if
you're using PRs and using "squash + merge" for all your changes (which should
really be the default IMO) the commit messages will be the PR titles and PR
number and that's pretty useful. And then the commit time for the file is
obviously super important.

What else might be really cool is some kind of indicator of how often the file
changes, in addition to the most recent change. Like sometimes if you see a
file, maybe it was changed 2 days ago but only because someone renamed a
method and that made a one-line change in 50 files. But before that, when was
it changed? Does it usually change multiple times a week, or was this the only
time it changed in the past month? Even if it was just a rough color gradient
or something it would be pretty cool to see at a glance which are the most
active directories and files in your repo.

~~~
userbinator
_And then the commit time for the file is obviously super important._

What's nice about git is that you also get this propagating to the directories
all the way up to the root, so you can quite easily see which _areas_ of the
code have been changed recently too. This isn't something normal filesystems
have (for performance reasons more than anything --- I imagine if one tried to
use git as a filesystem such that each file change was an actual git commit,
the root directory node would be hammered with constant updates and an
enormous bottleneck) but in the context of a VCS it's amazingly useful.

~~~
JoshTriplett
> What's nice about git is that you also get this propagating to the
> directories all the way up to the root, so you can quite easily see which
> areas of the code have been changed recently too.

Exactly! It's easy to see at a glance, for instance, that the code changed
recently but the documentation hasn't been updated in a long time. Or that the
LICENSE file just got updated a few days ago. Or that a new top-level module
got introduced.

------
Memosyne
> If you feel disoriented, give it a minute. Once you are used to it, you
> might notice it’s actually easier on the eyes and a bit lighter.

I've been staring at it for 5 minutes now and I'm still disoriented. The
borders and gradients gave the design an attractive depth and by removing them
you ruined for me. The whole high-contrast/no-gradient thing is also one of
the reasons I dislike using Gitlab. It was all going pretty well before then,
though.

~~~
MereInterest
Agreed. I was on-board with most of the changes, but that one removed all
visual distinction between elements. It became a load of black text on top of
a white background with no separation between semantically different elements.

On a related note, Gmail's latest redesign for Android made the exact same
blunder when viewed in the compact density. Just sender/subject/sender/subject
with very little indication of each one being a separate email. They spent an
extra line break, rather than adding a nice horizontal divider, which would
have used less space and given more visual separation.

~~~
RussianCow
Lack of visual distinction is a general problem with the current design
trends. Even Apple suffers from it at times—in Xcode, it's impossible to tell
whether certain elements are interactive (buttons vs passive status
indicators) without clicking on them.

The thing that drives me up the wall is when text inputs are not made obvious.
Google in particular is notorious for not giving any indication that something
is a text box, as opposed to just static text. I can't count the number of
times I have tried to focus and type into something that I thought was a text
field, only to discover that nothing was happening.

------
Aeolun
The tabs especially looks like a terrible idea. Something that had more than
enough space on every screen has now become a huge, long list of options that
you have to scan every time to find the one you want.

Removal of icons also plays into that since they were the visual hooks you
could use to navigate after a little while of usage.

Then the final redesign, I’m not sure there’s anything to say about it other
than that I strongly dislike it. Services like github change their image at
their peril, and I just don’t think that is worth it.

~~~
jrochkind1
The tabs redesign suggestion are actually one of the things I like best here!

I hate the two (it's actually THREE including the top black bar) navbars, I
always get confused about where to look to find something or what i'm clicking
on, and I've been using GH for years!

~~~
theaustinseven
Yeah, but if you look at the tabs redesign, they're cheating a little. They
are using a very busy repo(which most aren't) so the little numbers next to
each tab are acting as a divider. Most repos would be really hard to navigate
without some sort of additional separation between the tabs.

~~~
scaryclam
They're also ignoring any sort of internationalisation. In other languages
there wouldn't even be room to label all those tabs.

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

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

~~~
q3k
Why would someone post this other than to gather feedback? Yes, this redesign
idea upsets me. However, that doesn't make the points I raise (from the point
of view of a daily GitHub user! and one that uses it professionally!) any less
valid.

~~~
eswat
> Why would someone post this other than to gather feedback?

A good amount of these unsolicited redesigns are to generate interest in what
the designer can offer and provide a sample of work.

Other than posting the HN link the OP goes straight to "If you know someone at
Github, send them a link to this article.”, so they probably don't necessarily
care for feedback (huge assumption based on my experience with past
unsolicited redsigns).

> Yes, this redesign idea upsets me. However, that doesn't make the points I
> raise (from the point of view of a daily GitHub user! and one that uses it
> professionally!) any less valid.

Your points are definitely valid. But ironically, like the OP, you end your
post on a sour note.

By ending with “Stop fucking around with things for no good reason.”, for what
is just a harmless redesign by someone that has little-to-no power to affect
GitHub's UX, you painted the rest of your comment as unnecessarily critical. I
think this is what the parent comment was addressing.

------
wyattpeak
I think it's strange to focus on all these details without addressing what
seems to me the overwhelming problem with the GitHub layout - the
deprioritisation of the readme. Why is it below the fold?

I was very confused for a considerable time when people would point me to
GitHub for a description of a project, because there didn't appear to be a
description, just a repo. Was I supposed to build it to see what it was?

This seems very silly in retrospect, but there really was a month or two where
I just didn't understand at all what I was supposed to be doing there, and
I've never forgotten it.

And why? Why is it so critical that the first thing people see is the file
structure, and not a description of the project? Echoing the article, I
suppose it makes it "about git", but even when I'm interested enough to start
poking around, I'm more likely to clone a project than browse through it on
the site.

It just feels intentionally obtuse.

~~~
X-Istence
As a developer, the README is useless, I am usually on a Github repo to start
looking at code, and I don't want to have to first scroll through a README.

IMHO documentation websites and the like is where people should get their
first feeling for a project, that is where the README should be.

~~~
wyattpeak
That seems like a great idea in principle, but for most small projects the
GitHub page /is/ the documentation. If that weren't the case, you wouldn't see
half a dozen links to GitHub pages to show off projects on HN each day.

It's all very well to talk about ideals, but you can't ignore reality in the
process.

You're right, though, that you shouldn't have to scroll past it every time. I
don't really know what the solution is, but having it there but going
undiscovered is the worst of both worlds.

~~~
X-Istence
If you've read one README on Github, you know to scroll down to see it on
every other project. I would argue that it's not a steep learning curve, and
it's not like the hide the scrollbar... we scroll in other websites without
issue when we are looking for content, especially with ads being most of the
content above the fold these days.

~~~
wyattpeak
I agree it's not much of a learning curve, but neither is learning which icon
represents a commit. This entire discussion is about minor details.

------
tathougies
The redesign looks awful, IMO. Way too busy. Too many tabs at the top.

I rarely care about the contributors or the commits in a github repository. I
care zero about the stats. All I want are the files.

The last commit is incredibly important to me, since it lets me see if two
files changed at the same time by quickly comparing descriptions.

------
alfredxing
I don't love the design, but what bothers me more is that I disagree with many
of the premises informing the decisions, for example:

    
    
      - Github tab icons are purely decorative
      - Because we simplified the whole header, we don’t need that color coding anymore
      - Commits often touch files for completely arbitrary reasons, so the last commit tells you almost nothing
      - Get rid of gradients, dirty washed-out colors, unnecessary separators
    

Finally, cramming so much into one view makes it harder to navigate, not
easier.

~~~
jedberg
> Github tab icons are purely decorative

I actually agreed with that one. He made a pretty compelling argument. The
icons aren't universal, and I have to read the words every time anyway.

~~~
lostmsu
I don't know. In his giant image asking if the icon is the commit icon, my
first though was "history".

I was actually looking forward for me being hilariously wrong, and GitHub
having made funnily incomprehensible icons, and he did not deliver!

------
arnvald
Overall I like this redesign! Some parts I truly enjoy there:

* single layer navigation: it looks busy, but it would improve my life a lot; I find the current one pretty annoying * showing statistics on the main page: this is very useful information for me when I come to evaluate whether I should use the library in my project

* list of commits: again it helps me to see whether the project is still maintained; if the last commit was 5 years ago the project might still be good, but possibly it doesn't work with the new versions of other libraries; also adding tags there is cool!

* icons added to "find/create/upload file" menu, really good idea!

* watching/not watching button

* language names right on the main page. It's very confusing to have to click on the colour bar to see what languages does the project use

And here are some things I'm not sure about:

* colours are more intensive and I feel that my eyes would get tired more easily; I like the current colour palette

* flattening of buttons looks very iOS-ish and I'm not fan of the trend

* there's no separation between columns, for a moment I thought that users avatars belonged to the files column and I didn't know why some files had user next to them and other didn't.

That's a nice experiment and I'd love to see more ideas like this, to
understand the way of thinking behind certain design decisions.

On a side, I find it pretty sad that there's so much negativity in this
thread. I know people are used to certain designs and don't like changes, but
saying "I hate this" is very strong and I don't understand why anyone would
have such strong feelings towards other person's blog post.

~~~
Pawamoy
I was always angry at people telling they don't like my/his/her new haircut,
because I know they are just used to the previous one, and this is the only
reason they dislike the new one.

About this redesign: I would welcome it with all my heart. For me, GitHub won
on the social side. So let's put the social side in front. I find the current
project and profile pages very poor and limited. I would welcome ghuser.io
redesign as well.

If I really want to scan the code, I clone the repo and scan the code in my
IDE. Or I use a browser extension that displays a folder tree in a toggleable-
sidebar on the left.

The current "Files" is only useful to click on the files to get to see their
contents. The last commit message for each file is something I look at when
I'm bored and want to waste time. I also hate to see very old commit message
on very old files like LICENSE.

------
kettlecorn
I really like reading and seeing explanations like this. Blog posts like this
are a a brilliant way to help design design process.

There are some good ideas, and this article does a fine job of calling out
problems, but I also can't help but feel the end result is unpolished looking
and would perform very poorly when it comes to usability.

* The end result feels unstructured, like elements were just tossed on the page, due the lack of strong grids either from background colors or implied by layout.

* The left and right alignments of elements is basically non-existant, contributing to a messy feeling.

* The "statistics" category will be entirely useless on small repositories, or personal ones, just taking up a huge amount of space for no reason.

* Removing the icons makes it more difficult to develop "muscle-memory" on websites you use a lot. Icons, even if irrelevant, help us pick the item we want off of the page more quickly.

------
vemv
The final result looks too widget-y/SPA-y, overloaded with information.

That's precisely a front where GH wins (over Gitlab): it's visually calm and
sparse, ideal for something that would be part of daily, thoughtful work.

~~~
hliyan
It was heading in the right direction for a while, but at the end it basically
turned into Bitbucket. With all due respect to the author, I think the current
Github UI works just fine, and the fact that it has become the dominant player
in the market with a clean interface that hasn't changed much over the years,
is a testament to how well it works. I rarely say this, but let's not try to
fix this.

------
megous
I always have trouble finding the releases section on a repository. Every
single time. I need it rarely enough so that it's not readily in memory, and I
usually spend 5-10s just moving mouse around before I notice it.

I also dislike icons in general. Use icons or use text (on a button, ...) but
not both, was one of the first rules of thumb I've heard about from a friend,
and it makes sense. Especially these days when everything is colorless and
bland. I mean if icons in the menu row had all different color, it would at
least be a useful navigation aid after a while, but that's not how it's used
usually.

~~~
alexpetralia
I really don't understand this icon-ize everything UX trend. Since when do I
hieroglyphics instead of English?

Keep icons small, use brief text, employ information hierarchies. Don't turn
everything into a jumbled mess of icons "because they look nice."

Edit: This comment is not directed towards you. It's more my frustration after
spending two hours last night trying to understand the abysmal JIRA interface.

~~~
swish_bob
Not everybody speaks English and localisation is expensive. Icons don't
require localising.

------
smazero
oof, 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 programmer who has occasionally tried my hand at a little bit of
design; to my mind the design process is somewhere between fricking hard and
near impossible and I appreciated the article taking me through his thinking
and the incremental changes along the way. I may not like or agree with all of
his choices but I really liked the insight into the process.

Obviously it's fine to not like the final design he ended up with, but given
the above context I think the level of harrumphing discontent of some comments
is not really warranted.

~~~
MrStonedOne
I don't trust github to be that smart.

This is a well upvoted and discussed post on hackernews, if the arguments
weren't strongly in opposition, there is a chance somebody at github will be
stupid enough to follow this blog. There still is even with all of this
pushback.

~~~
tenryuu
I make complaints about the small shit that github do with their responsive
redesigns and they still don't even fix them.

The responsive nature of the new frontpage is garbage. Because you expect that
at least 95 percent of developers using the site are doing so on the desktop.
If your browser window is too small, you lose search behind a hamburger button
and a navigation menu that only looks like it belongs in your hand, not on
your desktop.

We're lucky this only affects the frontpage, and not within any repos were
developers are doing actual work

------
jonny_eh
I loved this whole post until just at the end where he removed the borders
around the various sections and it looked like a jumbled mess, for no reason.
Didn't stick the landing there.

------
obilgic
Having "branches" and "Pull Requests" tabs on the same level just doesn't make
sense :/

The main thing you want to see with the repo page is the code and the readme,
i don't want to see all these commit messages or stats. Irrelevant.

This actually made me appreciate Github's current design :)

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

------
nijynot
Definitely states the right problems, but not the right solutions.

The commits box is also bigger than the files box, which doesn't make much
sense. Whether a commit box even should be there is a big question. How useful
is commits to the average developer browsing a repo? I think a bit useful, but
not useful enough to have 1/3 of the screen width.

Stats of a repo is pretty nice, because it gives an overview of how active it
is, etc. But the problem is that majority of GitHub repos are empty and not
that active, so it'll make most of the repos look like ghost towns. Not
something you'd want on your site.

Moving all git tabs into the GitHub tabs makes it even harder to use the UI.
You have to spend way too much mental load just to find the right tab to click
on. It looks better, but will be harder to use.

The "Watch" button, moving description and tags is an improvement, and I'm for
a redesign of some sort.

------
makecheck
The first several changes, which stick firmly to the principle of “design is
_how it works_ ”, would help noticeably. The last step, where it starts to try
restyling, is no longer “how it works” and that goes too far for me; contrast
is lost, things that aren’t too important are suddenly loud and distracting,
etc. (i.e. everything I hate about many “modern” web sites).

------
jbergknoff
I like a lot of these suggestions. For instance, it's true that I never get
anything out of the commit messages in the file browser (though "how recently
has this file been updated?" is often useful).

One other thing I've never understood about the GitHub UI is why the issues
search defaults to open issues. I have literally never wanted to restrict my
search in that way. Maybe it's just geared towards maintainers? As a user of a
project, I would _rather_ land on a closed issue with a solution to the
problem I'm seeing.

~~~
structural
As a developer/maintainer of projects, the commit messages in the file browser
and open issue view are both incredibly useful.

There's important metadata about the structure of a project when looking at
the last commit of a group of files: do they all change together? They are
more tightly coupled to one another if so. If all the files are touched by
each commit, then there's an issue with the project's development process or
organization of code. I also tend to run into issues frequently that were
introduced by the last change to a particular part of the codebase. If I can
navigate to the appropriate directory and look at the commit messages for each
file, I can often be pointed directly at the commit that caused the problem
and the files involved with the change.

Secondly, when developing, I'm already running the latest version or something
later, so looking at closed issues contains no useful information whatsoever.
I'm looking for two things: 1) What I should work on next, or 2) Is the
problem I'm seeing already reported and has any work already been done on it?

Not showing open issues also has the negative UX that people will look to see
if their issue already exists in whatever page they land on, and if they don't
see it, create a new one. Therefore, defaulting to closed issues has the
potential to raise the number of duplicate issues by some amount. Project
maintainers don't like this much.

~~~
roryokane
> Not showing open issues also has the negative UX that people will look to
> see if their issue already exists in whatever page they land on, and if they
> don't see it, create a new one.

I think you misunderstand. The parent comment was suggesting showing both open
and closed issues in search results, not only closed issues.

------
m1el
So 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

\- Different info instead of code details: meh

\- Vanity counters: OK

\- Changed style/color-scheme: bike-shedding / meh

Opinionated summary: hit and miss.

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

------
alan_n
I don't want to be harsh, but most of these are awful ideas and just feel like
designing for designs sake and not usability (in fact usability is removed: I
like it's easy to edit the file description, file information is actually
useful, etc). There's a few areas where github could improve but these are not
it. The only thing I agree with is the position of the repo description.

Actual UI things that would improve github imo: \- Tree view to the side, so I
can browse and preview files to the right (Octotree helps but does not
remember position). \- Maybe some small custom area before the files, but
after the description, for putting things like build buttons, important notes,
etc. \- Other non-design things (better search, easier way to track
conversations, etc)

That's it, nothing else about the current design bothers me.

Also black on yellow! My eyes are bleeding.

------
leblancfg
_If you feel disoriented, give it a minute. Once you are used to it, you might
notice it’s actually easier on the eyes and a bit lighter._

I agree. It's easy to rush to the comments and complain; I had the same
initial reaction myself. But I end up agreeing with almost all points made,
and wish I could give it a try interactively to give some extra comments --
and I sure hope Github take notice.

\---

Some points:

1\. _That means we can get rid of the [files & folders] descriptions without
really losing anything_

\- I have come to depend a lot on last modified dates for files as an
indicator of both a repo's activity level, and as a maintainer it highlights
where I probably need to take a look at when refactoring. Dates to me are a
must. Commit message? I can live without.

2\. _Solution here is to flatten all tabs into a single navigational control_

\- This might not port well to mobile, and look clunky as a two- and three-
level stack of tabs with no hierarchical relationships. Is there a half-way
point that might work? I think the hierarchical relationships in Nikita's
other (satiric) mockup of "Github XP"[0] are actually well represented and
very clear.

Thanks Nikita!

[0] Windows XP satire
([https://twitter.com/nikitonsky/status/1003593821723267072?s=...](https://twitter.com/nikitonsky/status/1003593821723267072?s=21))

------
madrox
This is a great example of applying design thinking, and the reactions to it
really highlight the limitations of design thinking. Requiring training or
prior knowledge to use a tool is not en vogue, and so you must anticipate
every possible outcome a visitor has. The personas that use Github live in the
solution generation space. They don't need pre-ordained solutions. They need
functions.

------
jlarocco
I use GitHub almost everyday, and I didn't really like the redesign, TBH. No
doubt it doesn't help that I don't like "flat" interfaces in the first place.

I also disagree with some of his comments. For example, when he's talking
about finding the Releases page from the Wiki, he says, "Releases are as much
part of the Code as Issues or Wiki are." A Release is one specific version of
the code, so the "Code" tab is the first place I'd look for it. Issues and
Wikis are project level things that evolve separately from the code, so it
makes sense that they're at the project level next to the Code tab.

The only thing I strongly agree with is that the project description should be
outside of the Code tab below the name.

My only notable complaint with GitHub's UI is that it scales poorly. I'd
really like if they made the entire middle content area 95% of the window
instead of fixed width.

------
alanbernstein
I'm not sure if I'm for or against flattening the hierarchy, but here are a
couple of points:

\- Currently, the tabs at the the top level are github-related, and those at
the second level are git-related. There is a certain sensibility to this.

\- Zenhub, which adds a kanban board powered by github issues, adds a tab at
the top level, which makes sense according to the above hierarchy. Of course,
a third-party browser extension shouldn't be a primary concern if github
thinks about redesigning the page.

------
turdnagel
The redesign seems to be geared toward beginners who are too intimidated to
contribute to and explore large open source projects. I spend far more time in
GH exploring my team's code bases, reviewing code, writing PRs and issues...
and GH's layout is perfect for that.

I honestly believe GitHub is one of the best developer tools ever made. It's a
joy to use and I have a major appreciation for their conservative approach to
design refreshing.

------
Insanity
The article started off with making some good points, but then seeing the
suggestions applied made me dislike the result.

The single-navigation element looks cluttered, it's easier now with the
hierarchy. The 'vanity counters' serve a purpose. Stars tells you people like
it, forks tells you people might wish to change something. They are both
valuable.

And the final result just looked horrible in my opinion. Design guides and
standards for the 'general population' might not work in a setting where most
users are 'power users'. I really wouldn't like it if Github took lessons from
this blog.

And as a side-note, the fact that github's look hasn't changed much over the
years is a _good_ thing. Look at hackernews - stay with a proven design.

------
eximius
I'm supposed to trust someone about design when they have that horrid yellow
background? /s

Jokes aside, I was skeptical but I think the (2nd to last) result is really
good. I see a lot of the logic behind it and I could get used to it. There is
a lot of good thought that GitHub could draw from there.

The final theme changes were trash though. Something both his blog and new
design fail at is contrast. I use a darkreader plugin because I'm young and
don't want my eyes to crumble to dust before I die. That blue-on-white is not
going to fair well when inverted (or however dark readers work).

In some sense, I think that github might consider his _UX_ advice, but should
ignore his style advice.

------
habosa
I'm on GitHub hours a day. Many things on there are libraries or tools. In
those cases 90% of the people who come to the page just want to USE the code,
not read it.

I see a lot of developers in that 90% get really confused because the README
is below the fold. You're immediately presented with a directory structure
that you don't care about.

I'd almost like to see different views for different purposes. Not sure what
the answer is.

At work I made firebaseopensource.com to sort of re-skin GitHub with an
emphasis on the docs, not the code. GitHub Pages is often used the same way.

------
saagarjha
I think the author is trying a bit too hard to shove all the information they
can in that space. While it would be nice to have a slightly more detailed
overview, I think he may have gone a bit too far…

------
legitster
I was quite pleased at first but he completely lost me at removing the commit
descriptions. I use that _all the time_. Without it, it _is_ just a file
system. And then flattening the design just for the sake of making it look
more modern is a particularly bad idea.

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

~~~
IfOnlyYouKnew
They have >500 commits on Github in the last year. I’m pretty sure that makes
them a user: [https://github.com/tonsky](https://github.com/tonsky)

First rule of life: don’t stereotype people (“designers aren’t coders”).
Second rule: check before leveling ad hominems.

~~~
drusepth
For what it's worth, 500 commits is <2 commits per weekday for a year, which
seems pretty low for the kind of power user I would assume github is actually
designed towards.

~~~
tuananh
maybe work stuff ain't on github?

------
nichochar
Agree of disagree with OP's design, you have to admit that his breakdown is
very clear and highlights problems well.

Even without adopting his solution, this really gives github some ideas on
problem areas to focus on. I would consider hiring this person if I were them.

~~~
structural
This is exactly the kind of change that should not get someone hired: a lot of
the UX concerns he highlighted are valid, but the net result of his work
looked like "complete redesign" to most folks and hides some pretty important
information in the process.

The amazing designers that you really do want to find are the ones that will
give you the smallest set of improvements that fix UX issues without changing
the visual language of the product. If done right, most people wouldn't even
notice that the site had changed at all but their daily frustration with being
able to find things would decrease.

For example, the nested tab mess can be a real annoyance. It's worse on
mobile, too, but the designer managed to tweak the design and completely
forget about anything other than desktop dimensions. This is not really
forgivable in 2018. The least possible change might be: let's try placing all
the tabs together on the screen so that people don't go looking in one list
for an item that's in the other. Then, making all the pages have the same
navigation group containing both sets of tabs makes sense. At this point,
stop!

Certainly, if the company thinks a design looks "dated", it could be updated
at some other time, but ideally there would be zero change in information
architecture to go along with it. Again, most people wouldn't notice the
colors had changed subtly and information would be in exactly the same place
it was, but ideally you'd be able to measure things like "number of users
reporting that the site gives them eyestrain decreased by XX%".

GitHub certainly isn't perfect, but their UX people do seem to be fairly good.
I've been using the product since it looked as it did back in 2013, and
without side by side images, I actually couldn't point to any one point in
time and say "that's when they redesigned the product and everything
changed!".

------
bitt
> it’s time to fresh it up a little? Get rid of gradients, dirty washed-out
> colors, unnecessary separators, add a little more air. Something like this:

I'm not sure I agree with this. Gradients are not bad because not everything
has to have a flat UI. Also, separators can be very effective if used
correctly. IMO, I think a huge part of Github's success is it's user
experience compared to Google code, Codeplex and others that did not continue.

------
hvindin
I was actually pretty pleased with this as a proposal right up until _Problem
8_

I actually use the description of commit and the time of commit quite
regularly to figure out how active a project is.

If everything but the readme and maybe a contrib folder hasn't been updated in
6 years, I have concerns. Unless the commit message on one of those, say the
contrib folder, indicates that adjustments have been made because the repo I'm
looking at considers its work now be a solved problem space and I can see
few/no issues or pull requests then I'm backing right out and looking
elsewhere for a project that might address my particular problem.

Replace that information with a commit history that doesn't indicate to me
where those commits got made (ie. Was it core code changes? A spelling
mistake? Where are people actively working?) and a bunch of stats that I
usually don't care all that much about and which are already available if I
did really want them. Now the repo landing page becomea a chore to navigate.

However literaly everything up to #8 I actually think makes a lot of sense and
is a small enough deviation from what is there that users aren't going to be
immediately shocked.

------
augbog
Please don't remove the last commit touching a file. I personally love know
what parts of the code have been last updated at a glance.

> Why? I don’t know. Commits often touch files for completely arbitrary
> reasons, so the last commit tells you almost nothing. I can’t think of any
> case when somebody would need that particular information.

Way to shove your opinions on everyone else.

------
gjsman-1000
No... just... No. Also, Flat Design and getting rid of all (even subtle)
gradients is overrated.

------
ishankhare07
> Commits often touch files for completely arbitrary reasons, so the last
> commit tells you almost nothing. I can’t think of any case when somebody
> would need that particular information

You sir are using git in a very wrong way it seems. Its not dropbox, you get
to decide and see exactly what changed and why. Not just do a `git add .; git
commit; git push`

~~~
thegeomaster
I think I can see what the author meant. It's not about doing `git add . &&
git commit`; it's about things like changing the signature of a utility
function and touching all files which use it. Such a commit arguably doesn't
tell you too much about the file itself. I disagree with the author that it
happens often enough to make the "last commit which touched this file" not
useful, though.

------
mostlysimilar
The only point in the whole article I agree with is that the latest commit
per-file isn't particularly helpful. Otherwise I think the changes the author
proposes make for a usability downgrade. A cluttered, aimless pile of
shipwrecked links and elements floating on the sea of a page.

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

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

------
rident
The article says wraps up by stating the design hasn't lost any information
but where's the fork count, watch count and other download options? Also, the
lack of borders and flattening of button styles does not improve the design.
Borders are even more necessary when data density is increased. Buttons, menus
and links now have a variety of borders where they were consistent before.

The menu is marginally better but the extra density there makes the options
run together, especially as counts increase, and lacks room for feature
expansion. The grey background is useful also as it gives the page sections
depth and context without having to label it. A all white background with
various text sizes and lengths is not optimal for supporting more than the
example design and projects using more text or with longer titles will suffer.

This design doesn't take into consideration how the homepage of a repo relates
to the subpages of a repo. The article mentions showing more files yet the in
the current design, file view one click away from the current homepage removes
most of the account meta data and shows more files already.

This design also doesn't consider the logged out view which has a large call
to action banner to get an account strategically embedded at the top of the
code tab. This focal point is somewhat lost in the presented redesign and
would likely require rounds of A/B testing to decide on a new content
breakpoint for this business need.

5/10 - needs work

~~~
roryokane
> where's the […] other download options?

In the “Get code as” section. You can see it was moved in there when solving
Problem 11. It’s true that the fork and watch counts are missing though.

------
dustinmoris
> You see, the nature of description and topics is that it’s important to get
> people to fill them when they first create their repo. After that, people
> rarely change them at all.

I have to disagree with this. I have had to change the topics and description
very often on all my repos. Often the first description is the worst, because
when I create a repo all I care about is getting the content up first. Later I
start caring more about description and topics and particularly topics evolve
over time as a project grows.

Overall I think the article was interesting, however I don't particularly like
everything being squeezed as tightly together as possible. Having a few
background colours or lines in a design to visually separate things out is
actually quite nice. I don't mind if I have to scroll a bit further down to
see more content. Scrolling is not an issue as the content is already there.
Clicking is the problem. Modal popups or content hidden behind multiple
server-client roundtrips is the issue. So yeah.. I don't mind a slightly
longer page with better separated content.

Also his final design looks very inconsistent. Because all buttons and all
other indicators look very different it is not clear anymore which is just a
highlighted header (e.g. the issue counter) and which is an actual button
which I can click (e.g. Watching counter).

Maybe a few good ideas to takeaway for GitHub, but I would hate them to adopt
this design.

------
tanilama
Github is a utility, a developer facing utility, not a consumer beauty
product. As it works already, I would argue it doesn't need redesign, not many
people are complaining its look.

~~~
whoisjuan
100% this. Designers nowadays have trouble understanding the concept of
utilitarian design. Nobody chooses a productivity tool for its looks. They
choose it for its ability to solve a problem. The better it’s solving the
problem the more appealing it becomes to an audience of potential users.

Aesthetics serve a purpose and can increase satisfaction, as well as the
performance of a design, but they will never supersede functionality in a
product like GitHub.

------
shawnz
I think there is a design flaw with step 9: The code tab has been changed to
"overview", but an overview is supposed to be a glance of something, not an
authoritative source of data. So where's the authoritative source of files in
the repository now? Are we supposed to be using the "overview" as a file
browser too? I don't really want to see all that stuff on the right if I'm
just trying to traverse some directories to get to a file.

I like all the changes prior to that one though.

~~~
2T1Qka0rEiPr
I thought exactly the same thing. It _replaced_ the files tab, whereas it
should have been an _additional_ tab, otherwise where would files be?

------
burlesona
Two nitpicks:

1\. Why are the images cropped so strangely on mobile? It makes this article
really hard to read.

2\. Shouldn’t the title be “Redesigning _the_ GitHub Repository Page”?

^ And a meta question for programmers, what do you do when English grammar
calls for a question mark to be inside your quotation mark at the end of a
sentence, but you’re literally quoting something that should not include the
question mark? It’s grammatically wrong, but I’ve taken to moving the question
mark outside in the case to avoid ambiguity.

~~~
JonathonW
> what do you do when English grammar calls for a question mark to be inside
> your quotation mark at the end of a sentence, but you’re literally quoting
> something that should not include the question mark?

AP style (at least, according to the cheatsheets I've found online; I don't
have access to the current edition of the full guide) only puts periods and
commas inside quotation marks-- question marks, exclamation points,
semicolons, and other punctuation only go inside quotation marks if they
belong to the quoted matter.

So, that makes "Shouldn’t the title be 'Redesigning the GitHub Repository
Page'?" correct, according to them, at least. (This is a matter of style more
than a matter of grammar, though.)

~~~
int_19h
That's the best argument I've ever heard for always put everything
consistently after the closing quotation mark.

------
ultrabenos
There's two main things I don't understand about the redesign and other
comments here: what's wrong with nested tabs, and why is it confusing that
"releases" is under "code"?

The latter makes sense because a release is basically just a snapshot of the
code at a point that the developer(s) thinks it's in an acceptable state for
users. Sure, it might reference Wiki pages or issues or contain binaries that
aren't in the repo itself, but ultimately it's still directly related to code
and at best only partially related to anything else.

As for nested tabs... how is that bad at all? Grouping related things together
just makes sense. Maybe Github's current design isn't the best way to group
them, but the concept of grouping itself is fine. Grouping related links
together, assuming the links are grouped in an intuitive way, is far better
than overloading users with a long line of different options. Maybe the
current main tabs could be drop-down menus or something?

Also, as mentioned by some other people, I absolutely hate the current trend
of making websites and apps be as plain white as possible. Separators,
gradients, and soft colour backgrounds make it really easy to distinguish
different content areas at a glance. The end result of this redesign is just a
mash of text that looks like the CSS didn't load properly.

I'm also very surprised neither this redesign nor Github themselves have added
a dark mode. Why do people enjoy staring at white screens for any length of
time? I don't trust people who code with light themed environments.

------
combatentropy
Design 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).

------
sangd
I really disagree with your top 3 problems, the rest is still not very
convincing.

1\. Nested tabs -> it's a better way to organize when you have too much
content that should be grouped under the same tab. Nested tabs are found in
lost of well-organized designs. I am a programmer and I do like hierarchies. I
am uncertain about your statement of people normally don't like hierarchies.
Maybe nested tabs don't suit your design, but I don't think it's a problem.

2\. Redundant icons -> Of course when you stack them in the "intended images"
with lack of spacing like that, they would cloud our views and harder to see.
If you lay them out with good spacing, horizontally, they're much nicer to
see. If you're using it often enough, you would remember the icons. I think
you should keep the icons, push the non-regular items to a more option icon
like ellipsis.

3\. "Vanity counters" -> they're designed with different purposes. Out of the
3, I only care about Star and Fork. They're very good metrics and also good
pride badges for public repos.

I do see there're good improvements compared to the old design like the file
list, getting rid off the redundant commit description next to it, the stats.

------
l9k
Most of the ideas are good, especially the size reduction of the header.

Some thoughts:

1\. I like seeing when something in a folder has been modified, and be able to
spot easily what folders are active and the ones that have not been touched
for years. I agree the last commit message is useless.

2\. The file and directory list is currently displayed the same on the main
project page and when navigating inside sub-directories. How should the sub-
directories be displayed with these modifications?

------
dwaite
I disagree with the commentary in step 1 that people hate hierarchies. They
hate arbitrary, overly complex, and/or ambiguous ontologies.

For example, dividing a public library into fiction and non-fiction is
something that provides arguable value (although some might argue which books
should be on which side). Trying to figure out where something exists by the
rules of the Dewey Decimal or Library of Congress or any of the many other
classification systems out there can be maddening without experience.

Rather than starting with collapsing items, I believe it would be far more
useful if there was consideration for _how_ people use and intuit GitHub, and
create the items from there.

For example: there are organizations and people who have projects, and
projects contain facets like a code repository, issues, releases, and so on.

For example: the code repository contains branches which contain commits. Some
commits are tagged, but all contain a file hierarchy. But since users care so
much about the files, Github renders by default the latest commit in the
project-default branch (such as master).

So perhaps a better view for files would be to make code itself navigable by
breadcrumbs - top view is branches and tags, a branch/tag view winds up taking
you to a commit history, and a commit takes you to the file view. You just
default to a place inside the breadcrumbs when you go to the root of a project
and select to view code.

Step 8 seems to be where it finally broke down for me. The file view lost a
lot of information that people rely on and want, without consideration for
_why_ they rely on it, or how they can get it back if they need it.

------
sandaemc
I need those Files Description because I'll know immediately which
file/directory has changed recently.

The UI you propose cater to your needs. It's just that.

------
bichiliad
I think at the end of the day, this redesign doesn't seem to consider how the
site is used. This redesign constitutes an application of heuristics, without
a cohesive story around how the site should be used. If you start with "what
does a user want when they go to a repository" rather than "how could I
iterate on this design", I believe you'd end up with different results.

------
lqet
> [http://tonsky.me/blog/github-redesign/60_icons-
> removed.png](http://tonsky.me/blog/github-redesign/60_icons-removed.png)

Why should a user without any background in coding / git, care about the
branches when opening an issue? Or individual commits? Not the mention that
the number of commits may change depending on the selected branch, but the
issues and releases stay the same, which is something the author does not talk
about.

> If you are a programmer, you might be surprised but other people normally
> don’t like hierarchies.

Citation needed.

One of the big benefits of a hierarchy (be it in UI design or on a political /
social / corporate level) is that on any level, you really don't have to think
about the levels above or next to you that much, and thus even individuals
with a very limited skill set can be productive members of this hierarchy. The
anarchic approach of "everything is accessible to anyone everywhere" taken
here just excludes specialists from using a GUI productively.

~~~
oblio
> Citation needed.

All the popular modern interfaces don't use trees, they use lists and lists of
lists. Technically those are trees, but not to users, since they're only
exposed to 1 level at a time.

And regarding the "anarchy" is solved another way: searching and sorting, à la
Knuth.

The most successful interface of all time, Google, has 1 input and 1 button
and it returns a list of things.

------
rukittenme
Section 8 was my favorite redesign. Section 11 was okay. I could see the
utility in it. Section 12 would push me off the platform entirely.

------
ianstormtaylor
Fun article to read, and has some interesting ideas!

In case anyone else is interested I wrote a similar style of article about
refactoring GitHub’s interface a few years ago too:

[https://ianstormtaylor.com/refactoring-githubs-
design/](https://ianstormtaylor.com/refactoring-githubs-design/)

------
ricardobeat
This was really good, up until the 'refresh'. Why get rid of most of the
visual structure right after you spent all that effort making it cohesive?

I especially like the code + commit activity + stats in the overview page,
when visiting a new repository the initial code view is almost never what I
want to see.

------
self_awareness
> The traditional Windows File Explorer, together with macOS Finder, have
> established a simple pattern for file browsing: files on the left, details
> on the right.

I think the author is a very young guy that doesn't remember computing pre-
Windows. Probably everything before Windows has used this pattern...

Even more, it's a perfect example of trying to fix what's not broken. The
result will be something else, not better, not sure if not worse, but why
change it?

How am I supposed to buy the argument that a programmer has a problem with
understanding the difference between a fork, a like, and a watch request?
Wasn't GitHub meant for programmers?

> If you feel disoriented, give it a minute. Once you are used to it, you
> might notice it’s actually easier on the eyes and a bit lighter.

In other words, push through the pain. You'll like it.

------
kurzac
I hope GitHub stakeholders will never read that article. It's full of
nonsense. The author doesn't know what he's talking about in this particular
case.

Commits, branches, releases, contributors belong exclusively to Code! There
are no releases in Wiki. The GitHub design is perfect and it should stay like
that forever :-)

I hate those designers who try to "fresh up" things every single month. Is it
because they cannot create something valuable? I was just getting used to the
latest icons in my IDE and next month they "fresh it up" and I have no idea
what is what.

GitHub has been around for years, it gets the job done, everyone is used to it
and knows how it works. Let it stay like that!

The only thing that I'm missing sometimes is file tree. But one can get it
with the help of Octotree extension.

------
othiagocruz
The author logic for the header and tabs seems pretty reasonable because the
arguments come from ideas from most UI kits around, but after the break the
article clearly states a lack of knowledge on git and how github was designed
around that.

Thats one take i`d criticize on github design, it does fail to explain how git
or github works, but I think the platform was designed as a hub for git users
and does great on that.

I think we can agree comparing to other similar plataforms github has the most
straightforward design, so much that is used beyond coding. Some people are
running communities on it, with colaborative forums using issues and plain
text documents formatted using markdown. Its quite remarkable.

The intent of the article was good but as some of us programmers would say: if
it aint broke, dont fix it. :)

------
neop1x
I hate how they present is as "problem" they are trying to "solve". I don't
have any of these problems and I use Github almost daily.

Why someone always has to create artificial problems and re-design and re-
invent something which don't need any change? And it is not rare that they
make things worse from usability standpoint.

A similar example (not layouting though) is also that flat design in iOS.
Buttons which have no border and can't be distinguished from labels. Flat,
solid colors. If you look at Windows 1.0, it looks nicer than current iOS
design, it even has an innovative border around buttons, rounded! So why are
designers gong back and making it worse than it had been at the beginning of
graphical UI design...

------
hendrikpetertje
I don't know. Don't get me wrong - I like most of the changes. The thing I
miss in the final result you create is the presence of "last edited date".

I am a console guru, as such I actually run most of my github (yes github, not
only git) interactions from within Vim or the "hub cli".

When I need to actually visit Github, the primary thing I do is look over the
shoulders of a colleague and pointing out specific files. It is super
convenient to have the "16 minutes ago" at the end of each file or directory,
since I can basically just ask the colleague I'm helping to follow the "16
minute" pointer as a rabbit hole to the file in question (without bothering to
remember the actual file name).

------
rajangdavis
I don't really like the end result of all of the changes; it seems a lot
busier than the current UI.

Maybe I am just really used to the current UI, but I don't really feel like I
need to see the codebase, last N number of commits, and language statistics
all at the same time. I prefer the current set up in that the language stats
are incredibly minimalistic and the current list of commits are viewable if
you click on commits.

I also think putting the navigation all one line is a bit cumbersome in that
you would have to scan all of the links horizontally. I feel as though this
makes it harder to find which link I need to click on.

I do like that flat design on some of the buttons but overall, I feel like the
redesign is difficult to take in.

------
mpaiva-fl
Congrats on this - there are some really good ideas here that would definitely
improve Github further. IMHO, there is still room for improvement:

\- Mobile - Github's mobile experience is less than desirable, proposing a
mobile-first approach here would be amazing;

\- Tabs - having a row with more than 10 tabs won't help much on improving the
navigation, not to mention localization;

\- Overview tab - this is a great idea, but it would depend on the user type.
If you are the owner or contributor to the repository, you'd most like benefit
from the glanced overview page, but if you are a regular user, you would want
to see the Readme.md view to decide if the repo is what s/he is looking for or
if it's well documented.

------
adventured
I agree with several of the redesign suggestions, basically right up to the
ending where the entire thing collapses into a wash-out of overdone white
spacing that makes the entire layout a carnival of chaos without strong
separation.

I can hardly believe the author went through and carefully tried to improve an
already highly effective layout, mostly did a sound job at it (or at least
made an argument for their approach), and then destroyed it all in some kind
of strange burst of what the hell in conclusion.

It's like someone made a mistake at the end and accidentally dropped Github
into a bad css framework or design you might buy for $5 on Envato. The
separators aren't unnecessary, they're critical.

------
Leace
I really enjoy this kind of articles even if I don't necessarily agree with
all changes that the author made. Sometimes looking at the old/new comparison
makes me consciously think about what makes it a good design for me and what
doesn't.

------
squant0
I was so on board with change progression until the final mock - floating,
borderless sections on a sea of white is profane.

Big fan of the screenshot under problem 10 however and would love to see
Github implement some of the improvements on vertical space usage.

------
KhalPanda
I liked most of the changes, but it lost me with the final redesign. Three
columns without much separating whitespace is quite jarring to follow. Maybe
that would work better on a larger screen with some padding between the
columns.

Fun exercise, anyway.

------
pcurve
should've stopped here. [http://tonsky.me/blog/github-
redesign/160_files_buttons.png](http://tonsky.me/blog/github-
redesign/160_files_buttons.png)

------
snowe2010
I am completely fine with the final result, except the three columns. That
stuff is completely useless to me. What I want is this: README and Issues/PRs
front and center. If I want to view the code I'll use OctoTree or the `T`
shortcut. There's absolutely no reason to be viewing the code from the main
page in my opinion. Most of the time I'm visiting GH is to view the readme,
the issues, the prs, or the wiki. I never navigate through the code using
their 'file browser', as it's terrible and you can't even see the hierarchy.
OctoTree is much better for that.

------
yaleman
This is clearly a redesign done by someone who doesn't use GitHub, and doesn't
look at anything but the main screen or why it is the way it is - especially
when you start digging into the rest of the UI.

The tabs they want to take away from the "code" screen have little or nothing
to do with the other main tabs, that's why they're not cluttering up the main
nav bar (which doesn't fit into the author's screenshots.

No one cares about the description of the repo if they're trying to interact
with the wiki or the issues modes, that's why it's in the code/main section.

~~~
matt4077
> This is clearly a redesign done by someone who doesn't use GitHub

They have >500 commits on Github in the last year:
[https://github.com/tonsky](https://github.com/tonsky)

------
matchbok
Really well thought out. I love this. I've never realized 80% content on the
first page is completely useless.

I think adding the readme to above the commits/stats would be a good idea.
Perhaps make it ~500px and expandable.

------
giancarlostoro
What I really want to see is not having to click on 'Show Desktop' whenever
I'm on a phone to be able to read a whole README file. I just want to see the
README first, _all_ of it.

------
debaserab2

        Problem 3: Vanity counters 
        This is the “vanity menu”:
        The thing with vanity metrics is that there should be just one. One metrics is simple to understand and focus. Two or three split attention, making everything weaker.
    

Each one of these metrics is important to me - I judge a project by the
numbers in each of these, and they have very different importance depending on
the size of the repo. Please don't "simplify" this.

------
mshenfield
The GitHub designers are infallible GOATs, how dare this upstart - wait, WAIT.
This is actually pretty good. Designing for desktop width makes sense because
GitHub uses a relatively independent design on mobile [0].

I'd like to find a useful alternative to commit messages on the Code page that
was still per-file focused.

[0]
[https://photos.app.goo.gl/arU8HrUUw9yQgQyc8](https://photos.app.goo.gl/arU8HrUUw9yQgQyc8)

------
jimktrains2
This deprioritizes the readme even more (and it's already too much; why can't
I see it all by default in the mobile view?)

------
k4ch0w
I think the problem when it comes to any UI design is it's all personal
choice.

I was going through these comments and most everyone here disagrees with one
or two things and other's agree. Art is a subjective thing and I think
ultimately at the end of the day it's about giving the developer more options
and letting them decide what makes sense to them.

------
sireat
I am still amazed that there is no easy builtin way to sort your repositories
by date on Github.

Also, how do I filter all my repositories to be the ones I created from
scratch not the ones I forked? EDIT: This one is easy just use Sources
Filter(strange name but ok).

With 300+ repos it is getting rather unmanageable.

Sure there is an API for creation date but that is just silly.

------
_mrmnmly
Despite the fact I like some of the changes presented there, one particular
detail has shot me: lack of understanding why github has put commit messages
in file list and removing it - this might be a harsh opinion, but proved to me
that the author doesn't fully understand how most users (developers) are using
GitHub.

------
franzwong
I don't agree with repository overview. Most people visit home page are not
maintainer. They don't care much about commits and statistics.

What they do is reading the README.md or reading code without cloning them to
their machine. Perhaps commit message is not important, but the update date
reflects how active the repository is.

~~~
adjkant
To me this sounds like a prime opportunity to have two repo pages: one for
contributors/owners, one for everyone else, and the option to toggle the view
for each account per repo.

The danger would be overcomplexity/confusion, but if designed to match
eachother well with different priorities, it could work. Still, the singular
view no matter who you are is certainly a nice feature that may not be worth
getting rid of given how universal the repo page design is.

------
Phait
I was ok with this until the part where OP changed the background color of the
top of the page. From there, it all went downhill and very quickly became yet
another "yay everything is flat and overly saturated" design. Boring and less
usable.

I'm not even going to talk about that abomination done for the content.

------
keithnz
If given a vote, I'd stay with the current design. But some of the problems
identified are legit. I certainly think it can be improved, but not sure this
is quite what it should be. I think more thought needs to be put in to what
various people want to do/see when they hit that page.

------
lexx
I really enjoy this kind of articles. The author started with small logical
steps that indeed made sense and then he did a crazy leap to nowhere. The
final outcome is silly.

In any case, I would like to see a follow up article, taking account of the
feedback. That is how design works... iterations

------
hateful
You should make a browser extension to add css/js to apply your changes so
people can try it and/or permanently change it just for them. Even better if
you add a bunch of options to turn them on or off (like if you want to move
everything, but keep the old design).

~~~
gyvastis
I second this.

------
asattarmd
Github is used for at least two things: (1) finding new repositories and check
how actively they are developed and (2) actively developing repositories.

This design fits well for (1). But for 2, it performs badly. I need all the
files, the commits etc if I'm working on the repository.

------
feresr
I think you did a great job at identifying issues, but a poor job at
presenting better alternatives. The end result is harder to navigate IMHO.

"Test yourself, see if you can find Releases tab without an icon and if it was
harder than before? It wasn’t, was it?"

So you take them away anyways? ️

------
mpodlasin
There is so much comments about whether the proposal is good or bad. But for
me, without making usability tests, there is just no way to know if it's
better.

For me proposal for redesign without any experimental data presented is just
an invitation to endless speculation.

------
vkaku
Comments:

I like most of it, except adding the 'Statistics' and list of 'Commits' all
together; They should be collapsible, if necessary. I'd also like to see the
last commit against a file, and maybe modification time.

------
harrisonjackson
I was onboard through the navigation redesign (as others have said) but he
skipped a whole section! The global nav w/ search at the top. The only
problems I've ever had navigating a repo are search related.

------
louieadamian
This 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

------
mrchief
Started tinkering with a tampermonkey script:
[https://github.com/mrchief/github-
redesign](https://github.com/mrchief/github-redesign). WIP.

------
kissgyorgy
"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?

------
jkooda
Typo on final mockup "New pull Requrest" I like where this is heading, but
you'll get pushback from folks on the all-white UI... eye fatigue. Include
dark mode and you're good to go!

------
optikinescant
It feels like you didn't interview any real-world users here. I think the end
product might have turned out quite a bit differently had you done the leg
work required for such an undertaking.

------
zetabyte
Frequently used feature as a open source contributer on github. \- git fork,
clone, pull request. \- searching/filing the Issues.

Does this new redesign proposal enhanced the usability of these features? Not
at all.

Just my opinion.

------
DeonPenny
Meh this look super busy. I like the top section but the button is used
primarily to look through the files. Other two columns aren't worth losing the
ability to quickly find files I want to see.

------
xorand
This is so Microsoft redesigns the Github repos
[https://www.youtube.com/watch?v=EUXnJraKM3k](https://www.youtube.com/watch?v=EUXnJraKM3k)

------
eugeniub
I really thought this article would make the readme much more prominent.

------
miles_matthias
The main UX frustration I have all the time with Github is switching between
my fork and the upstream repo. I find myself re-clicking the fork button all
the time to be able to get to my fork.

------
sjapkee
Ban him from being a designer through the courts. It's awful af.

------
anotheryou
I love it.

What I don't like:

\- I like the "last touched" messages (but they don't have to appear on the
front page I guess)

\- I don't like getting rid of dividers (the final design part he does)

------
mcdevilkiller
The lack of boxing/borders make it more difficult for me to separate every
piece fast. I don't really like the design. Fira Code however, I love that.

------
miguelmota
Sorry but the way github currently looks is clean and uncluttered unlike the
redesign the author proposed and hope they keep it that way. Nice try though.

------
AlexAegis
1.) Last commit date is important, it's an easy-to-tell indicator of recently
modified files. 2.) I want my colorful language bar back >:(

------
revskill
I agree only the contributors part, it should be more focused on the homepage.
For other parts, current Github design is too good enough to change.

------
FPGAhacker
I thought many points were good, and was impressed. Right up to that last
"freshen up" step, which completely destroyed all the work.

------
mxcrossb
Speaking of github’s UI, how come on mobile there are lists of pull requests
and issues, and closing them doesn’t remove them from the list?

------
bobblywobbles
Clean up the space a bit, remove the icons, yes yes.

Please don't feel the need to redesign to "freshen" up the site. It looks good
as-is.

------
jedberg
Ironically all the images are broken on mobile. You'd think an article about
UI nitpicks would at least get that right.

------
mromanuk
Following his decisions along, they make sense, but the final product is
convoluted and busier than the original.

------
bctnry
> _When you get to the repository, the first page you see should not
> necessarily be Code._

No. It'd better should be.

------
duncan-donuts
Should have stopped at step 8. I was onboard until useful information for
developers was actually removed.

~~~
muratsu
Yeah agreed completely

------
ddtaylor
Stuff like this is why every once in a while a well-designed UI gets turned
into unusable garbage.

------
dimman
Seems like management arrived after solving problem 4, which resulted in 7+
new problems.

------
tinti
It is almost impossible for me to agree with "Problem 8: Files description".

------
timw4mail
This just makes me think: leave the design as is, and revert the stupid black
header.

------
blue4
I was fine with everything until the last change, the borders are needed,
visually.

------
apertoire
haven't read through, but two things

\- forks is important to easily find out alternatives, when a project has been
abandoned

\- i like the overview, but it should be more prominent ... when was the last
time the owner of this repo took interest in it ?

------
julienreszka
The most important part, responsiveness to screen width was completely
ignored.

------
Svoka
Honestly, I was hoping for the prototype to demo suggested changes.

------
nkozyra
Why does the star counter have a star icon and also the word star?

------
fourier_mode
As with most other I agree, don't like the end result.

------
LeicaLatte
Lots of good touches. Digging the new UI as a programmer.

------
est
I need a column to show file size on github.

------
yosoyalejandro
I have more trouble reading the blog post than github, that combination black
text yellow background is not confortable for reading.

------
paule89
I like it a lot.

------
iam13islucky
Probably gonna be lost in the sea since this is 2 days old, but here goes
anyway:

\- I agree maybe releases could be put to the top level menu, but not
Everything. Now It's way too hard to parse and took me much longer to find
things I need. I use the "Refined Github" extension on my firefox and that's
the only tab it adds, cause it makes sense.

\- Moving description and tags up top by repo name, good decision. I like that
one a lot.

\- This fear of hierarchies is why I struggle with many redesigns. Yeah,
everything being out there is fun, but it always takes forever to find things.
Once you have used the old for a week much of it is muscle memory.

\- An example of what I feel is an issue that keeps sticking in my brain, your
clone/download area. The Green dropdown is easy to see, Opens up to let you do
all you need, and is very explicit. "Get Code As ..." Is confusing, easy to
overlook, and doesn't look like where you'd download an easy .zip file or open
it in a desktop app. There's gotta be a middle ground, which is likely
separating the two things again. Theirs confused people looking for the clone
link, somehow, but yours looks _NOTHING_ like a download button for a zip
file.

\- Getting rid of the second set of tabs on the code tab honestly hurts a lot
of different use cases to benefit only the use case of a casual browser. I'll
often look around at projects to see if I can lend a hand, and being able to
see the code color bar under the buttons allows me to see how much my skills
are useful to the project at a quick glance. I know my colors, and if I see a
new one, a quick click informs me. Additionally, when seeing if I can use a
library for work, the easy, bit view of the license is crucial. Your design
had me searching for almost a minute, and still, when I go back I can't find
it immediately.

\- Removing quick editing from the description and tags is a mistake too. Just
cause it doesn't happen often for you, doesn't mean it should be hidden. I'm
certain there'd be tons of people who get really confused by it being moved
and would never think of it being put in a catch-all settings page.

\- Stars, forks, and watching, I'll agree with these changes pretty easy.
Makes sense.

\- Please don't get rid of the colors. Add more, change em up, whatever, but
don't go soulless white, black, grey, blue, hints of red. My eyes have a much
harder time parsing your dense, separation-less page than it would a bright,
saccharine mess that at least differentiated everything. This feels like
facebook or something else lacking joy, give it a light drop shadow or
background color if you wanna lose the borders! Seriously, take your end
design and give each of the three columns a little border radius and a
slightly offset drop shadow, add a light, simple background color on hover of
each folder/file/commit, and I can at least stomach the rest of it.

------
Bulbasaur2015
very good

------
anarchy8
I like it. The commits per file don't make sense in the current design, and
the tab hierarchy doesn't make sense. I don't like the "flat" redesign though,
it was better before.

------
thisisweirdok
> if you put too many icons in a row and they are all different, they won’t
> work.

uhh what? says who? where's the source of this? This is only the case if your
icons don't look different enough. In the example those icons aren't great
because they've overly complex and easy to mix up.

>you won’t come up with a great icon for a commit. Or a release. Or an issue.
Or a license.

You can, and you also don't necessarily need to. Icons aren't only for the
illiterate or first-time users... they create a signpost for repeat users to
scan for without reading a word. As long as you consistently use the same
icons and they make at least a little sense, they can be useful (I agree that
some of Github's don't make much sense at all though).

>I mean, Icon + Label + Counter make for a symmetric and weak composition:

It's best to refrain from insults during critique, but this is flat out dumb.
Completely unfounded. No evidence. The composition is "what is it" and "how
many" — it makes perfect sense.

>The thing with vanity metrics is that there should be just one. One metrics
is simple to understand and focus.

Again, no. This is how _you_ use it. You've done no research. I want to see
forks because I want to know how many people are potentially engaged in
_doing_ something with a repo. Stars matter less to me because there are some
repos that just have a lot of stars because someone wrote an interesting
article about it once. (I do think stars and watching is a bit redundant, I
personally have no need for both but my personal experience does not solely
dictate what the product needs to be)

> Watch button

Again, no. `Watch` is an action. If I click the dropdown I expect to have
options for "watch". "Not watching" simply adds words and makes me put forth a
little cognitive effort (minimal but it's there) to parse what the opposite of
"not watching" is. You are adding the need to think more, not less.

\--

Honestly I'm too exhausted to continue. This redesign isn't well thought out
at all. At this point I skipped ahead to the end, and honestly it's just a
garbled mess. You don't understand the product or its users. If you were my
student (I'm a design professor) I'd give you credit for the effort, and the
visual design is fine (though are you trying to trick me into thinking that
making corners more round is meaningful?)... but there's an endless mountain
of straight-up bullshit to call out here.

~~~
gabeio
I’m glad to see a designer agreeing with all of the developers.

------
carmate383
Author's UX/UI credibility went out the window as soon as I saw black on
yellow.

------
fxfan
Thanks for the blog post and the detailing of your thought process- I learned
a lot .

Fwiw- I 99% agree with try redesign (except that there are too many tabs and
can't put a finger why but feel that the color changes was a negative change).

Does anybody know how those "washed out" colors help navigation?

------
modzu
classic example of big company with too many employees who need to find
"something to do". its not broken dont fix it something something.. /end rant

