111–120 of 151 posts
Visual Studio Code has a huge realtime problem. I find myself typing ahead by ten or 15 characters most of the time before changes show up in the UI. At which point either my brain-typeahead buffer overflows, or keystrokes start getting dropped (I'm not sure which). Not sure if this is a problem specifically on Linux or not. I like to think that on Windows, UI-thread/process priority boosts take care of this problem,…
Earlier quoted context omitted.
That doesn't follow. Your UI can be responsive while the round trip happens. The application won't literally stop working 100%.
Depending on the application. Take single-window editor (think notepad) for example. If the "load" command is blocking, what can you do? You cannot allow editing - the existing buffer will be replaced once load completes. You can show the menu, but most options should be disabled. And it will be pretty confusing for user to see existing file remain in read-only mode after "open" command. The most common solution if y…
Even if you rebuilt the the entire OS and libraries on a separation of sync vs async code, you still come to the inevitable problem of propagating delays to the user in a predictable manner. So I've pressed a button to load a file that's usually really fast and this time nothing happens because the async call is taking it's time. Is that being represented to the user in some meaningful way? Is the button disabled unt…
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.
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.
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
They later gave this up and almost everything else in their very reasonable guidelines based on actual research when they switched to OS X in a hurry and multithreaded everything. The early Mail application was a disaster, for example. Generally, people started complaining a lot about the spinning beach ball of death.
In contrast, modern UX guidelines are mostly about web design, how to make web pages look fancy. They also recommend instant feedback, but many libraries and application designs don't really support it.
Visual Studio Code has a huge realtime problem. I find myself typing ahead by ten or 15 characters most of the time before changes show up in the UI. At which point either my brain-typeahead buffer overflows, or keystrokes start getting dropped (I'm not sure which). Not sure if this is a problem specifically on Linux or not. I like to think that on Windows, UI-thread/process priority boosts take care of this problem,…
Even if you rebuilt the the entire OS and libraries on a separation of sync vs async code, you still come to the inevitable problem of propagating delays to the user in a predictable manner. So I've pressed a button to load a file that's usually really fast and this time nothing happens because the async call is taking it's time. Is that being represented to the user in some meaningful way? Is the button disabled unt…
Earlier quoted context omitted.
That doesn't follow. Your UI can be responsive while the round trip happens. The application won't literally stop working 100%.
Depending on the application. Take single-window editor (think notepad) for example. If the "load" command is blocking, what can you do? You cannot allow editing - the existing buffer will be replaced once load completes. You can show the menu, but most options should be disabled. And it will be pretty confusing for user to see existing file remain in read-only mode after "open" command. The most common solution if y…
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…
You list a bunch of unrelated things that has absolutely nothing to do with the topic: UIs back in the day had less latency, by not caring about accessibility, internationalization, etc - but I’m quite sure they were way worse off in terms of properly handling blocking operations: you surely know the Solitaire effect
Earlier quoted context omitted.
> Code was constantly being profiled using raster bars. For those wondering: we'd change the background color from, say, black to blue for the "physics" part, to green for the "drawing" part, to purple for the "audio rendering" part... All in the same frame, while the frame was being drawn. So you'd see on the border of your screen (usually outside of the drawing area you'd have access to) approximately which percent…
> People don't understand that their 144 Hz monitor running a 3D game still doesn't convey that smoothness that my vintage arcade cab does when running an old 2D game with pixel-perfect scrolling while never skipping a frame. The actual motion-to-photon delay (measurable with a high-speed camera) in a well optimized competitive FPS is somewhere around 20ish ms or less these days, so it's on par with it in regards to…
I.e. more than two frames between input and output. That is quite a lot, and AFAIK a large regression.
Earlier quoted context omitted.
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