Re: [Gimp-developer] lgm 07, top‑5 GIMP user requ ests...

[peter sikking]

Sven Neumann wrote:

> On Sat, 2007-05-26 at 16:50 +0200, peter sikking wrote:
>
>> The choice it to make either the dialog or 'no dialog' a tricky power
>> feature. I choose, without a doubt, the former.
>
> I explained you why that choice is not acceptable. If you did not
> understand my last mail, why don't you just ask?

I think we are talking now past each other...

>> When I look fundamentally at what layers are, the optional character
>> of all functionality (name, size, fill) offered by the dialog,
>> combining that
>> to realise the percentage of times that each will be useful and the
>> alternatives to reach the same goal, take into account that this is
>> part of user request #5, then dealing with this dialog dozens of  
>> times
>> a day is a burden on GIMP's user experience.
>
> Please stop reiterating these buzz-words; it starts to become annoying
> after a while.

If user interaction problems need to be solved, then it needs to be
discussed in user interaction terms. If I would translate this totally
into user-space or developer-space, then it would trivialise the issue.

So that's it then, for this issue...

 --ps

 principal user interaction architect
 man + machine interface works

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



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

Re: [Gimp-developer] lgm 07, top‑5 GIMP user requ ests...

[Alexander Rabtchevich]

I just want to add 2c. I got a strange opinion - the most annoying thing 
of Gnome is its HUG. The opinion is caused by the majority of complains 
about it on Russian Linux forum. Not the HUG itself but the idea that if 
some feature can be considered as not totally obvious for a newbie, this 
feature should be simply deleted. Does anybody remember File Opening dialog?

Why should any powerful functionality be deleted in a sake of somebody 
who does not want to use it? Why does anybody want to take it from ME 
and others if HE does not need it? :)

IMHO the one and only way to solve this problem, if it is solvable at 
all, is to add an extra button - something like "Yes to all". Clicking 
this button means a a user says "Yes" to all further dialogs, maybe 
except file overwriting.

Sven Neumann wrote:
> 
> By removing the dialog you add an extra step to the workflow. The user
> will now have to fill the layer or add/remove the alpha channel. That
> does sounds like an extra burden. We need to look at this in more
> details. You can't just claim that the dialog would be useless and
> remove it. But I am sure that there are ways to improve the work-flow.
> 


-- 
With respect
Alexander Rabtchevich
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm 07, top‑5 GIMP user requ ests...

[peter sikking]

Sven Neumann wrote:

> On Fri, 2007-05-25 at 19:03 +0200, peter sikking wrote:
>
>>> BTW, the dialogs that you consider to be "unnecessary" can  
>>> already be
>>> skipped using the Shift key.
>>
>> Then the perfect solution is that we reverse the logic of that
>> shift key. Only with the shift key down the dialog is shown.
>>
>> Our users will be eternally grateful...
>
> Oh come on, you are really making things simpler than they are.

that is because from the perspective of my profession and after
the systematic effort put into evaluating this, it is really clear
that doing this benefits GIMP.

> Either a
> dialog is really redundant, then it should be removed. Or a dialog is
> useful and even necessary for certain important tasks.

I found 'reversing the shift key' a beautiful solution because the
dialog already exists and GIMP is full (rightly so) of these power
features.

It fits the interaction principle that straight ahead user concepts
(new layer) have a straight ahead UI.

> Then we can not
> only make it available by pressing some obscure modifier key. It would
> be more or less undiscoverable and we had effectively removed an
> important feature.

The choice it to make either the dialog or 'no dialog' a tricky power
feature. I choose, without a doubt, the former.

> We will have to stay with the current solution until we have found  
> other
> ways to provide the functionality.
>
>> But if like with the layers dialog, I see zero function 99% of the  
>> time
>
> The dialog saves you the extra step of filling the layer. In my  
> opinion
> it is very useful and speeds up the workflow. After all the user just
> needs to press the Enter key to acknowledge the last used settings.

When I look fundamentally at what layers are, the optional character  
of all functionality (name, size, fill) offered by the dialog,  
combining that
to realise the percentage of times that each will be useful and the
alternatives to reach the same goal, take into account that this is
part of user request #5, then dealing with this dialog dozens of times
a day is a burden on GIMP's user experience.

All I ask for is to give it a chance. GIMP has what adobe has not,
a community. They want to participate by using developer versions
in real life situations. I say let them help.

Try this in an early development version (like 2.5.2) and wait for
the learning effect (you changed it!) to go away. Then after a while
evaluate.

If it then turns out to be the wrong idea, I'll be the first one
to admit it.

 --ps

 principal user interaction architect
 man + machine interface works

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



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

Re: [Gimp-developer] lgm 07, top‑5 GIMP user requ ests...

[peter sikking]

Sven,

> On Fri, 2007-05-25 at 02:15 +0200, peter sikking wrote:
>
>> > requests_25.html>
>
> BTW, the dialogs that you consider to be "unnecessary" can already be
> skipped using the Shift key.

Then the perfect solution is that we reverse the logic of that
shift key. Only with the shift key down the dialog is shown.

Our users will be eternally grateful...

> Sure, perhaps not the most intuitive and
> discoverable approach, but it works well for our power users.

Like I said, there is no such thing as intuitive >^}

> And
> sometimes the dialogs are not that unnecessary at all. So we can't  
> just
> remove them. At least not all of them.

After the provocative statements that needed to go in the lgm talk,
I will be incredibly careful about recommending removing any of these.

But if like with the layers dialog, I see zero function 99% of the time,
then I want us to try this out in an early (2.odd.2) development  
version,
wait a month (learning period) and then evaluate if that was the right
choice.

> Some UI streamlining is definitely needed, but the solutions aren't
> necessarily as simple as you put them. Actually a lot of what you  
> say in
> your blog entry is well-known and there are bug reports for it  
> already:
>
> http://bugzilla.gnome.org/show_bug.cgi?id=85579
> http://bugzilla.gnome.org/show_bug.cgi?id=109929
> http://bugzilla.gnome.org/show_bug.cgi?id=121087
>
> These things are on our TODO for quite a while now. The problem is  
> that
> they are very difficult to implement.

Yes, the top-10 user request shows that on the user side there is a
demand for change. And that the developers are thinking of the same
things will only make it easier for us to go ahead and work together
in the same direction.

But because of the work my team of usability and interaction
professionals has put into this project since October the
status of the issues we are talking about has changed.

Now they are no longer 'anybody's guess', they are official.

And my team is there to work with the developers to find solutions
that can be realised, not pie in the sky. We are also there to
make sure that our dear developer resources are not wasted on
purely cosmetic UI makeover, and to make sure that the described
productivity stoppers do not get shelved as an enhancement, but
are treated as the GIMP-value reducers they are.

 --ps

 principal user interaction architect
 man + machine interface works

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



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