[maemo-developers] [maemo-developers] Optimized software

[From: Aleksandr Koltsoff]

On Thursday 16 June 2005 09:42, Jose Manrique Lopez de la Fuente wrote:
> I've read a review about Nokia 770[1] saying that the device is
> something slow. Sure you have all in mind that optimized software is
> important, and I hope that release unit won't have speed issues.

I'd rather have software without difficult to debug bugs at this time thank 
you :-). Speed will come later when capable people with platform (inc GTK) 
knowledge will benchmark properly and identify the issues.

I'll present some counter-points based on my experience (nothing personal 
though):

> Some reactions to this review[2] comment about latency experience
> solutions: * Wherever possible, use multi-threading to push latency into
> the background. 

Whenever possible avoid using threads unless you know how they're implemented 
in your architecture. When you know that, you will know how to use them a) 
efficiently b) safely and know how to debug programs. Until then, don't use 
threads or ask someone else to do the threading logic for you. Threads are no 
panacea for usability problems (not even latency). GTK+ and GLib provide a 
lot of means to implement "multi-tasking" without threads.

> * Latency can often be hidden from users through 
> multi-tasking
> techniques, letting them continue with their work while transmission
> and computation take place in the background.

Yes. If your CPU has idle time. If your CPU is busy 100% of the time, this 
won't help but make it worse.

> * Reduce the user's experience of latency.

By making the device even slower? what does this mean ;-). 

> * Acknowledge all button clicks by visual or aural feedback within 50
> milliseconds.

This is good, and I noticed that in maemo the task navigator reacts to 
"button-release" instead of button-press. I don't know how much this adds to 
the latency in this particular case (I didn't mind it at least), but it does.
But don't implement the _aural_ part. 

> * Display an hourglass for any action that will take from 1/2 to 2 seconds.

Or implement some other consistant way to notify the user about operations 
that take time. It is important that this way is consistant across the 
platform, not only your program. Does maemo have anything for this?

> * Animate the hourglass so they know the system hasn't died.

I'd rather go for blinkenlichts but seeing that 770 has them missing, animated 
is ok as long as the animation itself doesn't grab too much of CPU-time. (a 
simple - / | \ - animation would be enough for me personally but knowing that 
pango is involved in displaying text, an animated clock would be probably 
faster ;-). Playing some sound with "Aieeeee" is enough to notify the user 
that the system has died ;--) (just joking).

> * Display a message indicating the potential length of the wait for
> any action that will take longer than 2 seconds.

A 5 second limit for this target device would be much more appropriate since 
ppl tend not to notice and read within seconds.

> * Communicate the actual length through an animated progress indicator.

This is not always possible and sometimes counter-productive. Inproperly 
implemented progressbars are evil (especially ones that say that estimated 
time is 2 hours, then after a minute it's 1.5 hours, then again 3 hours). You 
know what I mean. And yes, implementing proper progressbars is hard. That's 
why one should think about what you want the user to see. Relative progress 
with respect time (this is what most people think it is when they see one), 
or phased progress with respect operations in programs (this is what 
programmers use when implementing progress bars). If you're implementing the 
latter, then do now use "Time" or "Percentage".

> * Offer engaging text messages to users informed and entertained while
> they are waiting for long processes, such as server saves, to be
> completed.

Or assume that the user is intelligent enough to be able to switch to another 
application meanwhile (xbill ;-).

> * Make the client system beep and give a large visual indication upon
> return from lengthy (>10 seconds) processes, so that users know when
> to return to using the system.

Do not make the client system beep. Never, ever. Overloading the users sensory 
system is bad enough as it is with modern "IT"-systems. Concentrate on clear 
and intuitive UI (intuitive for existing user base _and_ new users, again, 
this is actually quite difficult). You can ask some psychologist to tell you 
later whether to add sonic indication and where to add it.

> * Trap multiple clicks of the same button or object. Because the
> Internet is slow, people tend to press the same button repeatedly,
> causing things to be even slower.

Better yet, disable the button after you start processing or write your 
software so that it doesn't break in this case. This is a simple example 
where using threads without knowledge will lead to program crashes btw.

Just my 2 kopeikas worth.

ak.