Broken by redesign - Githubissues

I really liked your site before this redesign. I mean, light text on dark background wasn't ideal, but something you could live with. It was a simple collection of web pages, after all, that worked nicely without Javascript and didn't do weird things.

Now things are catastrophically different. The fade-in effect with which page content is now served just made me scream and feel like I need to arrange for an emergency meeting with a punching bag.

Also, that big magenta button with the ellipses in it in the top right corner is hilarious. It says: “I would tell you more, but you need let me execute some Javascript for that.” No, thanks.

Here's something to think about: Web of Documents.

Luckily, there's nothing particularly interesting hidden behind the top right button. I'm not opposed to removing the fade-in effect.

But basically, the old simpler site was something I put together with my own very limited design abilities, mostly from scratch. It got a lot of complaints (including for the light-on-dark thing you mention.)

This one is one step up in the specific sense that I used a commercial template (https://horace.netlify.com) adapted a bit to my usage. I suspect you won't enjoy the unmodified version more than my version -- though if you do, let me know which bits and I may be able to adapt them.

Basically, there exists no way for me to not get complaints short of hiring a brilliant designer for my specific use case, which is out of my current budget. The current level (cheap commercial template, adapted by me) gets fewer complaints than its predecessor, partly because it uses a bunch of Javascript bits and bobs so it looks intentional. "Looks intentional" is a surprisingly big deal in design, and much harder to achieve than it sounds.

I'm familiar with the idea that the web should consist primarily (or entirely) of very simple documents without Javascript and with minimal CSS. My experience has been that that doesn't work well for my primarily goals for the site, which are educating developers and selling books. Any ideal that gets in the way of those two is simply not fit-for-purpose, given my purposes. I have tried that. I find it to be an attractive philosophy as well. It's just not an attractive philosophy that seems, in practice, to work well for my actual goals.

With that said, it shouldn't be hard for me to get rid of that fade-in effect.

Looks like the fade-in effect is actually a CSS animation - not JS at all. I've removed it now. You may need to manually reload (I did) to see it go away.

Thanks for removing the fade-in. It's much better now.

But basically, the old simpler site was something I put together with my own very limited design abilities, mostly from scratch. It got a lot of complaints (including for the light-on-dark thing you mention.)

[...]

Basically, there exists no way for me to not get complaints short of hiring a brilliant designer for my specific use case, which is out of my current budget. The current level (cheap commercial template, adapted by me) gets fewer complaints than its predecessor, partly because it uses a bunch of Javascript bits and bobs so it looks intentional. "Looks intentional" is a surprisingly big deal in design, and much harder to achieve than it sounds.

Well, I mean, it really is kind of a drag to build a half-way decent website from scratch and then maintain it, especially when you're not in a position to go for a more or less uncompromising, minimalist design and people complaining about your site design matters economically. I get that.

I still wonder, though: What kinds of complaints did you get about the old site that could be solved by making things “look intentional” through the use of bits and bobs of Javascript?

I'm familiar with the idea that the web should consist primarily (or entirely) of very simple documents without Javascript and with minimal CSS. My experience has been that that doesn't work well for my primarily goals for the site, which are educating developers and selling books. Any ideal that gets in the way of those two is simply not fit-for-purpose, given my purposes. I have tried that. I find it to be an attractive philosophy as well. It's just not an attractive philosophy that seems, in practice, to work well for my actual goals.

I see. I mean, I can sort of imagine how this might be colliding with the goal of selling books. But how does having a website consisting of a set of well-organized documents interfere with educating developers? You'd think that would be ideal for educating developers.

On a more general note, I'd say that common present-day web design, with its focus on over-engineered “UX” and alleged efficiency, caters to an already spoiled relationship people have to actual content. So, I think it's a good idea to resist going with these trends as much as possible.

Apropos, how about underlining links?

First things first: sure, I can underline links.

What kinds of complaints did you get about the old site that could be solved by making things “look intentional” through the use of bits and bobs of Javascript?

Mostly of the general form, "I feel like I wandered into a web site from 2002." By making my web site look annoyingly faux-current, I avoided people feeling like it was wearing tie-dye bell bottoms.

But how does having a website consisting of a set of well-organized documents interfere with educating developers? You'd think that would be ideal for educating developers.

You would. I would too. Well-organised documents, by themselves, are certainly not an obstacle to educating developers. Some actions can serve both goals nicely (e.g. have topic pages, keep them reasonably up-to-date, organise them by what people are looking for.)

But a lot of human interaction is about how you make people feel. I'm reminded of the quote by Winston Churchill's mother:

"When I left the dining room after sitting next to Gladstone, I thought he was the cleverest man in England. But when I sat next to Disraeli, I left feeling that I was the cleverest woman."

You'll also see it expressed as, "people don't remember what you said to them, but how you made them feel." These things are, for better or worse, absolutely core to teaching people online. In person I can try to fix that with charm in various ways. Online that doesn't work well, or doesn't work at all.

And that brings us to making sites pretty, while having them feel "expected" and not "outdated" -- I'm putting those words in quotes because I mean them specifically in a marketing sense. They're about how people come away from the site feeling.

A developer who would prefer to deal with the site by downloading my archives as markup (or even RSS) and will cheerfully read through info as JSON is fairly rare in the wild. There aren't a lot of them, and they don't buy many books. Also it's possible for them to literally use my big directory of markup files, just as you did (this same repo, in the source/posts/ directory.) The argument "content is king" only gets you so far - most people do not want a literal database-style dump of information, and those who do are not usually my customers, plus they are already "served" in several important senses.

(In addition to the git repo of markup they can use the RSS feed that's linked at the top of every page.)

So the number of people who 1) want something decoratively arranged and entertainingly presented/written, 2) specifically do not want additional decoration and 3) want to read my blog in a web browser is fairly small. There are absolutely engineers who do not want any of the extra bits to make things entertaining or pretty, who will plough through like grim death to get just the information, and who find little content-free flourishes (like the fade-in) to be annoying. Indeed, on some topics I am one of those. But the number of them I am writing to is small.

Arguably what I would do to serve those folks best is something with the Google lightweight documents (I forget what they're called) in order to serve most of my data directly in Google search without them having to involve my site in any direct way. That demonstrates the other reason I don't do as much work for them beyond making information available: mostly they aren't buyers. I don't object to serving them, and I put effort in, but it's a lower priority. Any direct conflict between those folks and the folks who buy books gets resolved in favour of the folks who buy books.

It's possible, through excellent design, to route around most conflicts between them, just as an excellent software developer can often see a way to change product scope in a way that preserves important functionality while keeping performance excellent - there are tradeoffs, but a highly-skilled practitioner can navigate those tradeoffs in a way that looks like magic.

Which is why, when my budget is higher, I should hire an excellent designer. I am, at best, a nearly-adequate designer. And even purchasing a commercial theme means I spend time customising it and not doing a perfect job (though I think I do okay.)

When I do, there will certainly be decorative flourishes. Some of them are likely to involve JavaScript, or things like CSS animations which are also obviously not directly functional. Part of how you make the overall appearance seem intentional is to have things that aren't directly functional (that are similar in feel to the functional bits) -- or else to trim off everything nonfunctional or decorative, which in buildings is referred to as a "Brutalist" aesthetic, and most people find it similarly off-putting in web sites.

Links should be underlined now.

If someone who visited my website told me, “I feel like I wandered into a web site from 2002.”, or “the 90s”, I would probably tell them that they're welcome.

In my experience, the argument that “[THING] looks like straight outta [YEAR - (10 + x)]” is, most of the time, nothing but shallow pseudo-criticism provided by people who are either unable or too lazy to explain what the actual problem is.

Looking new, or rather “annoyingly faux-current”, as you put it, is by no means a desirable quality in itself. If some people don't get that – a lot of people don't, actually – then I feel sorry for them. And even more so for those who are not free to refuse catering to such stupidity. Then again, there's probably more room for refusal in most cases than one would realize at first.

That said, I was not meaning to imply that a website's design – or any kind of design, for that matter – should be confined to bare necessity. There's nothing wrong with giving something a decent look and feel. In fact, I'd consider that an essential part of a solid design. I mean, if you create a website, you should definitely follow a “content frist” approach (exceptions for fun permitted). But if your content is served well and you then add a few frills that don't do any damage to that, fine. Putting a fade-in effect on text definitley does damage a website's usability, however. Just imagine having the same thing on every page of a book you read.

So, I'm definitely not arguing for a Brutalist aesthetic. I'd say that Brutalism doesn't make any sense at all for web design because it would essentially mean serving the HTML source in plain text, at which point you could just strip away the markup altogether. But then, there's a good reason for not serving content on a website as plain text: HTML provides rich text facilities that can help create a much better reading experience (viewing pages in a text-only browser being a weird sort-of exception).

Apropos Brutalism: You're probably aware of the Guidelines for Brutalist Web Design by David Copeland. His use of the term Brutalism is based on a semantic hack, however. In the introduction, he proclaims: “A website's materials aren't HTML tags, CSS, or JavaScript code. Rather, they are its content and the context in which it's consumed.”

That's an arguably weird notion of Brutalism. Nonetheless, those Guidelines are a good read and I agree to most of what their author says, though I think the whole thing could and should really have been done without sticking a custom-defined ism on it as a label. I should probably fork Copeland's text and create my own version. I'd have a few things to add anyway.

As for serving people who want “just the information”, there's a rather simple way to do that: Make the site reasonably usable with CSS switched off. I've just had a look and I'd say yours is pretty much good as it is, except for that “Open Sidebar” button that will, of course, just sit there and do nothing when you click on it even if you activate all the Javascript in the world.

Links should be underlined now.

Classic.

Most of my belief that the "web site from 2002" criticism is attached to lower sales comes from circumstantial evidence - timing of longer-term increases in sales, mostly. Unfortunately, with sales and marketing it's nearly all circumstantial evidence in nearly every case.

In general, when selling people things, you can't rely on customers to accurately convey their mental state and decision-making process to you. People don't work that way. It's not even just when you're selling people things - you can't rely on people to accurately describe their decision-making processes. Among marketers, the follow-up anecdote would be, for instance, being told to immediately take down a pop-over window because nobody would ever use one, checking the return email address, and seeing that they subscribed to your list with the pop-over.

Related to the above: catering to people's weaknesses is, professionally speaking, my entire schtick. People who are already perfectly able to fully understand and convey their complete mental process and need, at most, raw information, tend to have limited interest in being taught. That's fair. But again, it defines who I'm talking to.

In any case, deciding that "common human preferences are stupid and I wouldn't want to cater to such weakness" (not your phrasing, but not far off from your sentiment) is something I can't do while selling things... and honestly, I wouldn't want to do because it keeps me from effectively teaching such a lot of people. A certain amount of catering to people's human frailty is built into the teacher gig if you do it well.

As far as the fade-in damaging usability, I had literally glanced past the fade-in without ever really noticing it, hundreds of times, before you pointed it out. That's one reason I was so willing to get rid of it. It's possible I was consciously aware of it at some point (maybe when first looking over the theme, before I bought a copy?) but quite possibly not even then. So I can maybe imagine that damaging a book if done on every page, but I find it pretty unobtrusive.

I've seen the Copeland page about Brutalist web design. I didn't pay a lot of attention when I read it, partly because it seems like such an excellent counterargument to itself -- it's hard to read and it's ugly. It has such a "pure focus on content" that it winds up distracting from that content by being jarring.

Huh. The sidebar literally had boilerplate items with nothing in them that never show up except on mobile. That, at least, is a trivial thing to get rid of. I should probably get rid of the sidebar entirely, but I haven't yet resigned myself to removing a last few vestiges of the old design (favourite articles, basically.) There's no obvious place to put that in the new design. It could be a topic page, but I don't think almost anybody currently finds and uses those.

Related to the above: catering to people's weaknesses is, professionally speaking, my entire schtick. People who are already perfectly able to fully understand and convey their complete mental process and need, at most, raw information, tend to have limited interest in being taught. That's fair. But again, it defines who I'm talking to.

In any case, deciding that "common human preferences are stupid and I wouldn't want to cater to such weakness" (not your phrasing, but not far off from your sentiment) is something I can't do while selling things... and honestly, I wouldn't want to do because it keeps me from effectively teaching such a lot of people. A certain amount of catering to people's human frailty is built into the teacher gig if you do it well.

I was just short of saying I mostly agree to this. On second thoughts, however, I don't, simply because catering to people's weaknesses is a pretty delicate issue. I mean, I'm surely not gonna turn to a paraplegic sitting in a wheelchair and tell him: “You could walk if you really wanted, you'd only have to do it on your hands.”

That said, if I was a teacher trying to educate people on, say, how to make use of common Unix command-line tools, I would try to do that in a way that enables them to overcome their own weaknesses instead of catering to those weaknesses. And this certainly wouldn't mean answering every “non-smart” question with “RTFM!”. (In fact, I'd never answer a question with “RTFM!”.) For example, if someone asked me how to make find exclude a certain directory tree, I'd tell them they need to use that utility's -prune option, which is documented in the manual page. And I would add that it's a bit tricky to use because find is a funny little DSL that behaves quite a bit different from the average tool in their box. And to that I would add that if they can't get it to work, we'll just try it together, step by step, and – if the situation feels like it needs to be mentioned – that there's no reason to feel ashamed or stupid if they don't figure it out on their own.

What I'm talking about when I criticize faux-current (I'm starting like that term.) UI or “UX” design as catering to people's stupidity is an entirely different matter. The argument here is against ways of computer-mediated interaction with the world that, to put it bluntly, make (and keep) you dumb and “will eat your soul”™.

It's against catering to people's weakness as in relentlessly exploiting (or simply giving in to) the fetishes they have acquired through years of being conditioned by what UI and “UX” designers (Or is it ruthless marketing people? Can't really tell.) have been shoving down their throats for purposes that mostly have next to nothing to do with serving content (in both senses of the term) and everything with stealing attention for profit and pretending that this stolen attention would be rewarded with anything that has the slightest amount of substance.

Speaking of substance, a lot of faux-current “UX” design is apparently striving to get people addicted to a product. It's really kind of like pushing a designer drug, reinforcing people's weakness to resist it. (Nothing against drugs in general, it's getting people addicted (and locking them in by other means aka being “inclusive”) that concerns me.)

The principles of this either intentionally malicious or simply brain-damaged way of designing user interfaces seem to have sunk into the common notion of what makes a good interface so much, it's beyond just bordering on the absurd. A lot of people seem to expect an “experience” these days when visiting a website.

I seriously think that anyone who really wants to design for the user should break that pattern, even if it hurts a bit, at first.

About Copeland's Brutalist web design page: Sure, there's room for improvement. For example, I'd choose a less aggressive tone of blue for links and refrain from having two different font sizes in headings, maybe increase the column width as well. But “an excellent counterargument to itself”? I don't think so. Anyway, I've forked the whole thing now and will try to also improve on the original's style while I rework it.

One of the difficulties of "reasoning through" what people should want (rather than observing that they do want) is that there's not a lot of room for habit, intuition and other unconscious or semi-conscious processes. That's a problem because people primarily operate via unconscious and semi-conscious processes, and that's a good thing, and people are basically good at it. Conscious thinking is too slow, unpredictable and (in biological terms) expensive to do everything that way. I don't just mean obvious stuff (heartbeat, say, or recognising common objects) but also things like habit. "Reasoning through" is such an expensive, annoying process that it should be reserved for cases where it brings a huge amount of benefit.

You can see roughly these same sentiments expressed popularly in books like "Thinking Fast and Slow" and "The Talent Code" as well as many, many more.

Here's why I think that's relevant.

Unix man pages are, frankly, awful. They're generally presented in font, colour and general setting where they're hard to read and hard to find specific bits of content. I've read through the entirety of the "bash" man page (which is awful) because finding simple things like the for loop syntax in it is awful, and there didn't used to be a world wide web that would explain these things quickly and easily. The "Brutalist" web page is light-on-dark, the left-right alignment is inconsistent, the vertical alignment is also inconsistent, he uses a wide variety of font sizes and weights more or less randomly...

"Why does this matter?" you might ask. First off, eyestrain. Second, it's hard to skim - you can't look for familiar things in familiar ways because it's presented without any attention to what a given size, font weight or positioning means. A bad presentation disrespects your comfort and your time. As a result it's only usable by people who expect it to hurt and to take their whole attention. Software developers, as a rule, expect their tools to hurt and to take their whole attention. That is not in any way a good thing and it artificially limits who can do these tasks.

If somebody says "it should all be simple, uniform documents" they're either saying that the presentation matters so much that it must be good everywhere, or that it matters so little that they don't care how painful it is to use, moment-to-moment. The person saying so will never tell you which camp they're in - you have to figure it out from the other things they say.

Here are some example (non-conscious, not stated outright) hints. If they recommend the Unix man pages, there's an excellent chance they don't think you're supposed to care about presentation that respects. If they recommend a page like the Brutalist Web Design page as a good thing, they're not worried about ergonomic web design.

And if somebody does that, you have to assume all their other recommendations may also disrespect your comfort and your time. That is, incidentally, why I don't want my site to look like I'm one of those people. If I'm "like a teacher, but I disrespect your comfort and your time" then I'm a bad teacher. There are plenty of those, but I don't want to be one.

You could say "no, I mean it should be uniformly excellent! And stop whining about eyestrain, being busy, hostile placement of things and lack of skimmability! If you were smarter you wouldn't care about eyestrain, having to read everything laboriously, your tasks taking longer and having no time for friends or children!"

(That is, obviously, an exaggeration. Nobody who was implying that would ever say it outright. It is, however, what is being said.)

If "usable by busy people who don't dedicate their lives to software development" is the same as encouraging stupidity, then I'm going to have to come down on the side of encouraging stupidity. Making a thing harder does not, as a rule, make it better. It's the wrong sort of weeding out - it's weeding out on effectively-random (or sometimes worse-than-random) criteria, like requiring excellent handwriting in job interviews (as they used to do.)

"Find" is a great example. Where there are easier ways than find to do a task, they should be encouraged. Because find is not a great interface, and should only be used where there is not a simpler, easier, more-rememberable way to do it. There is no basic virtue nor intelligence in memorising the arbitrary, obscure and poorly-designed "find" interface. The virtue comes only from its functionality, and should not be fetishised beyond that. If the interface requires a smart person to use by being difficult, that's not by itself a virtue. Just making things more difficult is basically a bad thing and should not be encouraged.

Let's be clear: I'm good at the find interface. I'm also good at old-style C systems programming, but I don't think there should be more of it. It's an old, painful idea that used to be necessary and now mostly isn't any more. So it shouldn't be used where it can be avoided, even if you have to be smart to have a chance of doing it well.

I certainly don't feel like sidebar menus, visual whitespace, readable fonts and so on are addicting people to a product on my site -- though if you see anything you feel is doing so, certainly point it out.

But if your objection to faux-current design, or design-beyond-minimalism is "but busy people who haven't dedicated their lives to software development will think they are welcome here!" then... well, then I think you and I will never see eye-to-eye on this. Those are the folks who want and need my services. I want to train people to get their basic tasks done rapidly, to make and use easy and eye-pleasing resources to do so, and to glory in the final functionality and not how smart they had to be to limp through the process.

I used to live in the world where only the smartest people could limp through. My full-time software career started in 1998, and I did it continuously through the present day. The modern-world approach where a lot of things aren't painful and horrible to use is just better, and I have no desire whatsoever to go back to bad typography, bad interfaces, disrespect for designers and interfaces where you get bragging rights for using them at all because they're so horrible.

A clean, spare underlying data format is nice and I could agree with it in principle. The Brutalist Web Design page doesn't even do that. Here's the markup for the very first content on the page, for instance:

<article class="bb b--silver mb3">
  <h1 class="f-subheadline-ns f1 helvetica lh-solid mt0 mb3">
    <small class="f2-ns f3 db">Guidelines for</small>
      Brutalist Web Design</h1>
  <h2 class="helvetica mt0 fw3">Raw content true to its construction</h2>
  <h3 class="helvetica mt0 fw3 f5"> By <a href="#about">David Bryant Copeland</a>
    Updated Jan 31, 2020 </h3>
  <ul class="f4 pl0-ns pl3 lst-square lsp-outside">
    <li> <a href="#readable-content"> Content is readable on all reasonable screens and devices. </a> </li>

If he wanted to suggest that we should have good, pretty, skimmable, searchable rendering of markdown built into browsers and then write all our pages in plain markdown, that I could get behind. But I suspect he wouldn't. He doesn't actually want simplicity and uniformity of content, not even on the page where he is nominally recommending those things. (Example: he wants interesting formatting of the titles, so he sticks "small" tags around some of the parts rather than finding a way to do it uniformly via CSS, or giving it up because it cannot easily be done uniformly. The way he uses the header tags is also atrocious.)

When I say it's an excellent counterargument to itself, I mean that it's hostile. It's hard to read, it's hard to skim, and he clearly doesn't even favour much simplicity and uniformity. I do not trust the recommendations of a man who claims to want what he wants and then gets that result. He is either well-meaning but inept, or what he actually wants is not what he claims. I strongly suspect the latter.

If I liked his results, I could forgive that - I could believe that I want what he wants even if he's not explaining what he wants very clearly. This does not make every recommendation wrong. But it means they're not especially likely to be right and I should absolutely not treat them as a "to do" list. If I do, I'm likely to get the result they're designed to create, and I don't want that result.

"Reasoning through" is such an expensive, annoying process that it should be reserved for cases where it brings a huge amount of benefit.

I agree, and this very debate has me feel the pain.

I wouldn't say the benefit need necessarily be huge. There should just be a sane ratio of what you put in and what you get out. In my experience, that's almost never the case with anything (You get out far less than you had to put in.), which is, in fact, one good and compelling reason to create interfaces that either don't require “reasoning through”, or require it only initially, meaning they need to be learned, but when they've been learned, make good sense or rather: reveal themselves as being well-designed.

The truth about Unix (Part one): An awful man.

Unix man pages are, frankly, awful. They're generally presented in font, colour and general setting where they're hard to read and hard to find specific bits of content. I've read through the entirety of the "bash" man page (which is awful) because finding simple things like the for loop syntax in it is awful, and there didn't used to be a world wide web that would explain these things quickly and easily.

I tend to agree to that. I'd just like to point out that a) the way those manual pages are presented visually can be configured to an extent that may help a lot when you need to make use of them and b) they (should) conform to a more or less uniform structure that can help finding things more quickly.

I'm pretty certain you know all that better than me. I just want to mention it for people who don't.

So, concerning point a), here's what I do: I've configured my terminal emulator to show text in black (or, occasionally, in some color) on a light gray background and in a type face that makes sense to me. In addition to that, I'm using an extension that will allow me to change the font size on the fly, just like (and with the same key bindings as) in the web browser I use. This makes a whole lot of a difference compared to reading (or trying to read) a manual page in a standard XTerm, or URxvt, which I use. (The extension is urxvt-resize-font, by the way.)

About point b): Unix manual pages generally follow a pretty well-defined structure. There's a SYNOPSIS for the command at the top, then a DESCRIPTION of what it does, then a list of OPTIONS, a section mentioning all the FILES that to are important to it near the end etc. (I'm using caps here because that's literally what those sections are (well, should be) called.) So, if, e.g., I wanted to know which configuration files Bash reads, I'd have a look at the FILES section in its manual page. And I would, of course, not try to find it by scrolling and reading through that page like I'd lost my sanity already. Instead, I'd use the pager's search functionality and have it look for ^FILES. (OK, it's a regex. But then, knowing a few bits about how to use regular expressions is beneficial so far beyond the Unix command line, I'd try to convince anyone to look into it. Just imagine your favorite web search engine supporting regex. It would be a revelation.)

Now, looking up the syntax of for is certainly not going to be that easy and will require knowledge of Bash and the structure of its manual page already. And, yes, that's a serious problem.

So, right, Unix manual pages are kind of awful but not that awful.

That said, I'm not trying to make excuses. If you'd have me choose between the Bash manual page or the one-page HTML version of the Bash Reference Manual, I'd surely choose the latter.

I actually still use the manual page most of the time because it just requires man bash to have it pop up instantly and I'm not always running a web browser but almost always running a terminal emulator. And there are – off the top of my head – other disadvantages to the HTML-in-a-browser solution. I either need a connection to the Internet to access it and will therefore run a risk of having my actions recorded (Really, it's no one's business that I'm looking at the Bash manual. Call me paranoid. I know I'm not.) or I'd need to download that file and then still run an irresponsibly massive browser monster to get the best reading experience. Okay, I could spend a day to read up about more minimalist browsers. Do I feel like doing that? Very likely not. Would these more minimalist browsers even work well for me? Re-read from five sentences back. Also, where do I put that file? Did I have to worry about all that when I was simply using the manual page? No, I didn't.

If somebody says "it should all be simple, uniform documents" they're either saying that the presentation matters so much that it must be good everywhere, or that it matters so little that they don't care how painful it is to use, moment-to-moment. The person saying so will never tell you which camp they're in - you have to figure it out from the other things they say.

Depending on what you mean by “uniform”, I'd be in the first camp – if it has to be a camp. If your goal in designing an interface (or document layout) is to reduce the mental overhead required to use it to a minimum (knowing and not ignoring there must me limits to that), I'm all on your side.

Here are some example (non-conscious, not stated outright) hints. If they recommend the Unix man pages, there's an excellent chance they don't think you're supposed to care about presentation that respects. If they recommend a page like the Brutalist Web Design page as a good thing, they're not worried about ergonomic web design.

You've been jumping to conclusions here. I have not, in fact, been recommending Unix manual pages in my last post at all. And what I had to say about the Brutalist Web Design page was that it's a good read, even though I don't completely agree to what its author says. On top of that, I acknowledged that the visual appearance could be improved.

Apropos Brutalist Web Design

The "Brutalist" web page is light-on-dark

It wasn't, for the most part, last time I checked.

the left-right alignment is inconsistent

I what sense? If you mean bulleted lists should have their bullets (or squares, in this case) aligned at the left edge rather than their text, I completely agree. Those lists look off.

the vertical alignment is also inconsistent, he uses a wide variety of font sizes and weights more or less randomly…

Calling that – What is it, two non-fancy type faces and four different font sizes? – a wide variety is a bit of an overstatement, don't you think? Sanitizing the headings would solve most of that problem, I'd say. But sure, it is a problem.

"Why does this matter?" you might ask. First off, eyestrain. Second, it's hard to skim - you can't look for familiar things in familiar ways because it's presented without any attention to what a given size, font weight or positioning means. A bad presentation disrespects your comfort and your time. As a result it's only usable by people who expect it to hurt and to take their whole attention.

When I first discovered that page, my impression was quite different. I felt that, for a change, someone was simply putting (half-way reasonably readable) text (and a few images) on a page to discuss a subject and arguing in that text that, basically, that's how it should be done. I may have liked that so much that I outright overlooked some of the site's flaws. I also didn't look at the makrup back then.

And that brings us to discussing that markup. You're right, it's awful. And it took me quite a bit of time to convert it to something I'd call basically sane (which involved dropping HTML5 for HTML 4.01 Strict). You can have a look, if you like, and tell me what you think. This is still a work in progress, though.

As for Dave's intentions behind creating that page, I don't see any merit in speculating about that. I have no reason to believe he's not sincere and well-meaning. That page is what it is. I find its content useful. I see room for improvement. That's it. And it's definitley not hostile. Or were you referring to the markup? Well, we'd be agreeing on that then.

The Truth about Unix (Part deux): Hard to find (and C).

If "usable by busy people who don't dedicate their lives to software development" is the same as encouraging stupidity, then I'm going to have to come down on the side of encouraging stupidity. Making a thing harder does not, as a rule, make it better. It's the wrong sort of weeding out - it's weeding out on effectively-random (or sometimes worse-than-random) criteria, like requiring excellent handwriting in job interviews (as they used to do.)

Can you point me to where I have claimed making something harder to use would, as a rule, make it better? I don't see that anywhere in what I have said here so far.

"Find" is a great example. Where there are easier ways than find to do a task, they should be encouraged. Because find is not a great interface, and should only be used where there is not a simpler, easier, more-rememberable way to do it. There is no basic virtue nor intelligence in memorising the arbitrary, obscure and poorly-designed "find" interface. The virtue comes only from its functionality, and should not be fetishised beyond that. If the interface requires a smart person to use by being difficult, that's not by itself a virtue. Just making things more difficult is basically a bad thing and should not be encouraged.

By using find as an example of how I would teach something if I was a teacher, I didn't mean to imply I like find. In fact, I came up with this example exactly because I know how painful it is to use. Apart from its general interface design being arguably poor, there are two other big problems with it, one of which I've already mentioned: It's a DSL sort of looking like an average command-line tool (albeit using MIT-style option syntax). The second one is a consequence of that: find often doesn't seem to fit with the, well, “mental model” of how you'd go about searching for something.

For most of my day-to-day use of find, it could be stripped down to what I'll call fynd here. And that would look as follows:

fynd <pattern> finds any type of file with the name used in place of <pattern> (case-insensitive)
fynd -r <pattern> or fynd -x <pattern> would do the same, except it would interpret the file name as a regular expression

Additonally,

-t <type> would let you limit searches to a file type
-p <path> would let you search only <path>

Let's be clear: I'm good at the find interface. I'm also good at old-style C systems programming, but I don't think there should be more of it. It's an old, painful idea that used to be necessary and now mostly isn't any more. So it shouldn't be used where it can be avoided, even if you have to be smart to have a chance of doing it well.

I don't know C, let alone systems programming. I mean, I've looked into C but given up. And I'm not looking back. In fact, an article on your website played a considerable role in convincing me that it's a good idea to give up on C (for me). I'm learning Scheme now. That's hard too, but it makes much more sense to me (which it didn't last year). Also, I've found a book that repects my current weaknesses and, by that, helps me stay at it and overcome them: Teach Yourself Scheme in Fixnum Days by Dorai Sitaram.

Better web design

I certainly don't feel like sidebar menus, visual whitespace, readable fonts and so on are addicting people to a product on my site -- though if you see anything you feel is doing so, certainly point it out.

I wasn't meaning to say that. I think if you'd just get rid of that – in my view – pretty annoying magenta button in the top right corner (including that “nothing particularly interesting hidden behind [it]”), there wouldn't be much left to complain about altogether. I mean, I haven't looked at the markup. And I think I won't.

Bad old days

I used to live in the world where only the smartest people could limp through. My full-time software career started in 1998, and I did it continuously through the present day. The modern-world approach where a lot of things aren't painful and horrible to use is just better, and I have no desire whatsoever to go back to bad typography, bad interfaces, disrespect for designers and interfaces where you get bragging rights for using them at all because they're so horrible.

If only your description of that “modern-world approach” was accurate, I'd be all for it. Unfortunately it isn't. Try blocking Javascript (for all the good reasons) for a day. Welcome to the half-broken (Or is it three quarters now?) web.

Final words (for this take)

Software developers, as a rule, expect their tools to hurt and to take their whole attention.

Do I have to say this is nonsense? Well, let it be said, just to be safe. I mean, you're a software developer, are you not? See.

I frankly can't tell what you're saying with a fair bit of this, other than the fact that you hate JavaScript and you believe everything on the web should be usable without it (I disagree, but I can see why somebody might say so.) I judge the modern approach by what happens with JavaScript working. I treat JavaScript as table stakes at this point.

Also: is this the same page you mean? It's the one I'm calling ugly. Just in that screenshot, I get five font sizes (47.25px, 105px, 31.5px, 21px, 26.25px.) In addition to the lists which, yes, are horizontally unaligned with the bullets, there are also alignment problems between the small and large lines of the top title (and the other multiline h1 titles throughout.) Highlight the first letters of the first two lines and you'll notice they start at a different left offset, but not so large that it looks intentional. For the vertical lack of alignment, scroll down to the (weird) emoji pull-quote. Screenshot 2020-05-06 at 18 17 52

You could "just" fix it by sanitising the headers, yes, mostly because he does everything with headers including things like bylines which shouldn't be headers.

I frankly can't tell what you're saying with a fair bit of this, other than the fact that you hate JavaScript and you believe everything on the web should be usable without it (I disagree, but I can see why somebody might say so.)

You should probably read it all again then when you feel like it and have the time – no offense. You were making quite a few claims about what I was suggesting that were unsubstantiated. So, I took the time to point that out and clarify things because I felt grossly misunderstood.

I judge the modern approach by what happens with JavaScript working. I treat JavaScript as table stakes at this point.

I, on the other hand, have two plugins running in my browser to block things that happen with Javascript working because, in my experience, most of that is tracking, broken design (needs JS to display any text, needs JS to make button work, will use JS to add frills that damage my reading experience etc.) or trying to run outright malicious code.

Also: is this the same page you mean?

Yes, and I think I know why you're seeing it light-on-dark. Quoting from the Colophon:

This site also supports “dark mode”, based on your OS settings.

Well, that kind of backfired…

You're right about the other points.

On a side note: I intitally started this discussion because I wanted to send someone the URL of that article of yours I mentioned in my last post. Then I was turned off by the new design so much that I thought I should voice my criticism. I have done that. And I think I've made my point. So, just let it be said that if you don't feel like continuing this debate, that's fine with me.

noahgibbs / codefolio_middleman