4 ms·

In that case they have outlines, and are clearly buttons?

deleted 8y ago
[deleted]
dmitriid 8y ago
Design flexibly -> Learn more. It's a link (hover over it). For some reason it's displayed as a button. Develop across platforms -> platform links. All links are links. Collaborate seamlessly -> View Tools. It's a link (hover over it). For some reason it's displayed as a button. Further down the page. Applying typography -> Learn more. It's a link (hover over it). For some reason it's displayed as a button. Applying typography -> Related -> Typography. It's a link. But it's displayed as plain text, and you wouldn't know it's a link until you hovered over it. And even then the only clue is cursor changing to pointer (if your status bar is turned off, good luck figuring out it's a link). What's new -> Develop -> Cards. It's a link. That looks like plain text. ---- And that's the main problem with anything coming from Google. Their pages and designs are wildly inconsistent and contradict their own guidelines. ANd sometimes it looks like they are implemented by the main character from Split. My favourite example is is their Google Maps "design": https://pbs.twimg.com/media/Dq2_soxWsAEqKWo?format=jpg https://pbs.twimg.com/media/Dq2_soxWsAEqKWo?format=jpg
- codetrotter 8y ago
  Regarding links vs buttons, when you talk about the difference between these, are you referring only to “a” vs “button” HTML elements or something else? That’s an implementation detail. I often use anchor elements and style them as flat buttons. Or are you referring to whether clicking a button triggers an action on the page vs navigating your browser elsewhere? To me a flat button is a design element that I use for actions that I want to call out to the user. These actions could be either on the page or they could be browser navigation triggers. For example, to me a link to “learn more” about a product can legitimately be styled as a flat button in many cases. That being said, flat buttons need to be used correctly. And I think material design, at least in the way it has been put to use in most products, is neither aesthetically pleasing nor intuitive. But flat or “flattish” design can work especially well for buttons and links that you want to call out without having them totally steal the focus. For example I am currently working on a tiny side project creating a countdown timer for pitch rehearsal, pitching, talks and presentations, for the person on stage to look at. It is intended for desktop use only currently. It’s a work in progress and I’ve not yet implemented the functionality fully so I am hesitant to link to it yet. Anyway, in that side project I make use of flat buttons for both some on-page actions and for a link leading to another page.
  - dmitriid 8y ago
    > Regarding links vs buttons, when you talk about the difference between these, are you referring only to “a” vs “button” HTML elements or something else? > That’s an implementation detail. It's not. These are semantically different elements. > For example, to me a link to “learn more” about a product can legitimately be styled as a flat button in many cases. "Many cases". What cases might that be, and what is the exact difference between a link to "Learn more" and a link to "Related -> Typography"? Funnily enough, material design guidelines state the following: --- quote --- Buttons. Usage. [1] Buttons communicate actions that users can take. They are typically placed throughout your UI, in places like: - Dialogs - Modal windows - Forms - Cards - Toolbars .... --- end quote --- > That being said, flat buttons need to be used correctly. Indeed. <a> means a link to a different page, or a place on the same page. <button> means an action. This is especially true for assistive devices. <a> and <button> behave and interact differently with the content around and inside them (see 4.5.1, 4.6 and 4.10.6 of the HTML Standard [2], and 3.13, 3.5 and 4.3.4 of WAI-ARIA [3]) [1] https://material.io/design/components/buttons.html https://material.io/design/components/buttons.html [2] https://html.spec.whatwg.org/multipage/#toc-semantics https://html.spec.whatwg.org/multipage/#toc-semantics [3] https://www.w3.org/TR/wai-aria-practices-1.1/ https://www.w3.org/TR/wai-aria-practices-1.1/
  - kbutler 8y ago
    Do you insulate the user from that implementation detail? Links and buttons have significantly different representations in accessibility, right-click, and keyboard behavior.

deleted 8y ago

[deleted]

Design flexibly -> Learn more. It's a link (hover over it). For some reason it's displayed as a button. Develop across platforms -> platform links. All links are links. Collaborate seamlessly -> View Tools. It's a link (hover over it). For some reason it's displayed as a button. Further down the page. Applying typography -> Learn more. It's a link (hover over it). For some reason it's displayed as a button. Applying typography -> Related -> Typography. It's a link. But it's displayed as plain text, and you wouldn't know it's a link until you hovered over it. And even then the only clue is cursor changing to pointer (if your status bar is turned off, good luck figuring out it's a link). What's new -> Develop -> Cards. It's a link. That looks like plain text. ---- And that's the main problem with anything coming from Google. Their pages and designs are wildly inconsistent and contradict their own guidelines. ANd sometimes it looks like they are implemented by the main character from Split. My favourite example is is their Google Maps "design": https://pbs.twimg.com/media/Dq2_soxWsAEqKWo?format=jpg https://pbs.twimg.com/media/Dq2_soxWsAEqKWo?format=jpg

codetrotter 8y ago
Regarding links vs buttons, when you talk about the difference between these, are you referring only to “a” vs “button” HTML elements or something else? That’s an implementation detail. I often use anchor elements and style them as flat buttons. Or are you referring to whether clicking a button triggers an action on the page vs navigating your browser elsewhere? To me a flat button is a design element that I use for actions that I want to call out to the user. These actions could be either on the page or they could be browser navigation triggers. For example, to me a link to “learn more” about a product can legitimately be styled as a flat button in many cases. That being said, flat buttons need to be used correctly. And I think material design, at least in the way it has been put to use in most products, is neither aesthetically pleasing nor intuitive. But flat or “flattish” design can work especially well for buttons and links that you want to call out without having them totally steal the focus. For example I am currently working on a tiny side project creating a countdown timer for pitch rehearsal, pitching, talks and presentations, for the person on stage to look at. It is intended for desktop use only currently. It’s a work in progress and I’ve not yet implemented the functionality fully so I am hesitant to link to it yet. Anyway, in that side project I make use of flat buttons for both some on-page actions and for a link leading to another page.
- dmitriid 8y ago
  > Regarding links vs buttons, when you talk about the difference between these, are you referring only to “a” vs “button” HTML elements or something else? > That’s an implementation detail. It's not. These are semantically different elements. > For example, to me a link to “learn more” about a product can legitimately be styled as a flat button in many cases. "Many cases". What cases might that be, and what is the exact difference between a link to "Learn more" and a link to "Related -> Typography"? Funnily enough, material design guidelines state the following: --- quote --- Buttons. Usage. [1] Buttons communicate actions that users can take. They are typically placed throughout your UI, in places like: - Dialogs - Modal windows - Forms - Cards - Toolbars .... --- end quote --- > That being said, flat buttons need to be used correctly. Indeed. <a> means a link to a different page, or a place on the same page. <button> means an action. This is especially true for assistive devices. <a> and <button> behave and interact differently with the content around and inside them (see 4.5.1, 4.6 and 4.10.6 of the HTML Standard [2], and 3.13, 3.5 and 4.3.4 of WAI-ARIA [3]) [1] https://material.io/design/components/buttons.html https://material.io/design/components/buttons.html [2] https://html.spec.whatwg.org/multipage/#toc-semantics https://html.spec.whatwg.org/multipage/#toc-semantics [3] https://www.w3.org/TR/wai-aria-practices-1.1/ https://www.w3.org/TR/wai-aria-practices-1.1/
- kbutler 8y ago
  Do you insulate the user from that implementation detail? Links and buttons have significantly different representations in accessibility, right-click, and keyboard behavior.