Om2009 testing release 4

[pike]

Hi

 >> In addition to this, in some situations one could add to 0.5s: 'user
 >> presses AUX again since there was no response when he first pressed
 >> it'

happens to me all the time :-)

>>> This is an issue happening in several places in paroli. The interface is
>>> very honest in the sense that it only shows what actually happened. Of
>>> course this means that changes are visible a bit later than in other
>>> interfaces. Should this paradigm be changed?
>>>     
>> After I read this about 2 days ago, I've been thinking about it and
>> the conclusion is that yes, I think it should be changed.

reading it very literally, I don't. I think paroli
should "honestly" show what is happening, not what is
supposed to happen; but that includes "receiving a ui
event" or "starting a process".

>> But as soon as Paroli & everything behind it are
>> stable enough that we can trust that clicking a button does what we
>> want it to do, I think the UI should make the change as soon as
>> possible and do the actual work ASAP after this. 

No machine will ever be that stable - not
if you spill a beer over it, drop it
from the stairs or accidentally zap half the
filesystem. Even then, I'd like to be able to trust
the ui to tell me whats really going on,
not what it thinks should be going on.

>> Concerning this, I'd like to see a 'busy' light/icon/something to
>> point out that work is being done, wait until it's finished before you
>> try anything else. The icon would be shown when the processor load is
>> 90% or more. 

Good idea; sounds like macs 'colored ball cursor'.
But it doesn't replace the "watch cursor" - saying
"we received your request, now please wait".

Paroli doesnt have a cursor, but it could have
an applet that applications can call, I guess ?
Something like a watch ? start-watch; do stuff;
stop-watch. The 'watch' (I imagine a rotating
circle aka adobe flash loader) could turn into
a "busyball" when the cpu reaches 90%, too.
And it could also indicate a failure.

I also like the idea of a buzz when an error
occures. The buzz feels very erroneous.

These things would only apply to paroli, though.
I think lower levels could give some more
feedback, too. Eg, the aux and power buttons
send a dbus signal every second they are pressed,
but that's counterintuitive to me - if it
would flash or buzz every second too, i might
be inclined to wait - and count. And even
lower, when  booting the phone, and during
the boot process, there's not enough feedback
for me. I never feel I can "trust" the thing.
But maybe that's me :-)


$2c,
*-pike