Personal Control Panel
- 1 Scope and Goals
- 2 Issues and Questions
- 3 User Study on Feedback Mechanism
- 4 Status at end of Year 3 and notes on integration
- 5 Related Pages
- 6 Wiki Categories
Scope and Goals
The personal control panel or PCP (possibly a custom floating control panel) will be a control panel that is adapted to the user's needs and preferences. For example, for a blind user, the control panel would always present their screen reader's speech rate and volume, but for a deaf person, it would show settings such as font size (and not speech rate and volume, since these settings would be useless). For someone with memory problems, the control panel would need to be always available (so it is not necessary to know where to go to open it).
The control panel should be available as a small widget that is easy to reach and that can be activated to expand it. The action to expand it to a floating panel may depend on the user, e.g. a simple gesture. It should be very handy, like a volume control. It should also be a way to get to other controls that people don't remember how to get to. An instance of the PCP would launch as soon as the user logs in (and remain available as a widget), while the PMT would be launched only on demand.
The control panel should also allow the user to respond to settings suggested by the matchmaker, e.g. move back to the previous setting, or providing a rating for a suggested new setting. When creating UI for user feedback on matchmaker suggestions, it is important to avoid the "Clippy problem", i.e. bothering the user with too many suggestions; this kind of functionality should be opt-in but not the default.
While the Preferences Management Tool (PMT) is meant to set up and edit preference sets, the PCP is meant for immediate and on-the-fly changes. The PCP should be available not only on PCs but also on mobile devices and ATMs, while the PMT is for more complex tasks. This is because the user's location and the device have a big impact on what tasks a user can be expected to complete.
Scope Defined in June 2013
Defined at Cloud4all Technical F2F June 2013.
- Showing/updating essential preferences.
- Select 2-3 default setups (possibly based on preference sets from first evaluation phase; see D402.2.1) – common terms: see the common terms in yellow from the first phase.
- Design based on mockups by IDRC (see Fluid wiki).
- Work with matchmaker teams in parallel to get dynamic setups.
- PCP will have a shortcut to the PMT.
Version 2: early ideas:
- Add more preferences (based on terms for second evaluation phase).
- Add rating mechanism.
- Ordering of preferences, i.e. how to organise or present them (alphabetically? hierarchically?).
- Keyboard shortcuts (especially important for blind users).
- Taking new designs/ideas/feedback into consideration.
Issues and Questions
Adapting the set of settings
A user's profile does not state whether the user is deaf, blind, etcetera. So what data would be used to determine that one user's control panel does not need to display font information (e.g. for a blind user without residual vision) or volume (e.g. for a completely deaf user)?
This can be solved by having preferences that say, for example: "I have no preferred font size" (for a blind user), or: "I have no preferred volume" (for a fully deaf user).
Sidenote: a blind person's font size may be set to 1pt to make sure all web page content fits on the same page.
Selection by User
Alternatively, the PCP can be defined as a panel that contains only controls that the user has chosen, i.e. only controls that he or she wants to have quick access to. This is the approach favoured in the discussion on 12 February 2013.
- The Chromium Embedded Framework (CEF) was considered as an option for implementation.
- Fluid UI Options (old version of the docs!) and UI Enhancer will be used.
- (Update 2015) Atom Electron was considered an option for the Discovery Tool.
User Study on Feedback Mechanism
Cloud4all is following a user centred design approach. A user study with the goal to receive early user feedback for the functions of the PCP is planned by TUD. The study does not focus on the design of the PCP. First thoughts about the interaction of users with results from the matchmakers have been elaborated by the matchmaker teams in the 1st year. More background information about these scenarios can be found below (see background information). Shortly summarized, the PCP should support the following feedback functions within the PCP:
- Modifying of determined preferences for a current device (context)
- Rating of new determined preferences for a current device (context)
- Information of new recommendations for a current device (context)
- Control mechanism for user feedback allowing the user to adjust the feedback mechanism.
The study focuses on these 4 functions that should be represented within the PCP. The goal is to receive early user feedback on these functions, especial to avoid the “clippy problem”. Results from the user study will help to implement the ideas of feedback mechanism within the PCP.
The technical concept of matchmaking (see D204.1 page 44ff) describes 2 overall scenarios: (a) inferring a preference for a target context, and (b) responding to user actions by recommending new preferences.
The first scenario describes the default case. All individual user settings for the current device (target context) are determined from the N&P set of the user. The result is precise, if the user has already used the device before (his/her old phone). Existing preferences can be gathered and activated for this case 1. New preferences are determined, if the user uses the device for the first time (user`s new phone). The results are new (inferred) preferences for this case 2 that are determined based on the preferences of the user that are already known. These new preferences have to be confirmed by the user before storing them in his/her preference set.
The 1st scenario aims to make sure that a user is able to use the current system based on his N&P. The 2nd scenario describes the recommendation of new preferences as response to user actions. Suggesting many new preferences and recommendations might stress or frustrate the user while he is performing his tasks. For this reasons, recommendations should be deployed carefully. In the current approach new recommendation will be only suggested as response to a user action for example if a user changes a setting manually (case 3). To control the way feedback is presented to the user specific preferences are need (case 4). A user might wish to automatically apply recommendations without asking. Other users might want no recommendations anymore. The following figure illustrates this 1st scenario on feedback and the function for the PCP:
Status at end of Year 3 and notes on integration
Here's a short video which will help you get a basic feel on what PCP is and can do: PCP demo
Briefly said, the PCP:
- shows settings that can be applied immediately to the local machine;
- represents a socket.io client and keeps constant bi-directional connection with the Flow Manager;
- renders settings according to payload received - expects term names + values for them;
- sends model on each user change for the Flow Manager to send to the Lifecycle Manager to invoke corresponding settings handlers;
- can receive and show 2 types of messages and is also able to produce messages on its own.
How to integrate with latest work
The branch containing the latest PCP work is gpii-941. This branch should be integrated with the latest work for the Universal repository.
Notes on integration:
- PCP can render any subset (empty as well) of the non mobile related common terms here AND the bold settings in the application terms list. To be maximally specific, here is where the transformation from a term name to a schema entry is made. If anyone wants to add another adjuster, they can check the GPII-1010 commits. This is obviously quite repetitive, so it won't be too difficult to implement automatic creation basing on most basic data only.
- PCP expects payload in this format. Note that PCP supports either common terms, or application terms. PCP does NOT support common terms for application. That would require extra work for adding another layer over an adjuster, specifying whether it belongs to an application (and which one) or not.
- You can see an example payload here.
- Notice lines 39 up to 49 - PCP can receive an array of messages to show at random times. It will take care of adding them into a queue, so that the human factor (delay when the user closes the message dialog) wouldn't be important.
- The PCP sends its model in the same format to the Flow Manager.
- Profile Management, especially the section about UI.
- Source code:
- Communication between PCP and the matchmakers:
- Status of the PCP on 6 June 2013 (mail to GPII architecture mailing list).
- Personal Control Panel API.