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.
This gets me every single time. I also have seen plenty of screens where buttons are given a "selected" state (e.g. a dark blue background), but it's non obvious if the dark blue background means selected or not. Radio buttons and checkboxes never give me these problems. Just use them.
I might be missing something, but I'm a little confused by this. Here's what that menu looks like on my phone (Galaxy Note 9) running the latest version of Android: https://i.imgur.com/uQaDDGG.png
Is there a different-looking menu that you're talking about on another version?
I don't have a picture, but most of Motorola phones have a mix of greys on it's menu, making it super hard to identify when it's activated or deactivated. IIRC activated is light grey and it really looks like it's deactivated.
This also sounds like a good example of problems that may arise with OEM skinning. Not that the OS maker is immune to flaws in design/layout, but you run into these minor changes that can be worse than "stock" for the sake of surface differentiation.
(My example of the same screen, slightly redacted)
I asked Flutter team to add an iOS checkbox widget. They refused, saying that I can just use the switch widget. They don't realize that checkboxes are far superior in usability. Checkboxes are part of the iOS widget library, used frequently in iOS Settings and Apple apps.
...where? A UITableViewController with one UITableViewCell with a checkmark accessory isn't a checkbox widget. You're looking for Flutter's Menu button widget, it's like UIAlertController crossed with what Settings.ipa does
I have a hard time believing this. My six year old has been using that menu just fine for years now, and on my phone (Galaxy S9+) one of those settings is either dark grey with a light gray icon, or bright blue with a white icon. It's hard to imagine being confused by that. Maybe your menu looks significantly different?
My phone that uses default stock android system have darker grey and lighter grey for on/off. It's difficult. Samsung uses modified skin on your phone.
Under Settings > Styles and Wallpaper there are a few different options. I think the default is blue for selected, but you can select "Ash" to make it grey vs grey.
> 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.
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?
Just setting opacity to show state is generally seen as bad practice, the difference in contrast is just too little compared to real life. Seeing as the screen is dimmable/ can be used in various lighting situations, if every switch is off it can be really hard to tell if the current opacity is 'all on' or 'none on'. In UX design it's common to see this solved by both using opacity but also a distinct shape/contrast and by changing the icon. Sometimes throwing a bit of color in can help those who are not color blind. Normally you'll see all three.
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)
That might be sensible with a latin language read left-to-right, but for other scripts read right-to-left, it's ambiguous. Is the enabled state then the inverse? (I believe the guidelines are that it should be left as selected for RTL languages)
The problem with trying to do it properly for RTL is that half of systems won't do it properly which is worse than everyone consistently doing it wrong and users learning to cope.
Possibly, but why not design widgets so that no such
consensus is necessary.
Prior GUIs did not need it and now literally
billions of people are burdened with it.
Even though UIs were always built on consensus and common experiences users might have from other platforms, I agree that deviating from the norm is a bad idea in most cases. That said, the specific component in question is so common now that for future generations it might become as intuitive as a checkbox.
> 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.
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 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 :)
> 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.
> 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.
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.
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.
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.
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?
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.
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".
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.
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.
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.
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.
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.
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.
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.
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]
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.
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?)
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.
Don't forget, the material design specifications and frameworks are being made freely available. When you compare interfaces designed by that vast majority of developers, using MD is an enormous step up in usability and functionality. It also incorporates concepts that, while not being the most "accessible", are patterns the vast majority of users have become familiar with and can navigate without explanation. For example, interactions like gestures are not accessible or obvious but are commonplace and understood.
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.
Material design is among the worst design languages I've ever seen. Developers without an eye for design typically use native widget toolkits which are superior to material design.
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’m not sure why the effort alone makes it worthy of use. The product needs to be judged on its functional merits, not based solely on what it costs and how much work was put into it.
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.”
> When you compare interfaces designed by that vast majority of developers, using MD is an enormous step up in usability and functionality.
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.
> It also incorporates concepts that, while not being the most "accessible", are patterns the vast majority of users have become familiar with and can navigate without explanation.
Are you kidding? This is hacker news and the topic is Google. I'd say the pitchforks are out, but these days I don't think they ever make it back to the shed.
> 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.
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.
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.
Yes, I was unclear. I meant that I think it's coming back now. My feeling is (but it could be just colored memory) that for a long time people were happy with just changing the colors/borders/css of the standard components. Now I have the feeling people (or frameworks) code new <option> functionality from scratch in JS, thus making them look and function slightly differently on each site.
I like material design. I have been deploying it to apps for years, and have had zero problems/complaints with it.
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.
> I have been deploying it to apps for years, and have had zero problems/complaints with it.
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.
All you said just means you are isolated from user's feedback or live in some sort of echo chamber. I would never believe that everyone is satisfied, you can never have 100% satisfaction, there will always be users complaining about any part of UI really just because they had a bad day.
> All you said just means you are isolated from user's feedback or live in some sort of echo chamber.
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.
The reality is that we're at the mercy of clients and bosses, and I don't see that changing. Every once in awhile someone will come along that realizes they have hired professionals, and trust the professionals to their job. But that's about 1 in 10, in my experience.
It's also the professional's job to convince the boss why their ideas are bad. "This is considered animation spam." or "This is considered a bad practice, but this other way is more effective." or "Our tests have shown that users are annoyed by X."
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 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.
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.
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.
> 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.
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.