Author's UX/UI credibility went out the window as soon as I saw black on yellow.
Redesigning GitHub Repository Page
71–80 of 315 posts
Re: Redesigning GitHub Repository Page
#72My retinas are burning
Re: Redesigning GitHub Repository Page
#73Agree 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.
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!".
Re: Redesigning GitHub Repository Page
#74I 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?…
I mention this in a sibling comment, as I've thought something similar: maybe the README should be on top. The problem, as I mention there, is that when you use GitHub as a tool, it's more common to navigate to the files than refer to the README. And with long READMEs, that's potentially a lot of scrolling to get to the files. What this implies is that GitHub is not your project page. The README there should be more…
I missed your comment, it's better reasoned than mine and I think I agree with it.
I was just saying on another comment that I think the problem is GitHub, while maybe it shouldn't be, is the de facto project page for many projects, and is a major use-case.
There perhaps can't be a good solution - it's convenient enough that most small developers can't be bothered maintaining two different information sources about their work, and GitHub certainly has no reason to dissuade people from using it that way, but to prioritise the readme would make actually using the site harder.
Just one of those awkward things you live with, perhaps.
Re: Redesigning GitHub Repository Page
#75I 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? ️
Re: Redesigning GitHub Repository Page
#76First 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 doe…
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.
Re: Redesigning GitHub Repository Page
#77Half 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 up…
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.
Re: Redesigning GitHub Repository Page
#78Earlier quoted context omitted.
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.
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 sol…
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.
Re: Redesigning GitHub Repository Page
#79> 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.
Re: Redesigning GitHub Repository Page
#80Two 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?…
> 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 poi…
That's the best argument I've ever heard for always put everything consistently after the closing quotation mark.