Hi,

I wanted to know if some people were interested working
on a refactoring of sourcehut design and frontend code with me. 

As for the reasons:

1. Design

From a design perspective sourcehut already has an identity as a
kind of "plain text website", but it's pretty barebones and sort of just
a byproduct of using bootstrap. I wonder if we could make
something feeling more intentional, with a more unique identity.

But to be clear: I'm not suggesting we turn sourcehut design into
something totally different from a user experience point of view,
or that we follow the current tech websites design trends.

2. Accessibility issues

The current design has some accessibility problems, even if not
many. Design wise, readability is bad in some pages like man.sr.ht
or repository pages, mostly because of poor spacing, grouping and
font sizes. There's also a few errors there and there, such as links
looking like buttons, some links looking like text, or wrong HTML 
tags used for their looks instead of semantics.

Nothing terrible, but rethinking all this would allow to address those
issues and create a few cool things like themes for high contrast or
dyslexia, and options like more spacing between elements or RTL
reading.

3. Bootstrap 

Using bootstrap for a project like sourcehut makes a ton of sense
since it's so battle proofed you can basically throw it there and it
works,

Still, I suggest that with the design should come stylesheets that
doesn't require it. It would make for less code and allow to ask
questions like "what component do you need" and design them
accordingly instead of taking the default.

Also bootstrap is hard to restyle.

---

Let me know what you think.

Thomas

On Fri, Dec 17, 2021 at 01:45:48PM +0100, Thomasorus wrote:
> Using bootstrap for a project like sourcehut makes a ton of sense
> since it's so battle proofed you can basically throw it there and it
> works,

That bootstrap might be https://getbootstrap.com/

Qoute from that website URL

   Build fast, responsive sites with Bootstrap

   Quickly design and customize responsive mobile-first sites with
   Bootstrap, the world’s most popular front-end open source toolkit,
   featuring Sass variables and mixins, responsive grid system, extensive
   prebuilt components, and powerful JavaScript plugins.


I have no idea if that bootstrap can shine without JavaScript,
but I hope that sourcehut remains JavaScript free.

Qoute from https://sourcehut.org/

   All features work without JavaScript



Regards
Geert Stappers

> 1. Design

I for one am a fan of Sourcehut's general design language as a clean,
distraction-free environment. More polish on rough edges could be nice,
but in general I think it's in a good place.

> 2. Accessibility issues

One of the noticeable issues I've found is the [Pygments style][1] that
Sourcehut uses is a hodgepodge of colors without a strong design sense
behind them. Replacing them with a well-authored style like [what
Pygments provides][2] would be a nice improvement to ensure consistency
and legibility.

> 3. Bootstrap

I believe Drew has a custom-built CSS framework in progress at
[~/sircmpwn/antiweb][3], though it's not finished. I assume it's
intended to replace Bootstrap for Sourcehut at some point?

[1]: https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/item/srht/scss/highlight.scss
[2]: https://pygments.org/styles/
[3]: https://git.sr.ht/~sircmpwn/antiweb

I think you misunderstood what Thomasorus means. SourceHut already uses bootstrap:
https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/item/.gitmodules

I believe the original message was that Bootstrap is a part of the problem
(being hard to restyle etc)

> 1. Design
> 
>>From a design perspective sourcehut already has an identity as a
> kind of "plain text website", but it's pretty barebones and sort of just
> a byproduct of using bootstrap. I wonder if we could make
> something feeling more intentional, with a more unique identity.
> 
> But to be clear: I'm not suggesting we turn sourcehut design into
> something totally different from a user experience point of view,
> or that we follow the current tech websites design trends.

I am doubtful drew will approve of this, but it's impossible to judge 
without mockups. What changes to the style are you suggesting?

> 2. Accessibility issues
> 
> The current design has some accessibility problems, even if not
> many. Design wise, readability is bad in some pages like man.sr.ht
> or repository pages, mostly because of poor spacing, grouping and
> font sizes. There's also a few errors there and there, such as links
> looking like buttons, some links looking like text, or wrong HTML
> tags used for their looks instead of semantics.

I'm sure drew would be open to patches fixing this!

-----------------

- Drew has a framework: https://git.sr.ht/~sircmpwn/antiweb
- I am interested in the idea of theme's, alps has support so I believe 
the sourcehut team is open to it too! I think the first effort should be 
done in this regard, design changes never make people very happy, more 
power to the user!

>> 3. Bootstrap
>
>I believe Drew has a custom-built CSS framework in progress at
>[~/sircmpwn/antiweb][3], though it's not finished. I assume it's
>intended to replace Bootstrap for Sourcehut at some point?
>
>[3]: https://git.sr.ht/~sircmpwn/antiweb

I'm really interested in this project, and considering testing it for
a site I'm developing: https://auslan.directory/

So if there's interest in expanding antiweb, I'm in!

-- 
Samuel Walladge
https://swalladge.net | https://useplaintext.email/

I think that it would also be an improvement to allow people who host
a sourcehut instance to customize the CSS or do some light templating
modifications in an easy way.

Right now, such customizations would need the user of to provide a
modified copy of the frontend, which is arguably useless/overkill. I
may be wrong on the licensing situation, though, I didn’t really
check.

Working on a new frontend with such details in mind would be
appreciated I think.

I would be pleased to see more investment into antiweb. Supporting
NetSurf is something I have wanted to do with the frontend for a while.
There are many users of niche operating systems for whom SourceHut is
the only viable choice because of lack of availability of mainstream
browsers.

Hey folks, sorry for the duplicate thread, I'm still learning.
Reposting my answers from the other thread + new ones.

> I have no idea if that bootstrap can shine without JavaScript,
> but I hope that sourcehut remains JavaScript free.

Bootstrap is normally used with jquery/JavaScript but it seems it
was removed by Drew when making Sourcehut. My proposal 
isn't to change how sourcehut works, but to give it a coat of 
paint.

> More polish on rough edges could be nice, but in general I 
> think it's in a good place.

I feel the same. It's more about polishing and giving alternatives.
Also it could be a way to organize and really defined the visual
language of sourcehut for people who want to use it or
expand it.

And technically, a way to organize code.

> Replacing them with a well-authored style like [what
> Pygments provides][2] would be a nice improvement to ensure 
> consistency and legibility.

That probably could be its own project since it's probably more
technical than design.

> I am doubtful drew will approve of this, but it's impossible to judge 
> without mockups. What changes to the style are you suggesting?

On the top of my mind:

- Try to create a visual identity to Sourcehut. Outside of the logo
there is almost nothing that characterize the project.
- A more intentional and readable color palette that would allow
making themes.
- More coherent spacings to group and separate things so it's
more easy to scan information. Should be themable too, to have
something like a compact mode.
- More coherent font sizes and typography, again to help with
readability.
- Overall make it more polished and unique in its own way. 

> Incidentally, I'm surprised there's any mention of JavaScript here.  In 
> these days of CSS -- indeed CSS 2! -- there's surely little need for 
> that in a webpage design.  Or am I missing something?

No you don' t need JS for a website like Sourcehut, mostly because
Drew designed the whole thing to work without it, using pages
instead of lazy loading things for example.

A good example is the tabs in a repo: modern frontend would use
JS, but Drew used pages.

> Supporting NetSurf is something I have wanted to do with the 
> frontend for a while.

I think that' s not incompatible with doing a more modern take on
the current design of sourcehut.

Using progressive enhancement techniques could work, and it's
actually already working. If you go to man.sr.ht in netsurf you can see
that flexbox is not working and defaults to block. Even things like 
custom properties can have fallbacks.

My question then Drew is: do you have strong feelings about
how your started and organized antiweb? Or are you open to
suggestions about how to do it? I've looked a bit inside the code
and it seems very opinionated. 

And also, since you are the creator of this website, how do you feel
about talking design and changing it?

Thanks everyone for your feedback.

On Fri Dec 17, 2021 at 7:45 PM CET, Thomasorus wrote:
> My question then Drew is: do you have strong feelings about
> how your started and organized antiweb? Or are you open to
> suggestions about how to do it? I've looked a bit inside the code
> and it seems very opinionated.

How so?

I am open to suggestions, yes.

> And also, since you are the creator of this website, how do you feel
> about talking design and changing it?

I think the conservative approach works, and any improvements will need
to be similarly conservative.

> How so?
> I am open to suggestions, yes.

Just by looking quickly I think there are some ways in 
how you approached it that can be detrimental to the 
project long term:

- Heavy use of sass variables to the point where it's 
sometimes hard to read when you're new. Sass is still 
important and useful but I've seen a lof of sass codebases 
that could only be understood by their creators because
 of vars, extends, custom functions, etc. I recommend a 
more lean approach so newcomers can join in.

- Re-declaration of vars at the top of the files and also 
some hard coded values there and there. Those are 
design tokens and should be standardized for the 
whole frontend. 

- A mix of declarations of html elements and classes 
in files, and sometimes both with things like element.class 
that are not needed if you have a clear naming convention.

Taking a step back and using a down to earth code 
organization like CUBE CSS would benefit the project 
by focusing first on design tokens, then utility classes, 
then containers, then components. https://cube.fyi/

- Design tokens can be customized by anyone which
allows making themes more easily for clients and users.
- Utility classes generated from those design tokens makes
changing a thing or two easier than creating a class or a
chan of declarations like .tab > li > a.
- Containers can be reused in several situations and
we can control they degradation for older browsers.
- Then, when there is a super specific component, we can
start to tackle it, but at this point most of the design
is already done.

That' s how I would approach it.

This is good feedback. Can you start by preparing a patch for antiweb
(or maybe even in a separate tree) which demonstrates some of the basics
of your preferred approach? Then we can start from more robust
foundations.

On 21/12/17 07:26, Drew DeVault wrote:
> I would be pleased to see more investment into antiweb. Supporting
> NetSurf is something I have wanted to do with the frontend for a while.
> There are many users of niche operating systems for whom SourceHut is
> the only viable choice because of lack of availability of mainstream
> browsers.

There are also users (like myself) who deliberately choose to avoid JavaScript
and "frameworks". The less of the "modern Web", the better. The simplicity of
sourcehut web interface is one of the major reasons why I'm using it as a
primary git host. If everything was "Github/Gitlab-ified" I would search for
alternatives.

> Can you start by preparing a patch for antiweb
> (or maybe even in a separate tree) which 
> demonstrates some of the basics of your preferred 
> approach? Then we can start from more robust
> foundations.

No problem, I'll try preparing something during the
holiday season. Might reproduce a page from
sourcehut to show how the code is organized so
everyone can get a better idea.

I'll give you an update in this mailing list once it's
done.

On Fri, 2021-12-17 at 19:48 +0100, Drew DeVault wrote:
> On Fri Dec 17, 2021 at 7:45 PM CET, Thomasorus wrote:
> > My question then Drew is: do you have strong feelings about
> > how your started and organized antiweb? Or are you open to
> > suggestions about how to do it? I've looked a bit inside the code
> > and it seems very opinionated.
> 
> I am open to suggestions, yes.

I think the accessibility of the site could be improved by reducing the
number of classes. I know this does not directly affect the
accessibility, but relying on classes leads to situations like the
following.[1]

> <div class="header-tabbed">
> 	<div class="container">
> 		<h2>
> 			<a href="/~sircmpwn/">~sircmpwn</a>/<wbr>cstyle
> 		</h2>
> 		<ul class="nav nav-tabs">
> 			<!-- [...] -->
> 		</ul>
> 	</div>
> </div>

This is not as accessible as it could be; this parent div clearly has
semantic value, but divs are not semantic elements. Instead, this should
be replaced with the following.

> <header>
> 	<div>
> 		<!-- [...] -->
> 		<nav>
> 			<ul>
> 				<!-- [...] -->
> 			</ul>
> 		</nav>
> 	</div>
> </header>

Not using as many classes improves the accessibility here because it
forces us to use semantic elements. Specifically, the div with a
semantic class has been replaced by a header. The ul has also been put
inside a nav because it previously had a class indicating that it was
navigation. Now, the browser has a better idea of the page's structure.
(Also, the div's class has been removed because a div is, by definition,
a container without semantic value. This part is mostly personal style.)
None of this prevents the page's styling, because we can just use css-
selectors instead of classes. Example:

> div {
> 	/* previous '.container' styling */
> }
> 
> header {
> 	/* previous '.header-tabbed' styling */
> }
> 
> 
> header nav {
> 	/* previous '.nav-tabs' styling */
> }
> 
> // or
> header nav ul {
> 	/* previous '.nav-tabs' styling */
> }

This example is simple, but the concepts it demonstrates apply
regardless of complexity.

Not relying on classes improves page accessibility by requiring the use
of semantic HTML elements. It also reduces the CSS complexity because
one immediately knows which elements a given portion of CSS applies to.

[1]: https://sr.ht/~sircmpwn/cstyle/

Cheers,
-- 
DJ Chase
They, Them, Theirs

> There are also users (like myself) who deliberately choose to avoid JavaScript
> and "frameworks". The less of the "modern Web", the better. The simplicity of
> sourcehut web interface is one of the major reasons why I'm using it as a
> primary git host.

Hear, hear!

> If everything was "Github/Gitlab-ified" I would search for
> alternatives
Thankfully I could just begin hosting my own instance should it ever 
happen (although it certainly won't under drew's guidance)

On 21-12-18 00:07:31, Thomasorus wrote:
> ...Might reproduce a page from
> sourcehut to show how the code is organized so
> everyone can get a better idea.
> 
> I'll give you an update in this mailing list once it's
> done.

Even if this doesn't pan out, I would like to thank you for your effort.

/Marius

Hello everyone, thanks for your patience. 

I've spent a few evenings recreating sourcehut 
git repository page using the CUBE CSS
methodology. This is a technical demo and not
a design proposal. To get a better understanding, 
please read the CUBE website before
reading the SCSS files (starting with index).

You can see the code here:
https://git.sr.ht/~thomasorus/sourcehut-cubed

In the README, you will find links to different versions
I created. What I am particularly happy about is how
older browsers are supported. I tested in netsurf and
it's working better than the version in production.

All pages are responsive in both new and old
browsers, without using a single media query. 

Let me know what you think.

Thomas

Quoth Thomasorus <oss@thomasorus.com>:
> Let me know what you think.

It’s quite a good recreation of the original design. I’m not a fan of
the large variation, it’s less efficient and readable than the original
spacing.

While we are discussing the matter: what about font preferences? I think
that setting the font-family to sans-serif and monospace would lead to a
random direction but may allow better accessibility for dyslexic persons
for example. Or even allow people to set the programming font they are
used to in their browser preference. Just chiming in.

Quoth Romain Hervier:
>While we are discussing the matter: what about font preferences? I think
>that setting the font-family to sans-serif and monospace would lead to a
>random direction but may allow better accessibility for dyslexic persons
>for example. Or even allow people to set the programming font they are
>used to in their browser preference. Just chiming in.

I never understood why there are long lists of type faces that might 
be installed in the CSS; is there any reason for that?  I’d rather use 
the type face I configured as default throughout my system than one 
the designer thought was common or something.

Regarding accessibility: In the worst case, you can always override 
the site’s settings.

So yeah, I’m in favor of using generic names only.

-- 
Humm

Quoth Humm <hummsmith42@gmail.com>:
> I never understood why there are long lists of type faces that might be
> installed in the CSS; is there any reason for that?  I’d rather use the type
> face I configured as default throughout my system than one the designer
> thought was common or something.

They have their use for general public websites and whatnot (defining a
coherent fallback stategy to have a consistent layout, or if an hosted
font doesn’t load), but I’m not so sure about their usage on a technical
websites like sr.ht :^)

Nice work! I have some feedback, which I will dump into this email in an
unorganized fashion.

I like the careful use of scss features to apply consistent and
configurable design rules throughout.

Nice work getting it to look good on Netsurf.

Typography needs work. Headings are too big and we probably want to
bring the underlines back. The margins are uncomfortable, such as in the
code sample. The font needs to be set back to the browser default, the
user can configure it differently if they so desire.

I think I understand what you're trying to accomplish with the "big"
design, but it needs a *lot* of work. If want to provide a better touch
interface, we need to accomplish it while still being information dense.
If possible, we should try to only increase margins and sizes around
objects which are interactive, like buttons and tabs. Perhaps we should
do this based on the @media query for prefers touch interaction? We
might also want to choose the margins not arbitrarily, but based on
desired traits with respect to real-world measurements, like ensuring
that interactive objects have some number of millimeters of
interactivity and some number of millimeters of margin between one
another.

The default theme also needs to provide a light and dark variant (based
on a similar design to the present-day sourcehut dark theme) which is
enabled via @media prefers-color-scheme. Also, if we are to have
entirely separate, swappable themes, we need to justify it a lot better
IMO. That adds a lot of complexity and "the same theme but with an
orange motif" is insufficient justification for that complexity. I'd
like to see an example theme which really overhauls the appearance of
the UI into a different, but equally compelling design.

I'm also not sure I love the gorko dependency. Ideally this system would
not involve NPM. Can we incorporate the important parts of it into our
framework directly?

There's also some more work to be done on responsiveness.

On the whole I suspect that you know what needs to be improved and
where. I would be interested in seeing this sample page being developed
to completion, to the point where it could be seriously pitched as a
replacement for an equivalent SourceHut page.

Hey folks,

> It’s quite a good recreation of the original design. I’m not a fan of
> the large variation, it’s less efficient and readable than the original
> spacing.

I actually find the larger version way more readable, but way less
balanced from a design standpoint. It doesn't feel like good design but
things are less cluttered, which allows for an easier scan (see below).

> While we are discussing the matter: what about font preferences? I think
> that setting the font-family to sans-serif and monospace would lead to a
> random direction but may allow better accessibility for dyslexic persons
> for example. Or even allow people to set the programming font they are
> used to in their browser preference. Just chiming in.

The current fonts are already sans-serif and monospace fonts, that are on
your system, so this part is already done.

Allowing to use custom fonts would be a very different project in itself as 
each user would need to use the cascade to overwrite the default font
family entries. That could be done with an input/textarea in your meta
section, but I have no idea of the technical aspects of this. Drew can maybe
tell you a bit more about this than I do.

For dyslexia according to this study:
http://dyslexiahelp.umich.edu/sites/default/files/good_fonts_for_dyslexia_study.pdf
Helvetica, Courrier, Verdana and CMU are better for dyslexia. Sans serif, 
monospaced, and roman fonts are better so in this aspect the current
Sourcehut is already doing the right job.

But thinking that swapping a font will solve the issue is not realistic. You
need to tackle things like letter and word spacing, line height, font weight,
colors, and overall clutter. 

You can read more about this here:
https://www.smashingmagazine.com/2021/11/dyslexia-friendly-mode-website/

That's one of the reasons why tokenizing design elements can help. It would
take way less work to add this kind of mode.

> Typography needs work. Headings are too big and we probably want to
> bring the underlines back. The margins are uncomfortable, such as in the
> code sample. The font needs to be set back to the browser default, the
> user can configure it differently if they so desire.

My goal wasn't to 100% reproduce the design but just give an overview of
the type of code organization we could take. Since everything is tokenized,
there are small differences that will happen there and there when an 
in-between size or spacing isn't in the scale compared to the existing
website.

> I think I understand what you're trying to accomplish with the "big"
> design, but it needs a *lot* of work. 

Yes, it needs a lot of work and as I said before, this big design is more
a proof of concept on how we could handle new designs technically than
a graphic proposal.

> If want to provide a better touch interface, we need to accomplish it 
> while still being information dense.
> If possible, we should try to only increase margins and sizes around
> objects which are interactive, like buttons and tabs. Perhaps we should
> do this based on the @media query for prefers touch interaction? 

Information density is important, but please don't assume that only people
using their fingers need larger interactive elements.  Touch mediaqueries 
exists, but increasing the size of interactive elements just for touch devices 
is not the good way of looking at this. If you check the WCAG guidelines, 
you'll see that interactive elements, independently of the device, should 
be at least 44x44px, even when using a mouse.

That's because you can have mobility or fine motor control impairments, 
or have tremors. Some users may have specific custom made input devices, 
or use a bigger cursors.

> We might also want to choose the margins not arbitrarily, but based on
> desired traits with respect to real-world measurements, like ensuring
> that interactive objects have some number of millimeters of
> interactivity and some number of millimeters of margin between one
> another.

The better way to do this is to have a scale and rules. How much space is
allowed between elements of the same group? How much to separated 
groups?

That's the kind of things design tokens are good for. This way you just...
apply the rules. In a way it's a very good way for developers to look at
design (design system).


> Also, if we are to have entirely separate, swappable themes, we need 
> to justify it a lot better IMO. That adds a lot of complexity and "the same 
> theme but with an orange motif" is insufficient justification for that complexity. 
> I'd like to see an example theme which really overhauls the appearance of
> the UI into a different, but equally compelling design.

If you take the time to separate most things ahead, you'll see that theme
are way easier to add than you might think. I agree there should be better
ideas than swapping colors. 

Some quick ideas:
- Compact/classic theme (the actual design)
- Normal (actual design with WCAG fixes, that will make the elements larger)
- Large (things like the dyslexia changes discusses earlier)
- High contrast

And why not...
- black and white apple 1 style
- personal computers themes
- ultra minimalist .txt style
- christmas theme...?!

> I'm also not sure I love the gorko dependency. Ideally this system would
> not involve NPM. Can we incorporate the important parts of it into our
> framework directly?

In itself Gorko is sass files. I'malmost  sure we can either extract it from its npm
package or find another tool making the same. We'll need to work on
the stack either way.


> On the whole I suspect that you know what needs to be improved and
> where. I would be interested in seeing this sample page being developed
> to completion, to the point where it could be seriously pitched as a
> replacement for an equivalent SourceHut page.

I've seen in the mailing list that people are a little stressed about change.
To be perfectly honest, one of my goals is to make sourcehut more 
inclusive, welcoming and personal through its design. For myself, because
I have a hard time using it in its current state, but also for others. 

But the thing with accessibility and designing inclusive websites is, you
can't know how and by who your website will be used. You can't
assume everyone has your needs, and you can't assume other people's
needs. So in the end, the redesign might impact everyone.

If we decided to make sourcehut inclusive, some things would have to change for
sure and it would probably make sourcehut "less sourcehut" in its design if
we do nothing to compensate for it. We would probably have to change 
colors, margins, enlarge buttons, add a few lines of JavaScript for user 
experience features (like toggling different themes, using accordions).

Of course everything would still work without JavaScript, because I'd use
progressive enhancement techniques. And being inclusive means keeping
the current design as an option for those it works for. But be conscious that 
most changes in my proposals may not directly for you, the current users.

If you are OK with this, I'll take the time to experiment and propose some
design approaches.

Thanks for your feedback.

Thomas

Quoth Thomasorus <oss@thomasorus.com>:
> The current fonts are already sans-serif and monospace fonts, that are on
> your system, so this part is already done.

My bad, the sans-serif is indeed the only body font defined on sr.ht,
but it’s not the case for the monospaced font declaration.
 
> Allowing to use custom fonts would be a very different project in itself as 
> each user would need to use the cascade to overwrite the default font
> family entries. That could be done with an input/textarea in your meta
> section, but I have no idea of the technical aspects of this. Drew can maybe
> tell you a bit more about this than I do.

Oh yeah, I know. That’s why I’m suggesting to only use bare sans-serif
and monospace as font declaration. Such settings are at the user’s
discretion (any serious web browser allow to define every default
fonts). But since the body font is indeed defined as sans-serif rather
than a specific font stack, any end-user can already enjoy sr.ht with a
easier to read font like OpenDyslexic :)

> But thinking that swapping a font will solve the issue is not realistic. You
> need to tackle things like letter and word spacing, line height, font weight,
> colors, and overall clutter. 

sr.ht is not that text-heavy, the longest piece of texts must the
READMEs and occasional manpages. Plus, we can’t be sure of the result
if the body font is declared as sans-serif. Spacing between elements is
much more important. I think that sourcehut is doing a pretty good job
in prose-heavy layouts, a bit less on interfacey pages (but they are
mostly handwritten html pages like man.sr.ht/index.html rather than core
components of the sourcehut style). There are some colors problems as
well (#f8f9fa being on the fringe of subtile/frustrating, I added a 1px
border around those in my custom css)

> Information density is important, but please don't assume that only people
> using their fingers need larger interactive elements.
> That's because you can have mobility or fine motor control impairments, 
> or have tremors. Some users may have specific custom made input devices, 
> or use a bigger cursors.

I agree, if only web browsers had inclusive feature flags for those
cases, it would make all of this easier for users and designers :(

I think we can get a lot out of this discussion for users who need
more accessible interfaces, and for experts/technical users who want
efficient interfaces.

> add a few lines of JavaScript for use > experience features (like toggling different themes, using accordions).

Theme toggles don't require javascript, it's the server's choice what to 
send to the client, of course.

```py
if usersettings.colorscheme == "dark"
	res = "dark.css"
```

Same goes for accordions, I have a working CSS only implementation, 
although I have not tested it outside of firefox. Getting it working 
everywhere would be an extra challenge, although dare I say possible.

It's really amazing what can be done without javascript!

I'd like to note that the widely spaced version currently looks quite wonky on mobile: [1] vs [2].

[1]: https://ttm.sh/ea6.png
[2]: https://ttm.sh/eaV.png


-------- Original Message --------
From: Thomasorus <oss@thomasorus.com>
Sent: December 21, 2021 11:34:09 PM UTC
To: DJ Chase <u9000@posteo.mx>, Drew DeVault <sir@cmpwn.com>, Romain Hervier <romain@sansfontieres.com>, Samuel Walladge <samuel@swalladge.net>, Noelle Leigh <noelle_leigh@fastmail.com>, Norman Gray <gray@nxg.name>, Marius Orcsik <marius@federated.id>
Cc: ~sircmpwn/sr.ht-discuss@lists.sr.ht
Subject: Re: Improving Sourcehut design, accessibility and frontend code

Hello everyone, thanks for your patience. 

I've spent a few evenings recreating sourcehut 
git repository page using the CUBE CSS
methodology. This is a technical demo and not
a design proposal. To get a better understanding, 
please read the CUBE website before
reading the SCSS files (starting with index).

You can see the code here:
https://git.sr.ht/~thomasorus/sourcehut-cubed

In the README, you will find links to different versions
I created. What I am particularly happy about is how
older browsers are supported. I tested in netsurf and
it's working better than the version in production.

All pages are responsive in both new and old
browsers, without using a single media query. 

Let me know what you think.

Thomas

---
Sebastian LaVine | https://smlavine.com

Quoth Thomasorus:
>- ultra minimalist .txt style

We have that, it’s called “don’t use CSS”.  Just wanna mention at 
least once in this thread that most stuff needs to continue to work 
well not only without JavaScript but also without CSS.

>I've seen in the mailing list that people are a little stressed about change.
>To be perfectly honest, one of my goals is to make sourcehut more
>inclusive, welcoming and personal through its design. For myself, because
>I have a hard time using it in its current state, but also for others.

As long as it doesn’t annoy me with distracting styling for some 
self-imposed need for visual identity and continues to work fine in 
mothra, I’m all for such change.  I don’t know what exactly you mean 
by but am a little concerned about the “welcoming and personal”.

-- 
Humm

On Wed Dec 22, 2021 at 10:16 PM CET, Thomasorus wrote:
> The current fonts are already sans-serif and monospace fonts, that are
> on your system, so this part is already done.
>
> Allowing to use custom fonts would be a very different project in
> itself as each user would need to use the cascade to overwrite the
> default font family entries. That could be done with an input/textarea
> in your meta section, but I have no idea of the technical aspects of
> this. Drew can maybe tell you a bit more about this than I do.

Users can configure custom fonts with their web browser. This is why we
just use sans-serif instead of setting a huge font list. This is
deliberate, and by design.

> > I think I understand what you're trying to accomplish with the "big"
> > design, but it needs a *lot* of work. 
>
> Yes, it needs a lot of work and as I said before, this big design is
> more a proof of concept on how we could handle new designs technically
> than a graphic proposal.

Right, but this needs to be fleshed out more if you want it to be an
*actionable* proposal.

> Information density is important, but please don't assume that only
> people using their fingers need larger interactive elements. Touch
> mediaqueries exists, but increasing the size of interactive elements
> just for touch devices is not the good way of looking at this. If you
> check the WCAG guidelines, you'll see that interactive elements,
> independently of the device, should be at least 44x44px, even when
> using a mouse.

I am well aware of these constraints, but the 44px recommendation is
kind of ridiculous. Consider, for instance, that essentially zero
websites on the internet have inline links in paragraphs set to 44px
high or greater - and if they did, it would look awful. Accessibility
guidelines are best treated as recommendations, not prescriptions, and
applied alongside a generous dose of good sense. I think on the whole
SourceHut is quite accessible for a wide range of people, much moreso
than our competitors. That's not to say that there's no room for
improvement, but it probably won't come from blindly applying all of the
WCAG rules.

We can use media queries here to good effect. For instance, @media
(any-pointer: coarse) could be used to have more generous margins for
touch users, but there's no reason that someone with mobility concerns
couldn't also configure this in their browser. Note that in general I
would strongly prefer to use media queries to customize the UI before we
would have someone switch to a separate theme.

> The better way to do this is to have a scale and rules. How much space
> is allowed between elements of the same group? How much to separated
> groups?
>
> That's the kind of things design tokens are good for. This way you
> just... apply the rules. In a way it's a very good way for developers
> to look at design (design system).

I'm listening. Let's see some of these ideas fleshed out in the
prototype.

> If you take the time to separate most things ahead, you'll see that
> theme are way easier to add than you might think. I agree there should
> be better ideas than swapping colors.

Complexity has a cost, and I'm going to end up being the one paying for
it. Not every feature is worth adding. Simplicity is a strong virtue of
SourceHut's engineering sensibilities.

> Some quick ideas:
> - Compact/classic theme (the actual design)
> - Normal (actual design with WCAG fixes, that will make the elements larger)
> - Large (things like the dyslexia changes discusses earlier)
> - High contrast
>
> And why not...
> - black and white apple 1 style
> - personal computers themes
> - ultra minimalist .txt style
> - christmas theme...?!

I think you should take a step back here. I'm not sure that your work is
entirely aligned with the values of SourceHut right now. The UI design
needs to be an extension of our ethos. We value simplicity, utility,
performance, and accessibility, and we strive to *balance* those values.
Notably absent from this list is things like attractiveness - though we
should have it so long as it is not in conflict with the other values.

We value conservative software design, and you should seek to make
conservative changes. We can make radical changes, but only as a series
of well-justified, incremental improvements. One step at a time.
Moreover, managing your scope is important if you actually want to ship
something.

> I've seen in the mailing list that people are a little stressed about
> change. To be perfectly honest, one of my goals is to make sourcehut
> more inclusive, welcoming and personal through its design. For myself,
> because I have a hard time using it in its current state, but also for
> others.
>
> But the thing with accessibility and designing inclusive websites is,
> you can't know how and by who your website will be used. You can't
> assume everyone has your needs, and you can't assume other people's
> needs. So in the end, the redesign might impact everyone.
>
> If we decided to make sourcehut inclusive, some things would have to
> change for sure and it would probably make sourcehut "less sourcehut"
> in its design if we do nothing to compensate for it. We would probably
> have to change colors, margins, enlarge buttons, add a few lines of
> JavaScript for user experience features (like toggling different
> themes, using accordions).
>
> Of course everything would still work without JavaScript, because I'd
> use progressive enhancement techniques. And being inclusive means
> keeping the current design as an option for those it works for. But be
> conscious that most changes in my proposals may not directly for you,
> the current users.
>
> If you are OK with this, I'll take the time to experiment and propose
> some design approaches.

You should be aware that I come from a deep and diverse web development
background. I have been working in web development for about 20 years
now. I have been there hacking alongside the rise of jQuery,
Knockout.js, React, Vue, etc. I have deployed production applications
based on every version of Bootstrap that ever shipped. I've built
hundreds of websites in every style and approach imaginable. I am an
expert in modern web development, and also in every other age of web
development. And I /chose/ to design SourceHut this way.

I am open to improvements, but ultimately, I am the gatekeeper for any
changes to SourceHut's design. You have to understand and appeal to my
design sensibilities if you want to get anything merged.

I don't want to discourage you; in fact, I want to encourage you. This
is important work and you can deliver a lot of value to real people who
depend on SourceHut, now and in the future, by taking on this work. But,
to maximize your odds for success, you should strive to understand why
SourceHut is the way it is today, and to apply that knowledge to your
design for SourceHut tomorrow.

Let's solve one problem at a time. Here's what I'm most excited about
from your work right now:

- A more robust approach to SCSS, free of Bootstrap
- More consistent and tunable parameters for layout and typography
- Better support for marginalized browsers like NetSurf, Mothra, Lynx

These are smaller, well-defined goals that we can accomplish within a
finite scope. Good planning looks to identify goals like this, with
relatively few unknowns and a finite, manageable scope. These goals also
form modest, incremental improvements that you can achieve without
making anyone on the mailing list worried. You will also accomplish
several secondary goals along the way, such as:

- Building trust with the SourceHut community
- Familiarizing yourself with SourceHut internals and development process
- Understanding SourceHut's design and development ethos
- Teaching your design and development ethos to us

This is a better way to go about this work. I hope that makes sense.

December 21, 2021 11:35 PM, "Thomasorus" <oss@thomasorus.com> wrote:

> Hello everyone, thanks for your patience. 
> 
> I've spent a few evenings recreating sourcehut 
> git repository page using the CUBE CSS
> methodology. This is a technical demo and not
> a design proposal. To get a better understanding, 
> please read the CUBE website before
> reading the SCSS files (starting with index).
> 
> You can see the code here:
> https://git.sr.ht/~thomasorus/sourcehut-cubed
> 
> In the README, you will find links to different versions
> I created. What I am particularly happy about is how
> older browsers are supported. I tested in netsurf and
> it's working better than the version in production.
> 
> All pages are responsive in both new and old
> browsers, without using a single media query. 
> 
> Let me know what you think.
> 
> Thomas

I hope this dark theme is not ended up being used.  
Its contrast is way too poor (2~2.5) to be considered accessible.

> I hope this dark theme is not ended up being used.  
> Its contrast is way too poor (2~2.5) to be considered accessible.

This is a technical test, not a design proposal. It won't
be used in production.

On Thursday, December 23rd, 2021 at 15:07, Ngô Ngọc Đức Huy <huyngo@disroot.org> wrote:

> I hope this dark theme is not ended up being used.
> Its contrast is way too poor (2~2.5) to be considered accessible.

Please try to use a more constructive wording when giving feedback. I think
contrast and accessibility is important too, but Thomasorus spent some time
working on this. Negatively worded replies are frustrating and aren't a good
way to invite people to make a change. Consider the following alternative
reply:

"I've looked at your demo, and I've noticed the contrast of this theme is a bit
low: 2 ~ 2.5. To ensure proper accessibility a contrast of $value would be
better. Would you consider making this change?"

It's saying the same thing, but with a higher chance of getting your concerns
addressed. ;)

December 22, 2021 9:18 PM, "Thomasorus" <oss@thomasorus.com> wrote:

> Hey folks,
> 
>> It’s quite a good recreation of the original design. I’m not a fan of
>> the large variation, it’s less efficient and readable than the original
>> spacing.
> 
> I actually find the larger version way more readable, but way less
> balanced from a design standpoint. It doesn't feel like good design but
> things are less cluttered, which allows for an easier scan (see below).
> 

I agree with Drew on the readability part.
Sparser content force my eyes to move more horizontally and that's tiring.

I would add some more comment:

- The "tabs" hides a part of the repository name.
  Fixing this should be trivial, I guess.
- You talk about interactive elements having to be large,
  but the buttons and links stay the same.
- The paragraphs are, to my surprise, quite readable on phone,
  except that the overflowed code makes you have to scroll horizontally to read
  (Not a problem on the current design though)

December 23, 2021 2:21 PM, "Simon Ser" <contact@emersion.fr> wrote:

> On Thursday, December 23rd, 2021 at 15:07, Ngô Ngọc Đức Huy <huyngo@disroot.org> wrote:
> 
>> I hope this dark theme is not ended up being used.
>> Its contrast is way too poor (2~2.5) to be considered accessible.
> 
> Please try to use a more constructive wording when giving feedback. I think
> contrast and accessibility is important too, but Thomasorus spent some time
> working on this. Negatively worded replies are frustrating and aren't a good
> way to invite people to make a change. Consider the following alternative
> reply:
> 
> "I've looked at your demo, and I've noticed the contrast of this theme is a bit
> low: 2 ~ 2.5. To ensure proper accessibility a contrast of $value would be
> better. Would you consider making this change?"
> 
> It's saying the same thing, but with a higher chance of getting your concerns
> addressed. ;)

I see. Thank you for your advice. I am sorry for being insensitive in my earlier replies.

> Please try to use a more constructive wording when giving feedback. I think
> contrast and accessibility is important too, but Thomasorus spent some time
> working on this. Negatively worded replies are frustrating and aren't a good
> way to invite people to make a change.

I'm happy someone said this.

Adding on:

Many people here are blunt, it's something that comes with what 
sourcehut is: blunt to the point software, but equally I think it's 
important to remind newcomers that despite the attitude, their work is 
welcome and appreciated, people just cut to the chase.

I certainly am excited for the work you are doing, it's looking great so 
far!

On Thu, Dec 23, 2021, at 1:17 PM, Evan Boehs wrote:
> I certainly am excited for the work you are doing, it's looking
> great so far!

Agreed! Thomas, your work has the potential to improve the foundation of
how this service's frontend is constructed, which will make future
additions and changes easier to implement! Try not to get too
discouraged by harsh feedback :)

Greetings.

On 23 Dec 2021, at 18:17, Evan Boehs wrote:

> Many people here are blunt, it's something that comes with what 
> sourcehut is: blunt to the point software, but equally I think it's 
> important to remind newcomers that despite the attitude, their work is 
> welcome and appreciated, people just cut to the chase.

On this point, I think it's also important to remark that this is not 
just about 'newcomers'.  I've been doing this broad type of stuff for 
30+ years, and I for one strongly prefer communities where folk make the 
obvious effort to express themselves in a civil way.  'Bluntness' is 
not, for me, a virtue (I'm not dutch!), and Simon Ser's rephrasing, in 
this thread, seems exemplary.

I am by vocation an academic.  This is a profession where people are, in 
effect, paid to disagree with each other on technical matters, at length 
and in detail.  Participants are trained to be clear about the nature 
and grounds of a disagreement, but the plainer the disagreement, the 
more scrupulously respectful is the expression of it.

Best wishes,

Norman


-- 
Norman Gray  :  https://nxg.me.uk

Participants are trained to be clear about the nature
> and grounds of a disagreement, but the plainer the disagreement, the 
> more scrupulously respectful is the expression of it.

Very much so, there is an elegance to communicating effectively while 
being respectful.

Hey folks,

When I created this mailing list, I was hoping that Sourcehut would be a place 
where I can contribute with my knowledge and experience about accessibility
and inclusive design, and have a positive impact for its users. 

I knew it would take time and patience, because devs communities are not used
to these topics, but I was ready for it. And since Drew committed to accessibility 
in a previous blog post, I was confident we would be able to work together, in 
incremental steps, to make Sourcehut better.

So Drew, you can imagine that seeing you cherry pick and bend to your 
own tastes or "good sense" accessibility standards and inclusive design rules ;
while boasting about your professional experience in order to get away with 
it ; and all this despite the apparent flaws in your reasoning (and the flaws of 
Sourcehut implementation of accessibility), is very disappointing.

I already exhaust myself defending this topic's importance at my job with
managers, marketing, designers and developers, all acting like you did to
avoid changing their own ways. I don't want to have to do it in my personal
life and OSS contributions where people should already know better.

So Drew, if you are willing to make compromises and adopt a standard
for the sake of the project and its users, we can continue. But if not, I 
prefer not involving myself anymore. 

Thomas

On Wed Dec 22, 2021 at 12:34 PM NZDT, Thomasorus wrote:
> You can see the code here:
> https://git.sr.ht/~thomasorus/sourcehut-cubed

This looks fantastic. The large spacings theme looks great in netsurf,
too. Definitely continue work on this!

Hi Thomas,

I hope you will continue to try improving the accessibility of sr.ht.

As both you and Drew seem to agree, this has to be done incrementally,
each contribution being a new trade-off between what you think is good
and what the maintainers are ready and/or able to accept.

For this to work smoothly, it's better to be aware from the beginning
of what you can expect as a contributor.  It seemed to me that Drew
expressed something like "SourceHut design will not blindly obey a11y
rules just because they are rules, but we are open to small iterative
improvements, because we care about this", which sounds fine to me.

Of course, you are perfectly entitled not to contribute if you do not
agree with this rule, but that'd be too bad, really.

(My personal motto at work is "better is better than good" and I see
many people giving up the "better" because they believe that good is
better than the better... If all this makes sense.)

Also, I sympathize with your feelings when it comes to convince your
coworkers and hierarchy about the importance of accessibility.  

This is actually something you share with free software supporters:
in general, we are spending a lot of time and energy to convince our
coworkers/hierarchy, meeting the same kind of resistance you describe:
people superficially "getting" it, but unwilling to take action, even
for things that look obvious and easy to us.

Having a forge that cares both about user freedom and accessibility is
precious, I hope to see some of your patches land in sr.ht core.

Thanks!

-- 
 Bastien

G'day,

I've read through this thread a few times (as I tend to enjoy Thomas' 
work and I've only recently gotten over the "learning how sourcehut 
organises content hump") so I was slightly disappointed this thread stalled.

I have a few observations and will follow up with a few suggestions as 
to how a process like this can potentially be handled differently in the 
future. I don't expect any of these ideas to be adopted or even be good, 
but I'm contributing them for the purposes of hopefully providing a 
useful perspective.


Observations:

1. It seems that in these threads it's difficult to properly 
differentiate between goal/value/design comments and questions vs 
particular comments about the proof of concept. As someone who works 
with clients, proof of concepts can be valuable for getting across an 
idea but can quickly become a point of critique in its own right instead 
of focusing on the broader idea it's trying to represent.

2. Certain changes such as the UI design while they can be done 
incrementally do benefit from broader proposals. My observation here is 
that it might be difficult to appreciate how the design will come 
together if it was entirely incrementally implemented, hence why 
multiple elements of the design where discussed at once.

3. The lack of separation between elements of the proposal made 
communication difficult and can conflate comments in odd ways.

4. The approach taken by some (Simon, Noelle, Norman) really shown 
through in terms of friendliness and without that input I think the 
thread would have felt much more transactional/blunt.


Suggestions:

1. A structured approach for handling larger proposals might be 
beneficial. A full-fledged RFC process might be too heavyweight, but in 
my experience being able to separate a proposal into different review 
stages (goals/vision -> constraints -> in scope/out of scope -> actual 
changes) is valuable for ensuring feedback is focused.

Additionally, having a lightweight labeling mechanism can help to make 
sure that comments about particular elements are segmented, allowing 
them to be more transactional. E.g. #2 regards SCSS and #3 regards font 
choices.

In addition, having a single place for a specific proposal could also 
help as items are incrementally addressed. Once say the SCSS element of 
the proposal is locked in (regardless of other elements) work can start 
and be tracked in a central place.

2. To the point about building a relationship within the Sourcehut 
community, it might be valuable to signal how much each side can expect 
in terms of relationship input. For example, the core maintainers might 
be unable to handle the load of building relationships with all 
tentative contributors, but a signal of "If you plan on contributing a 
proposal of x-size, then let's have a chat over IRC/mail/video to get to 
know each other and set the scene". I realise this isn't entirely 
scalable as such, but it does set a good precedent for building the 
relationship from both sides.


I'd like to end this by just saying I'm not trying to suggest the best 
way for running an open source project, especially not to you all who 
have significant experience in this space. The above is merely some 
observations I've made about this thread in isolation and some ways to 
reconcile to the point feedback with more substantive debate.


Cheers,
Ruben