(Created page with 'The intent of this list is to provide a set of use cases that we can use to sanity test our design and implementation approach, to help ensure we are accounting for as many techn…') |
m |
||
| (3 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
| - | The intent of this list is to provide a set of use cases that we can use to sanity test our design and implementation approach, to help ensure we are accounting for as many technical areas as possible, as early as possible. | + | The intent of this list is to provide a set of use cases that we can use to sanity test our design and implementation approach, to help ensure we are accounting for as many technical areas as possible, as early as possible. The intent of the use cases are not to define the requirements for telephony in MeeGo, but to capture what users will want to do with the platform. |
= General = | = General = | ||
| Line 45: | Line 45: | ||
=== I want to place a call in an FDN SIM locked phone === | === I want to place a call in an FDN SIM locked phone === | ||
FDN is not required for the first version. The exception to this is if a SIM card is used that has FDN enabled, the SIM card will be rejected -- except for allowing emergency mode. This means that the system must be able to detect an FDN restricted SIM and to then limit the UX accordingly. | FDN is not required for the first version. The exception to this is if a SIM card is used that has FDN enabled, the SIM card will be rejected -- except for allowing emergency mode. This means that the system must be able to detect an FDN restricted SIM and to then limit the UX accordingly. | ||
| - | |||
=== I want to call back the phone number using the bluetooth headset === | === I want to call back the phone number using the bluetooth headset === | ||
| + | |||
=== Questions === | === Questions === | ||
| - | + | ==== Can the user configure FDNs? ==== | |
| - | == Can the user configure FDNs? == | + | ==== Can the user view approved FDNs? ==== |
| - | == Can the user view approved FDNs? == | + | |
= Receiving a call = | = Receiving a call = | ||
| Line 76: | Line 75: | ||
=== Switch to/from BT headset === | === Switch to/from BT headset === | ||
=== Switch to/from speaker phone === | === Switch to/from speaker phone === | ||
| - | === Use DTMF during a call === | + | === Use DTMF during a call === |
| + | |||
| + | User dials service provider. The automated system says to "Press 1 for English." User presses 1 and it makes the DTMF code for 1, allowing the user to have a successful customer service experience. | ||
| + | |||
=== Mute on/off === | === Mute on/off === | ||
The intent of this list is to provide a set of use cases that we can use to sanity test our design and implementation approach, to help ensure we are accounting for as many technical areas as possible, as early as possible. The intent of the use cases are not to define the requirements for telephony in MeeGo, but to capture what users will want to do with the platform.
User presses 'Phone' icon in the application quick launch bar, which launches the dialer. The dialer opens to the last view the user was in when they used the dialer previously. If this is not the Call History (Recent) view, the the user presses the Recent tab.
Tap on the more details part of the people card in the Call History (Recent) view in dialer brings up the contact details.
Unknown persons (not already in the contact list) will show up as Unknown caller in the call history view, showing the phone number. Tapping the more details button on that contact card entry will take you to a new Contact card (as if you had gone to an existing Contact card and pressed 'Edit'), populated with just the phone number. The user can then enter as much information they want, and press Save.
Question: Should the more details button be replaced with New contact or similar text for entries not in the Contact list, or should it continue saying more details? If the later, should it really go straight to the edit view, or should the interaction pattern be the same for normal contacts:
call history view => *tap more details on contact* => more details view for contact => *click edit* => edit view for contact
Per Dialer.pdf 2010-06-24 pp. 2: The first time the dialer application is launched, the dialer tab will be open. When returning to the dialer, the last state/tab visited will be remembered. This is a fixed setting, not configurable by the user.
An application can use:
QDesktopServices::openUrl("callto:+9163562663");
Internally, QDesktopServices forks xdg-open, passing it the Url. xdg-open then uses the gconf key matching the protocol name under /desktop/gnome/url-handlers. The value for 'command' is then launched, substituting the full Url for %s.
The specific user interaction when the dialer is invoked in this method is TBD; two options are to prompt the user first (Do you want to call ######? Yes / No) only launching the full dialer and placing the call if Yes is pressed, or to launch the full dialer immediately and pre-populate the dialout number, but require the user to manually press Send.
FDN is not required for the first version. The exception to this is if a SIM card is used that has FDN enabled, the SIM card will be rejected -- except for allowing emergency mode. This means that the system must be able to detect an FDN restricted SIM and to then limit the UX accordingly.
User dials service provider. The automated system says to "Press 1 for English." User presses 1 and it makes the DTMF code for 1, allowing the user to have a successful customer service experience.