Simple Does Not Mean Ugly
uglyduck.ca
uglyduck.ca
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.
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 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?
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.
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.
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.
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 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.
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.
A lot of desktop apps are basically packaged web apps now, so that's no surprise.
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.
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.
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.
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.
but, it is lightweight it is responsive and it works
Hero images are eyesores.
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 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.
Works fine.
the original motherfucking website is already perfect, no reaching for the reader mode.
That's very funny
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.
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?
Using e.g. Hugo you can generate nice static websites from markdown that are compact but not ugly.
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...
To be fair, it's not like I've found a better solution for styling checkboxes.
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.
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.
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 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.
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!
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.
[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.
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_...
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".
Surely that's not appropriate for every brand, though? Especially if you're trying to look cutting-edge.
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.
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!
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.
Buttons are great. We still press lots of them every day.
The only exception I can think of is that it's obviously a button if it uses system controls.
Those are a thousand times better than "buttons" that are just underlined text.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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... )