10 ms·
I submitted feedback over it but, aside from the over-reliance on rounded corners, and making pills and buttons hard to separate, the single worst change is tha
by ljm 6y ago
I submitted feedback over it but, aside from the over-reliance on rounded corners, and making pills and buttons hard to separate, the single worst change is that you can't see the latest commit status from the repo screen. Instead, you get the commit hash, and have to click a tiny ellipsis button to get the commit message and the status indicator.
When I'm browsing on github and not using git directly, the commit short-hash is the last thing I care about. You cannot see if your default branch has passed CI/status checks now. Those things should be first class citizens, that's why we put status badges all at the top of our readmes to make that info more visible with what we have.
It follows the trend of designing with lower information density. This trend IMO is not appropriate for developer tools.
- blueline 6y agoyep. this and the change to the file browsing, where the lines that delineated files/folders are now gone, causing me accidental misclicks of the wrong file, are two very glaring annoyances. everything else i feel neutral on
- JoshTriplett 6y ago> the single worst change is that you can't see the latest commit status from the repo screen. Instead, you get the commit hash, and have to click a tiny ellipsis button to get the commit message and the status indicator. Omitting the commit message is a net improvement to me; I've found that the commit message of the random commit that happens to be at top of tree is completely unhelpful for someone browsing the repository, and especially someone new to the project. However, showing the status indicator inline does indeed seem like a good idea. That said... > You cannot see if your default branch has passed CI/status checks now. If it hasn't passed CI and status checks, it shouldn't be in your default branch. (There are cases where periodic status checks may get re-run after merging, such as checking if your default branch builds with more recent versions of software than it was originally tested with. But the normal CI and status checks should run before merging.)
- ljm 6y agoIt's not so clear cut. Most places I've worked, we don't build artifacts (docker images, whatever) until there's a merge to master or a tag has been pushed. This automatically means that even though your tests remain green, you still want the status check for the stuff that isn't relevant inside a PR. For us, if the status is red in master, it doesn't mean the code is wrong, it means something went wrong in the deploy pipeline.
- JoshTriplett 6y ago> Most places I've worked, we don't build artifacts (docker images, whatever) until there's a merge The projects I've worked on have used a bot for merges, and that bot handles building artifacts. In some cases, there's a lighter CI for "this looks reasonable", and then the full CI (including building artifacts and running more extensive test suites on every supported platform) runs before merging.
- als0 6y ago> If it hasn't passed CI and status checks, it shouldn't be in your default branch The number of broken master branches I’ve seen on Github is astounding. So I find the CI status indicator to be very useful.
- meddlepal 6y ago> If it hasn't passed CI and status checks, it shouldn't be in your default branch. Broken master is inevitable in a large enough project. Really what you want is to be able quickly fix a broken master. By all means keep a perfect master if you have a toy project but once things have several developers hacking on a project with multiple artifacts and hundreds of thousands or millions of lines of code then you need to accept a broken master.
- JoshTriplett 6y ago> once things have several developers hacking on a project with multiple artifacts and hundreds of thousands or millions of lines of code That's exactly the case where you need more strictness about passing tests and CI before getting merged. It amazes me when I come across a major project where the latest committed version often doesn't even build, let alone pass tests. Yes, there are absolutely cases where you can't test everything; for instance, if you have complex combinatorial configurations and one obscure configuration fails. But that's a far cry from "inevitable in a large enough project". On the contrary, it's more important to avoid in a larger project.
- pbreit 6y agoWow. I don't get it. It's still very similar just a bit worse all the way around.
- lostmsu 6y agoThat was my initial thought too. But I discarded it as conservatism, and giving it a try. To be fair, likely there's not much difference. One good thing I noticed is now there is a link to the the latest release.
- als0 6y agoThere’s also the issue of the huge amount of white space within the files table. And the lack of centre alignment of the table.
- lukeplato 6y ago> the single worst change is that you can't see the latest commit status from the repo screen Maybe they are trying to push towards using badges/shields inside the README [1]. But yeah, I agree that this makes monitoring repo health less convenient. [1] https://shields.io/category/build https://shields.io/category/build
- yellowapple 6y ago> Maybe they are trying to push towards using badges/shields inside the README If they're pushing for that, then keeping the README below the file list seems counterproductive.
- rwoll 6y agoI’d second this. In fact, I think the README should be the first thing (potentially in collapsible form so you can easily see the file list without scrolling too much). Intuitively, I’d bet most people landing on the front page of a repo are consumers of the library looking for a README with info on how to get started or where to look for information on how to get started. Again, this is only intuition—no data to back it up. Project maintainers are most likely interacting with the issues and PR sections or code on the command line.
- waheoo 6y agoI personally liked this change. Even if it is the MS MO embrace extend extinguish. If I want to read your readme ill click on your readme. If im visiting your github page I want to read your code. Eee, theyre downplaying the focus on cross platform friendly md files showing repo info, instead they want you to use the newly more prominent side bar that is wholy only available on github.
- fxtentacle 6y agoI find it much more difficult now to line up filename and last modified time in the file browser. And I agree on the low density. Plus it now looks like a children's toy, not like a work tool. A while ago, there was an article on HN about kawaii cuteness culture sneaking into everything. It appears that has happened here.
- TheSpiceIsLife 6y agoThe Kawaiization of Product Design - 33 days ago: https://news.ycombinator.com/item?id=23243646 https://news.ycombinator.com/item?id=23243646
- verdverm 6y agoI started rereading The Design of Everyday Things by Don Norman last night. They be building Norman Layouts at GitHub
- huntermeyer 6y agoYa I noticed the file list no longer has borders between rows. This makes it harder to scan.
- natfriedman 6y agoThanks for the feedback about the latest commit status. This is something we should definitely fix. Also – I don't think there is a principle of lowering information density at work here. I think it's just a design that we will keep iterating. We are pro information density at GitHub.
- chrisandchips 6y agoIt's great to read this comment - it's always nice to know that community suggestions aren't just cast into the void
- nmstoker 6y agoYes, I was really impressed to be contacted by a genuine developer with sensible questions when I gave feedback on the GitHub Android app beta a little while back (funnily enough, given other comments here, my concern was it had simplified away something I found useful!)
- baby 6y agoReminds me of when HN added the [-] and everybody complained it was on the wrong side but they couldn’t be * to fix it.
- zacharycohn 6y agoI love that it's on the right. It means when on mobile, I don't accidentally upvote something that I meant to collapse.
- purrplexed 6y ago100%. This was the first thing out of my fingers today. I want to fully use github actions. Status is huge and getting to a build is a must.
- smcameron 6y agoAlso you used to be able to hover over a commit and see the full commit message. That doesn't seem to work anymore. Overall, seems like change for the sake of change. Boo.