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