The Finder’s GUI tax can be very expensive

Re:The Finder’s GUI tax can be very expensive by cesarb on Thursday December 08, 2016 @04:49PM (#13134615)

> a window with a single progress bar for the entire task would be OK, but would still slow operations down.

There's a simple way to do a visual progress bar with almost zero slowdown: run the task in a separate thread from the progress bar, and update the progress through lock-free shared variables. Make the progress bar read the shared variables only a couple of times per second, sleeping between its updates.

[ Parent | on HN ]

Re:The Finder’s GUI tax can be very expensive by fredsir on Thursday December 08, 2016 @05:52PM (#13135061)

It's not only the communication between the task and the GUI that is slowing things down (if it is at all, which I doubt). Even more, I think, it's the fact that macOS, the OS in question, has some conventions for windows, controls and so forth, one being that it takes X seconds for the window to appear and X seconds for it to disappear. If it was being shown and hidden again as fast as the task starts and finishes, it would be just be a flicker on the screen, which would confuse the user. It also doesn't make sense to spend a second to show a window, if the progress bar it embeds has completed before the second has elapsed, so there has to be a delay there, and so forth. The task is so quick it can really not be presented to the user without the presentation being slower than the actual task.

I think it comes down to good UI+UX, which in this particular case becomes bad UI+UX.

[ Parent | on HN ]

Re:The Finder’s GUI tax can be very expensive by waterhouse on Thursday December 08, 2016 @11:44PM (#13136737)

If they're simply following UX recommendations blindly, they could go for this one:

"Use a progress indicator for any action that takes longer than about 1.0 second."

https://www.nngroup.com/articles/progress-indicators/

You don't necessarily know in advance whether it'll take 1 second, but I think a strategy that would work is: after 1 second, if the task is not done, open a progress bar, and if the task completes immediately after that, display the completed progress bar for 500 milliseconds or something before closing it.

[ Parent | on HN ]

Re:The Finder’s GUI tax can be very expensive by userbinator on Thursday December 08, 2016 @10:24PM (#13136440)

If it was being shown and hidden again as fast as the task starts and finishes, it would be just be a flicker on the screen, which would confuse the user.

Maybe the really inexperienced users, but it makes sense that something which happens quickly, will mean a window that also appears and disappears quickly. This is why Windows has options to disable animations and other effects, and everything does feel noticeably more responsive when they are disabled --- windows and menus appear and disappear instantly.

[ Parent | on HN ]

Re:The Finder’s GUI tax can be very expensive by oneeyedpigeon on Thursday December 08, 2016 @07:44PM (#13135750)

I think an 'in-line' style of alert can work well in this situation, like a status bar but closeable. It can be dealt with at a time most convenient to the use, still provides feedback. It could even just display the output of a CLI command with a given flag, even for a small subset of 'blessed' commands if necessary.

[ Parent | on HN ]