
Sourcehut's spartan approach to web design - kragniz
https://drewdevault.com/2019/03/04/sourcehut-design.html
======
smt88
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).

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

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

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

~~~
isthisnagee
I can reproduce it.

I'm on Firefox Developer Edition, 66.0b9.

I went to [https://meta.sr.ht/](https://meta.sr.ht/) and tried to tab through
the site. Here's a gif:
[https://i.imgur.com/2dQL2C2.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.

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

~~~
isthisnagee
Done: [https://webcompat.com/issues/27204](https://webcompat.com/issues/27204)

~~~
Sir_Cmpwn
This... is not the Firefox bugzilla.

~~~
isthisnagee
[https://bugzilla.mozilla.org/](https://bugzilla.mozilla.org/) > New Bug >
Report an issue with a website that I use

Seemed like the most appropriate place to put it.

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

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

~~~
Sir_Cmpwn
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](https://todo.sr.ht/~sircmpwn/git.sr.ht/188)

Thanks for the feedback!

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

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

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

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

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

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

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

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

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

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

~~~
rrhyne
Super late reply, apologies. On this [https://man.sr.ht](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.

------
krzkaczor
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 ;)

------
rglullis
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](https://www.python.org/dev/peps/pep-0008/#imports)
is your friend.

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

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

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

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

~~~
Sir_Cmpwn
[https://todo.sr.ht/~sircmpwn/git.sr.ht/189](https://todo.sr.ht/~sircmpwn/git.sr.ht/189)

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

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

~~~
Sir_Cmpwn
More like this?

[https://sr.ht/BzTP.png](https://sr.ht/BzTP.png)

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

------
onli
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/](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.

~~~
Sir_Cmpwn
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](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!

~~~
onli
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](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.

