Programmers make mistakes in the category of "why didn't they learn from other people's mistakes?" in large projects all the time. In any project of sufficient complexity (not exclusively programming projects), you'll inevitably find something that falls into that category. I've typically seen this type of error as the result of trying to balance trade-offs of the "you had to be in the room at the moment" sort, and then you fix it later when it's a real issue for you.
I like that this post points out the issue, and I hope it gets fixed.
I think more importantly, given the growth rates of our industry, an average programmer or designer has less than 2-3 years of any kind of experience in building software, therefore they didn't have time to learn about, much less from, other people's mistakes.
> The question is why material design didn't learn from other people's mistakes.
While reading the original material design spec, it seemed enlightened, but now its clear it's more of a standard than a best-practice. Its by no means the "best" design, just like the qwerty keyboard wasn't the best. However, due to a huge marketing push by google, it's now considered a standard and if you do not conform, you'll look weird. Not so different than in the 1990s, if you had a Windows application without a "file" drop-down menubar, you would also be considered weird.
Material design should not be thought of as an optimal design approach, it should be thought of as a standard to rally behind. If you build something adhering to the standard, regardless of whether it's a good or bad design choice, users will understand it because they have already been it by Google.
If you have something that's better, it may be rejected simply because folks weren't already trained on it.
Before Material Design, Android UI was highly inconsistent. I was used to the inconsistency on my Gingerbread phone but I really appreciated the MD upgrade. Using F-droid brought back all those old UIs.
The old style material field which were mentioned that are just an underlined text instead of a box were absolutely terrible too. It's disgusting that someone would actually think those were a good idea.
Also, what he calls out in the end, use high contrast guys! The old material design grey text on grey background was terrible to read. GCP used to be full of this.
To be honest, Adresse de courrier électronique professionnelle would probably look awkward on any kind of interface that is optimized for Work email address, and vice versa. Is there any shorter equivalent in French? In my native language (with a non-Latin alphabet), we also have a long word for email, so in localized captions we often just use email or e-mail in English, and nobody has a problem with it.
Awkward but at least usable. The way the Material fields break with long or scaled label text is pretty bogus. That said, you're right: excessively long labels are a usability blemish worth avoiding, as long as the semantics of the field remain clear.
It's an example though; most of the time, French requires more letters than English to write the same thing.
As my browser is configured in French, I regularly see interfaces broken because of these. Most of the time it's not a big deal (as in the article's example), but sometimes it makes the website/application harder to use, either because some text is hidden, or the text box goes over a button/text field, which then becomes impossible to use.
> Is there any shorter equivalent in French?
The shortest would be "email pro", but it's informal. The best you can do in formal language (and if you're ok with dropping the "address" part of the label) is "email professionnel".
I18N is the bane of my existence. It's a horribly thankless task. Apart from that, I work with a company that uses an external translation company for 30+ languages, and at least from cursory checking, most are horribly wrong, to the point where they are either completely nonsensical in the given context or just misleading enough to mean something slightly different in the context, which is even worse, since this is an industrial product that can cause severe damage). It's not my job to check or even correct the translations' content (just that they fit ot to make the changes to the layouts to make them fit), so I'm only reporting the most severe violations. Every correction is a multi-week roundtrip to the translation company, delaying releases.
I am suspecting that those translation companies actually just use Google Translate or something similar. I recently saw a commercial product for the blind, developed in an english speaking country, where the german translation of the app was so horribly wrong to the point of totally being useless to non-initiated users.
Hours -> Stunden
Minutes -> Protokoll
This is so horribly wrong, that it is very unlikely that it was translated by ahuman.
I remember a lovely example from when I was living in Germany years ago. I got a letter about some upcoming local election, and was very impressed that it was in English for my convenience, but it opened with the marvellous greeting "Dear male voter, dear female voter".
> most are horribly wrong, to the point where they are either completely nonsensical in the given context or just misleading enough to mean something slightly different in the context,
That's because translators will get just a bunch of strings, with no context.
Only if they are lucky, they will do partial handbacks and will receive builds with their translation included.
> Only if they are lucky, they will do partial handbacks and will receive builds with their translation included.
That's what I ended up doing. We made a Windows version of our (actually our customer's) embedded product and I replaced the translation backend with an Excel table, and an Excel library so the translators could edit and test themselves without needing to recompile / convert anything. Just edit entry in table and restart the application.
Implementing this backend was surprisingly easy (half a day); thanks to Qt.
Yes, "courriel" is the common and official [1] word in Québec. Portmanteau of courrier (mail) + électronique.
Their professional translator must have used Google Translate. But much worse translations are common in our corner of North America.
"Work" is the tricky part. I generally use e-mail (work) rather than trying to translate verbatim as it tends to read like "E-mail at the office" or "Professional e-mail", both weird.
Yeah, I really wish Google did a better job across the board here.
The gmail settings example is instructive, because the author is right, it's much more usable than the Material design examples. It does, however, look terrible! All the spacing and alignment for everything is wrong and the whole thing looks incredibly wonky (the radio buttons don't line up properly with anything). It looks very "programmer design".
I'd take it any day over inaccessible-but-beautiful Material design, though. You'd just hope that a company of Google's scale could do both.
> Here is just a small section of Gmail's settings form, which configures a vacation responder message. The form UI here is much more conventional, with bold, persistent labels and clearly outlined text inputs. So it seems that even Google doesn't find it appropriate to use their Material Design form fields for every situation.
Or, more likely, nobody touched this part of the UI since 2004.
> That's probably the case, but if so then that's a real harsh judgement of Material design: that accessibility has actually decreased since 2004.
We've banged it too deep into our heads that change is progress, especially with technology. Sometimes change is really regression, and that's more likely the more refined something gets.
Regressions are happening all the time now, and too many people foolishly defend them as progress.
True! Nowadays a lot of companies have people not working every day here in Europe, but for Google's it's 'Out Of Office' or not. No way to set specific days. I'd like to see Google adding a partial Out-Of-Office option.
A text field following the Material Design specification.
If you don't know what it is, you probably aren't going to accidentally use them, and aren't a target of the advice, since you would probably have to either read the spec or adopt a library that waves around being an implementation of the spec to do it.
The term is well-known and understood by the intended audience.
Material Design has many other bad ideas in it too.
Examples: the color suggestions are garish. The idea that a website should simulate physical motion has usability problems for people with motion sensitivity. There is a lack of aesthetic restraint. It encourages gratuitous animation spam, like the ripple effect. It's like a cake where 50% of the cake is frosting.
Some of those things could be fixable, but I think it's unwise for other companies to adopt Google's visual branding in general.
Its a matter of taste I guess, but Ive always found all of Googles UI design to be incredibly ugly. I use a bunch of them every day from Ads to Gmail and its all just bland and looks half baked. Am I alone in this?
No you are not alone. I find it ugly as well. I have a feeling that most people just went with liking the design purely because it was pushed by Google. Classic case of "If you can't beat 'em, join 'em".
Nah man, they hired some designers to have an arts and crafts day cutting out shapes from paper and shining lights on it. It's all physically based on the real world and made by Smart People so therefore it's good.
We should make a different internet for dummies who get confused with something so simple as a Material Design text field. Usability is not going to fix stupidity.
so, if any junior software engineer is looking at this comment : the rule is that users aren't stupid. Your software most likely is, and that's probably because you made the wrong assumptions about human beings.
I guess it's nice that you can potentially customise everything, but working out what place in the class hierarchy you need to adjust takes a while. I mean most text fields will have a separate label and don't need a label as part of the text field. But how to get rid of it? That should be simple right..... not in my experience.
I'd like to add that most things done in the front-end space seem very over-engineered. It is as if developers are bored a lot and need to build overly complex structures and concepts in order to keep themselves busy, perhaps, employed.
The way I see it is that frontend developers at the far far end of a product development funnel. When it gets to their computers any suggestions from them are laughed at and they need to just make it work.
Imagine a frontend dev saying “this way of doing things is unreasonable, lets just use this simpler and more robust method instead” - very few places would allow this.
So frontend devs naturally gravitate towards solutions that are infinitely customizable which ends up being dramatically over engineered.
The code for material design components is crazy complicated because it was designed by UX designers for multiple platforms with little engineering input.
Material UI is bad to horrible on many levels. My recent "discovery" was their choice for font, color and contrast [1]
And their own guidelines are thrown out of the window on their own website. See an older version of the website [2] (the new one isn't much better), or their approach to displaying information [3]
Edit: And the problem is that these designs are applied with literally no thought involved [4]
About label size, I don't think the label should be that big anyway.
On an input, there is an option for explanatory text under the input element. At least in Material-UI.
So with proper responsive design, the input should expand with the label text size, and the label itself should be short, with the necessary explanation on the bottom.
I've never really liked material design. I don't care about your pretty icons, fancy text above (or inside) a box. Save me from your megabytes of CSS and scripts, and just give me the content. That's what I'm here for.
To author: Stop having XHR to load your images. Just load them. If I don't want them, I won't load them.
No. The question is: why can't every website be like gov.uk sites: with proper legibility, quick content, clearly designed and labeled for controls etc. [1-3]
Or things like BBC's Global Experience Language [4]
Because to some people (like me) the gov.uk website looks ugly and gives off a harsh "beware" vibe? Design is at least as much about achieving a certain emotional reaction as it is about legibility and clarity
That's a valid concern. Unfortunately, it looks like most of current design on the web tends to overdo emotional reactions to the detriment of legibility and clarity.
For me it was just ugly from first glace and I never warmed up to it. And convention of putting important button in the bottom right corner is still counterintuitive for me.
I've noticed that when creating a large, dynamic, multi-tab form, the labels and help texts can get in the way of actually viewing the actual entered information in the form. It's actually pretty tricky to come up with technical solutions where the labels are initially very clear up front, when people are adding data, but disappear in the background when most of the information has been entered so the actual contents can get most of the visual focus.
It's easy to show in detail how a big, friendly and accessible label makes a field more usable, but in the context of a large, complex form, the overview of the form structure and completeness of the data already entered are also important. Too prominent labels and too much help text can distract significantly, also for those who are visually impaired or are relying on screen readers.
My conclusion is that some form of two-phase, view/edit approach seems to work best for large forms. Labels and help are minimal by default, but the parts or "blocks" the user is actively editing gets more help and meta information added while it has the focus.
> the overview of the form structure and completeness of the data already entered are also important
Hum... The entered data is only important on the context of the place it is in.
By default labels and inputs have very clearly different appearances so that they would not be confused. And if you make the label information not accessible, you have just made the input information context-free and thus useless.
(Also, what is that with text prominence and screen readers? Are you completely removing the labels for blind people?)
I think Windows 7 and Windows 10 still have very clear interfaces (I mean Win32 GUIs, not the Metro/Modern stuff no one outside of MS really cares about).
I've never understood however the need to disable Aero and switch to Windows Classic, which looks gray, boring and feels like using Windows 98 again.
Ironically, most of the people I know who used Windows Classic mode switched to Linux later using something like GNOME or Cinnamon and then complained how ugly Windows was in comparison :)
My definition of superfluous eye candy includes the default green and blue theme of Windows XP, Aero in Vista and 7, and Metro in later versions. What you describe as boring is predictable and usable to me.
You guessed right, I run various Linux distributions with Cinnamon on every computer but the gaming one, and I still envy the clean and crisp look of 2000.
Regarding Metro, the new control panel in Windows 10 lacks most settings a normal power user (not a domain admin) needs so all the useful functionality is hidden behind one extra layer.
> I've never understood however the need to disable Aero and switch to Windows Classic, which looks gray, boring and feels like using Windows 98 again
I've always disabled it. Not because it's awful or anything (I'm neutral to it) but because it uses up machine resources without giving me any particular benefit. There's nothing wrong with the classic look. I don't need my UI to be all flashy. I need it to be functional.
> I've never understood however the need to disable Aero and switch to Windows Classic, which looks gray, boring and feels like using Windows 98 again.
Gray and boring is good. IMHO, flashy computer UIs are for movies and other cases where actual usability is secondary.
I've always switched to Windows classic, because the menus and icons are more compact, and I can better arrange things so I can access them more quickly. I'm not deficient in motor skills, so the the one thing I don't need is giant, colorful buttons.
actually no, real usability research specifically lacking in flat is how to design for older workers. MD handles this Apple still has not address this in FD
Any sources on this? I'm genuinely interested in how preferred flatness is somehow correlated with younger age. I know that children probably like to click on everything and explore how software works – heck, that's what I still do when I encounter new programs – but it's much easier if basic UI elements behave in expected ways.
I guess it's cognitively harder for the UX designer to create unusual workflows if the UI elements are saying "this is wrong" right in the face.
My favorite GUI was always IRIX. I know saying Motif looks good sounds a bit silly... but the whole thing looks ugly-good. Like craigslist or reddit before the remodel. It looks bad on first sight and then once you use it for a while you forget it looks like much of anything. It’s just easy to use.
I really wish these kinds of articles would take a less condescending tone. "stop doing this", "you should do that". No, I do whatever I want within the boundaries that my employer and the law have set.
> Do make sure all text meets WCAG colour contrast requirements.
Presented by the person that places #BBBBBB text on #FFFFFF background. Meh. If you want to talk about good practices on the web maybe stop using lazy loaded images and that other unnecessary JS clutter.
The best UX test for me was that my kid at age 4 could easily manage iOS apps or sites with bootstrap-like design, but would get totally lost on pages with the material design. In their effort to make it super minimal they've removed too much of the visual hierarchy. If you can't read, you just don't know if something is a static label or a button to click. And that means that even if you can read it requires some extra mental strain to navigate it quickly. Obviously, like with anything, you learn to use it with time, but problem with that is that even a small change will confuse you again. Put an element in an unexpected position or too close to some body of text, and people will miss it completely.
Their Floating Action Button was one of the worst choices ever made in UI design. No Context, overlaps content if you want to see it, placed in a weirdly hard to reach space, hidden under the thumb. Gah.
139 comments
[ 3.1 ms ] story [ 206 ms ] threadI hope future designers learn from its mistakes.
I like that this post points out the issue, and I hope it gets fixed.
While reading the original material design spec, it seemed enlightened, but now its clear it's more of a standard than a best-practice. Its by no means the "best" design, just like the qwerty keyboard wasn't the best. However, due to a huge marketing push by google, it's now considered a standard and if you do not conform, you'll look weird. Not so different than in the 1990s, if you had a Windows application without a "file" drop-down menubar, you would also be considered weird.
Material design should not be thought of as an optimal design approach, it should be thought of as a standard to rally behind. If you build something adhering to the standard, regardless of whether it's a good or bad design choice, users will understand it because they have already been it by Google.
If you have something that's better, it may be rejected simply because folks weren't already trained on it.
Throughout the 80s and 90s, Apple's UI guidelines were considered best practice and widely adopted by other companies.
I won't rally behind it, personally. I'd rather rally behind a good standard.
> If you have something that's better, it may be rejected simply because folks weren't already trained on it.
That's fine. Such a loss may be mitigated to some degree by gaining users who really hate MD -- and there are a lot of them.
The old style material field which were mentioned that are just an underlined text instead of a box were absolutely terrible too. It's disgusting that someone would actually think those were a good idea.
Also, what he calls out in the end, use high contrast guys! The old material design grey text on grey background was terrible to read. GCP used to be full of this.
The use of e-mail you describe also exists in French.
"addresse mèl" is used in governments websites while regular website simply write "addresse email"
As my browser is configured in French, I regularly see interfaces broken because of these. Most of the time it's not a big deal (as in the article's example), but sometimes it makes the website/application harder to use, either because some text is hidden, or the text box goes over a button/text field, which then becomes impossible to use.
> Is there any shorter equivalent in French?
The shortest would be "email pro", but it's informal. The best you can do in formal language (and if you're ok with dropping the "address" part of the label) is "email professionnel".
This is so horribly wrong, that it is very unlikely that it was translated by ahuman.
That's because translators will get just a bunch of strings, with no context.
Only if they are lucky, they will do partial handbacks and will receive builds with their translation included.
That's what I ended up doing. We made a Windows version of our (actually our customer's) embedded product and I replaced the translation backend with an Excel table, and an Excel library so the translators could edit and test themselves without needing to recompile / convert anything. Just edit entry in table and restart the application.
Implementing this backend was surprisingly easy (half a day); thanks to Qt.
Their professional translator must have used Google Translate. But much worse translations are common in our corner of North America.
"Work" is the tricky part. I generally use e-mail (work) rather than trying to translate verbatim as it tends to read like "E-mail at the office" or "Professional e-mail", both weird.
[1] http://www.gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=83539...
[0] https://developer.mozilla.org/fr/docs/Web/CSS/::placeholder
[1] https://design-system.service.gov.uk/components/text-input/
The gmail settings example is instructive, because the author is right, it's much more usable than the Material design examples. It does, however, look terrible! All the spacing and alignment for everything is wrong and the whole thing looks incredibly wonky (the radio buttons don't line up properly with anything). It looks very "programmer design".
I'd take it any day over inaccessible-but-beautiful Material design, though. You'd just hope that a company of Google's scale could do both.
Or, more likely, nobody touched this part of the UI since 2004.
I think that's rather the point...
We've banged it too deep into our heads that change is progress, especially with technology. Sometimes change is really regression, and that's more likely the more refined something gets.
Regressions are happening all the time now, and too many people foolishly defend them as progress.
The article seems to assume that this a well defined and well known term that needs no further introduction.
Anyway, it's like crystal meth. If you don't know what it is you are winning! The advice is for people who are unlucky enough to be near it.
If you don't know what it is, you probably aren't going to accidentally use them, and aren't a target of the advice, since you would probably have to either read the spec or adopt a library that waves around being an implementation of the spec to do it.
The term is well-known and understood by the intended audience.
If you have a form with many fields, it’s advised to force the label to always be in the top-left corner anyway.
The field should also be wider, which also helps with the text being cut off.
And with only a few changes, most of the complaints of this article are instantly fixed.
Examples: the color suggestions are garish. The idea that a website should simulate physical motion has usability problems for people with motion sensitivity. There is a lack of aesthetic restraint. It encourages gratuitous animation spam, like the ripple effect. It's like a cake where 50% of the cake is frosting.
Some of those things could be fixable, but I think it's unwise for other companies to adopt Google's visual branding in general.
I guess it's nice that you can potentially customise everything, but working out what place in the class hierarchy you need to adjust takes a while. I mean most text fields will have a separate label and don't need a label as part of the text field. But how to get rid of it? That should be simple right..... not in my experience.
I'd like to add that most things done in the front-end space seem very over-engineered. It is as if developers are bored a lot and need to build overly complex structures and concepts in order to keep themselves busy, perhaps, employed.
Imagine a frontend dev saying “this way of doing things is unreasonable, lets just use this simpler and more robust method instead” - very few places would allow this.
So frontend devs naturally gravitate towards solutions that are infinitely customizable which ends up being dramatically over engineered.
I also like the look of Elastic UI [0], but haven't used it on a project yet, so don't know what the dev experience is.
[0] https://elastic.github.io/eui/#/
And their own guidelines are thrown out of the window on their own website. See an older version of the website [2] (the new one isn't much better), or their approach to displaying information [3]
Edit: And the problem is that these designs are applied with literally no thought involved [4]
[1] https://grumpy.website/post/0TEJkwzPA
[2] https://grumpy.website/post/0Ra93yy33
[3] https://grumpy.website/post/0TEKUvqDX
[4] https://grumpy.website/post/0TKa2-she and https://grumpy.website/post/0TBOWnfjB
EDIT: for help text, put it below label or a tooltip
On an input, there is an option for explanatory text under the input element. At least in Material-UI.
So with proper responsive design, the input should expand with the label text size, and the label itself should be short, with the necessary explanation on the bottom.
To author: Stop having XHR to load your images. Just load them. If I don't want them, I won't load them.
Or things like BBC's Global Experience Language [4]
[1] Government Design Principles https://www.gov.uk/guidance/government-design-principles
[2] gov.uk Design System https://design-system.service.gov.uk
[3] Or even tings like "Why the GOV.UK Design System team changed the input type for numbers" https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des...
[4] https://bbc.github.io/gel/
It's easy to show in detail how a big, friendly and accessible label makes a field more usable, but in the context of a large, complex form, the overview of the form structure and completeness of the data already entered are also important. Too prominent labels and too much help text can distract significantly, also for those who are visually impaired or are relying on screen readers.
My conclusion is that some form of two-phase, view/edit approach seems to work best for large forms. Labels and help are minimal by default, but the parts or "blocks" the user is actively editing gets more help and meta information added while it has the focus.
Hum... The entered data is only important on the context of the place it is in.
By default labels and inputs have very clearly different appearances so that they would not be confused. And if you make the label information not accessible, you have just made the input information context-free and thus useless.
(Also, what is that with text prominence and screen readers? Are you completely removing the labels for blind people?)
https://developer.mozilla.org/en-US/docs/Tools/Accessibility...
The Windows GUI usability also peaked somewhere in the decade spanning 2000, XP and Seven, if you disabled the candy themes.
I think Windows 7 and Windows 10 still have very clear interfaces (I mean Win32 GUIs, not the Metro/Modern stuff no one outside of MS really cares about).
I've never understood however the need to disable Aero and switch to Windows Classic, which looks gray, boring and feels like using Windows 98 again.
Ironically, most of the people I know who used Windows Classic mode switched to Linux later using something like GNOME or Cinnamon and then complained how ugly Windows was in comparison :)
You guessed right, I run various Linux distributions with Cinnamon on every computer but the gaming one, and I still envy the clean and crisp look of 2000.
Regarding Metro, the new control panel in Windows 10 lacks most settings a normal power user (not a domain admin) needs so all the useful functionality is hidden behind one extra layer.
I've always disabled it. Not because it's awful or anything (I'm neutral to it) but because it uses up machine resources without giving me any particular benefit. There's nothing wrong with the classic look. I don't need my UI to be all flashy. I need it to be functional.
Gray and boring is good. IMHO, flashy computer UIs are for movies and other cases where actual usability is secondary.
I've always switched to Windows classic, because the menus and icons are more compact, and I can better arrange things so I can access them more quickly. I'm not deficient in motor skills, so the the one thing I don't need is giant, colorful buttons.
I guess it's cognitively harder for the UX designer to create unusual workflows if the UI elements are saying "this is wrong" right in the face.
https://old.reddit.com
Or ddg "reddit tuir github"
Presented by the person that places #BBBBBB text on #FFFFFF background. Meh. If you want to talk about good practices on the web maybe stop using lazy loaded images and that other unnecessary JS clutter.
I scanned the site source code and the only bit of text which uses that particular colour is the "#" symbol before headings.
Sounds like you're just trying to find something to complain about.