Simple Does Not Mean Ugly(uglyduck.ca)
uglyduck.ca
Simple Does Not Mean Ugly
https://uglyduck.ca/simple-does-not-mean-ugly/
130 comments
While I don't entirely disagree, how many web sites need the kind of features you're talking about? Have you ever looked at Hacker News and thought "if only this had user-definable menu shortcuts," or been shopping on Amazon and thought "this would be so much better if it had toolbars with custom icons"? Probably not.
One of the most frustrating things about modern web development, at least to cranky old people like me, is the conflation of web sites with web applications. If the use case you're talking about is truly trying to replace what would otherwise be a desktop application, like Gmail or (heaven help us) a code editor or word processor, then many of the features you're talking about start becoming useful. But for so, so many web sites, the focus on feature-rich client side toolkits has become, well, kind of a distraction. Is there any real advantage to the user if the New York Times web site is a state-of-the-art React application? Is it improving my reading experience? I not only don't need them to be using a toolkit that gives them desktop-class drag and drop capability, I don't want it, because I'm just there to read a damn article.
So when you write "web application UX designers are still re-inventing the wheel and without some enforced UI guidelines like Apple had in the 90s websites will never fully catch up with desktop apps in terms of usability," my reaction can't help but be: you literally just used "web application" and "website" as if they were interchangeable, and they are not. There's a worthwhile discussion to be had over how much "desktop-class UX" we actually need for our web applications, but I'd like to see our web sites stop being built like they were web applications when they don't need to be.
One of the most frustrating things about modern web development, at least to cranky old people like me, is the conflation of web sites with web applications. If the use case you're talking about is truly trying to replace what would otherwise be a desktop application, like Gmail or (heaven help us) a code editor or word processor, then many of the features you're talking about start becoming useful. But for so, so many web sites, the focus on feature-rich client side toolkits has become, well, kind of a distraction. Is there any real advantage to the user if the New York Times web site is a state-of-the-art React application? Is it improving my reading experience? I not only don't need them to be using a toolkit that gives them desktop-class drag and drop capability, I don't want it, because I'm just there to read a damn article.
So when you write "web application UX designers are still re-inventing the wheel and without some enforced UI guidelines like Apple had in the 90s websites will never fully catch up with desktop apps in terms of usability," my reaction can't help but be: you literally just used "web application" and "website" as if they were interchangeable, and they are not. There's a worthwhile discussion to be had over how much "desktop-class UX" we actually need for our web applications, but I'd like to see our web sites stop being built like they were web applications when they don't need to be.
Honestly, I have never wanted user-definable menu shortcuts on a 90's desktop application either. Each time I saw it, it was a crutch for making a badly designed menu a bit less worse, and things would be much better if the time spent on that feature was simply spent on a better menu.
Very few CAD programs gained something from customized menus (not icons). But this one was also almost always a crutch for fixing bad designs, and those same few programs always gained much more by having a good keyboard based interface.
Very few CAD programs gained something from customized menus (not icons). But this one was also almost always a crutch for fixing bad designs, and those same few programs always gained much more by having a good keyboard based interface.
Even if everyone is doing everything really well, there will always be the endless battle between "usability" aka having a few obviously-named-and-organized features that a new user can instantly understand (while severely limiting overall functionality) - think Asana task management software - vs. "flexibility" which is having all the features anyone could want which almost invariable leads to bloated incomprehensible menus that lead to menus that lead to more damn menus - think Jira or Salesforce.
I think non-enterprise sites/web apps are usually going to tack toward "usability" and enterprise sites/web apps are usually going to tack toward "flexibility".
I think non-enterprise sites/web apps are usually going to tack toward "usability" and enterprise sites/web apps are usually going to tack toward "flexibility".
There's a few times I've used macOS's ability to define menu shortcuts -- although it's generally either to add a shortcut to a menu item that didn't have one or to make the shortcut consistent with the OS and/or other applications. But in general, it's not something I think of as a critical missing feature in apps, you're right.
>”it had toolbars with custom icons"
This would be pretty cool, actually. Specially the AWS services where the icons are more or less divorced from what they’re supposed to represent.
This would be pretty cool, actually. Specially the AWS services where the icons are more or less divorced from what they’re supposed to represent.
That's true. Sort of like avatars for your specific services. :)
> How many websites have...
Honestly I'd settle for buttons that are obviously buttons and menus that aren't hidden by default.
A lot of web design has gone backwards in usability, especially since Google popularized Material design.
Honestly I'd settle for buttons that are obviously buttons and menus that aren't hidden by default.
A lot of web design has gone backwards in usability, especially since Google popularized Material design.
I think we hit a pretty good local maximum for website usability in the few years when "leftnav column, header, content" layouts all looked and worked basically the same and were the standard look for lots of sites. Granted they weren't mobile friendly ("what's mobile?") but at least you could figure out how a site worked pretty fast if they stuck to that.
I liked that era too, and I agree that mobile-unfriendliness is most of what killed it.
I do also think that the incentive of a designer is not to create those kinds of designs. Familiarity is often more usable, but if your designs are familiar, why hire you at all? Why not just copy a competitor?
I do also think that the incentive of a designer is not to create those kinds of designs. Familiarity is often more usable, but if your designs are familiar, why hire you at all? Why not just copy a competitor?
I Agree about usability regressing. One of the biggest I've seen is this trend towards two part login screens. Now rather than hitting my password manager button once, I have to do it twice, for no good reason. The "best" theory I heard was that the site is checking if you're SSO or not, but you can do that without two steps, just ignore the password and pas to SSO if they are, or use the password if the SSO check fails.
Shuttling the left-column navigation beneath the content, and preserving a minimal header, would preserve most of the functionality and remain mobile-friendly.
> How many websites have user-definable menu shortcuts, unlimited undo, instant user-feedback for every operation, tooltips that can be switched on or off, full internal drag & drop and OS-level drag and drop of files, standard user interface elements that work how the user expects them to work, a context-sensitive online help system, reconfigurable toolbars with user-definable icon sets, multiple open documents at once, movable and reconfigurable tool windows, manye internationalizations, and so on?
The reason you got all that stuff with desktop applications is that the designers of the platforms those applications ran on (Microsoft and Apple, mostly) included them in the platform by default. As long as you colored within the lines of the platform, your application would pick up all those nice features without you having to do any work to add them. You got them all "for free."
You could of course build a desktop application that didn't get those features by coloring outside the lines -- building your own GUI widget set rather than using the one the platform provided, for instance. But, and this is the important bit, that meant doing extra work, and most programmers (like most people) are lazy. They don't want to do extra work unless they really have to. So most developers stayed within the lines, and the platform rewarded them for doing so by giving them all these nice accessibility and usability benefits. The Lazy Way and the Right Way were deliberately aligned, and everybody benefited.
This is what the Web platform is missing: nobody has done the extra work to force the Lazy Way and the Right Way into alignment. The set of UI primitives the Web platform offers a developer is very small, and hasn't really changed since the late '90s. So the inevitable result is that everyone ends up building their own custom versions of everything -- and since people are lazy, those custom versions end up half-baked. They get just enough polish to address the most common cases, but things like accessibility and usability aren't deemed worth the extra effort they'd require to implement. So we get applications that feel broken compared to desktop apps.
What we need is a richer set of common primitives that are attractive enough to convince people to use them instead of rolling their own, and that also provide all those nice features you mentioned by default. We'll never get an accessible Web app ecosystem if we expect every developer to build accessibility for themselves. It only works if they get that stuff for free.
The reason you got all that stuff with desktop applications is that the designers of the platforms those applications ran on (Microsoft and Apple, mostly) included them in the platform by default. As long as you colored within the lines of the platform, your application would pick up all those nice features without you having to do any work to add them. You got them all "for free."
You could of course build a desktop application that didn't get those features by coloring outside the lines -- building your own GUI widget set rather than using the one the platform provided, for instance. But, and this is the important bit, that meant doing extra work, and most programmers (like most people) are lazy. They don't want to do extra work unless they really have to. So most developers stayed within the lines, and the platform rewarded them for doing so by giving them all these nice accessibility and usability benefits. The Lazy Way and the Right Way were deliberately aligned, and everybody benefited.
This is what the Web platform is missing: nobody has done the extra work to force the Lazy Way and the Right Way into alignment. The set of UI primitives the Web platform offers a developer is very small, and hasn't really changed since the late '90s. So the inevitable result is that everyone ends up building their own custom versions of everything -- and since people are lazy, those custom versions end up half-baked. They get just enough polish to address the most common cases, but things like accessibility and usability aren't deemed worth the extra effort they'd require to implement. So we get applications that feel broken compared to desktop apps.
What we need is a richer set of common primitives that are attractive enough to convince people to use them instead of rolling their own, and that also provide all those nice features you mentioned by default. We'll never get an accessible Web app ecosystem if we expect every developer to build accessibility for themselves. It only works if they get that stuff for free.
To be really fair, how many applications from around 2000 actually had all of that stuff you're describing.
I know that it was built into a lot of the default application toolkits at the time, but my recollection is that not every application supported everything. Sometimes the things that were supported didn't actually work very well and what actually happened was a bit of a surprise.
I know that it was built into a lot of the default application toolkits at the time, but my recollection is that not every application supported everything. Sometimes the things that were supported didn't actually work very well and what actually happened was a bit of a surprise.
>To be fair, a comparison with modern desktop apps is much more favorable, because most of them have regressed in terms of usability.
A lot of desktop apps are basically packaged web apps now, so that's no surprise.
A lot of desktop apps are basically packaged web apps now, so that's no surprise.
Very old and very relevant:
https://motherfuckingwebsite.com/
http://bettermotherfuckingwebsite.com/
And if you search for "motherfucking website", you'll find a million similar, satirical versions of a website inspired by that first one.
https://motherfuckingwebsite.com/
http://bettermotherfuckingwebsite.com/
And if you search for "motherfucking website", you'll find a million similar, satirical versions of a website inspired by that first one.
Is it bad that I unironically like the first one, actually more than the second one?
You might like https://bestmotherfucking.website
Yeah, this is the best one of these i've seen! Here's a SFW version too: https://www.goshdarnwebsite.com/
Nice. Usually people link https://thebestmotherfucking.website which is not better than "better motherfucking website" but seriously worse. This one was actually better.
> Your meme website isn’t as random as you think it is and will compress much faster.
That's very funny
That's very funny
agreed, the "better" motherfucking website wastes all that precious space with it's gloriously large and dumb margins around the text. the kind of silly idocy that makes me glad there's a reader mode to undo that crap.
the original motherfucking website is already perfect, no reaching for the reader mode.
the original motherfucking website is already perfect, no reaching for the reader mode.
I actually prefer the margins, as it doesn't force me to move my eyes so much. I know it sounds stupid, but that's why we have text wrapping containers.
It doesn't sound stupid. Readability declines as line length increases.
Except that goes against decades of studies that have shown that people read columns of text faster with better comprehension. So while you may prefer the column-less design, it is empirically worse.
Why would you think your user is not capable of resizing their rendering window? This seems to be a wide-spread notion in the ranks of the "responsive" design lads (where "responsive" means: choose one of those four fixed designs which do not react graciously on window resizes).
Tiled window managers make usually halving (or doubling) one dimension of your browser window just one key(combination-)press away...
Why should I care (assuming I'm a designer). If I make my column the correct width it would work no matter the size of the browser window. If they want to narrow it to the same size as the column they'd just see the column. But for those who didn't want to do that having the column helps them as well.
this is not about columns nor line lengths, it's about the width of the single column relative to screen size.
The problem is with hw vendors and their 16:9 aspect mania. That's way afar from what olden motherfuking screen glory was to begin with. Look at the ridiculous small space gmail leaves you to actually write your stuff.
If your "reader mode" doesn't have margins, it's not a reader mode.
the cool thing about it is that you can adjust it to your preferences.
This is the one advantage of the column-less layout... you can create your own column by resizing your browser where otherwise you don't get a vote, you get what they think is best.
I do too.
I'm biased for obvivious reasons, but:
https://codepen.io/dredmorbius/full/KpMqqB
https://codepen.io/dredmorbius/full/KpMqqB
Yeah, but can it really be good if you can't load the motherfuckingwebsite because your IT department blocked the website because it has a dirty word in it?
My IT department intercept TLS and break half of the internet in the process.
So they can get fucked in my opinion. I’m not convinced that the issue lies with the website.
Infantilising your users is exactly why contempt exists for sysadmins.
And I say that as a sysadmin.
So they can get fucked in my opinion. I’m not convinced that the issue lies with the website.
Infantilising your users is exactly why contempt exists for sysadmins.
And I say that as a sysadmin.
Sure but they are web pages, not websites. The distinction matters and does undermine the satire somewhat.
There’s a distinction between a website and a web app. Web pages and websites are synonymous.
No I meant those two pages are each a single, individual, isolated page. A website is a collection of web pages, usually structured (even if loosely).
So, to make it a website you just need some links on each page that let you get to the other pages. I don't see how that undermines the satire.
Because it's easy to make one webpage, but when you make a website, you immediately run into a huge wall of issues about consistency and navigability. For example, it's become a convention that in the upper-left of a website, there will be a logo that leads you to the homepage of the site. How do you do that with bettermotherfuckingwebsite?
Hugo or any other static page generator work perfectly for maintaining clean and consistent markup.
Since the location of the menu to go to other pages was a big part of the original post, I'd say in this context it's pretty relevant.
For a blog you can just have one "posts" page or similar, linked from every page, organized chronologically. Or even with anchor links to the same posts organized a few different ways. Then you also don't need a search function for searching post titles. Or to worry about paginating your list.
"But what about when there are a lot, won't that be too big?" Look at how much transfer & memory your favorite Javascript framework uses just to show up to the party, and get back to me. You'd have to blog a hell of a lot for it to even be a factor. An HTML list of text & links is small and compresses well.
"But what about when there are a lot, won't that be too big?" Look at how much transfer & memory your favorite Javascript framework uses just to show up to the party, and get back to me. You'd have to blog a hell of a lot for it to even be a factor. An HTML list of text & links is small and compresses well.
A collection of one item is still a collection. My website of a single page is still my website. It's also my web page.
https://danluu.com/
Works fine.
Works fine.
There can be many web pages on a single web site. And they may or may not be part of an web app.
[deleted]
Right. This page is also not interactive. I'd like to to see an interactive example that's also not an eye sore.
I thought you were joking, since the last time I saw craigslist it was hilariously awful looking.
But, actually, it seems super clear and easy to navigate and certainly doesn't hurt my eyes. I am really surprised that either my usability/design standards have dropped so massively, or craigslist has improved enough without an overhaul.
I'm note sure which is true.
But, actually, it seems super clear and easy to navigate and certainly doesn't hurt my eyes. I am really surprised that either my usability/design standards have dropped so massively, or craigslist has improved enough without an overhaul.
I'm note sure which is true.
Craigslist has slowly changed over the years with little tweaks here and there. It’s really fun to go through the Wayback Machine on it when people bring it up as an example of something that hasn’t changed.
I’m no designer, and I have lots of love for Craigslist, but ... does it qualify as ‘not an eyesore?’
It's a thing of beauty. Simple, functional, information dense, logical layout. I don't use craigslist, but pulling it up, it is immediately obvious what needs to be done and how to do it.
Hero images are eyesores.
Hero images are eyesores.
It's a thing of pure, unadulterated beauty in this day and age.
No. It's certainly an eye sore.
Is it?
I've never had any problem using Craig's List and it just works. There are no hamburgers, no material design, the dropdowns look like dropdowns, and the links look like links. I love Craig's List! It's one of the only shopping/marketplace websites I don't dislike.
My philosophy is that if you want it to have fancy CSS and skeuomorphic buttons, use a CSS extension and make your own CSS for it. Even better - use a browser that lets you edit a page's CSS in WYSIWYG (if there are any).
If Craig's List was suddenly revamped and looked like Amazon or Newegg, I would no longer use it.
I've never had any problem using Craig's List and it just works. There are no hamburgers, no material design, the dropdowns look like dropdowns, and the links look like links. I love Craig's List! It's one of the only shopping/marketplace websites I don't dislike.
My philosophy is that if you want it to have fancy CSS and skeuomorphic buttons, use a CSS extension and make your own CSS for it. Even better - use a browser that lets you edit a page's CSS in WYSIWYG (if there are any).
If Craig's List was suddenly revamped and looked like Amazon or Newegg, I would no longer use it.
agreed it is eyesore.
but, it is lightweight it is responsive and it works
but, it is lightweight it is responsive and it works
What's the distinction?
More than one page. Sounds trivial, but having more than one web page also means you'll have navigation, which is much more challenging on default browser styles than simple document markup.
It's almost a shame the idea of having a sitemap.xml which the browser could parse and provide native navigation for never took off.
Of course it didn't because native controls are the first thing any designer changes because native controls on the web were always associated with amateur websites.
Of course it didn't because native controls are the first thing any designer changes because native controls on the web were always associated with amateur websites.
To be fair native controls were total ass for years. And still kind of are. Doubly so if you're trying to build an "app". Basic crap any half-decent UI toolkit would provide out of the box, just not there at all. The stuff that is there's often not great.
It seems like as soon as it became common to work around problems with HTML ui in Javascript, the already-slow work to improve the standard appearance and functionality of HTML websites dropped to almost zero. We got some alright semantic-markup stuff after that but it took forever to even get a couple layout primitives that are non-terrible.
It seems like as soon as it became common to work around problems with HTML ui in Javascript, the already-slow work to improve the standard appearance and functionality of HTML websites dropped to almost zero. We got some alright semantic-markup stuff after that but it took forever to even get a couple layout primitives that are non-terrible.
When did beauty become something we loathe? Any attempt to make something look nice invites scorn from the programmer community. Get out of here with your styling and your white space, we only want to see black text on a white background.
I mean, I get it -- it's about load times, readability, accessibility, yadda yadda. But does that really mean everything has to look like shit? Why is it a binary choice?
"Well, I actually think that motherfuckingwebsite looks good. It's beautiful in its simplicity."
Fair call, there's no accounting for taste. But does this attitude also extend to, say, public spaces? What about architecture? Should a house be designed like motherfuckingwebsite.com?
I mean, I get it -- it's about load times, readability, accessibility, yadda yadda. But does that really mean everything has to look like shit? Why is it a binary choice?
"Well, I actually think that motherfuckingwebsite looks good. It's beautiful in its simplicity."
Fair call, there's no accounting for taste. But does this attitude also extend to, say, public spaces? What about architecture? Should a house be designed like motherfuckingwebsite.com?
If a house is hard to live in, does it really matter how beautiful it is?
You can make beautiful static websites with almost no extra load. Just add a little CSS.
Using e.g. Hugo you can generate nice static websites from markdown that are compact but not ugly.
Using e.g. Hugo you can generate nice static websites from markdown that are compact but not ugly.
Look, I wouldn't want to live in a "beautiful" house that didn't have a bathroom. But your response also kind of demonstrates my point, which is that somewhere along the way we decided that beauty was the antithesis of usability. My suggestion is that they can coexist.
Usability != Aesthetics. "Ugly" it's an inaccurate term for what this person is trying to explain or argue here. If you ask me, I find the website of the article quite ugly. But that doesn't mean it's not usable and simple.
> I’m saying that you shouldn’t hide the elements themselves just to replace them with mimicking components...
I've fallen into this trap before. It's easy to make a component that's just a little different than a default HTML field e.g. a text input with auto-complete. If you start disabling/hiding the underlying input element, accessibility drops massively...
I've fallen into this trap before. It's easy to make a component that's just a little different than a default HTML field e.g. a text input with auto-complete. If you start disabling/hiding the underlying input element, accessibility drops massively...
It's funny that he says that, then suggests using Normform instead, which very much hides checkboxes to replace them with mimicking components.
To be fair, it's not like I've found a better solution for styling checkboxes.
To be fair, it's not like I've found a better solution for styling checkboxes.
Yeah, checkboxes simply need better theming support. Hiding them is not good, but also having them break consistency and sticking out like a sore thumb because there's no way to skin them is also not good
Completely agree! I've been meaning to jump back into that project and try some new things (maybe pull back on some of the custom styling even). It has been quite a while since I've updated that repo...
I'd love to see styling guides for very large forms, hundreds of inputs, intended for rapid data entry. They've been a major part of my job for a few decades and I have plenty of thoughts on the subject, but I'm not super happy with any of them.
Things like Normform look great for basic forms, but when the entire screen is filled with inputs, so much uniformity and white space seems to hinder navigation and input speed.
Things like Normform look great for basic forms, but when the entire screen is filled with inputs, so much uniformity and white space seems to hinder navigation and input speed.
I'm curious about why the entire screen is filled with inputs. Is it because the job is complicated, and the user should be highly skilled and trained?
The user is, or will quickly be, very familiar with the forms. The forms have been the same for decades, some users have even been using them that long. They occasionally need to jump around the form to reference other data so tabs and wizards slow them down.
Also, the forms are filled out differently based on customer defined rules which vary widely and change frequently, especially around qualitative questions. For large, long-term projects, the final form is hidden, qualitative questions are turned into multiple quantitative questions and mapped to the final answer so the user doesn't have to constantly think about the custom rules. But for small projects, it's too much development work and the user is expected to follow the rules manually.
Also, the forms are filled out differently based on customer defined rules which vary widely and change frequently, especially around qualitative questions. For large, long-term projects, the final form is hidden, qualitative questions are turned into multiple quantitative questions and mapped to the final answer so the user doesn't have to constantly think about the custom rules. But for small projects, it's too much development work and the user is expected to follow the rules manually.
Rapid data entry and Web app/site/page cannot be put in the same sentence.
From experience I agree, but is it impossible or are the current frameworks just lacking?
Usually some terminal UI is the best for rapid data entry, which is why a shop I used to work at switched back to their TUI because the shiny new GUI was blocking everything.
The TUI you had to learn and the GUI was intuitive, but after a week anybody could use the TUI at the same speed and after a month they'd 10x or and soon 100x the entry speed.
Usually some terminal UI is the best for rapid data entry, which is why a shop I used to work at switched back to their TUI because the shiny new GUI was blocking everything.
The TUI you had to learn and the GUI was intuitive, but after a week anybody could use the TUI at the same speed and after a month they'd 10x or and soon 100x the entry speed.
"The hamburger is a great example of “ugly simple”. You are purposely hiding the main structure that allows your users to move around your product freely behind an additional interaction. That is the opposite of simple."
The author appears to be confusing two forms of simplicity. The burger bar isn't there to simplify the number of user actions to navigate. It's there because navigation is not the main mode of interaction, rather a side-affair. Always showing that content actually increases the visual clutter and cognitive load placed on the user for ALL their interactions.
The author appears to be confusing two forms of simplicity. The burger bar isn't there to simplify the number of user actions to navigate. It's there because navigation is not the main mode of interaction, rather a side-affair. Always showing that content actually increases the visual clutter and cognitive load placed on the user for ALL their interactions.
May be slightly relevant to the topic
worst kind of embedded video seen so far
https://womenhack.com/events/#eb-events-section-title
why is that video running behind a text?? (only on a desktop, it doesn't show up on mobile)
It makes me dizzy as soon as I start reading the text. I can't finish reading!
worst kind of embedded video seen so far
https://womenhack.com/events/#eb-events-section-title
why is that video running behind a text?? (only on a desktop, it doesn't show up on mobile)
It makes me dizzy as soon as I start reading the text. I can't finish reading!
Sorry, but those buttons are absolutely atrocious. I get that underlined links aren't that great, but I'd much prefer it to that. Or maybe something like this: https://dribbble.com/shots/7299868-Download-Buttons
You've linked to animated download buttons. Are you being serious?
What's wrong with it being a download button? Does it have to be a "Cancel" or "Yes" button for the example to apply?
But sure, they're animated. I'm referring to the design of the buttons, not the animations. Try this on for size: https://dribbble.com/shots/5915773-Unlock-calls
I don't get this obsession with Skeumorphism. IMO it's not a good look and should be left in the 2000's.
But sure, they're animated. I'm referring to the design of the buttons, not the animations. Try this on for size: https://dribbble.com/shots/5915773-Unlock-calls
I don't get this obsession with Skeumorphism. IMO it's not a good look and should be left in the 2000's.
The very word 'button' is is a skeuomorphism referring to a physical object. There is nothing wrong with visual cues hinting at a physical button if you are going to call the object a button.
A lot of hate for skeumorphism comes from using ux that resemble or preserve obsolete physical objects. Like floppy disks, corded desk phones, flip phones or analog clocks.
Buttons are great. We still press lots of them every day.
Buttons are great. We still press lots of them every day.
Personally, I find that animated buttons scream "ads" to me. And animated "download" buttons scream "malware ads"!
Buttons are for pressing, not for displaying information.
I think the buttons are a little much, but they are also very obviously buttons, which is good for usability.
> very obviously buttons
They might not be to some non-tech-savy people... If you don't understand the concept of a virtual button that thing might just look like a rounded, blue rectangle with text in it. Nothing hints that it is supposed to be touched, it might as well just be some kind of highlighting.
They might not be to some non-tech-savy people... If you don't understand the concept of a virtual button that thing might just look like a rounded, blue rectangle with text in it. Nothing hints that it is supposed to be touched, it might as well just be some kind of highlighting.
Sure, but I think something like this: https://dribbble.com/shots/5915773-Unlock-calls is just a obviously a button. I might be wrong.
You can't decide whether it's "obviously a button" in isolation. Depends entirely on how that particular element fits into the rest of the page.
The only exception I can think of is that it's obviously a button if it uses system controls.
The only exception I can think of is that it's obviously a button if it uses system controls.
Things that look real-world buttons or switches are more obviously a button in isolation than things that require a lot of context. Things can look "pressable" without context.
Those are quite obviously buttons. The difference is the design is flat versus the style in the post.
Those are a thousand times better than "buttons" that are just underlined text.
Those are a thousand times better than "buttons" that are just underlined text.
Or simply bold blue text.
[deleted]
Test test test test test.
I'm no UI pro but there's one thing I'm confident in saying through my experience and it's that you can't be certain something is intuitive until you've tried it on real people in a real scenario.
Your example button is fine with me but I feeling like it's the sort of thing that would confuse my mother. Acceptable depending on your app but I'm guessing that's Skype or similar and the 60+ market is probably important for them. But maybe I'm wrong, test test test.
I'm no UI pro but there's one thing I'm confident in saying through my experience and it's that you can't be certain something is intuitive until you've tried it on real people in a real scenario.
Your example button is fine with me but I feeling like it's the sort of thing that would confuse my mother. Acceptable depending on your app but I'm guessing that's Skype or similar and the 60+ market is probably important for them. But maybe I'm wrong, test test test.
I strongly disagree that it's obviously a button.
Lots of websites use that little pill shape for other things.
A button should announce that it is clickable, while the rest of the UI isn't. Just because something has a different background and shape doesn't tell me it's clickable.
Lots of websites use that little pill shape for other things.
A button should announce that it is clickable, while the rest of the UI isn't. Just because something has a different background and shape doesn't tell me it's clickable.
Many of your users would probably disagree.
Many of Hacker News visitors would probably disagree. What most of us don't seem to understand is what Hacker News says is not the common statement of most. People here tend to be on the less design side of things, most on the can I use this entirely with my keyboard. Most of the population however is not like that.
I don't see any statistics that the average user has any preference over which button to use out of the 3 examples provided. I think most users would assume buttons are supposed to look like the sites/apps they visit/use most, amazon, facebook, google, instagram, etc. If you button functions similar to those examples your users would be happy.
I don't see any statistics that the average user has any preference over which button to use out of the 3 examples provided. I think most users would assume buttons are supposed to look like the sites/apps they visit/use most, amazon, facebook, google, instagram, etc. If you button functions similar to those examples your users would be happy.
Normal users tend to be "less on the design side" when it comes to actual usability. They might (or might not—I don't think most companies bother to find out) care that you came up with some hot-shit pretty design that impressed the VPs, but for UX the more "designery" your site the greater the odds it'll be hard for normal people to use.
[EDIT] which is to say I think a lot of application design hours/$s have more to do with cargo-cult "brand styling" from the marketing department, and internal promotion of a project + personal portfolio-building and design-insider signaling than with benefits to end-user marketing, sales, or usability. It's not all useless from that perspective, obviously, but I'm very confident a lot of it is.
[EDIT] which is to say I think a lot of application design hours/$s have more to do with cargo-cult "brand styling" from the marketing department, and internal promotion of a project + personal portfolio-building and design-insider signaling than with benefits to end-user marketing, sales, or usability. It's not all useless from that perspective, obviously, but I'm very confident a lot of it is.
> People here tend to be on the less design side of things, most on the can I use this entirely with my keyboard.
Wrong dichotomy. "Design" is not about the amount of eye-candy. Design is about how to make a product so that the user can use it most effectively. Making it visually appealing is an integral part of that, but only part of it.
https://en.wikipedia.org/wiki/Dieter_Rams#%22Good_design%22_...
Wrong dichotomy. "Design" is not about the amount of eye-candy. Design is about how to make a product so that the user can use it most effectively. Making it visually appealing is an integral part of that, but only part of it.
https://en.wikipedia.org/wiki/Dieter_Rams#%22Good_design%22_...
Really? I personally doubt users would prefer Skeuomorphic buttons. I know most of my friends are hit by nostalgia when they see something Skeuomorphic, sort of a "Remember when things were this way?", and I honestly do not want any of my products to perpetuate this emotion.
> I personally doubt users would prefer Skeuomorphic buttons.
I personally doubt users would know the word Skeuomorphic, let alone care what the button looks like.
> and I honestly do not want any of my products to perpetuate this emotion.
Why would you not want nostalgia? There are entire product brands built on taking advantage of nostalgia.
And nostalgia doesn't even imply "Hah, this is old and inferior".
I personally doubt users would know the word Skeuomorphic, let alone care what the button looks like.
> and I honestly do not want any of my products to perpetuate this emotion.
Why would you not want nostalgia? There are entire product brands built on taking advantage of nostalgia.
And nostalgia doesn't even imply "Hah, this is old and inferior".
> Why would you not want nostalgia? There are entire product brands built on taking advantage of nostalgia.
Surely that's not appropriate for every brand, though? Especially if you're trying to look cutting-edge.
Surely that's not appropriate for every brand, though? Especially if you're trying to look cutting-edge.
I think it genuinely depends on what your users are nostalgic over.
You can look cutting edge while taking advantage of nostalgia.
To be entirely honest, the "flat design" doesn't look "cutting-edge". It looks basic, which is because, well. It is. Intentionally so. If users don't care what your buttons look like, why spend tons of time making them look a specific style. That's just more time spent.
I'd argue that the reason it's become so prevalent, is exactly that. Less time spent designing, more time spent on features.
You can look cutting edge while taking advantage of nostalgia.
To be entirely honest, the "flat design" doesn't look "cutting-edge". It looks basic, which is because, well. It is. Intentionally so. If users don't care what your buttons look like, why spend tons of time making them look a specific style. That's just more time spent.
I'd argue that the reason it's become so prevalent, is exactly that. Less time spent designing, more time spent on features.
> Really? I personally doubt users would prefer Skeuomorphic buttons.
Have you tested this assumption, or is it simply something that you suspect? There's nothing wrong with having an opinion, but don't mistake it for an analysis!
Have you tested this assumption, or is it simply something that you suspect? There's nothing wrong with having an opinion, but don't mistake it for an analysis!
Agreed 100%! Which is why I made sure to write that it was my personal assumption.
I found the article to be frustratingly light on details and examples. Does anyone have more to contribute here?
This probably isn't quite what you're looking, for but I wrote a post back in 2017 that might touch on these items a bit more? https://uglyduck.ca/death-of-personality/ (it's more of a "hot take" on flat design trends making for poor design in general)
There are some good examples of what not to do. Your button state example is the best.
I agree with you that they've turned the dial too far.
I'm hoping someone has a good collection of examples where the designer chose obvious interactions and visuals instead of something "clever" and it turned out well.
I agree with you that they've turned the dial too far.
I'm hoping someone has a good collection of examples where the designer chose obvious interactions and visuals instead of something "clever" and it turned out well.
It's a strawman version of a blog post. It argues against trivial issues that are inflated into something they aren't.
As a leader that manages both design and engineering teams I feel worse sin is being committed by the latter these days through unnecessary complexity in front end technology usage.
> Your job as a designer is to focus on the user experience journey and understand what those users expect to happen - not what you want to happen. This is a very delicate balance of design “give and take”, hence why simple designs always seem to work best.
Interesting. Why not give users exactly what they want and make it easy by using standard patterns they see on all the consumer products they use?
Interesting. Why not give users exactly what they want and make it easy by using standard patterns they see on all the consumer products they use?
This article seems a little biased as the two images shown for example - one flat and one with gradients and reflections are poorly picked.
The flat one is clearly a better designed one and the gradient/reflection one is a badly designed and there are better examples the writer of the article could've chosen, but I think they picked it on purpose to back up their subjective opinion.
The flat one is clearly a better designed one and the gradient/reflection one is a badly designed and there are better examples the writer of the article could've chosen, but I think they picked it on purpose to back up their subjective opinion.
This comes off as excessively ranty.
That said, if you replace the word "ugly" with "unintuitive", the points are mostly valid, if not particularly original.
#2 bothered me though, because while I've seen overly-simplified buttons that were just colored text without a border, I've never seen ones where the text was underlined. Underlined colored text is still respected as the absolute universal signifier of a link. Now, some sites do remove those underlines on links which can create interference with other sites where non-underlined colored text is a button. But still, he should've used a more realistic example of the actual problem instead of a straw-man.
That said, if you replace the word "ugly" with "unintuitive", the points are mostly valid, if not particularly original.
#2 bothered me though, because while I've seen overly-simplified buttons that were just colored text without a border, I've never seen ones where the text was underlined. Underlined colored text is still respected as the absolute universal signifier of a link. Now, some sites do remove those underlines on links which can create interference with other sites where non-underlined colored text is a button. But still, he should've used a more realistic example of the actual problem instead of a straw-man.
> Simple Does Not Mean Ugly
Sure, but that's obvious.
Simplicity of use and the simplicity of appearance are two different things. Of course, one doesn't mean the other.
Sure, but that's obvious.
Simplicity of use and the simplicity of appearance are two different things. Of course, one doesn't mean the other.
Counterexample: the Apple watch design.
The header font is way too cramped. Simple is fine sure, but poor font pairing is indeed uncomfortable to look at.
This blog looks so beautiful
Still have overly complicated animations on his blog :hover.
the ugliest part of the site imo is the super dark borders around the code snippets near the bottom. Should have kept it simpler
The author’s CSS form project seems interesting:
https://normform.netlify.com/
https://normform.netlify.com/
Honestly it seems terrible and wrong according to most popular user experiments on web forms.
1. Error messages are non existant, all that shows is a redish/pink badge on the left. Which a color blind person may have trouble finding a difference from the blue one above. Also gives no indication as to what is wrong? Email missing a ., shows a red. Hard to say what exactly the error is without further details. And honestly errors are the biggest and most important part of any form. Good quality errors with clear messaging will go miles above any other "improvement".
The number one biggest annoyance is filling out a form only to get an error with something you didn't know needed to be done or you did incorrectly.
Rules are simple
- Keep already in inputted date
- Try and indicate as clearly as you can what the error is
- Show the user to the error (if it's one maybe focus that element)
- Help the user fix the error by offering suggestions, things like if a user types @gmial.com maybe say are you sure it isn't @gmail.com?)
- If you are gonna hide forms in an accordion like checkout experiences, let me go back. And show something that indicates that section is good to go. Real time validation is really good. But PLEASE KEEP it the same as on the backend. Nothing worse then getting a checkmark on the front only to get an error after submitting from the backend.
- KEEP THE ALREADY ENTERED DATA EXACTLY AS IT WAS I cannot stress this enough. The amount of times I've closed a website after entering a form and having all my data cleared from an error is more then enough.
2. There is WAYYYY to much space between each element.
3. The font is small, you should be using larger then size 12px font on forms. At least 14px.
4. The implied "success" is a green border, however the dropdown does not turn green on selecting an option. So it does not look correct.
5. The hover/focus state on the buttons is a slightly bigger light grey box shadow. Hard to read, and hard to know what is focused.
6. Checkbox/radio group has no tab function, you cannot tab to it.
I could go on and on, and I'm not even that skilled with UX.
Also it breaks default styles for several other html 5 input elements, because it targets "input" rather than specific input elements.
Honestly if you want alright base styles that look good just use Bootstrap, at least it handles focus states correctly.
1. Error messages are non existant, all that shows is a redish/pink badge on the left. Which a color blind person may have trouble finding a difference from the blue one above. Also gives no indication as to what is wrong? Email missing a ., shows a red. Hard to say what exactly the error is without further details. And honestly errors are the biggest and most important part of any form. Good quality errors with clear messaging will go miles above any other "improvement".
The number one biggest annoyance is filling out a form only to get an error with something you didn't know needed to be done or you did incorrectly.
Rules are simple
- Keep already in inputted date
- Try and indicate as clearly as you can what the error is
- Show the user to the error (if it's one maybe focus that element)
- Help the user fix the error by offering suggestions, things like if a user types @gmial.com maybe say are you sure it isn't @gmail.com?)
- If you are gonna hide forms in an accordion like checkout experiences, let me go back. And show something that indicates that section is good to go. Real time validation is really good. But PLEASE KEEP it the same as on the backend. Nothing worse then getting a checkmark on the front only to get an error after submitting from the backend.
- KEEP THE ALREADY ENTERED DATA EXACTLY AS IT WAS I cannot stress this enough. The amount of times I've closed a website after entering a form and having all my data cleared from an error is more then enough.
2. There is WAYYYY to much space between each element.
3. The font is small, you should be using larger then size 12px font on forms. At least 14px.
4. The implied "success" is a green border, however the dropdown does not turn green on selecting an option. So it does not look correct.
5. The hover/focus state on the buttons is a slightly bigger light grey box shadow. Hard to read, and hard to know what is focused.
6. Checkbox/radio group has no tab function, you cannot tab to it.
I could go on and on, and I'm not even that skilled with UX.
Also it breaks default styles for several other html 5 input elements, because it targets "input" rather than specific input elements.
Honestly if you want alright base styles that look good just use Bootstrap, at least it handles focus states correctly.
I've been meaning to look-over Normform again (since it's been a while since I've touched it) and these are excellent points. I'll be looking to remedy these issues in the next iteration. Thank you!
Not to detract from a very good rant, on a site design which exemplifies and models its message, but the most critical element for design to me is that design complexity should be appropriate to the problem domain.
Note that in most cases, the problem domain is relatively simple, and the design should reflect this.
Also: the design AND problem domain should have minimal sufficient complexity.
But beyond that, I see several specific cases of obviously bad design:
- The design is needlessly complicated. It is excessivly complex for the problem domain.
- The design is insufficiently expressive. It is overly simplified for the problem domain.
- A variant of the second: the design sweeps complexity under the rug. Usually a small area pattern with three horizontal lines. A/k/a, if you're relying on a Hamburger Menu (or its diet power-yoga version, the kebab menu), you've probably got a Complexity Impedence Mismatch Problem.
Cases of design insufficient to a problem domain are ... well, pretty much anything which requires repeatitive actions on more than about 10 elements at a time. If your interface can present me with 10s, 100s, 1,000s, or more, elements or options, and there is no way to meaningfully group or class those actions, then you have insufficient design capability. You've created an appearance of simplicity by squooshing the complexity into the user-site (or -app) interaction.
Power-user tools are examples of more complex, but also infinitely more capable designs. As a long-time user of tools such as vim, mutt, awk, etc., a small number of advanced capabilities allow me to work with ... 10s to 100s of thousands of emails, millions of files, documents numbering in the thousands (or more) printed pages, etc.
Contrast, as a totally random example, Google Chrome/Android, in which managing open tabs becomes effectively impossible at counts above 10-20 open tabs -- a milestone I can achieve in seconds after starting a new session.
My Firefox session, on a desktop, using Tree-Style Tabs, has 1,530+ tabs open (among other features: the browser includes reporting, buried, but available, of open tabs. I literally do not know the equivalent count on my Chrome session, it's not available).
The count is, admittedly, high.
*But the browser remains useful and usable, and (given time to go through and process the tabs), I can in theory deal with the overage. I can at least identify and contain the parts of the session associated with various projects.
Firefox's "Pocket" article archiver is an example of a tool exceedingly poorly matched to its problem domain. I have ~15,000 articles saved within the system. The browser is actually more useful than the putative archival tool.
(I've written on Pocket's many failings: https://old.reddit.com/r/dredmorbius/comments/5x2sfx/pocket_...)
Also: bradley_taunt: "if you" should be "if your", typo.
Note that in most cases, the problem domain is relatively simple, and the design should reflect this.
Also: the design AND problem domain should have minimal sufficient complexity.
But beyond that, I see several specific cases of obviously bad design:
- The design is needlessly complicated. It is excessivly complex for the problem domain.
- The design is insufficiently expressive. It is overly simplified for the problem domain.
- A variant of the second: the design sweeps complexity under the rug. Usually a small area pattern with three horizontal lines. A/k/a, if you're relying on a Hamburger Menu (or its diet power-yoga version, the kebab menu), you've probably got a Complexity Impedence Mismatch Problem.
Cases of design insufficient to a problem domain are ... well, pretty much anything which requires repeatitive actions on more than about 10 elements at a time. If your interface can present me with 10s, 100s, 1,000s, or more, elements or options, and there is no way to meaningfully group or class those actions, then you have insufficient design capability. You've created an appearance of simplicity by squooshing the complexity into the user-site (or -app) interaction.
Power-user tools are examples of more complex, but also infinitely more capable designs. As a long-time user of tools such as vim, mutt, awk, etc., a small number of advanced capabilities allow me to work with ... 10s to 100s of thousands of emails, millions of files, documents numbering in the thousands (or more) printed pages, etc.
Contrast, as a totally random example, Google Chrome/Android, in which managing open tabs becomes effectively impossible at counts above 10-20 open tabs -- a milestone I can achieve in seconds after starting a new session.
My Firefox session, on a desktop, using Tree-Style Tabs, has 1,530+ tabs open (among other features: the browser includes reporting, buried, but available, of open tabs. I literally do not know the equivalent count on my Chrome session, it's not available).
The count is, admittedly, high.
*But the browser remains useful and usable, and (given time to go through and process the tabs), I can in theory deal with the overage. I can at least identify and contain the parts of the session associated with various projects.
Firefox's "Pocket" article archiver is an example of a tool exceedingly poorly matched to its problem domain. I have ~15,000 articles saved within the system. The browser is actually more useful than the putative archival tool.
(I've written on Pocket's many failings: https://old.reddit.com/r/dredmorbius/comments/5x2sfx/pocket_...)
Also: bradley_taunt: "if you" should be "if your", typo.
"User experience design" is one of the most pretentious titles that Design (with a big D in front) has ever appropriated. As if a designer (little d) can really design an experience... Experiences unfold in realtime, shaped by a multitude of forces which the designer could never predict or even begin to comprehend.
This article reminds us to focus on what Design (big D) once knew when our practice focused on interactions and augmenting human intellect... affordances, feedback, loops.
Seeing my parents and peers struggle with understanding iOS or dealing with shitty bank websites makes me feel that we lost our way somewhere. Maybe one day we will return.
This article reminds us to focus on what Design (big D) once knew when our practice focused on interactions and augmenting human intellect... affordances, feedback, loops.
Seeing my parents and peers struggle with understanding iOS or dealing with shitty bank websites makes me feel that we lost our way somewhere. Maybe one day we will return.
I would argue that what you're seeing with bad design is not the fault of UX design as a concept but rather specific examples where it failed. UX designers are supposed to help ensure that software is usable and frustration free. If the software fails to achieve those things, then either the UX designer has failed or has been overridden by someone else. Or it's consensus design. The UX designers job us not to make things prettier or more sexy than usable, because sacrificing usability with frustrate people, which is something they should understand and apply.
Sorry but as a UxD of 15+ years, that is exactly what I and my team do. It is entirely possible and reasonable for a little d designer to understand and account for the realtime forces that affect a user in context.
The problem is three-fold. First, is that UxD has become a catch all for any digital designer (it took me 8 months to hire 2 qualified UxDs). Second, most companies simply don't pay for professional design talent.
I can tell you with certainty that banks pay between 30% and 50% of market rate for senior design talent. Most mobile app startups pay slightly less than that.
Third is that we don't write the code. We can only recommend what a developer should build and what a stakeholder should prioritize. I've watched both sandbag good design in favor of more features more times than I can count. I've watched both sandbag good design because there was no percieved business value more than once. I've had so many countless conversations with developers who wouldn't do the work because they didn't know how to implement a design and wouldn't admit their knowledge gap.
A true UxD who can cover interaction, behavioral psychology, kinesiology, aesthetics, workflow, accessibility, information architecture and basic research methods can command good money that most companies outside FAANG aren't willing to spend.
The problem is three-fold. First, is that UxD has become a catch all for any digital designer (it took me 8 months to hire 2 qualified UxDs). Second, most companies simply don't pay for professional design talent.
I can tell you with certainty that banks pay between 30% and 50% of market rate for senior design talent. Most mobile app startups pay slightly less than that.
Third is that we don't write the code. We can only recommend what a developer should build and what a stakeholder should prioritize. I've watched both sandbag good design in favor of more features more times than I can count. I've watched both sandbag good design because there was no percieved business value more than once. I've had so many countless conversations with developers who wouldn't do the work because they didn't know how to implement a design and wouldn't admit their knowledge gap.
A true UxD who can cover interaction, behavioral psychology, kinesiology, aesthetics, workflow, accessibility, information architecture and basic research methods can command good money that most companies outside FAANG aren't willing to spend.
> I've watched both sandbag good design because there was no percieved business value more than once.
Riffing on the article title: Simple Does Not Mean Deficient.
“Star had many fewer commands than today’s systems, and it didn’t do it by having fewer functions. It just had fewer commands.” — Dave Smith at The Final Demonstration of the Xerox ‘Star’ Computer (video: https://www.youtube.com/watch?v=_OwG_rQ_Hqw text: http://archive.computerhistory.org/resources/access/text/201... )
Riffing on the article title: Simple Does Not Mean Deficient.
“Star had many fewer commands than today’s systems, and it didn’t do it by having fewer functions. It just had fewer commands.” — Dave Smith at The Final Demonstration of the Xerox ‘Star’ Computer (video: https://www.youtube.com/watch?v=_OwG_rQ_Hqw text: http://archive.computerhistory.org/resources/access/text/201... )
As a ux designer it can also be incredibly hard to find a job that's doing actual ux research. When I worked as a UX designer every boss just wanted me to confirm a design is "user friendly" instead of taking the time to research user flows and designing behaviour.
How many websites have user-definable menu shortcuts, unlimited undo, instant user-feedback for every operation, tooltips that can be switched on or off, full internal drag & drop and OS-level drag and drop of files, standard user interface elements that work how the user expects them to work, a context-sensitive online help system, reconfigurable toolbars with user-definable icon sets, multiple open documents at once, movable and reconfigurable tool windows, manye internationalizations, and so on?
The web is still the future, I know, but web application UX designers are still re-inventing the wheel and without some enforced UI guidelines like Apple had in the 90s websites will never fully catch up with desktop apps in terms of usability.
To be fair, a comparison with modern desktop apps is much more favorable, because most of them have regressed in terms of usability.