Editing Maemo User Interface Issues (Presentation)
Warning: You are not logged in.
Your IP address will be recorded in this page's edit history.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
| Latest revision |
Your text |
| Line 33: |
Line 33: |
| | | | |
| | * [[Media:Samoff-Maemo_Summit_Presentation.pdf|View the presentation]]. | | * [[Media:Samoff-Maemo_Summit_Presentation.pdf|View the presentation]]. |
| - |
| |
| - | ==Commentary==
| |
| - |
| |
| - | ===From Eric Warnke / brontide===
| |
| - |
| |
| - | I don't know if I will be able to attend this session, but wanted to give my feedback on the current state of the Maemo UI standard by Tim. I agree that we need to improve the quality of the baseline Maemo application that is out there, but I think we are shooting too short with many of the examples given. Modal dialogs are something that all applications should attempt to minimize at all costs. I'm not saying that dangerous actions should be taken without some sort of mitigation, but the UI should be optimized for speed and obviousness.
| |
| - |
| |
| - | In the example of closing the facebook app there are a few other possibilities that might be better in a mobile applications and still fulfill the rule of last surprise for the user.
| |
| - |
| |
| - | # Ok: Confirmation prompt to close the app. This fulfills the rule of least surprise, but forces the user to confirm a rather trivial action.
| |
| - | # Better: Confirmation prompt if the user has a facebook request pending, or un-sent status text. This allows the application to close is there is no danger in loss
| |
| - | # Good: Close never prompts, but unsaved text is automatically saved and restored on next launch. Transactions with facebook run until completion even if the UI is closed.
| |
| - | # Best: Good + uses osso tools to save the state automatically so that hildon can close this application when it's in the background and the system needs memory; hildon will relaunch it when needed. The user need never know the application was closed.
| |
| - |
| |
| - | So I say that we need the UI to get out of the users way. Applications should be quick to launch and quick to close, state should be updated at regular and sane intervals so that accidental, deliberate, or powerloss does not result in loss of data to the user. Dialog boxes demand attention and should be used sparingly as it prevents other things from occurring. I would personally rather see an action as undoable rather than prompting to confirm.
| |
| - |
| |
| - | My other pet peeve is not taking advantage of the, poorly documented, hildon-input-mode in order to hint to the system what kind of data to expect. This allows, for example, turning off auto-capitalize, turning on the numbers only, activating "phone number" mode so that the OSK has keys grayed out. I will post a python example soon so that other developers need not suffer as I did to figure this out.
| |
| | | | |
| | ==Q&A== | | ==Q&A== |
Learn more about Contributing to the wiki.
