A DIFFERENT GitHub redesign proposal
blog.alexrohde.com
blog.alexrohde.com
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.
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.
> 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.
>> Your proposal has a significant drawback right away, _as_ I dislike it.
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.
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.