No offense but that isn't a redesign, it is a gutted version that takes signal rich features out and makes Github much less usable. Signals like "number of releases", "number of contributors", "languages used in the project", and "number of commits" are all important ways that people evaluate an open source project before adopting it.
This redesign even hides the "Insights" tab. Maybe that makes sense if you are someone who only ever pushes code, but if you are a user of open source, and doing something like trying to determine whether an NPM module is healthy, then one of the best signals available to you is to click on the repo for the module and check the "Insights" tab to see if it is actively maintained, if it is a one person project or a group effort, etc. Even if the project has no activity and therefore nothing to populate the "Insights" tab that is actually also an important signal that this project is probably kind of dead and if there are fixes that need to be made I'll have to do them myself.
Would be interesting if users were allowed to customize the ui depending on their needs actually, even if that was client side. — the more I think about this the more certain I am that there must already be a chrome extension that does that.
Agreed. The information presented currently serves a point. Removing items from the design for the sake of removing them is not efficient design. If anything, that is counterproductive.
The presented design would be better received as a personal preference. The tone presented is I’m right and if you don’t recognize that then you’re wrong.
Thank you for taking the time to write this up and mock up your suggestion. I could not agree more on your changes. (Might have some issues with the position of the new buttons and lack of releases link but that’s minor).
The only thing I’d add back somehwere under the description would be the languages the project uses and its labels.
There is one good point in the post, which is that it would be cool if things not used by the repo were automatically hidden (but still accessible if you want to start using them). Dont have a wiki? Dont show the wiki button (hide it under "more"). Dont use Projects? Hide the Project tab.
That is already the case though. You can disable wikis, projects and issues and if you do so they will not show up. Granted it is kind of opt-out rather than opt-in, but I think that if you are starting with GitHub it is better to see what is available and if you are experienced you know what to do to hide them.
In the end I disagree with the author that gratuitously hiding stuff under some submenu is good if there is no need to save space.
You gutted most of the features out of sight that I use as a developer, at least based on that screenshot. I am not a fan of hiding things behind countless links, so, I'm a no on this one.
> I have zero expertise and no real design credentials.
> If these rules don’t click for you, then you probably have a long way to go in your UX journey.
You seem to establish yourself as knowing very little, but then belittle people that might know more than you if they disagree with your rules that you've just made up.
> Wiki and Insights are features I have never used on github and may never use. They should be hidden by default.
Just because you have never used them doesn't mean nobody has used them, and I read the next line about "intelligently" showing them (since when has a boolean comparison been considered intelligence?) if they've been used before; but then how do those features get discovered?
I only want to sound as rude as you were to the person whose work you've criticised for pageviews, so I'll leave it at: stick to DevOps.
> There is always a flexible solution which caters to both experts and novices simultaneously.
That's wrong, regardless of how bold you make the word always.
> You seem to establish yourself as knowing very little, but then belittle people that might know more than you if they disagree with your rules that you've just made up.
Yeah, that "you probably have a long way to go in your UX journey" comment irked me when I read it. I'm glad it's not just me who found it patronising.
Your point about feature discovery is a good one that the article didn't address. It's all well and good hiding less used 'expert' features, but all experts were once novices.
> As a senior-devops engineer, I have zero expertise and no real design credentials. Yet I think I can still do better.
> Far be it from me to tell everyone else how to do their job, but here are some principles that seem intuitive to me, and maybe designers might consider them too.
> If these rules don’t click for you, then you probably have a long way to go in your UX journey.
It's always hard to look at changes once you've gotten used to the status quo. When github first started I hated everything about it, wasn't clear at all how it improved over just using git.
Now that I've been using github a lot (we switched a lot of our corporate repos over to internal githubs) I don't even notice whether the GUI is good or not. I still feel a lot of common tasks are buried in weird icon/button/tab clicking sequences but I've committed them to my lizard brain so now it literally doesn't matter what the GUI elements look like or where they are.
It's the same with other tools that I've used for decades: VS, vi, word, excel. Do they have good GUI? I don't know but it doesn't matter anymore.
There seems to be some general consensus that the github UI is in need of a refresh (which I strongly agree with). Instead of having random sniping via blog post, it would be awesome to see an open design competition where anyone in the community can submit mockups with some bounty for the winner.
20 comments
[ 571 ms ] story [ 116 ms ] threadThis redesign even hides the "Insights" tab. Maybe that makes sense if you are someone who only ever pushes code, but if you are a user of open source, and doing something like trying to determine whether an NPM module is healthy, then one of the best signals available to you is to click on the repo for the module and check the "Insights" tab to see if it is actively maintained, if it is a one person project or a group effort, etc. Even if the project has no activity and therefore nothing to populate the "Insights" tab that is actually also an important signal that this project is probably kind of dead and if there are fixes that need to be made I'll have to do them myself.
The presented design would be better received as a personal preference. The tone presented is I’m right and if you don’t recognize that then you’re wrong.
The only thing I’d add back somehwere under the description would be the languages the project uses and its labels.
I believe that GitHub has way better metrics for knowing which functionalities have to be put forward.
As a personal note, the author removed the Projects tab, which is the reason I moved back to GitHub from Bitbucket.
In the end I disagree with the author that gratuitously hiding stuff under some submenu is good if there is no need to save space.
>> Your proposal has a significant drawback right away, _as_ I dislike it.
> If these rules don’t click for you, then you probably have a long way to go in your UX journey.
You seem to establish yourself as knowing very little, but then belittle people that might know more than you if they disagree with your rules that you've just made up.
> Wiki and Insights are features I have never used on github and may never use. They should be hidden by default.
Just because you have never used them doesn't mean nobody has used them, and I read the next line about "intelligently" showing them (since when has a boolean comparison been considered intelligence?) if they've been used before; but then how do those features get discovered?
I only want to sound as rude as you were to the person whose work you've criticised for pageviews, so I'll leave it at: stick to DevOps.
> There is always a flexible solution which caters to both experts and novices simultaneously.
That's wrong, regardless of how bold you make the word always.
Yeah, that "you probably have a long way to go in your UX journey" comment irked me when I read it. I'm glad it's not just me who found it patronising.
Your point about feature discovery is a good one that the article didn't address. It's all well and good hiding less used 'expert' features, but all experts were once novices.
> Far be it from me to tell everyone else how to do their job, but here are some principles that seem intuitive to me, and maybe designers might consider them too.
> If these rules don’t click for you, then you probably have a long way to go in your UX journey.
I guess I have a long way to go on my UX journey.
Now that I've been using github a lot (we switched a lot of our corporate repos over to internal githubs) I don't even notice whether the GUI is good or not. I still feel a lot of common tasks are buried in weird icon/button/tab clicking sequences but I've committed them to my lizard brain so now it literally doesn't matter what the GUI elements look like or where they are.
It's the same with other tools that I've used for decades: VS, vi, word, excel. Do they have good GUI? I don't know but it doesn't matter anymore.