User Preferences UX Meeting 2013-02-05
ASTEA described the status of the Personal Control Panel; see the message from 3 February 2013 and the attached video. In the video, the PCP is launched when the user logs in, check a radio button for the on-screen keyboard and edits the font size. When the user logs out, the system is restored to its original state.
The current code uses Firefox to run the PCP. In order to create a widget to launch the PCP on demand, the code will at some point start using native application wrappers for web content. That should allow us to create a floating panel.
Launching an instance of the PCP is the behaviour we would also want in the end. This instance would be given a token to communicate with the Flow Manager throughout the session.
PMT and PCP UI
IDRC presented work on UI and interaction for both the PMT and the PCP.
IDRC has been doing three activities:
- logic & flow mindmap,
- PCP sketching & PMT sketching,
- trying to get some realistic but extreme use cases, with FhG.
It is important to reduce complexity for the users. The notion of a preference set may not be meaningful to them. Encumbering them with many decision is not going to work; people would opt out.
When the user registers for the first time, there are three choices for creating a base preference set:
- use the local settings,
- start from zero using the editor,
- a guided setup (what we used to call the wizard).
If a user chooses to use the local settings, they might confirm some kind of overview of these settings, but it is not clear yet how this should be presented. This overview may be very complex because the number of local settings can be large.
Before a base profile has been set up, the PCP has nothing to do or to display.
The communication between the PMT and the PCP through the architecture would use JSON.
Merging the PMT and the PCP, as suggested last summer, does not seem a good idea. The PMT would be point of entry; the PCP was meant to be the tool that is out there in the wild. For example, when you go to a kiosk, you would not want to tweak the preferences. Phones have limitations due to small screen – so PMT would be difficult. On a bank ATM, you would not invoke a tool like the PMT. Location and device have a big impact on what tasks a user can be expected to complete. PCP is more immediate & on the fly ...
We should not bother the users with different preference sets. The preference set presented to the user would be based on the current context. When making a change, the user might be asked to confirm this just for the current context/device or for all devices. However, there is also the notion of a "base preference set".
- Previous meetings: see User Preferences UX.