Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Elements of UI Engineering

overreacted.io

Post reply on HN
Print view View original

11–20 of 84 posts

Re: The Elements of UI Engineering

#13

Post by coogie »

amelius wrote: post #10

Wow, this page made my top icon tray in Android turn pink. What is the CSS property responsible for this? (My guess would be: background-color)

This would be the "theme-color" meta tag[1] which I think only works in Chrome on Android, at the moment.

[1]: https://html.spec.whatwg.org/multipage/semantics.html#meta-t...

Re: The Elements of UI Engineering

#14

Post by kakarot »

miguelrochefort wrote: post #2

I've been building consumer apps professionally since 2013 on iOS, Android, Windows Phone and the web. I also spent a few years designing and implementing UI frameworks. I've had to deal with all of the problems listed in Dan's article (with and without frameworks). Over the years, I have grown convinced that designing and implementing UI by hand simply doesn't scale. There are too many things to consider, too many d…

> I think the job of service providers should be to semantically annotate their data, so that a general purpose client can dynamically render it.

You mean like HTML? We tried that already and people disliked the lack of branding ability.

Re: The Elements of UI Engineering

#16

Post by nenadg »

Entropy. Good point. I don't think many brought up that issue, it's either ignored (we know what we're doing) or coped with when it's too late (we knew what we're doing).

Entropy handling should be the goal for 2019 UI/Frontend engineering.

Re: The Elements of UI Engineering

#18

Post by revskill »

One example of hard problem in UI Engineering: Accessibility. In github markdown editor, we can format code by wrapping with ``` . But after that, what happens if we press Tab ? Should the code indent, or the focus move outside of the editor ? It's confusing and annoying currently to move the focus outside of editor.

Re: The Elements of UI Engineering

#19

Post by Vinnl »

nenadg wrote: post #16

Entropy. Good point. I don't think many brought up that issue, it's either ignored (we know what we're doing) or coped with when it's too late (we knew what we're doing). Entropy handling should be the goal for 2019 UI/Frontend engineering.

I think the reduction of the cognitive load of entropy was what propelled React (and specifically its innovation of the Virtual DOM) to be the most widely-used front-end framework. Being able to write a function transforming state to a description of the view, without having to worry about getting from whatever the view currently looks like to what you want it to look like, is a huge advantage.

It can certainly still be greatly improved, but I think we've already made great strides in entropy handling on the front-end in recent years.

Re: The Elements of UI Engineering

#20

Post by ehnto »

mwcampbell wrote: post #3

From the part on accessibility: > But we also need to make it easy for product developers to do the right thing. What can we do to make accessibility a default rather than an afterthought? Yes! We accessibility advocates have been wishing for this for decades. In the context of web development, application developers should rarely, if ever, have to reach for the ARIA role attribute, because they should be able to re-…

I have had this in mind for years but never followed through with it. Do you know of any groups currently working on the problem?

The dream is framework agnostic Web Components that "just work" in a modern browser. You can make it happen with a bit of polyfill javascript. My worry has been spending a bunch of effort making them and then having to maintain separate sets for all the different frontend "web component-ish" frameworks so that people would actually use them.

Post reply on HN