Re: Meaning of delay in screenshot plugin

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sven wrote:

>> We would like to see however two improvements:
>>
>> 1) A big, fat visual countdown of the delay. I can see a
>>     big (200 point font) semitransparent numbers overlaying
>>     the screen counting down 4-3-2-1. No more guessing how
>>     long do we still have to get that other window in front.
>
> Unfortunately that is probably not possible to implement in a portable
> fashion.

Yeah, only a desktop environment can pull something like that off.
Which brings us back to "absolute number one:

Yes, taking screenshots is a task for the OS/desktop environment."

> One thing that I could imagine that might work is to use custom
> cursors. While the pointer is grabbed, we could let the mouse cursor
> count down the remaining seconds.

The delay has one purpose: to allow the user to get her
window/ desktop in order, ready for the shot. Maybe better
leave the cursor normal during that.

Akkana Peck wrote:

> peter sikking writes:
> P> At the moment Kamila and I are very busy with our (interaction
> P> architecture) expert evaluation of the current GIMP, and this
> P> morning we happen to stop by the screenshot plugin.
> [ ... skip to end of message ... ]
> P> I think that puts an end to any doubts,
>
> Oh, well, that's it, then.
> There's no point in mere users trying to offer any input.

input is fine, if you tell me something that makes me doubt
about the decision that I have taken, then I will re-evaluate
the whole thing, taking into account all old and new input.

> P> - the fact that it is a piece of cake to cut out a rectangle
> P>    out of a image in GIMP, or two added rectangles (window +
> P>    menu sticking out).
>
> 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,
in order to make 1% happy. The decide to make 99% happy
in the standard distribution, and the 1% can use the (already
released! go open source!) super screenshot plugin, or a load
of other ways of getting the job done efficiently.

> Peter, I couldn't find in your message where you explained why
> you concluded the pre-selection delay is worthwhile, while the
> post-selection delay is not. Can you explain that more clearly?

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. Hence the delay. Taking screenshot of something
on the screen is a field that is one or two orders of magnitude
broader than taking screenshots of transient user interface
elements. Combined with other factors (need exactly the window,
user sees GIMP actually as the right tool for this job...) we
get to my estimate useful at max for 1% of our users.

Clarence Risher wrote:

> On 1/30/07, peter sikking <peter@xxxxxxxxxxxx> wrote:
>> - the fact that it is a piece of cake to cut out a rectangle
>>    out of a image in GIMP, or two added rectangles (window +
>>    menu sticking out).
>
> For the record, windows are not always rectangular, or do not always
> fill their bounding box.

You see, you had me doubting there, but then Sven wrote:

> The windows are still rectangular […]

else I would have given the whole thing a re-think.

Marco Ciampa wrote:

> See ksnapshot for an example of a better interface.

So I had a look, one delay, but they also gave me an idea how
we can make everybody here happy, without the cost of two delays:

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.

The latter captures menus being open or pushbuttons being down
exactly when the timer expires.

So you can set a single timer, go to the app, push open or down
whatever needed to be pushed and wait for the delay to expire:

snap.

So this mail has become a running narrative towards a better solution.

I thank everyone for their extra input. It helped us to improve GIMP.

     --ps

         principal user interaction architect
         man + machine interface works

         http://mmiworks.net/blog : on interaction architecture



_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux