Contour will combine existing KDE technologies with new ideas and approaches to handle the context data that mobile devices provide. The image below gives a rough overview of the components that make up a Contour-enabled system:
Core Components To Be Developed
The Recommendation Manager is the heart of the Contour extension on top of Plasma Active. It maintains a list of recommended actions which are kept in sync with the current context of the user and the device.
To this end the recommendation manager constantly updates recommendations based on usage patterns, the current context, and recently taken actions.
Recommendations are passive propositions for actions or information that are there all the time. Recommendations change over time based on the changing context and detected patterns. Recommendations are not to be confused with system notifications for incoming calls, text messages, or events. They are non-intrusive and can either be accepted (activated) or ignored by the user. Ignoring a recommendation means to simply not react on it. Recommendations are specifically not yes-no questions.
Examples include Contact person X, Open file Y, Start playing music (this will take into account preferences of the user), Take note about the phone call just received, Open presentation for the meeting which you just entered, The next bus to X goes in 10 minutes (When in the office late at night).
The location manager monitors the geo location and manages known locations.
Here a distinction has to be made between the geo location expressed through longitude and latitude and a location like the office or the home town. While storing the former is very simple determining the latter is a bigger problem. This is where the location manager comes into play. It will make use of user feedback and statistical data to extrapolate locations.
At a later stage it can take information from online map services into account to determine the locations the device is currently at.
There are at least two ways to store the location:
- The current location can be stored in the metadata graph of each created triple. This would provide useful statistical data, allowing to evaluate where what has been done. This approach, however, only covers situations in which actual data is created in Nepomuk. In case the user just remains in one place for a long time but does not use their device no information is stored.
- The location can be stored independently from any other data and then be matched via the timestamp. This allows to store the location at any point but it also adds additional complexity as the system has to decide when it is of interest to store the location and when it is not.
In any case we need a QLandmarkManagerEngine that can store the created landmarks in Nepomuk.
The most important task of the location manager is to determine when the device changes a location or when a new interesting location pops up. Possible locations that could be determined via geonames and contact information include:
- Locations like offices or homes could be extrapolated by statistical analysis.
If, for example, the user stays within a certain area for a longer time, and if in that time they even have a meeting in their calendar then the area could be used as basis for the meeting place. The system could either learn and improve the area based on additional events or ask the user to confirm.
Locations are an important thing for better recommendations. However, users do not want to name each and every location they ever stay at. Thus, whenever the location manager detects a new location (typically since the device has not left a certain area for a longer time) this location is stored as an anonymous location. This means that it does not have a name yet. The user should get the possibility to set a name via a non-intrusive GUI element but does not have to. At a later point these anonymous locations may be looked up in a map service and automatically be linked to real locations like cities or shops or clubs.
The Sensors manager monitors the sensor information provided by the device. This includes device orientation, rotation, and so on. This information is accumulated and provided to the recommendation manager.
Technologies used in Contour:
Since one of the main goals of Contour is to integrate with Meego good Qt-Mobility support is essential. To that end a set of engines that store contact, organizer, or message data in Akonadi are implemented. This ensures that both Contour-enabled applications, KDE applications, and pure Meego applications use the same data, thus, providing the best user experience.
Akonadi, the PIM storage and communication solution for KDE, is used for all PIM purposes like EMail, calendar, RSS feeds, and so on.
Akonadi already integrates with Nepomuk and, thus, provides all the information that is necessary for including PIM data into the recommendations provided by Contour.
Plasma Mobile Shell
Plasma is the desktop and netbook workspace of the KDE project, as well as a library for the query and visualization of any kind of data, based on the Qt QGraphicsView framework (and more recently, on the QtQUICK module as well). The Plasma library permits to build any kind of deeply personalized user interface, with a unified SVG-based theming system and with a clear separation between the data itself and its visualization. It is also the natural complement of QtQUICK to develop user interfaces that can adapt themselves (even with radical changes) for different form factor devices. The Plasma Quick will be used as the primary user interface for the interaction with a Contour enabled device. It will visualize all the activities and suggestions of the system, and will be the UI framework for its main applications.