Hacker News new | past | comments | ask | show | jobs | submit login
Sourcehut's spartan approach to web design (drewdevault.com)
68 points by kragniz 15 days ago | hide | past | web | favorite | 52 comments



The philosophy described in this article sounds like a naive guess at what makes things usable instead of reading the mountains of actual research on the topic.

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).


>many links don't look like links (because they're black or gray, like the rest of the text)

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.


The naive approach would just be to underline everything. Here are some examples:

https://sr.ht/nK6J.png

https://sr.ht/LLUJ.png

https://sr.ht/MavH.png

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?


>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


maybe use a slightly darker blue and a lighter weight underline that wouldn't contrast quite as much? (i'm not a designer so take that for what it's worth)


That actually looks great.


Author here, thank you for the feedback. I'm a little bit confused by your comments, though. Can you point out a particular page and some specific improvements you think would help? I admit that I'm not a great UX designer, I would appreciate help in refining my approach.


Some things that stand out to me:

- 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.


Thanks for the feedback!

>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?


Re: icons, sorry if I was unclear — I'm not suggesting you add more icons, and I think your opinion in the article is good! I'm saying that it's not obvious to me what the right arrow means specifically, and (IMO) it's common enough that it adds visual clutter. For example, in the tree summary, "browse" and "log" have the right arrow, but the repo URL under "read-only" doesn't, and it's not clear why.


I can reproduce it.

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.


This is totally bizarre. I think it's a Firefox bug. Can you open a ticket on Firefox's bugzilla?



This... is not the Firefox bugzilla.


https://bugzilla.mozilla.org/ > New Bug > Report an issue with a website that I use

Seemed like the most appropriate place to put it.


Fair enough, I didn't realize that was a Mozilla thing.


It's absolutely fine to be a not-great UX designer. I'm also not a great UX designer.

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)

- https://www.smashingmagazine.com/category/ux-design/

- https://designmodo.com/design/ux-design/


>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).

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.


You're right.

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.


While I agree that the line-height could use a little work, don't take any criticisms from the HN crowd to heart.

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.


My criticism was specific: the site is confusing to use. It's hard to find what I want. I gave reasons for this.

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.


[flagged]


Commenting without the presumptive and condescending "calm down" and "decaf" would make your point just as effectively without making you come across as petty and/or unable to argue unemotionally.


Don't worry about it, dude. The GP made a childish and pathetic attempt at bullying, because you dared to question his straw man.

Just ignore the trolls.


I'm not a designer, but:

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.


> In practice, this means that the first thing on any page to grab your attention should be the thing that brought you there. Consider the source file view on git.sr.ht. For reference, here are similar pages on GitHub and Gitlab.

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.


Author here, thanks for sharing your thoughts. Some of this is a product of the newness of the service, rather than a deliberate design choice. The latest commit used to be here, but I removed it for performance reasons and will have to swing around later with a better approach. I haven't had time to implement git blame, though I want to.

>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!


> Editing on the web _is_ a deliberate omission, and I consider this an anti-feature.

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!


I agree with the general sentiment in the thread thus far: the goal of minimalism and focus is a nice one, but at the moment it seems like a bit less sparseness in the design could actually help facilitate that goal, rather than hinder it.

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).


Thanks for the suggestion! I'll pick it up.


Sourcehut's design seems inspired by terminals and line-oriented interfaces more so than early 2000's boxy HTML, so some choices are head-scratchers.

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.


I appreciate the mention and use of breadcrumbs. I think breadcrumbs are one of the most under-rated UI elements. Breadcrumbs make one's position in the navigation hierarchy instantly obvious. It is a shame that they have fallen out of fashion.

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!


My only quibble is that this: "Therefore, it’s important to bring the information you’re there for to the forefront, and minimize distractions. In practice, this means that the first thing on any page to grab your attention should be the thing that brought you there." ...is just as true for any restaurant, store, or even social network webpage as well. But that appears sometimes to be a lost battle, at least for the moment, so I appreciate that there are at least a few corners of the internet still styling things in the way that helps you to use the page, rather than the way that makes it look more impressive in design meetings with executives or clients.


What I don't like with this sentence is, this makes it sound like visual design and efficiency are polar opposites. Good design can be both things.


They're not opposite - a statement like "the first thing on any page to grab your attention should be the thing that brought you there" is a visual design principle.

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.


The philosophy is good, but IMO, the lack of attention to margins and the weight of key content elements is hurting the readability of the designs.


Author here, thanks for the feedback! Can you point out a few key places where this is a problem? I'd like to improve it.


Super late reply, apologies. On this https://man.sr.ht page, giving .event items 1rem padding reduces crowding and makes the elements. Start doing that to the other elements as well, pre, etc. They should all be the same so the gutters are the same.

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.


Offtop: I was wondering for a long time what the heck sr.ht was supposed to mean. Sourcehut is a great move forward regarding naming ;)


OT, but since the author is here: please take a look at your pep8 validation, your imports in the screenshot are all over the place. https://www.python.org/dev/peps/pep-0008/#imports is your friend.


I don't generally agree with PEP-8. I order my imports alphabetically, though generally I put `import x` lines before `from x import y` lines - so this file isn't correct anyway.


This is quite a Chesterton's fence that you are willing to bring down... for what benefit?


I don't think that this line of questioning is on-topic. Feel free to send me an email to discuss it off-thread: sir@cmpwn.com.


Suggestion: add a way to reset the lines anchors. When I click on a line link I can't see any way to reset it, except removing it in the browser's address bar. Maybe making the filename in the breadcrumb clickable could be a good fix (at least, that's the first point where I looked to when I wanted to reset the anchors)



This piece reads as a rationalization for ignoring UX research. I mean, by all means, forget the fads of web design but at least consider the pitfalls of others who've tried (and failed)

It strikes such a weird and defensive tone.


minimal distractions throughout

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.


More like this?

https://sr.ht/BzTP.png


I added 15px when I was tinkering with it, but only to match the horizontal padding. That looks better to me, but I'm definitely not a designer.


Hey, since the author is that responsive to feedback here is mine: Minimal design is great, but my projects work a bit better since I moved away from having that as a goal. I still like to keep it simple, but there are elements not fitting to a minimal design that help to make a page more usable.

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.


Thanks for the feedback!

>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:

https://sr.ht/QhUN.png

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!


Just in case you are not already bored thinking about the design of this ;) My header and font size remarks would result in something like this: https://screenshots.firefox.com/UbXL8WRNN95pfYRm/git.sr.ht (strangely, the shadow looks better in the browser).

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.


The coloured top navigation will not take the focus away, people are too used to navigation areas for that. It will help them however to separate the areas of the page. It's just very strange for you as you are too used to the existing design :)

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.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: