From kde-usability  Tue Dec 01 00:08:42 2009
From: Hugo Pereira Da Costa <hugo () oxygen-icons ! org>
Date: Tue, 01 Dec 2009 00:08:42 +0000
To: kde-usability
Subject: Re: [KDE Usability] Oxygen animations configuration
Message-Id: <4B145E8A.6030702 () oxygen-icons ! org>
X-MARC-Message: https://marc.info/?l=kde-usability&m=125962618700304

... but ... strings are frozen right now ... How do we do that ? Wait 
for kde4.5, or ask for an exception ? To whom ? I can easily code a mix 
of both your and Markus suggestions withing a couple of hours, keeping 
all the underlying options as "hidden" anyway.

(btw Markus: you actually can set different time durations for all 
animations, by editting the rc file manually. Advanced-advanced-advanced 
stuff ...)
> On Mon, Nov 30, 2009 at 3:19 PM, Hugo Pereira Da Costa
> <hugo@oxygen-icons.org>  wrote:
>    
>> Hi Leo,
>>
>> Unfortunately I agree with all your points.
>>
>> Now: the first option is the one and only you ask for. (it is "turn all
>> on" or "all off").
>>
>> The other seven options ... I added them while adding new animations.
>> There is "some sort" of reasoning between them: tab transition for
>> instance, is the only one that can possibly trigger repaints of large
>> portions of the screen. All others are very local.
>>
>> I won't try to motivate each of the options. I left it this way because
>> of lack of time and poor usability skills (lack of time being: coding
>> furiously, changing things often, and always postponing the moment where
>> I should ask usability guys for help. My bad.).
>>      
> Hi Hugo.  Thanks for the reply, and I apologize again for the harsh
> tone of my initial post.   Overall the work you did on animations is
> awesome, I just saw this and felt I needed to raise the issue.
>
>    
>> I think On/Off is too drastic (due to the limitation above):
>>      
> Ok.  Given the realities of timelines and other pressures, I can see
> that in the short term it might be necessary to keep some options.
>
> For the tab transition, the problem is people with slow graphics
> cards, or people with bad graphics drivers (that's me!).
> I would argue that if a significant number of people will have issues
> with this animation, then it should not be included in the default
> theme.   If people see that switching tabs by default on KDE is really
> slow, they will walk away with a very negative impression of the
> project.  Graphics driver performance is a sore point for many people,
> and I think the default theme needs to be conservative in terms of its
> requirements until this situation improves.
> So as a quick fix, Tab animations could remain an option, with the
> future goal of removing it once there is feedback as to its
> performance or utility.
>
> Then label transitions.  There is a problem of a some obscure
> application updating a label often and having the animation go beserk.
>   I think that is the app's responsibility to fix, but in the short
> term the option to disable this particular animation would give some
> apps a workaround until they have a chance to fix their program.
>
> All the other options I really don't see a need for.  They are
> harmless in terms of processor resources, even for poor graphics
> cards.
>
> I don't see why they couldn't be removed for 4.4.  Should lessen the
> load on translators, and otherwise not affect much.
>
> Disclaimer: I am not a usability expert.  Just took a few grad classes
> on the subject and do some GUI design at work.  I'm just applying
> guidelines and best practices as I understand them from the design
> field.
>
> Leo
> _______________________________________________
> kde-usability mailing list
> kde-usability@kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
>    

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability