peter sikking writes:
> > Peter, I have to ask: how much have you actually used GIMP for
> > screenshots? Have you done a lot windows cut from full-screen
> > screenshots? Or talked to users who do?
>
> 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? Is that the percentage of
users who would be slowed down by seeing both delay options?
Or by the previous behavior of having a delay only after selection?
What is the corresponding percentage of users who are slowed down by
having only a before-selection delay? Are these numbers based on
usability testing, or user interviews, or analysis of bugs or public
comments, or what?
I'm hoping that, this being an open source project, the methodology
involved in this interaction analysis is public and available for
everone to see and understand and learn from.
[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?
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 purpose?
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% case).
> In 'snap window' mode the shot shall be taken:
>
> a) on the first mouse-down after the timer (can be zero) has expired;
> b) immediately, when a non-zero timer expires AND a mouse-button
> (left, right [pop-up menu], even middle?) is being held down.
That takes care of menus, but there transient effects which don't
involve a mouse button down. For gimp, examples include the cursor
outline of a brush, or the line you get pressing shift in a drawing
tool. That's admittedly an uncommon case, but how about the very
common case of hover effects in a browser?
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?
Steve Stavropoulos' interface, with the two clearly explained
delays, seems so much easier to understand than trying to intuit
a mouse-already-down behavior.
--
...Akkana
"Beginning GIMP: From Novice to Professional": http://gimpbook.com
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
