Stop using Material Design text fields
matsuko.ca
matsuko.ca
I have been using GUIs since the 80s (remember Atari ST GEM). Not once have I been confused about whether an item was selected or not.
Enter material design.
On android's slide down config screen (the one with wifi, bluetooth, etc toggles) I always have to stop and think a bit to determine if wifi is on or not.
Similarly, on many other config screens, horizontal sliders that snap to either the left and right positions are used to indicate on/off but it is never clear which one is which.
I believe there are proper check boxes somewhere in the Widget set but they are not used much.
To me this seems like a case of aesthetic dogma trumping usability.
The good ones also switch between greyish being off and some color (e.g. green or blue) when on. But not all of them change color, so I tend to toggle them to see if this one of the colored ones -- and thereby confirm what setting it was on.
(ps. In general I do like material and flat designs, it's just these checkboxes I find hard to read)
I know I still find it confusing and occasionally have to toggle the switch to both positions before working out which position I want.
I'm a bit surprised by this -- it transitions from dark gray on light gray when it's off to _bright_ white on _bright_ blue when it's on. This would seem to mirror many physical things that have status lights which are not illuminated when disabled and are illuminated when enabled. What's the source of initial confusion for you?
Ironically, you can see the team trying to solve this in material's filter chips by adding a checkmark: https://material.io/components/chips/#filter-chips
Is there a different-looking menu that you're talking about on another version?
(My example of the same screen, slightly redacted)
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 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.
Or ddg "reddit tuir github"
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.
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...
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.
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...
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
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.
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?)
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.
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.
Constructive criticism of design is important and with these frameworks being open source, we can modify and "improve" as we see as appropriate. Google has invested enormous amounts of money, energy, and time into making this available for free. They are not enforcing these concepts, even on their own platforms so we should appreciate that they make these systems available if you choose to use them.
I also disagree that it was a step up for spec made available by other vendors before. Apple’s original Human Interface Guidelines for the Macintosh (http://interface.free.fr/Archives/Apple_HIGuidelines.pdf ) was a paragon of usability. AFAICT nearly everything we’ve invented since has been a step back.
If anything, Material Design is a textbook example of “you get what you pay for.”
Outside github and dribbble there is a large population of developers creating internal tools that abide by no UI/UX standards or even common sense.
There are many frameworks available. Which ones might be a better choice?
Gestures may be commonplace but are not understood. They are inconsistently implemented and you can tell the general populous doesn't understand them if you watch folks use them (or mistakenly trigger them) 'in the wild'.
Material design documentation is internally inconsistent. The numerous re-implementations are inconsistent. Usage of the libraries are inconsistent. The first-party usage is inconsistent. The documentation leaves holes in common use cases and steers toward uncommon cases (FAB for example). Consistency is a requisite feature of a good UI design.
Material design completely fails an accessibility review. From the labels referenced in the article to the terrible contrast and lack of meaningful dimension and dividing elements.
No amount of money invested in documentation is going to make material design any better.
Material design should be scrapped. There are no redeeming qualities.
I disagree. MD is terrible, and is a a couple of steps backwards in terms of usability and discoverability. Its use and influence has been pretty harmful, in my opinion, and is one of the reasons why UI design has been growing increasingly worse overall.
Does that include ios/macos/windows users?
I 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.
[0] https://developer.mozilla.org/fr/docs/Web/CSS/::placeholder
[1] https://design-system.service.gov.uk/components/text-input/
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.
https://twitter.com/gnyman/status/1230424668970024961
Not sure if it's material design widgets being limited, a lazy Web dev or google intentionally making it hard to update your marketing settings.
I think I'm having flashbacks to the custom windows UI's/skins of the 1990's when SW devs and designers felt they needed to differentiate and replaced the standard windows components with their own designs.
I work on way too many apps to pay much attention to any of them. I use Vuetify (a material design framework for VueJS) and it works beautifully.
Personally I think Development is becoming too idealistic. Ideally everything works for everyone all the time. But that's never the case, in my experience. These principles are a godsend for those of us who have bosses that want the app, "flashy", but also functional. While also having an abysmal amount of time to work on said app.
Personally I'd love to see less, "stop using this", and more, "start using this instead, here's why". I don't have time to go in and hack my material design framework, to fix an issue, I haven't had an issue with.
Read a book, and create your own UI doesn't work for me.
P.S. WCAG principles are basically unattainable in the real world. Almost any national entity has hundreds of millions of violations. I know because I also manage an app that scans for them.
An insinuation.
>I would never believe that everyone is satisfied
I've worked in this industry long enough to know no one is ever satisfied. That is background noise. I consider something to be a good implementation if I don't get consistent questions or issues about it. There will always be users that have issues with even the most basic and intuitive UI.
Which means nothing. I would never bother complaining to developers of an application I use because they employed MD, even though it actively annoys me (although I certainly would stop using such apps immediately if I found an equivalent app that didn't use it). The reason is because it's sadly become expected, so complaining would be pointless.
> Personally I think Development is becoming too idealistic. Ideally everything works for everyone all the time.
I'm not a UX dev, so my criticisms of MD are not from a development point of view. They're from a user point of view. And as a user, I don't care if something works for everyone all the time. I care if it works for me, and MD really doesn't.
I think that's part of the problem. Clients and bosses often don't know what they are doing and have really bad ideas about "spicing up the website."
It's the new version of what was formerly done with <marquee> and <blink> tags and DHTML.[1]
It doesn't always work, but sometimes it does.
Yes. This is why Google AMP is popular and how their SERP became an SEO wasteland for most search terms.
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.
https://developer.mozilla.org/en-US/docs/Tools/Accessibility...
EDIT: for help text, put it below label or a tooltip
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.
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.