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.
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.
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?
Yeah, that second line of development went in another direction with different guiding principles.
If the first set of changes can get positive reviews here, maybe they'll get merged.
The second line could benefit from some questions about its targets and see how they align/diverge with the aims of a common vcs UI model. I wonder how this matches other UIs.
In any event, a roadmap would help so we could put this in a broader view of where and how it fits in to our needs. See also, https://github.com/isaacs/github/issues/
I agree with the author, the last commit to touch a file or directory isn't very useful. A single white space change will replace the message for a large refactor.
The commit message is a proxy for freshness, but only if you are familiar with the commit log. It is a proxy for related changes, because a commit will update the details for many files.
'Freshness' indicated by color that is more washed out the older the file achieves the first use case.
A sparkline showing changes over time would indicate recent changes, hot files, related changes, and freshness.
This really depends on how disciplined your commits are. Yes a refactor makes it useless but really, in my opinion, a whitespace only change should be a seperate commit. Additionally a commit should be a group of changes that make sense together, certainly not two unrelated features. I think this is why I tend to find the last commit a pretty valuable field.
> in my opinion, a whitespace only change should be a seperate commit
yeah and now your 'most recent commit' is 'fix whitespace' instead of whatever your relevant commit message is. No matter how disciplined your colleagues are, commit messages describe what was done and sometimes what was done is just cleanup or refactoring.
I don't - I use this quite a lot in the current view to see how active they still are. The commit log is maybe nicer - but as an external user of something hosted on GitHub - that level of detail is actually not that interesting. A "last updated" would be more useful.
If you would get the commit/pull req/issue list in your default view when you have commit rights on - or have been contributing to a repo, sure, seeing the commit/pull req/issue log could be an interesting information stream in that situation.
But then lastly - the other statistics? It just creates an information overload. I prefer a cleaner look with a single focussed view.
It gives me a sense of which files have changed and if my changes are still the latest ones.
Or as I've had to do with other VCS in the past, "what was the last thing that happened to this file?" is a commonly asked question which that description answers, especially when there is a bug in it.
Right. More generally, this UI proposal (as most unsolicited ones are) is a snapshot of a single page. It doesn't aim for consistency across the other pages, or look at workflows involving more than one page.
"What happened to this file?" is one of the most common tasks I have, and it's poorly supported by every web VCS interface I've used, including GitHub. This proposal would make the situation even worse, by hiding any remnant of changes in the file listing.
If I wanted to see the history of a file I would go to that file for more context. I agree with the author that I don't think it's useful enough to show in the front page.
I personally care about the commit log most of the time I go onto github, or the issues, or pull requests. Not that keen on navigating to files from github.
Removing the last commit message 'because commit messages are often bad' was one thing, but tossing out the last change date alongside it with nary a mention? Unforgivable.
I feel conflicted. There's a value to show the log graph on project's home. It feels that the main emphasis is not really the static nature of source but the contribution you can make to that tree (as in branches history graph).
> I can't articulate why, but honestly it's extremely useful to see the last commit message on each file.
Pride and curiosity.
If they are your changes, and they are on a big/famous project, it's immensely rewarding to stare at your name in the commit log. Making things a simple chronological list only emphasizes the most recent committers overall. The fact that you're a ninja who improved something that nobody else was willing to is obscured. It satisfies the human "mastery" motivator.
As for curiosity; I'm not going to pretend to be some compiler or JIT guru (although I wish I was). That being said, I can focus on that area of <thing> and see what people have been doing, possibly scraping off something off of that wisdom iceberg.
I have a huge amount of respect for the magical things that designers do in my company (the first video on this page[1] is a short demonstration of their utter and humbling talent). That being said, I've disclosed a pretty big idea to these guys and they're talking about ingesting bulk email into ML to learn user habits and suggest ideas. No, guys! Not only are you missing the point, but you're violating privacy!
We all do it. Developers come up with grandiose designs for shit that nobody needs. Designers come up with ideas that are technically impossible. Sales sell things that don't yet exist. Support will stop at nothing, including breaking everything, to solve one issue. Corp/management will create enough processes and red tape that nothing can get done.
I'd still take this article very seriously as Github. There's certainly things there that I wouldn't use but that design is clean and awesome.
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.