Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Exclusive Design (vasilis.nl)
112 points by robin_reala on Jan 30, 2019 | hide | past | favorite | 40 comments


Accessibility for the disabled is important. But since the theme here is to encourage design that doesn't presume the audience to be like the designer (probably educated urban middle class and up young adults), I'd like to add "different culture, education level, socioeconomic status, and age" to the list of things that designers should be aware of. As someone who deals with such people quite often, I can say from experience that the disabled are far from the only group that modern digital design excludes.


Don't do accessibility just for the disabled. Normal people are slowed down by today's graphics design for websites, too. If it's thin and gray on your retina display, guess how it looks on my 13year old monitor with washed out CFL, or on cheap phone outside when the sun is shining. How it looks when your stupid website is presented on the wall projector (you know, on a meeting to a group of people deciding whether to buy your service subscription or not), or printed on the paper.

Reading mode had to be invented, so that many websites could actually be read.


Thin and light text also merges with the background when a red filter is enabled―which are becoming more popular and are now included in OSes.


Why should developers cater for users who are running severely outdated hardware?

I don't disagree with you, I was running an ancient laptop as my main box until a few months ago, so I know first-hand how frustrating it is. It's hard to play games or watch videos with only 128mb VRAM and almost no shader/codec acceleration support!.

But at the same time, it greatly increases the variety of devices and standards you need to support (there's a pretty huge gap between a 10 year old machine and a modern one, but 3 or 5 years are reasonably similar), and thus blows out the scope and difficulty of creating and maintaining a system. As a programmer, it's quite frustrating when removing support for outdated hardware / operating systems could make a system so much cleaner.

Then there's security considerations, e.g. if you have to leave deprecated versions of SSL enabled to support outdated clients, that weakens the entire system.


> Why should developers cater for users who are running severely outdated hardware?

They don't have to. I know how to fix the font width via developer tools. But many people don't and devs can then hardly go and complain that their websites are losing audience or have high bounce rates.

Also this is mostly about respect for displays people may be using to view the website. There's nothing that much outdated about an old display. It just has lessened brightness/contrast. You don't have to support it in any way and there are no security implications.


12 pt Times New Roman white on black works pretty well on old hardware.


> Roughly said, in the past 25 years we have been designing websites mostly for people who design websites.

This. They're not only missing accessibility, they're missing general usability. We're drowning in a mess of shiny, over engineered but annoying pop-ups, carousels, hamburgers, infinite scrolls, etc...


We're drowning in exponentially increasing data and functions while shrinking screens from 200-1000 sq inches to 20-40sq inches, and frantically inventing new UIs to cope.


We’ve been designing for sales.


Not infrequently we’be been designing for sales of design work.


If only designers had any say, this'd actually be true.

Design has barely been born on computing devices frankly. Apple was the first, and remains, the only computing company with any taste at all. So really, the entire industry has some designers working for one company, that the rest shamelessly copy.


Shrugs, as the old maxim has it "In matters of taste, there can be no disputes" - I'm not a massive fan of Apple UI's on the ipad (and my house owns three, two are mine for testing and one is the boys), they are serviceable enough but they put everyone in the same slot, if you happen to fit that, great but if not then not so great.

That said I'm not the target market and I accept that.


Similar to the cobra effect.

Which was brilliantly satirised by Pratchett's in discworld by the cities ruler (same except with rats) who had a simple solution "tax the rat farms".


This entire post seems entirely subjective.


There is a trend among web designers to use large, clear fonts and less clutter. I really like this style. After using a computer for more than 25 years, I can't stand to see so much on screen at once. I may have developed a special need caused by prolonged information overload, but I may have also learned how to improve focus.

Unfortunately, no style sheet will help people write clear and concise text. I continue to have to skim through lots of large text .


> There is a trend among web designers to use large, clear fonts and less clutter. I really like this style.

I don’t. Because typically these redesigns do away with visually distinct borders on tables/elements/zones and make everything flat and indistinct. Because that’s cool right now.

The new Kinguin frontpage is a very good example. I hate it.


I think this might be in part due to Edward Tufte's philosophy, as especially described in his book The Visual Display of Quantitative Information [1]. He uses "ink to data ratio" as a measure of the effectiveness of numerical charts. This superficially makes sense: why add more visual noise if it adds no more information? As an example, he suggesting shortening the axes on scatter plots to reflect the range of data in each dimension, which is a win-win: it adds more information and reduces ink. Boxes around objects and lines separating things are specifically called out as especially evil, since they add ink without contributing any information. I think this idea may have leaked from quantitative displays to general design.

The flaw of course is that more ink does not necessarily mean more visual noise. With the axes example, disconnecting them means that you now have two high-level visual objects rather than one, and the whole chart starts to looks like a mess of individual objects on the page. If you have several graphs next to each other then it's much easier to focus one and exclude the others if they're in boxes rather than having component objects floating indistinctly near each other. But Tufte only sees a count of black blobs of ink or black pixels, as if each one has its own mental cost.

As an aside, the book is still fantastic because it has loads of examples of unconventional charts and figures, and you can just ignore the text (or, better, read it skeptically). I found out about it from xkcd originally [2] and I suspect that many others did too.

[1] https://www.edwardtufte.com/tufte/books_vdqi

[2] https://xkcd.com/124/


Ah, the modern classic pattern of "the search box is the only part of the page that matters, and it's invisible"


I actually find this quite hard to read, partly the alignment so far to the right (not sure why that bothers me), but also the fonts - particularly the italic, to a lesser extent the regular. I found myself not very able to focus on the text at all.

I suppose as with most things your mileage may vary.


I have to say, I am particularly fond of the first example on this page: https://exclusive-design.vasilis.nl/the-defaults-suck/ .

"As you may see, when they reach the bottom of the screen the text of the link disappears behind the so called status bar. This is just one example of the broken state of default focus behaviour. There are many more. It shows that keyboard navigation is neglected by the people who build browsers as well."

This originated as part of a wider initiative to give us a "cleaner" browsing experience (part of the whole make-everything-flat-and-hide-it-behind-a-hamburger-menu) with less wasted space, by hiding the once always-present status bar (see http://toastytech.com/guis/ff15t.html ) and showing it only when needed. Kind of like GTK scroll bars today.

Like many other similar attempts, this fell flat on its face in the real world (for this and many other reasons), but the field of UI/UX design is still in a state where if you point out things like these, you're contemptuously told that this is how progress looks like and that consumers today want a functional look without extraneous widgets, and that it's a fringe case anyway. Punched cards are usually brought into discussion if you so much as utter the name "Netscape".

Edit: Reading this series makes me feel vindicated, I think?:-). See this: https://exclusive-design.vasilis.nl/design-like-its-1999/ .

<<This enables Simon to browse the archive and use it for his pleasure and his research. Simon was amazed. While he had tried many times before, he had never found these three thematic entrances to the 2Doc archive.

When I showed this design to Yuri Westplat, a colleague of mine and very experienced UX designer, he exclaimed: "this is what websites looked like in the nineties! Where did we go wrong?!">>


> I have to say, I am particularly fond of the first example on this page: https://exclusive-design.vasilis.nl/the-defaults-suck/ .

Also from the same page a very interesting point that I have not given much thought:

> Screen readers

> I’ve always assumed that adding detailed structural semantics to an HTML document is a good idea. I started to doubt if this is such a good idea when I observed casual computer users who depend on a screen reader. All elements that have some relevant semantic value, like heading levels, navigation items, links and forms get this meaning attached to it, which is spoken out loud. So this page would’t simply start with the title spoken out, but it would sound like heading level one, The defaults suck. When a page consist of many elements, things can become very annoying.


Yes, but read past the inline image:

> My impulsive reaction was to create websites without any structural semantics in them. Bram Duvigneau pointed out that, while this might indeed help some casual screen reader users, it would very much cripple the experience for experienced users.

I've thought about stripping away some HTML semantics to make screen reader navigation less "wordy." Navigation menus are often coded as unordered lists. I've considered not making them lists because I'll keep menu length manageable (no more than 7) and I know the screen reader will announce "link" plus the link text for every item; the separation between items should still be clear. But it might not be clear when they reached the end and it would be contrary to the norms users are familiar with; I wouldn't make this change without testing it with multiple real screen reader users.


That's a pain, but it seems better to fix the behavior of screen readers than destroy the structure of all the websites of the world.


As a user, I prefer to strip styling from a site. No need for who knows how many people around the world to tweak and retweak the fonts, especially when the top competing priority is brand signalling.

Soon you'll just be asking Siri things without knowing where information comes from, and the information will likely be derived from many sources, so crediting any single author becomes irrelevant in a world where many authors contribute to any result or answer.

While we are different human beings, we don't even have the same computer lenses. I believe the digital assistant will be the one homogeneous interface to rule them all. Everything should become an API, whether you're offering content or services.


In an utopia scenario you own the digital assistant. It is based on open source (even if deployed to cloud ) and you carefully curate the data sources is has access to.

In a dystopia version megacorporations own and control the digital assistant and can decide what information it feeds to you. It will become the marketer you trust, which has a significant influence on the decisions you do.


I'm not going to lie when I saw this in /New earlier -- I thought it's a great resource (time and effort) and gave it an upvote.

But, man, the design this page is using is anything but pleasant on the eye...


Huh? Can you describe what you experience as not pleasant here?

That being said, making the browser window less wide changes the design to a more readable variant.


It might just be me, but reading right-aligned paragraphs with all that white space to the left is quite painful. My eye naturally drawn the left edge of the page at the end of each line. It's a little better when you get to parts with the notes on the left, but even then the notes distract from the text they actually want me to read.


This is very important. More and more a11y functionalities are added to HTML5 and browsers, but I yet have to see them used / put in place. I've work at small and big companies, and this has never, _ever_, been a subject of discussion. From anyone.

I think most people are not even aware of neither the need, nor the features available to them, but let's be honest: it is more work to make a website accessible, and so it will rarely be put in a budget. We need laws, just like we have a11y laws for buildings, etc.


I'm generally supportive of accessibility requirements, but I'm not sure they're the only way we can get to where we want to be in this regard. GUI apps are generally much more accessible than Web apps are, but that's not because of legal requirements; it's because the vendors of GUI operating systems and widget toolkits took the time to make the parts of those things app developers used accessible out of the box. All you had to do to make your app accessible was color within the OS' lines and use the standard widgets. If you did that, you got accessibility for free.

The Web platform, on the other hand, has no standard widgets; everybody invents their own, and because making those widgets accessible requires more work, nobody does that. Things like Bootstrap are a step in the right direction in this regard, but are still a long way behind the things that GUI app developers were taking for granted 20 years ago.

If we want accessible Web apps, we need to make developing accessible Web apps easier than developing inaccessible ones.


We do have laws? Numerous companies in the US have been sued over their lack of website accessibility (the biggest was Target, the most recent Beyoncé). The same goes for EU states: Norway recently had a high-profile case and Tesco in the UK was forced to amend their site. The problem is that this approach doesn’t scale.


Yes, at least in North American and European countries, there are sufficient laws. In the U.S., there is already case law, like the Target case, that clearly established that the ADA's requirements for accessibility in "places of public accommodation" apply not only to brick and mortar places but websites as well. I'm not sure why this hasn't been sufficient for people to "get it," maybe because almost all cases are settled, rather than having actual rulings, and none have been been presented to the U.S. Supreme Court.

That being said, there is a need for more detailed guidance on what it means to make something accessible. For instance with video captions for the hearing impaired, is it ever okay to post a video then add the captions when they're done? Is it ever okay to post videos then add captions to each upon request; what if all the videos had automated captions, generally considered not sufficient, but could be fixed by humans upon request? If a video is of a single person speaking continuously, would a transcript be an adequate text alternative?


Every user has different abilities and preferences. A human designer can only consider a small subset of them. This is the reason why all interfaces we have go from terrible to mediocre.

User interface design and implementation has to be automated. The current paradigm doesn't scale, neither for providers nor users. It's perhaps software's main bottleneck.

This is not a new idea. I'm sure many people are working on this, but I still think this is something we don't talk about enough.


Generally, my policy with accessibility has been to let other people deal with it; specifically, the people making the software that your app/website/document will be using to display itself. It's pretty easy to make passable accessible apps if you use standard platform controls and lay them out in a standard way, or acceptable websites if you use HTML semantic tags properly.


The design and execution of the site is really terrible. The banner loads immediately then the content pops in after a 3-4 second delay.


The entire page loads instantly for me on Firefox and Chrome, admittedly on a decently fast connection. I tried using it on Chrome with the 'slow 3g' network speed and with cache disabled - in a few seconds the old page is replaced with a blank white screen, in a few more seconds the red background of the header shows up, and a few seconds later all the text renders at once.

What seems to be happening is that the page waits for the woff2 fonts to be downloaded before allowing the text to render. I recall also reading on HN that Google AMP has an 8 second timeout before it allows the page to be rendered, unless the AMP js scripts are all loaded first (so people who use content blockers effectively have an enforced 8s delay). Both are stupid techniques - sure, a user with good internet (and the web designers) will no longer see a split-second flash of text (on this website) or unstyled HTML (on AMP) before it switches to the new font - but it's effectively a mandatory delay for those who don't have this privilege. An improvement of 1% for the [rich and included] and a significant decrease in functionality for the [poor or excluded].


Every time this kind of post comes up it seems that the post itself suffers from numerous flaws. Maybe designers don't actually know how to design websites.


It's kind of ironic that firefox's reader mode can't render the page and it still honestly produces more readable output than the authors.


Awesome. Had to tweet it. Nice writeup, never thought about it.


a primer on design principals, which imo has some design-fails of its own. at least when viewing on mobile




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

Search: