[squeak-dev] dynamic FileDialog pop-ups considered harmful

tim Rowledge tim at rowledge.org
Sun Dec 29 19:40:52 UTC 2019



> On 2019-12-28, at 10:03 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
>  Dude, it's even emperically measurable along dimensions of user wait-time!  Liken to booting up phreaking windows, a solid HD light, chunking away, as I wait for my golden opportunity to... wait for it...  get ready to do same slavish response to the computers bidding as everyone else 99.999999999999% of the time with this function... wait for it.... -- NOW! smack that darn OK button!  Train-of-thought, obliterated!  :/ It's simply too intrusive to impose this one way of working onto all Squeak users.

Well, let's measure it. On My Pi3, probably the slowest machine regularly running Squeak, with about 10% of the performance of a typical laptop of the last 5 years. That way we'll get an idea of how terribly slow it is to open a complex dialogue like the FileSaverDialogue.

With a little whacking to make a suitable method that sidesteps having to actually interact with it before getting a time worked out, it turns out that it takes 170ms to create, open, and display the dialogue. On a typical laptop I'd expect around 20ms - or about a single frame refresh cycle. I won't even bother to measure the time it takes for the plain old FillInTheBlank because it can't be less than that in a Morphic world unless one has fiddled with the cycle rate. Oh hell, let's measure it anyway - 115mS on the same machine.

So to save an image with a new name via the UI, a not common activity but one that would typically involve wanting to at least see some reminders of what image names are in use in the current directory so as to not accidentally over-write them, or to save to a different directory, the new dialogue adds *no* visible time to open and no extra clicks. You still have to type any new name just as before. It simply provides more information and user action choice.

For saving preferences - again a not-common activity, and in any case one where you've mentioned an altogether different approach - using the FileSaverDialogue clearly adds some time over simply clicking on a button. However, I claim that it adds utility by providing a UI route to choosing where you save said preferences. That means one can keep a single (or several if that be ones desire) preferences file to share between images kept in different places or different machines. And if the general view is that it is better to be restricted to the preferences file always being 'my.prefs' in the image directory and having to manually find and copy it to any other directory where one has an image - well I don't care since it was a suggestion based on 5 minutes work.

For handling fileouts from a browser it doesn't bother me personally because I so rarely do that that I haven't noticed. I think it's fairly poor UI in general to only allow saving some item in one place under one name. It's especially stinks in the context of a deep and rather opaque context like the all-in-one directory tree. A simplistic (but I think bad) option would be to have two menu options
file out
fileout as...
.. since we already have way too many items bundled up in poorly laid out menus.

I'm not seeing any cases where I'd expect any terrifying interruption of mental state. The only case mentioned so far where one might be wanting to rapidly click-click-click would be filing out a bunch of items in a browser - I suppose one might be quickly clicking on a bunch of methods/classes and hitting menu->fileout repetitively? In which scenario there is plenty of UI interaction already getting in the way and there must be much, much, better ways to do the job. At the very least we ought to be able to multi-select browser list items to improve that sort of action. Or provide drag/drop to a filelist? 

All in all I'm having a lot of trouble seeing where there is a problem. Clearly I need simpler explanations of the issue in order to comprehend it.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
atheism: not a religion, more a personal relationship with reality.



More information about the Squeak-dev mailing list