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

The Finder’s GUI tax can be very expensive

robservatory.com

Post reply on HN
Print view View original

71–80 of 125 posts

Re: The Finder’s GUI tax can be very expensive

#71

Post by yoz-y »

radley wrote: post #35
patio11 wrote: post #16

I wonder whether this is not an example of a UI interaction which is slow on purpose, to emphasize how much work the OS is doing for you. TaxAct and TurboTax, for example, both operate on (in the typical case) kilobyte scale data requiring trivial math. They also make both saving the data and calculating taxes take 5+ wall-clock seconds when they actually require milliseconds and nanoseconds respectively. This is lar…

No, it's about showing it long enough so you know what the dialog is and what it's doing. If a dialog popped up for the brief amount of time it actually takes to unzip, it might freak out users: "huh? WTF was that??"

Maybe a new type of dialog could help? Rather than showing this blinking things, just show a notification of style "24 archives extracted" (kind of like what forklift does)

Re: The Finder’s GUI tax can be very expensive

#72

Post by chipperyman573 »

matheusmoreira wrote: post #65
TazeTSchnitzel wrote: post #17

Earlier quoted context omitted.

This reminds me of how some PlayStation game's developers complained that they were required by Sony to add a false multi-second delay to their game's save routine, so the user would have enough time to read the mandatory warning not to turn off the console. Their game in fact saved so quickly there needn't be a warning at all.

This is really interesting. I read that warning every time I save and I never noticed the delay. For some reason, it doesn't bother me like the archive utility animations. I guess it's because saving the game is a such ritualized action. I wonder what other requirements Sony imposed on developers. Maybe they have their own video game-oriented human interface guidelines. Do you have a source for this information? I fo…

Kind of related, the reason there's a "Press A to play game" on xbox (and a lot of PC ports) is because Microsoft requires a button press every x seconds, and if the game takes too long to load before the menu appears, pressing A will circumvent that requirement.

Re: The Finder’s GUI tax can be very expensive

#73

Post by _v7gu »

TazeTSchnitzel wrote: post #17
patio11 wrote: post #16

I wonder whether this is not an example of a UI interaction which is slow on purpose, to emphasize how much work the OS is doing for you. TaxAct and TurboTax, for example, both operate on (in the typical case) kilobyte scale data requiring trivial math. They also make both saving the data and calculating taxes take 5+ wall-clock seconds when they actually require milliseconds and nanoseconds respectively. This is lar…

This reminds me of how some PlayStation game's developers complained that they were required by Sony to add a false multi-second delay to their game's save routine, so the user would have enough time to read the mandatory warning not to turn off the console. Their game in fact saved so quickly there needn't be a warning at all.

I'm never actually sure if I actually saved in the PC port of Valkyria Chronicles. I think we've been trained to wait a while to save since the 8 bit consoles so something feels a bit wrong when things instantly save. Undertale makes amazing use of this, though.

Re: The Finder’s GUI tax can be very expensive

#74

Post by arjie »

thaumasiotes wrote: post #46
dijit wrote: post #31

Earlier quoted context omitted.

quiet reminder that writing to file descriptors is blocking. STDERR and STDOUT are file descriptors.

Maybe so, but, as pointed out elsewhere in the thread, printing to stdout is much, much, much, much slower than printing to a file. The fact that stdout is a file descriptor can only explain a vanishingly small quantity of the time cost of using it.

It's a combination of many things. You're probably writing to a file buffered, but terminal writes are generally unbuffered. In addition, I had a terminal setup once that just did a poor job of displaying text (line wrapping was slow, perhaps) and programs that would write out to stdout would be slow.

Re: The Finder’s GUI tax can be very expensive

#75

Post by matheusmoreira »

chipperyman573 wrote: post #72
matheusmoreira wrote: post #65

Earlier quoted context omitted.

This is really interesting. I read that warning every time I save and I never noticed the delay. For some reason, it doesn't bother me like the archive utility animations. I guess it's because saving the game is a such ritualized action. I wonder what other requirements Sony imposed on developers. Maybe they have their own video game-oriented human interface guidelines. Do you have a source for this information? I fo…

Kind of related, the reason there's a "Press A to play game" on xbox (and a lot of PC ports) is because Microsoft requires a button press every x seconds, and if the game takes too long to load before the menu appears, pressing A will circumvent that requirement.

>Microsoft requires a button press every x seconds

What is the rationale behind such a requirement?

>if the game takes too long to load before the menu appears, pressing A will circumvent that requirement.

Does this mean those screens/videos that get displayed after the game starts and before the menu appears are required by Microsoft to be skippable?

If that's the case then it's good UX design in my opinion. I think those things are an unacceptable waste of player's time; I hate them so much I rename the files in the game's directory so it will fail to show them.

Re: The Finder’s GUI tax can be very expensive

#76

Post by frik »

_v7gu wrote: post #73
TazeTSchnitzel wrote: post #17

Earlier quoted context omitted.

This reminds me of how some PlayStation game's developers complained that they were required by Sony to add a false multi-second delay to their game's save routine, so the user would have enough time to read the mandatory warning not to turn off the console. Their game in fact saved so quickly there needn't be a warning at all.

I'm never actually sure if I actually saved in the PC port of Valkyria Chronicles. I think we've been trained to wait a while to save since the 8 bit consoles so something feels a bit wrong when things instantly save. Undertale makes amazing use of this, though.

There was a time, when F5 key for Quick-save was common in PC games.

Together with Quick-load, it worked very fast, no need for info-screens, it just worked in milli-seconds and allowed gameplay styles completely forgotten or newer experienced by console gamers who are keen to their save-point system.

Re: The Finder’s GUI tax can be very expensive

#77

Post by seanp2k2 »

8ytecoder wrote: post #22
patio11 wrote: post #16

I wonder whether this is not an example of a UI interaction which is slow on purpose, to emphasize how much work the OS is doing for you. TaxAct and TurboTax, for example, both operate on (in the typical case) kilobyte scale data requiring trivial math. They also make both saving the data and calculating taxes take 5+ wall-clock seconds when they actually require milliseconds and nanoseconds respectively. This is lar…

No kidding. In one of my previous companies we explicitly added a delay in our financial webapp. We saw a significant improvement in bounce rate after that.

Hahaha, I remember coding some physics problem solvers in Visual Basic back in high school, and I added a "calculating" progress bar and messed with the timing a lot to make it still pleasant to use but seem like it was really crunching through your problem. "Crunching" is even funny and a throwback to the days of spinning rust + lots of random seeks.

Re: The Finder’s GUI tax can be very expensive

#78

Post by frik »

chipperyman573 wrote: post #72
matheusmoreira wrote: post #65

Earlier quoted context omitted.

This is really interesting. I read that warning every time I save and I never noticed the delay. For some reason, it doesn't bother me like the archive utility animations. I guess it's because saving the game is a such ritualized action. I wonder what other requirements Sony imposed on developers. Maybe they have their own video game-oriented human interface guidelines. Do you have a source for this information? I fo…

Kind of related, the reason there's a "Press A to play game" on xbox (and a lot of PC ports) is because Microsoft requires a button press every x seconds, and if the game takes too long to load before the menu appears, pressing A will circumvent that requirement.

N64 had press Start to start, years before XBox was even a thing.

And yes, many/most PC ports are of very low quality. Gone are the days of PC-first Triple-A games with forgotten features like Quick-save/load, LAN-multiplayer, Map-editor, official Mod-support. These days, these ports feel like they started porting two months before release, done by two coders. All these console-ish things like messages "don't turn off your system" (yah-right), press a key to start (yup), save-points (wtf), always-on single player (...)

Re: The Finder’s GUI tax can be very expensive

#79

Post by PebblesHD »

frik wrote: post #76
_v7gu wrote: post #73

Earlier quoted context omitted.

I'm never actually sure if I actually saved in the PC port of Valkyria Chronicles. I think we've been trained to wait a while to save since the 8 bit consoles so something feels a bit wrong when things instantly save. Undertale makes amazing use of this, though.

There was a time, when F5 key for Quick-save was common in PC games. Together with Quick-load, it worked very fast, no need for info-screens, it just worked in milli-seconds and allowed gameplay styles completely forgotten or newer experienced by console gamers who are keen to their save-point system.

One of the best, and most under-utilised features of Half-Life, to name one of many. Made clearing a room an entertaining exercise in how few crowbars/bullets/rockets can you use...

Re: The Finder’s GUI tax can be very expensive

#80

Post by pvdebbe »

hughw wrote: post #3

"Finder (nee Archive Utility) should just execute the task without any visual feedback" -- no.

J Nielsen would disagree with you. A subsecond operation could very well operate without visual feedback and only after that start showing the progress. Does finder have a way to show messages in status bar or some such? For quick ops it would be ideal to say, "operation completed".
Post reply on HN