I have a theory that almost every UX/UI developer today is an avid player of twitch video games. And this is clear from the way they design the UI. Every page, every screen, every window, is constantly and dynamically reflowing. Buttons and other elements are moving before your eyes. Popups come and go without much rhyme or reason. "Undo" opportunities are often on short timers in a little notification window that disappears in five seconds. Web pages are often designed to surprise and inveigle the visitor with dialogs that appear when we least expect it, triggered by things like how long we've viewed a page, or our attempts to move the mouse away from the viewport, etc.

It's like the UX/UI designers have taken twitch video games as the gold standard for a UI, and therefore the visual acuity and reaction times of a twentysomething are baked-in as prerequisites for operating a simple thing like a mobile phone with your banking application, or a desktop computer viewing a normal news article.

In these cases, it's not sufficient to simply learn the UI, it's necessary to anticipate it, and lead your target so that you're prepared to click it when the opportune moment presents itself and before that moment disappears again.

And thus was it shown why lightweight markup has taken over the document space.

Teams and then enterprises got real, real, reaaaaaaal tired of watching their overhead costs clock up new zeroes every time a new Project Manager landed a gig in the MSO/Adobe/PTC/Wherever design office.

The exception are those enterprises locked into a tool ecosystem by their customer contracts, aka, "you must use tool X to do the thing we're paying you for". I don't have any doubt that such contracts will die in a fire as the quest to cut costs continues; they're a bad deal for literally everyone.

Which lightweight markup formats?

I see this as a win for accessibility, and a way to standardize many complex problems under the same umbrella. Would be interesting to find if they'd publish this, and it could lead to a way to fast-test the UX of many design iterations.

Currently, that process is slow, expensive and requires too many people involved to design, process and review the data.

> I see this as a win for accessibility

Is the definition of accessibility: "Where the hell did they moved the menu and the scrollbar in the new release ?". /s

> For example, it is possible to guess if a UI element is "tappable" from a screenshot (i.e., based on visual signifiers) or from potentially unreliable metadata (e.g., a view hierarchy), but one way to know for certain is to programmatically tap the UI element and observe the effects.

Sigh.

If your site is accessible, this is pretty easy to semantically derive. The issue is that frontend barriers to entry are so low, and good teaching nonexistent, that we have an Eternal September of new web devs making divs instead of buttons and links.

---

The draggability work is certainly more interesting. I suppose it's because it went out of fashion before the revival of new standards in CSS and JS but it's kind of crazy there still isn't a great, standardized way to do drag-and-drop on the web.

Random web apps that aren't the worse offenders. Heck, half of web apps use bootstrap and at least make buttons buttons.

It's the big "professional" players like Apple, Microsoft, Google, etc which appear to think that turning random text into indiscriminate buttons is a good idea. It's the worst of fad driven trends.

For example everytime I open up Apple TV app I have to button left and right to figure out which show is highlighted because the highlight is so subtle and I'm not 20 anymore. All the other TV apps are just as bad, much less the phone apps.

The irony is that these abominations are created in the name of "cleanliness" and "clarity", purportedly to make it simpler for users to make sense of UIs.

This paper is about App Store apps, not web sites.

Swift and Android also both have accessibility built in.

https://developer.apple.com/documentation/swiftui/view-acces...

https://developer.android.com/guide/topics/ui/accessibility/...

> Swift and Android also both have accessibility built in.

ROTFL. Like in iOS where menu names are truncated, because they won't fit on the screen, because i was shameless and used a biggest font because the default one was unreadable ?

Or like in Android where, in Messages, the Status message after a copy to clipboard operation, obscures the input field ?

I am willing to bet $1m that fewer than 100 iOS or Android devs use generic views instead of buttons.

>Never-Ending Learning of User Interfaces

At first I thought it's about users continually being forced to relearn UX they relied for years because app's developers came up with a new "design" that should "improve things" according to their "studies" which found something confusing.

This is why the number-one request from users is: "Please don't change anything."

When you go through an office area, where people are using "enterprise" software all day, make a mental note of the little pieces of paper taped to their monitors and cube walls, with written-out instructions for getting through everyday tasks. One thing is that they don't want to be forced to re-make those instructions, which may have been discovered at great cost.

Yep.

Some industries, at this point in time, should be using the same compute and toolkit in 100+ years.

My mechanic is using software he bought in the 90s, in an emulator, becuae why change? What's the point?

He enters customer names, he books appointments, he inputs inventory, he bills. Nothing has changed in 30 years, norhing will change in another 30.

It's barely a gui by today's standard, and works wonderfully.

Why transition to another POS system? Why worry about conversion of current data?

And the stuff he has is rock solid. All the new stuff he tried has bugs, and the bug fixed versions have different bugs.

You wanna be a hard core dev? Develop stuff that will be written to floppies and pressed to CDs, with no internet for updates.

90s? Look at banks, ticket reservation systems, utility management systems, etc, where COBOL sticks from 1960s, and benefits of a rewrite remain dubious.

Another thing is you wouldn't want to impose that great cost of discovering UI for everyday tasks to all the future generations of office area dwellers

That's what it should be about. I thought the same thing. I'm so tired of looking for where the "submit" button is or trying to figure out your stupid new password requirements. Must contain: 1 letter, 1 emoji, 2 uppercase, no "Z"s allowed... smfh

You forgot to include today's wordle answer in your password.

Pardon me that I'm somewhat off-topic but it seems tangentially related, the rant I'm about to go on --

When looking particularly at the evolution of MS Office, I often land on the view that UI peaked around 2010 and promptly shot down in ruins with the advent of flat design. It's flat design which went away from gradient textures on buttons which for preceding years familiarized us with the impression of button states, importance information, and a handful of other subtle things.

The stated reason was simple and understandable, the designs had needed to remain sensibly consistent when switching from small form factors to large ones, when resizing (or rotating e.g. when a tablet goes from horiz. to vertical, etc. But I'm not satisfied with this defense: it seems lazy, the gradient textures could have been retained. It would have required a lot more work by Microsoft/Google UI designers, but they chose not to step up to the plate by just giving it all up to go the easy road. At least Apple has had the courage to not take the easy way out.

The ribbon design apparently came out in 2007, which fits my memory—it was terrible, Office was already well into decline by 2010.

Although, really, it is just what some of the other comments mention here. Re-learning UI is just a pain in the butt. So, I guess the first version of office that we all hate is the first one that came out after we were kids and learning new UI was fun.

> I guess the first version of office that we all hate is the first one that came out after we were kids and learning new UI was fun.

It's not (just) that. It's that the "ribbon" didn't simplify things, it just lowered the number of clicks to get to some things. But one of the reasons you organize things in submenus is to organize things.

It's easier and faster to find a particular thing hiding within a few dozen labelled boxes, each filled with another few dozen labeled boxes, than to find something when all of the contents of all of those boxes are dumped out onto the floor. Even more, within a hierarchy it's easier to find other, closely related things to the thing that you were looking for, if the thing you were looking for turns out not to do the job.

Office on macOS still has a menubar. I think some of the options are only in the ribbon, but it's there.