Comment by themacguffinman | Hacker News Reader

Comment by themacguffinman | Hacker News Reader

themacguffinman

Congrats on releasing, that's a huge feat. A Go GUI app is an interesting concept, it definitely has compelling advantages like single binary targets and inherently cross platform code.

I do take issue with the repo description "Cross platform GUI in Go based on Material Design" though. Looking on the screenshots in the README (eg [1]), I can't see how this is actually based on Material Design, other than using some material design icons. The widgets don't even follow the basic spirit of Material design [2]:

> Material Design UIs are displayed in an environment that expresses three-dimensional (3D) space using light, surfaces, and cast shadows.

It looks much closer to Microsoft's "fluent design".

Maybe the repo description was accidentally left unchanged? It's weird that the public website https://fyne.io/ doesn't actually contain any references to material design.

[1] https://raw.githubusercontent.com/fyne-io/fyne/master/img/wi...

[2] https://material.io/design/environment/surfaces.html

"Material Design UIs are displayed in an environment that expresses three-dimensional (3D) space using light, surfaces, and cast shadows"

Somewhat amusing because my biggest issue with Material Design is buttons I don't know I can click, because they are flat and have no depth or shadows:

https://storage.googleapis.com/spec-host-backup/mio-design%2...

People for some reason always think just because things are flat in material design they shouldn't have shadows. Or maybe it's just people calling lots of things material design that really aren't.

Maybe taking cues from the official docs. My picture is from the Material Design website. https://material.io/design/components/buttons.html# (scroll down to types)

Most of the buttons on that page have a shadow though...

Okay then, the buttons on their home page have no shadow: https://material.io

See any of the (many) "Learn More" and "View All" buttons.

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

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

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.

> 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

[2] https://html.spec.whatwg.org/multipage/#toc-semantics

[3] https://www.w3.org/TR/wai-aria-practices-1.1/

Do you insulate the user from that implementation detail?

Links and buttons have significantly different representations in accessibility, right-click, and keyboard behavior.

That's an example of bad documentation: the image shows all buttons without shadow, but then goes on to explain that contained buttons (the thing most people would call a button, as opposed to links etc) are "distinguished by their use of elevation and fill", with elevation obviously being represented by a shadow.

The rest of the page also always shows contained buttons with shadow, just that one picture showing them all together doesn't.

>> Material Design UIs are displayed in an environment that expresses three-dimensional (3D) space using light, surfaces, and cast shadows.

> It looks much closer to Microsoft's "fluent design".

It's a bit of a digression, but Fluent Design (esp. 2.0, but even 1.0) actually has very similar requirements of light, surfaces [materials], and casting shadows. It's a more nuanced approach than Material Design, which can somewhat be summed up as Material Design imagines the application as a stack of paper and cardboard and Fluent Design has both a subtler concept of "materials" (not every thing needs to be obviously stacked like a three-tiered 2.5D layer cake when displayed in 2D) and a broader concept of "materials" than Material Design (Fluent throws in things like glass-like parts, "acrylics", glinting metal bits, etc).

I understand what you probably meant that it looks like Microsoft's Windows 8.x-era "modern" designs, but I find it useful to point out that Fluent Design and Material Design have nearly converged at this point and Fluent Design is a lot more like Material Design than people think. (To the point where I'd argue today that a lot of the best Fluent Design stuff is better at Material Design than Material Design stuff.)

Does this not sound almost exactly like the Material Design quote above? [1]

> The physical world is our vocabulary. Fluent speaks in light and shadow, in spatial dimensions, in the weave and fold of fundamental materials.

[1] https://www.microsoft.com/design/fluent/

The biggest reason is that we have not implemented shadows yet... once we have that things may look more like you expect.

Reply on news.ycombinator.com