February 2009 Archives

i ust went through the process of sending an SMS, looking for usability issues. Besides obvious issues (like speed) it's often the small things that make an app comfortable or awkward to use. I think with the previous issues solved, the SMS app would be a little nicer to use. I haven't filed all this thigns as trac issues, i guess quickdev is the one that should be commenting on the feasability of implementing them, as I have never looked at the code in question, nor am I familiar with efl.

SMS Content

• Existing trac issues: Allow empty text messages (with warhing?) and get char counting right.

Inbox

• Selecting a message highlights it yellow, but nothing else is possible. Clicking (or double-clicking) should "Show" it which let's us remove an unneccessary button and is more intuitive.
• "Options" button should indicate that it leads to more options ("Show..." or "Show^")
• Inbox (and many other places) should show contact name rather than number if its in the contacts (need for a function num2name that returns contact name or number?)
  

Define Recipients

• Put "Add contact" into the upper part of the "Add reipients" part for consistency with the dialer app.
• Even better, just invoke the dialer here, which makes for good usability reuse. (most of the time, we'll only need one contact; I'd guess). invoking dialer also allows us to punch in a number immediately without having to press an unneeded "Add number button".
• The "Remove" button is confusing with regard to what gets removed (especially if there is no contact yet). Why not remove it and only show it as a "X" button on the contact line when that contact is selected.
• Also here we should show contact names rather than numbers when replying to a number in my contact list.
• A "recently called" list would be nice (I often send messages to only a handful of people)
• "Continue" button should be called "Send" to make clear that this is the last step an we are actually going to send now.
  

Dialer

• Dialer should have a preferene whether we start it in "number punching" mode, it contact list selection mode or in (a yet to be created) "last calls/messages" mode.

I (spaetz) have been thinking about how to handle screen blanking in SHR. Currently there are 2 overlapping and conflicting mechanisms that blank the screen: The illume power gadget (code) and frameworkd which uses idle timeouts for screen dimming/blanking/suspend.

Illume does a good job, in that it also is able to suspend after blanking in a way that a tap with the stylus will wake up the Moko but not be registered as a click. On the downside, it doesn't know about specific situations, such as when in a phone call (at least that is what I think).

frameworkd knows about that and prevents dimming e.g. while in a call, the only issue with it is that is blanks the screen (it actually only turns the backlight off) but does nothing else. So when you tap on the screen to make it bright again, and you have managed to tap the "Delete" button (or any other widget that does something), then it will execute that action.

Currently both are turned on, which makes for a very confusing situation. Sometimes a tap will hit a button, sometimes not. If you disable screen blanking in SHR-settings, illume will stilll blank the screen, etc. How should this be resolved?

There are 3 issues to be resolved:

1. Currently frameworkd blanking in SHR is broken because of an obsolete rules.yaml files. This needs to be fixed first.
2. frameworkd blanking needs to prevent the first stylus tap to click anything on the screen. This also needs fixing independent of how the rest is handled.
3. illume power settings and frameworkd need to be made compatible. Generally, I like that there are power settings in the illume preferences, but ideally those settings would do the same thing as when setting timeouts in framworkd via shr-settings (or the config file), and ideally they would honor each other (ie modifying frameworkd.conf should show up in the illume power config). Alternatively one could do away with either illume power settings completely or disable the frameworkd timeouts

Usually, when the screen goes blank (isn't there some more energy efficient way of turning the screen off, rather than just disable the backlight by the way?), we should be able to suspend at the same time to save power. Of course there needs to be an easy way to prevent suspend in certain situations (#172, #300), e.g. while logging a GPS track or while in an SSH session via WLAN etc. But I think we  can save some power by applying somewhat more aggressive defaults here.

UPDATE: After talking to raster on IRC I have been convinced that frameworkd works in a hacky manner. Screen blanking needs to go through proper X rather than just turning of the backlight behind X's back. Still, what frameworkd knows is when not to go blank. So the correct solution is to issue xommands (like "xset s activate") to make the screensaver do the right thing (or prevent it from doing so).