-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
download: consider changing asset ordering #308
Comments
On 2023-09-25 a user in the Zig Discord (in #meetups) asked:
After being shown that there is indeed an x86_64 linux asset listed, the user said that they were confused by this: #311 is a follow up to that, and it looks like an improvement to me. But I think the ordering is also a contributing factor here. |
Yes the ordering of OSs and architectures is deliberate and defined here https://github.com/ziglang/www.ziglang.org/blob/master/config.toml#L29-L50 This was originally designed to be like this by Andrew and since I too shared the same preference, I reimplemented the original system when I redesigned the website.
True, but at the same time the idea is simple:
Hopefully this makes clear the intent behind the ordering, and why we never really made it explicit. In the end, in my opinion, while minor, it's a good thing to have even at the expense of making the sorting a bit weird for people that stop to smell the ordering :^) I've merged #311 and with that implemented I don't feel impelled to make any other changes given the information at my disposal. That said, happy to discuss it further if you want to add some more arguments to the mix. |
Thanks for your thoughts. I think 931966d is a significant improvement, and probably prevents most problems like that experienced by the Discord user above. I'm fine with the current ordering, and I can see the rationale now. But since you're interested in more arguments against the status quo, I'll try to provide some below. Please feel free to close this issue if you still aren't impelled to make more changes - I'm no longer persuaded that this is worth the reader's time. TL;DR: Bikeshedding, I think there's still an argument for either:
I don't think it works exactly like "the user looks for macOS, then starts searching the arch column, and finishes earlier because their architecture is higher up". I think putting x86_64 at the top for Windows (and Linux) produces an expectation that x86_64 is at the top for macOS. Especially if the user has to scroll down to see the macOS assets, and because "x86_64" is now vertically higher than "Windows" (and the user looks first in the top left).
I'm fine with the ordering of OSes as it is currently. But I'm not sure that the current ordering is consistent with the above rationale: shouldn't we move FreeBSD (and potentially later NetBSD/DragonFlyBSD/OpenBSD, given that they're currently in the same support tier as FreeBSD?) upwards on the basis that BSD support is often an afterthought? Furthermore, if we order OSes by "decreasing OSS afterthoughtness", isn't it unintuitive to order architectures by something akin to "increasing OSS afterthoughtness"?
Is this strictly true? Does "popularity" mean download counts of Zig assets? And if not, popular for whom - all people globally, developers globally, or Zig users in particular? Do we have data to suggest that for that audience, for example:
Would we plan to adjust the ordering in the future as architectures change popularity? And how would we decide where to put |
At the time of writing, the ordering of the Zig 0.11.0 assets (and the Zig master assets, minus FreeBSD) on https://ziglang.org/download/ is:
Questions:
Even if the above asset ordering is supposed to convey something, the ordering isn't currently explained on that page. And I think on a download page people mostly just want to:
I think people are used to assets being ordered alphabetically (for example, on GitHub - see e.g. hyperfine assets). And I find the below ordering to be significantly clearer (I'm also fine with BSDs being at the bottom).
Thoughts?
The text was updated successfully, but these errors were encountered: