Launchpad Entry: coming soon...
Packages affected: network-manager, network-manager-applet
In order to provide an easy to use, always connected mobile consumer device experience, improvements need to be made to both the user interface, and the core behavior(s) of Network Manager and it's associated applications.
As there has not yet been an official release of Ubuntu Mobile, end-user impact is not applicable.
That said, if any of the improvements described in this specification were to be included as part of Desktop, end-user impact is expected to be minimal; at a minimum, requiring the end-user to learn the simplified user interface and it's beavior(s).
Network Manager ( from here on, Network Manager refers to both the network-manager daemon process, and the UI provided by the network-manager-applet, and gome-system-tools packages ) currently provides a user interface which both too "techie", and in some measures incomplete with respect to the mobile devices. For instance, how many people understand the difference between WEP 64/128-bit Hex and WEP 64/128-bit ASCII? Why should a user be forced to pick the type of security for passphrase/key? To further exemplify, the default Type on the passphrase dialog for a WEP access point is: WEP 128-bit passphrase, which if selected instead of WEP 64/128-bit ASCII won't associate with the desired AP. Examples of missing functions include:
- no UI for enabling/disabling network radios ( eg. Bluetooth, Wi-Fi )
- no UI for enabling/disabling power management
1. Ozzy tries to connect his new mobile device to his nephew's home access point, who scribbled a WEP key value on a piece of paper before leaving for vacation. Ozzy doesn't know the difference between a passphrase, an ASCII key or Hex key. He selects the access point, and is prompted for a Passphrase / Key; the dialog figures out the type and does validity checking without making Ozzy select the type.
2. Sheila boards an airplane with her new mobile device, to turn off all radios on her device, she clicks the Airplane Mode icon on the Network Settings page; all radios ( eg. Bluetooth, Wi-Fi, 3G ) are turned off and the icon changes to show that Airplane Mode is active. Upon landing, Sheila clicks the Airplane Mode icon, each radio is enabled, and if possible, the device re-connects to the Internet without manual intervention.
3. Peter attempts to connect to an AP with his mobile device. He types a key which although valid ( ie. it's the correct length ), is wrong. When his mobile devices fails to get an IP address, the passphrase dialog is automatically redisplayed with an error message asking him to check his key.
4. Jason buys a new access point and connects to it with his mobile device. A co-worker tells him he'd better enable security on the access point. He does so, and now when he tries to connect to the AP, it fails to associate, and then re-prompts him for a new passphrase and/or key.
Note - ideally there'd be some way to change or clear the current key associated with an access point so that you don't have to try and fail before entering a new key.
5. Maria decides to change here access point so that it doesn't broadcast it's ESSID. She does so, and uses "Join Other Network", this connects her mobile device to the Internet. Maria puts her device to sleep, when it resumes from sleep at some later time, she should not have to use "Join Other Network" in order to re-connect to her access point.
Note - this could be a bug in NetworkManager, user error, or it's the way it's supposed to behave. If it's the latter, it should be changed...
6. Phil is a providing support for mobile devices using Unbuntu Mobile; while reviewing the daemon.log file from a device, he no longer needs to wade through HAL events which aren't relevant to networking.
7. Alice uses a mobile device running an OEM-customized version of Ubuntu Mobile. In order to connect to a 3G network, she selects 3G from the nm-applet's menu. If she hasn't yet entered the credentials for the 3G provider, she's prompted to do so.
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
Should cover changes required to the UI, or specific UI that is required to implement this
Code changes should include an overview of what needs to change, and in some cases even the specific details.
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.
This need not be added or completed until the specification is nearing beta.
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.