[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: [KDE Usability] Oxygen animations configuration
From:       Hugo Pereira Da Costa <hugo () oxygen-icons ! org>
Date:       2009-12-01 0:08:42
Message-ID: 4B145E8A.6030702 () oxygen-icons ! org
[Download RAW message or body]

... 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
[prev in list] [next in list] [prev in thread] [next in thread]