>> I am an interaction architect, I have to take a decision what is
>> the best solution for 1 million users. We spend time evaluating
>> this feature systematically. We especially focussed on your
>> use case. But we saw the cost in UI complexity to put in the
>> second delay. This complexity slows down 99% of the users,
> Not being an interaction architect, I'm still not understanding.
> How did you arrive at the 99% number?
I explained how I got to the 1%, the 99% are the rest of GIMP users.
And 1% is already a very generous, on the safe side, estimate.
Do you really think you can round up ten thousand GIMP users who
ever have to take a screenshot of a window with something pressed
AND consider GIMP actually the right tool for this?
You'll struggle to find one thousand, exactly because most would not
choose GIMP. But 1% is a convenient number and it drives the message
I simply want you to concentrate on 990000 GIMP users, who will
never ever take a screenshot of a window with something pressed,
with GIMP. Confront them with two delays, and you make them think
what the difference is. You just stopped them working...
Now you take the same decision as I had to take.
> [pre- vs. post- selection delay]
>> I estimate the chance that one is not taking a screenshot of GIMP
>> itself as higher than 50%. So you need time to get GIMP out
>> of the way.
> To get the screenshot dialog out of the way, you mean?
No, to get GIMP out of the way. The 800 pound gorilla that eats a
million pixels of screen real-estate for breakfast.
> Is it really that common to screenshoot a single window which is
> so large that there isn't room for both it and the screenshot dialog
> on the screen at the same time?
> To the list: does anyone here actually uses the delay for that
> The people who have asked for before-screenshot delay mostly seem to
> want time to switch desktops (a valid reason but surely not a 99%
In general the delay is 'time to get ready'. Get GIMP out of the way.
This can be done in a multitude of ways, of which switching desktops
> I also wonder about discoverability: "Sometimes I have to click on
> the window after the delay, but sometimes I don't." Will people
> figure out that having a mouse button already pressed is what
> makes the difference?
I already asked for the improvement that we use two lines of
text to explain what happens (depending on the snap option)
during and after the delay.
Everything is cool with the interaction syntax, when the delay
expires, the user says 'this one' by either clicking on it, or
already holding it up by the ears.
And you know what? It feels really good that I have sped up your
workflow, compared to 2.2, without making 990000 other users
pay for that.
> Steve Stavropoulos' interface, with the two clearly explained
> delays, seems so much easier to understand than trying to intuit
> a mouse-already-down behavior.
Only if you have been taking many screenshots of stuff pressed
in windows with GIMP for the last few years.
Putting the two delays in the UI on the same level is a big
mistake, actually. Makes one even more think "what is this
selection..?" The 2.2 dialog did that better.
principal user interaction architect
man + machine interface works
http://mmiworks.net/blog : on interaction architecture
Gimp-developer mailing list