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

List:       kde-usability
Subject:    Re: K-ARTIST:Mime icons usability & visibility ;-)
From:       Simon Edwards <simon () simonzone ! com>
Date:       2002-04-22 18:29:25
[Download RAW message or body]


Hi,

On Friday 19 April 2002 22:13, Eric E wrote:
> On Friday 19 April 2002 12:45 pm, Simon Edwards wrote:
> > o make the computer smart enough to detect how long it is taking to do
> > things, and then having turn the eye candy down if it's taking too long.

> I think this is a very good medium-term goal for KDE.  This autodetection
> might apply to background tasks as well as eye candy - any "less important"
> processes that may be slowing down your computer. 

maybe. Disclaimer: I was speaking purely in terms of the GUI, GUI 
reponsiveness and perceived speed.

> Maybe we don't kill em,
> we just nice em.  This seems like a good app to write, test now and then,
> and add pieces to over a long period of time.

Now that you mention it, a simple, but possibly effective way of doing this 
would be for the currently focused app to automatically get higher scheduling 
priority. Basically, the window manager should just automatically un-nice 
(what ever) the process that owns the currently focused window. This isn't 
exactly a new idea. I believe NT is _meant_ to do this (although I have 
trouble believing it does a good job), and back in the Amiga days there was a 
replacement scheduler (Executive was the name) that did this, and it made 
HUGE difference. A background build didn't even affect the GUI performance.

> The adaptiveness you're talking seem more general to me how many apps can
> you run at once, extra tray apps, etc., in addition to eye candy.

See the disclaimer above first. :-)

> 1) The KPersonalizer level.  With a simple metric for how fast your
> computer is, KPersonalizer can tell you that it might not be a good idea to
> enable image previews.  If we wrote the "settings analyzer" so that it
> could be invoked at any time, any relevant control panel could ask for an
> analysis of the computer's speed whenever you propose to turn on some eye
> candy.  I say this with some trepidation, because I think such metrics
> could be pretty hard to write, but in this arrangement, you can ignore or
> turn off the analysis when you like.

What I was thinking of was something more like this. Let's take the new 
SuperEyeCandyMenuSystem 2005 edition for example. Now, say you turn the eye 
candy level up way high. You use a menu, it takes 5 seconds to appear. Now, 
S.E.C.M.S.2005 knows that your performance setting is set to 'Snappy', and 
the 'Snappy' means max 0.2 sec response time for GUI elements. 5 seconds 
isn't good enough, so next time S.E.C.M.S.2005 tries rendering with a 
slightly less heavy setting (automatically), and this time 0.2 sec is 
achieved...

I whole idea here really is that the GUI monitors it's performance (the time 
from GUI event, to the GUI element changing state. for example, the between 
the menu button being pressed and the menu being displayed), and uses it as a 
guide for the future.

A real implementation would be a bit more complex than what I have presented 
here. But it is certainly not impossible or requiring 50 years of HCI 
research, or sentient AI or agent software.  

Some more notes:

* A real implementation would probably have to remember and interpolate from, 
a set of data. Say, the last 20 menu clicks.

* You would _not_ try to implement so kind of some super-code that tries to 
manage and pull together data from every different GUI element. (menu, 
button). That just wouldn't be managable if think.

* Different menu sizes take different times to render, for example. This would 
have to be taken into account.

* A deep knowledge of CPU, RAM, etc etc is not needed, because we are 
calculating Eye Candy Setting vs Speed at run time. It's an emperical method.

* Good algorithms for statistics and curve fitting already exist.

* The system would have to constantly monitor performance and adjust itself 
based on the recent past. (i.e. you can't just compute once, adjust the Candy 
setting, and forget about it). It's dynamic, and responds to what is 
currently happening.

* Yes, this is a researchy thing but I think it's doable.

* This email is getting way too long.

> 250000) The adaptive level.

That's not really what I had in mind.

> but you're asking a team of
> volunteers to solve the next 50 years of HCI problems.  Let's go a little
> slow here, man, even if we are just polishing railings instead of building
> new buildings.

True, but firstly don't underestimate volunteers. Most of us are IT 
professionals. Secondly, yes I realise that there are more important and 
immediate things in KDE that need fixing. Hopefully in the not too distant 
future I'll get some time to hack on this idea myself...

Ok, back to your" regularly scheduled program". :-)

-- 
Simon Edwards             | Guarddog Firewall
simon@simonzone.com       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]