Sourcehut's spartan approach to web design
drewdevault.com
drewdevault.com
For example, it seems like one tactic for "simplicity" or "minimalism" is that nearly all the text is in the same font (same size, same font face, and mostly the same color).
That tells my brain that everything is of equal importance. It's confusing and actually has the opposite effect of "bring the information you’re there for to the forefront" (the goal the article describes).
Many buttons don't look clickable, many links don't look like links (because they're black or gray, like the rest of the text), and the whitespace is a disaster on my screen (line spacing is very condensed, margins are all over the place).
It often seems like half the people here are only happy on original DEC VT-100 terminals, and the other half are only happy if they can transform the web into an Xbox game.
And if all else fails, remind yourself that Craigslist, fleaBay, and PayPal didn't become billion dollar companies by throwing around a bunch of gradients, animated GIFs, or whatever the latest craze is.
Generalizing about the HN community has nothing to do with what I said.
If you specifically think that most text and links should be the same, that buttons and non-buttons should be undistinguished rectangles, and that margins should bump up against the sides of the browser, then please say so and explain why you think these things are better for usability.
The way you wrote and posted this article, there was an implication to me (and I'm guessing to others) that you think this design philosophy is better than what most other people are doing. The article would benefit from some qualifications, e.g.: "I'm still teaching myself UX and aesthetic design," for example. As it is, it comes across as a strong argument from someone who thinks he's an expert (and thinks other people's design decisions are wrong).
In terms of resources, you could take a full-semester class just about typography. Designing UIs is really hard and requires a ton of research. I've spent hundreds of hours over the last 10+ years just reading books and articles, and I still consider myself an amateur.
My strong recommendation is to pay someone who is great at UX and understands how to accommodate people with physical disabilities. Even people who are just 40+ years old (and not disabled in any way) are getting significantly less light coming through their retinas, and it's possible to choose fonts and colors that are difficult for them.
You can find someone who could revamp your stylesheet in a couple of days, and it shouldn't cost you more than $1k-$2k with the right person on Upwork.
You seem to be great at a lot of other things, so why not find someone who has equal depth at UX design? As a generalist myself, I often rely on specialists because it's truly impossible to be great at a large number of fields.
If you want to take a DIY, some good initial resources are:
- https://alistapart.com (note that its design is very functional and minimal, but still uses fonts, colors, and whitespace in a helpful way)
I thought I covered this pretty well in the conclusion: "I’m not a particularly skilled UI designer, so keeping it simple like this also helps to make a reasonably nice UI attainable for an engineer-oriented developer like me."
Outside of that, thank you very much for the resources.
I took "not particularly skilled UI designer" to mean that you're not very good at Photoshop and/or you don't want to learn this skill. It seemed (to me) that you're against the idea that UX design is a complex skill that people should learn before becoming a vocal practitioner of UX design.
I also pay more attention to the difference between "UI" and "UX" than most people do, I'm sure.
Like I said, I think (based on upvotes) that my impression was shared by others, but that certainly doesn't mean it was correct or universal.
- In the header, it looks like you're using the same text style for the inactive navigation links as the helper text ("Logged in as").
- Icons should be used to help clarify things, but most of the icons seem to be just arrows pointing right on links. You can probably omit them!
- In the source tree, I had no idea I could click on the file names until I hovered over them by chance. Blue text alongside black text is a very strong signal that the blue text is a link and the black text is not. (Also note that in the file path at the top, the ancestor directories are blue and clickable while the current directory is black and not). Here is where an icon would be useful: to disambiguate between directories and files.
- Not a visual UX issue, but an accessibility one: for whatever reason, keyboard navigation doesn't work for me in Firefox.
In general, just try to have consistent styles for things, and consistently different styles for different things. Links should look like links, not unclickable text. It's okay if you take a bit of artistic license in specific places (like the main navigation) but things should at least be internally consistent within that place.
>Icons should be used to help clarify things, but most of the icons seem to be just arrows pointing right on links. You can probably omit them!
I discussed my opinion on icons in the article, and I stand by it in this case.
> the source tree, I had no idea I could click on the file names until I hovered over them by chance. Blue text alongside black text is a very strong signal that the blue text is a link and the black text is not. (Also note that in the file path at the top, the ancestor directories are blue and clickable while the current directory is black and not). Here is where an icon would be useful: to disambiguate between directories and files.
Good point. I don't want to add an icon, but I should make filenames underlined or something like that.
>for whatever reason, keyboard navigation doesn't work for me in Firefox.
That's bizarre, it works fine for me. Can anyone else reproduce this?
I'm on Firefox Developer Edition, 66.0b9.
I went to https://meta.sr.ht/ and tried to tab through the site. Here's a gif: https://i.imgur.com/2dQL2C2.gif.
Explanation of gif:
I clicked on the search bar, then clicked on the site, then pressed tab repeatedly.
Seemed like the most appropriate place to put it.
On the file page, the links at the top (git, builds, todo, etc) have a hover effect, the links to ~sircmpwn and git.sr.ht do as well. The links to summary, tree, log, refs and contributors do not. From context, it's easy to guess that they're links, but they should share a hover effect with one of the other links.
I strongly agree with this. I see that mouse-over styling is being used for links. I think links should be always formatted in a way that makes it obvious that they are links. In other words, I like the old-fashioned way of having persistent link underlines, or one could do what Wikipedia and others do and make all links consistently blue text, which seems to work well enough.
Honestly I find this a bit distracting. I'm not opposed to adding underlines in a few places - perhaps anywhere that the links don't convey their nature with the blue color would be a good compromise. What do you think?
I don't find it distracting. It is a bit ugly, though. I like ugly-but-functional UI, but I understand not everyone does.
The advantage is that I can see clearly what is clickable. For example, I did not realise the relative timestamps ("a day ago", "an hour ago") were links until I saw your altered screenshots with the underlines.
I think any of these would make it clear enough:
- All links blue
- All links underlined
- All non-blue links underlined
I don't even consider this a good example of good UI/UX. Sourcehut's page gives way less information and has less QOL tools like straight edit or dedicated git blame. I have to dive into submenus and close the file to get last commit information.
On example : making visual note of the currently selected tab, "Tree", I then click on "Log" to get this information. I then instinctively click on "Tree" again to come back, only to be greeted by the whole file tree. I have to manually press the browser's back button twice.
>straight edit
Editing on the web _is_ a deliberate omission, and I consider this an anti-feature. Web edited commits on GitHub are notorious for failing to compile or pass tests, disregarding the style guide, etc - and raising the barrier to entry that little bit more helps to filter out this kind of noise.
>On example : making visual note of the currently selected tab, "Tree", I then click on "Log" to get this information. I then instinctively click on "Tree" again to come back, only to be greeted by the whole file tree. I have to manually press the browser's back button twice.
Hmm, this is a good point. I filed a ticket about this:
https://todo.sr.ht/~sircmpwn/git.sr.ht/188
Thanks for the feedback!
I prefer liberty of choice rather than such opinionated decisions, but that's not up to me. There's a rationale and I respect this. It's just convenience: I've honestly just been happy to be able to update some of my project's READMEs of wiki on my phone. As for failing tests or disregarding style guide, IMHO it's more up to the project to enforce these things rather than to my code hosting platform to limit possibilities. Again, this is largely preference.
> Hmm, this is a good point. I filed a ticket about this:
Will happily follow this!
Sir_Cmpwn, if you're looking to up your UX game while keeping things stripped down I would recommend taking a look at Josef Müller Brockmann's book Grid Systems. It's written in the context of print layouts, but many of the principles can be extrapolated to web design. It covers some excellent techniques for managing information density and prominence with base visual elements such as a well composed grid and some simple variations on fonts (size and weight).
The lack of visible bounding boxes or ("old-style") underlining around the core navigation links draws inspiration both tab-oriented keyboard navigation and very modern, ~201x UI design, but lifts only their outward look without incorporating strengths from each: it neither has strong indicators of a series of menu items that can be stepped through (like a right-facing triangle to the left of the menu item's text), nor does it evoke the Metro-style UI, where UX-meaningful text is king on a sparse field. Underlining each link in the top bar would immediately communicate that many of the words are clickable but not all; as would the use of background shading and color to set the static top bar apart from the rest of the page content. Or even just a 1px bottom border.
Similarly, visual suggestion of tabs for 'summary', 'tree', etc, is not very convincing in a browser. Desaturated borders around the inactive tabs would clearly communicate that there's a tabbed interface here. Bolding of the text of the active tab would reinforce that further.
EDIT: When I think about minimalism on the web, I'm inspired by the box model and by occasionally-visible borders, which help translate the tree structure of the page into a coherent interface. Borders have gone out of fashion in mainstream design, and so has the use of text decoration for links, so it's harder now to distinguish between interactive and static elements in an interface. Sourcehut's 'spartan' take on this misses an opportunity to clarify a distinction that's been lost in other schools of design.
Also, +1 for not using icons. Instead of having a link with some undecipherable symbol that requires a tool-tip to translate it for the user, just put a damn word there!
The problem with design as practiced on the web today isn't about methodologies as much as it's about goals. The design choices maximizing value provided for end users are polar opposites of the "industry standard", the ones your average startup runs with.
Seeing the modern UX practices defended and rationalized brings to my mind the image of a 13 year old asking parents for a computer to use "for education" - yes, a computer can be a powerful tool for learning, but you and I both know that's not what you will really be doing with it.
Setting .btn padding to .5rem .75rem balances the hight of the type vs. the edge of the button a bit, making the buttons both more 'substantial' and moving the harsh btn edge away from the type, which makes it easier to read.
Add margin-top 2.5rem to your h* elements to space your content out.
It strikes such a weird and defensive tone.
I find the compact design incredibly distracting. If elements like the .header-extension bar had more vertical padding I'd find it much easier to scan for important details.
For example, it should be useful to move the top navigation bar into a big colored menu bar, like on github or on HN. That way the central content element of the page is no longer just separated by whitespace or placement from the navigation. I found that to be incredibly useful, I discovered that pattern for Pipes when as an in-joke re-using the Yahoo pure CSS framework (https://www.pipes.digital/, I guess having a look makes it clearer) and then had to adopt that pattern for my other projects. Also a place where using a drop shadow to put the navigation visually on a different height level can work out well.
There recently was a discussion of two github redesigns proposals on HN. The first redesign removed parts of the file area (at first, in a later step completely iirc?) from the summary page. Sourcehut is missing that area as well and I think it's a mistake, as was convincingly argued in the comments there: A part of what made github great compared to other code hosting pages was to not just show a list of commits or meta information on the central project page, but to have the files tree as the central element. It helps so much to give a clear understanding to visitors about what actually is in the repo. Imho the summary tab should show the files in the repo, as Github does.
A useful rule for links is that all links should be colored as long as they are not in a navigation area, those are understood without needing that. Ofc even good designs don't always do that, the links to commits in the file area of github for example, which is good as it puts focus on the file links instead. And sometimes links are buttons and that's usually hard to put into rules as well.
But with regards to links: It's a bit strange that the top navigation has a highlight on link hover, the second one does not (summary, tree, log, ...)
Your css applies `font-size: .9rem;`, it shouldn't. That's often ignored and who am I to preach design, but I have the absolute conviction that body text should not be messed with. Trust in the browser, keep it as is, just make headings bigger and detail elements a little bit smaller, the latter only when absolutely needed. Fits to your design philosophy anyway.
"Design for Hackers" is a nice book that could be added to the book recommendation you got already, at the very least it is nice to read.
PS: It might be that even for a project as big as this a CSS framework like Skeleton could be useful to get the basics of the design in a better shape (without saying it's awful now, it evidently works already), though of course there would still be lots of custom design work to be done.
>For example, it should be useful to move the top navigation bar into a big colored menu bar, like on github or on HN.
I tried this but I really dislike it:
It's just sooo distracting to me, and it plays up sourcehut as being more important to the visitor than the content they came for, imo.
>Imho the summary tab should show the files in the repo, as Github does
I disagree here as well, just as a matter of taste.
>A useful rule for links is that all links should be colored as long as they are not in a navigation area
>It's a bit strange that the top navigation has a highlight on link hover, the second one does not (summary, tree, log, ...)
Aye, I'm going to revisit this.
>Your css applies `font-size: .9rem;`, it shouldn't. That's often ignored and who am I to preach design, but I have the absolute conviction that body text should not be messed with. Trust in the browser, keep it as is, just make headings bigger and detail elements a little bit smaller, the latter only when absolutely needed. Fits to your design philosophy anyway.
>Your css applies `font-size: .9rem;`, it shouldn't. That's often ignored and who am I to preach design, but I have the absolute conviction that body text should not be messed with. Trust in the browser, keep it as is, just make headings bigger and detail elements a little bit smaller, the latter only when absolutely needed. Fits to your design philosophy anyway.
I'll think about this.
Thanks for sharing your thoughts!
However, the contrast between the inactive menu elements and the background might be a bit low. And sure, there is a visual branding part in play here as well that you might want to think about a bit longer. Something else than a black bar could work better in that regard, maybe white with a small border and a shadow below? Something a bit more in line with the current design will ease the transition.
But I think it absolutely works a lot better than the current whitespacy solution. Maybe ask a few people more for their impression? I'd be very surprised if it does not work better for most.
That's of course not completely done nor a fix-all. There might be an alignment issue with the navbar entries and the sourcehut logo? It also made me think about the file header (git.sr.ht/gitsrht/service.py -rw-r--r-- 3.0 KiB View raw), that one needs a bit of structure, and that darker grey next to the different line number grey looks strange.
body font size removed, but I kept making the code font size smaller (code normally is smaller still) and reduced the line height there to 1.2. h2 font size reduced as well, but whether that's the right size depends on the ratio chosen for the other hs.
One remark more:
> > Imho the summary tab should show the files in the repo, as Github does
> I disagree here as well, just as a matter of taste.
This shouldn't be a matter of taste. It's a matter of what helps users gets the job done better. It's a question to observe during a user test.