Most UI applications are broken real-time applications • Hacker News Board

Re: Most UI applications are broken real-time applications

#91

Post by dumpsterdiver » Fri, Sep 22, 2023, 3:33 AM UTC

redserk wrote: post #53

_y5hn wrote: post #49

Earlier quoted context omitted.

There were all kinds of standards, guidelines that made people recognize what the program is doing and how to operate it. Nowadays, UIs are mostly defective, trying its best to hinder effective usage and hide/strip functionality. There are of course progress too, but something was lost that make applications today much less intuitive and hard/tough to use.

I don't understand what specifically is of concern here. Do you have exact examples? Some platforms publish a list of recommended guidelines which are effectively a standard. For example here's one from Apple about when and how to use charts in an application: https://developer.apple.com/design/human-interface-guideline...

One made up example that attempts to embody the complaint:

If I visited a site dedicated to hamburgers today, I would not be surprised if the "Log Out" button was presented as an image of a hot dog. It would be a mystery to me what that hot dog did until I clicked on it.

Compare this to 90's UI, where it would pretty much be unheard of to do something like that. It would have been a joke, or a novelty. These days that sort of ambiguous interface isn't presented as a joke or a novelty - it's the real product.

Re: Most UI applications are broken real-time applications

#92

Post by bc_programming » Fri, Sep 22, 2023, 3:46 AM UTC

eitland wrote: post #56

OliverGilan wrote: post #35

Earlier quoted context omitted.

Can you be more specific about what was “solved” in the 90s? The platforms upon which apps are run now and the technologies as well as the expected capabilities of those apps have drastically changed. Not all UI development has changed just for being shiny. I see little reason why building a UI today cannot be a superset of what was solved in the 90s so I’m curious to know what that solved subset looks like to you

Just start with the fact that all desktop programs had a menu bar where you could find every feature - and at least on Windows - also a shortcut for that feature. This was broken with Ribbon and the hamburger menus that every application seems to have switched to for no other reason it seems than to copy Chrome. To be fair Ribbon is somewhat useable again, but the in the first version I have no idea how people were s…

A related detail, even things like icon design have gone in a strange direction. In the interest of simplicity they've gone from recognizable to rather amorphous blobs. A button for print has gone from a clearly recognizable image of a printer, enough you could probably even guess the model number, to the icon being a rounded square with another rounded square sticking out the middle top. Many of these newer icons are just too abstract and similar to one another to be recognizable, IMO, and I think the user experience suffers.

Re: Most UI applications are broken real-time applications

#93

Post by Qwertious » Fri, Sep 22, 2023, 4:10 AM UTC

eitland wrote: post #56

OliverGilan wrote: post #35

Earlier quoted context omitted.

Can you be more specific about what was “solved” in the 90s? The platforms upon which apps are run now and the technologies as well as the expected capabilities of those apps have drastically changed. Not all UI development has changed just for being shiny. I see little reason why building a UI today cannot be a superset of what was solved in the 90s so I’m curious to know what that solved subset looks like to you

Just start with the fact that all desktop programs had a menu bar where you could find every feature - and at least on Windows - also a shortcut for that feature. This was broken with Ribbon and the hamburger menus that every application seems to have switched to for no other reason it seems than to copy Chrome. To be fair Ribbon is somewhat useable again, but the in the first version I have no idea how people were s…

IMO ribbon menus are when implemented correctly actually better than a menu bar. It gives icons and the benefit of a GUI to old text-menus.

Hamburger menus I disagree with but sort of understand the logic of - they're basically like making 'fullscreen mode' the default mode, and then the hamburger menu button just sort of temporarily toggles that off. It makes perfect sense on mobile (I don't think that's what you're talking about though), and on the desktop it can make sense in a web browser when you have, essentially, 3 sets of chrome - you have the desktop window, the browser's chrome, and then the website's chrome all before you get to the website's content.

Re: Most UI applications are broken real-time applications

#94

Post by brundolf » Fri, Sep 22, 2023, 4:20 AM UTC

taeric wrote: post #80

brundolf wrote: post #69

> One of the fundamental problems is that many UI applications on Windows, Linux, and macOS call functions that are not specified to run in a bounded amount of time. Here’s a basic example: many applications don’t think twice about doing file IO in a UI event handler. That results in a tolerable amount of latency most of the time on standard disk drives but what if the file is stored on a network drive? It could take…

Huh? It used to be very common to find that a web page was stuck processing some script. Still isn't that uncommon, all told. You are mostly right that you couldn't block on IO, necessarily, but you could still hose up the event thread quite heavily.

If you're actually doing busy logic then it'll block the UI thread, but you have to work pretty hard to do that, and IO won't block the UI thread

Re: Most UI applications are broken real-time applications

#95

Post by zubairq » Fri, Sep 22, 2023, 4:26 AM UTC

Is this article another way of saying that the user doesn't like to wait more than 100ms when they perform an action?

Re: Most UI applications are broken real-time applications

#96

Post by Animats » Fri, Sep 22, 2023, 4:27 AM UTC

I miss running Photon on QNX, which, being a hard real-time OS, did have upper bounds on timing for many operations. Photon was a GUI for near real time interfaces for hard real time programs. It was far smoother than what we see today.

* No paging. Entire program in memory at all times. Although it was possible to put a paging library inside an application and let it manage its own paging, which was done for gcc.

* A real time CPU dispatcher. Real time priorities were strictly preemptive. Unblock a higher priority task, it starts now, not when the dispatcher gets around to it.

* The usual test for a hard real time OS is that you have an interrupt routine that senses an external pin. It unblock a user level task when the pin goes high. The user level task turns on an output pin. You hook up a scope and a square wave generator, and watch the latency. If there are outlier values on the scope, something is broken. One implication is that stuff below the OS, such as anything running in system management mode after boot, has to be eliminated. It cannot be allowed to steal cycles.

* While real time work is going on, you can still run compiles and web browsers. They get preempted. I was impressed that that worked. Our real time application had a hardware stall timer, and if the commands coming out were late, a relay tripped and everything shut down.

So, it's absolutely possible to do this. Downsides:

* You're way out of the mainstream.

* You're going through the general case every time. Fast paths are unwanted.

* Everything is always on. Power consumption is constant. No CPU slowdowns, no sleep modes, no battery saving. This is just fine when you're running a rolling mill, and 99+% of the power is driving the heavy equipment. Not so good when you're running a credit card terminal. Battery powered devices cannot run well in this mode.

Re: Most UI applications are broken real-time applications

#97

Post by aatd86 » Fri, Sep 22, 2023, 4:33 AM UTC

bc_programming wrote: post #92

eitland wrote: post #56

Earlier quoted context omitted.

Just start with the fact that all desktop programs had a menu bar where you could find every feature - and at least on Windows - also a shortcut for that feature. This was broken with Ribbon and the hamburger menus that every application seems to have switched to for no other reason it seems than to copy Chrome. To be fair Ribbon is somewhat useable again, but the in the first version I have no idea how people were s…

A related detail, even things like icon design have gone in a strange direction. In the interest of simplicity they've gone from recognizable to rather amorphous blobs. A button for print has gone from a clearly recognizable image of a printer, enough you could probably even guess the model number, to the icon being a rounded square with another rounded square sticking out the middle top. Many of these newer icons ar…

And since saving to a floppy is not a thing anymore...

Re: Most UI applications are broken real-time applications

#98

Post by _y5hn » Fri, Sep 22, 2023, 4:47 AM UTC

DiggyJohnson wrote: post #88

_y5hn wrote: post #29

Earlier quoted context omitted.

UI was pretty much solved in the 90's including the problem of instant feedback. Then abandoned for shiny stuff. Personally I set up i3 to open most windows asynchronously, so my flow isn't interrupted. It's great, but takes a bit getting used to windows not randomly stealing focus. It's not for everyone though.

My biggest issue with i3 (which I generally love and have used for 5+ years) is that if I switch to a workspace, launch an application with dmenu, and switch to a different workspace before the application loads, the application will load on the current workspace instead of the workspace I originally launched the application from. Anyone have a solution?

If you use the same workspace for the same apps, I believe people configure i3 to force apps on the same workspace.

Not my cup of tea, but I got the same problem.

Going to try this: https://faq.i3wm.org/question/2828/open-application-and-fix-...

Re: Most UI applications are broken real-time applications

#99

Post by rerdavies » Fri, Sep 22, 2023, 4:55 AM UTC

masfuerte wrote: post #60

scott_w wrote: post #24

Earlier quoted context omitted.

If I recall correctly, the PS4 controller has a disgusting amount of input delay. I noticed this most strongly on the FFX Remaster where you need to hit timer events before the arrow enters the shaded box. It doubly screws you in the chocobo racing section because the controls assume no delay, meaning you can’t respond to hazards in time and constantly overcorrect movement.

Some multiplayer network games memoise the game state. When an input event arrives from a remote player it is applied to the game state that existed at the time of the event. Then the state is fast-forwarded to the present time and the game continues. Ideally you shouldn't notice this happening. The obvious fix for laggy input is to apply the same processing to local input, but I've not heard of anyone doing this. (I…

Early versions of Android had this feature (Android 3-ish, 4-ish?)

Touch events were run through a filter to predict where the touch position would be some number of frames in the future -- presumably to compensate for page-flipping delays. Not sure it made much difference, mostly because smooth animations on old versions of Android were extremely difficult because of inadequate CPUs/GPUs.

The classes used to do predictive tracking don't seem to be used anymore in current best practice/current API sets.

Re: Most UI applications are broken real-time applications

#100

Post by ReactiveJelly » Fri, Sep 22, 2023, 4:58 AM UTC

RecycledEle wrote: post #78

Yes. UI should be run in a separate processor in real time. I am tired of clicking to see the screen change after I click and the click registers on the new screen, not what I clicked on.

Total overkill. If the screen loading is slower than a frame because of...

- I/O like file access or networks, you can punt to an async framework like Rust's Tokio

- CPU number crunching like cracking a password, you can punt to a worker thread (like Tokio's `spawn_blocking`)

The kernel scheduler is smart enough to give time slices to the UI thread even if the password-cracking thread is trying to eat as much CPU as possible, or, God forbid, the network thread is _sleeping_ until a packet arrives. (Networking is a waste of a thread. Most requests and responses are small enough that the CPU could process them on the UI thread, it's just that sleeping the whole thread until the message shows up is goofy)

It's not a lack of processors, it's the fact that good multi-threading and UI totally changes the architecture of a program, and most of us aren't trained for it or incentivized to implement it.