About Habitat
-------------
A complete, realistic interaction environment for children, older users, and users with basic computing needs. Components should
 resemble their real-world equivalents where possible.

There are 3 important components for the complete concept:
 * Habitat environment
 * Ascend office applications
 * KidsPlay activities suite

Each customisable environment is a "habitat", users are "inhabitants". Customisation is an important element of the environment: we should enable as much modification of the appearance as possible. Customisation options include:
 * Contents of rooms (administrators/parents determine the exact contents of a room, so that unneccessary clutter is not present, and usage and learning is tailored to the needs of the user).
 * Colours (of doors and other painted surfaces)
 * Wallpaper and carpets (we should provide many preset patterns)
 * The name and type of their pet (if enabled)
 * If more than one room (different rooms for different users), the user can customise the outside of the door with name plates and stickers

Several different types of habitats are available for different types of uses. Whilst children may feel more comfortable in a family room, older users will want a habitat resembling a study or office room - this more advanced environment would have a larger desk, to host the larger amount of office-oriented features. As the user grows, their habitats evolve.

Evolution of habitats is effected through two means: active manipulation by users (to add more appropriate features as users develop), and through achievements earned through activities in KidsPlay - for example, on reaching a certain level, the user may be provided with a new toy for their pet.

The current weather and time is graphically displayed by changing conditions outside the window - snow, rain and sunshine animations, with the sky darkening as the day progresses. A more precise display of the time can be provided by an optional wall clock (available in digital and analogue variants, and many visual styles). Plasma data sources are used for these displays.

Both the window and the clock can be selected, so that the view zooms and centres on these elements. The clock view could possibly be linked to "learn to tell the time" activities in KidsPlay.

Objects are visual metaphors for tasks (applications). Current thinking is that we include lots of possible objects, then we allow more through GetHotNewStuff, finally, you will be able to reassign what application is run by any given object.

Examples of objects:
 * Photoframe (either hanging on the wall or stored on the desk)
  - A sequence of photos can be specified, and the frame will change its display periodically.
  - When clicked, the view zooms and centers on the photoframe, where the photo collection of the user can be browsed and dislpayed.
 * A stack of physical folders on the desk can permit access to the filesystem.
  - Selecting the folders presents a zoom and centred view: if a device is currently connected and on the desk, these devices appear at the side of the view, to allow transfer between the device and the filesystem.
 * When a device is plugged in (camera, music player), it appears on the desk. Selecting it provides interaction functionality, such as downloading photos, and adding new music to the device.
 * A hi-fi device provides access to music.
 * A television provides video viewing.
 * An art board, for drawing and painting.
 * Play bricks (or another suitable visual metaphor) can be used to access KidsPlay activities.
 * A computer for internet access and communications.
 * A calendar on the wall.
 * A mail tray for email.
 * A rolodex for contacts.
 * Globe for Marble.
 * Toolbox for settings.
 * Pets/Plants that grow (user can select whether it can die, needs feeding, interaction, etc).

Administrators can explicitly control the experience of the user. Apart from specifying the components of a room, they hae finer control over functions, for example, whether the user can logout or turn off the computer. Logging out is done by clicking on the room door, turning off the computer by clicking on the light switch.

The state of all elements of the environment is saved between sessions. This provides a physical sense and security to the inhabitants.


GetHotNewStuff integration
------------------
* To make habitat more flexible, new objects could be installed over the network. Downloadable objects consist of an SVG visual representation of the object and configuration (such as the application which should be run onclick)
* The download process could check if a dependent application was installed, and only appear in the room if the app was installed
* If the download fails because the dependent application is not installed, a log can be kept for an administrator, prompting them to install the application
* New pets, plants, screensavers and translations can also be provided over GHNS. Pets, plants and screensavers can be manipulated with kross-compatible scripting


Central configuration of rooms (vs. in-room configuration)
------------------
* Allows an administrator to define:
  - which objects can be added to rooms
  - what the user can do (log out, turn off computer)
  - keep deleted files (for a week | for two weeks | etc. | forever)
  - parental controls (should only apply to "play rooms"):
    + amount of time games can be played
    + whether internet browsing and chat is restricted to a white list
    + whether pets can die
  - usernames and passwords (if they are needed, and changing them)


System Requirements
-------------------
* Will run on kdelibs >= 4 and qt >= 4.3
* Will not require an existing active desktop environment to run (i.e., KDE) as it will perform as a lone desktop, although a seperate standalone application will be available in order to ensure easy switching between habitat and the "real" desktop.
* Will not be overly hardware-intensive: schools often do not spend much on equipment, and parents will not buy a high-end PC for their children
* An internet connection will be required for use of GHNS, web browsing, etc.
* Applications from KDE-Edu will be heavily used, especially in the playroom. Therefore, KDE-Edu is a mandatory dependency of Habitat.
  - this gives us the option of removing the object that starts the application in question from the room, or leaving it in and spewing an error when clicked.
* Ideally, the application will run fine under 800x600, 16-bit colour. This continues the ideology of low-end hardware and budgets.


Non-System Requirements
-----------------------
We must have three libraries which operate independently of each other:
  - libhabitat. this is the main library for the operation of habitat
  - libascend. this is the library for the ascend office suite
  - libkidsplay. this is the library for the kidsplay edu suite


Non-System Non-Requirements (read: Stuff That Would Be Pretty Cool To Have(tm))
---------------------------
* No IM client will be required to be installed in order to utilise chat facilities:- our own system will be designed for this
  - the reasoning for this is that most IM clients are too complex for simplistic usage, and embedding an existing client would actually be more overkill than developing our own. Remember, we need minimal impact on system resources.


Platform
--------
Habitat will be designed with the intention of becoming a standalone desktop environment based on KDE. However, a seperate implementation will be provided whereby habitat can run on an existing KDE desktop. This will require two completely seperate implementations of habitat as opposed to just using compile flags due to the sheer difference in the two implementations.


User Interface
--------------
The user interface should be customised using CSS. A GUI tool will be available inside habitat in order to select from preloaded designs or build a custom interface design (with an easily accessible option to revert all changes that cannot be customised in order to stop "help, I messed up" scenarios during experimentation). This allows the UI to "mature" along with the user - and the user's skills - making it a comfortable transition towards a full, standard desktop.


With restrictions on access to the internet inside habitat, the user could just minimize habitat and get on the internet anyway... so there could be password protection to close the application, as long as alt-tab, etc can be intercepted.

One of the most important elements of the interface is the "minimenu", which is omnipresent in the top-left corner of the screen whenever the user is in the habitat environment (ie. not running an application). The minimenu is used for configuration - configuration contexts change depending on the current context of the environment.
For example, the minimenu on the login screen lets you configure stuff like passwords, and add new rooms, etc, whilst inside the room, the mini menu is all about customisation, like adding objects and changing colours.

The icon in the minimenu is called "blinky" - when the minimenu requires attention (like when a new, empty room has been created, and the menu needs to be used to populate the room), an animation will be employed. On other special occasions, blinky will do a little jig or something similar.

Users will be able to create their own "inhabitant" (inhabitants visually represent a user), using a simplified interface similar to that of the Mii creation utility on the Nintendo Wii. This inhabitant will be used as their picture in the frames alongside the doors in the login manager. Inhabitants can also customise their door (colour, stickers). The favourite colour of the inhabitant should be used wherever necessary. On the day of an inhabitants birthday, the room can be filled with balloons and other decorations.

When changing room visual settings (colours, wallpaper, etc), we use live previews which temporarily change the item in the room to the setting (when the choice is hovered over). The same "live preview" concept is used when selecting a user to login in the hallway login manager - when the picture frame is hovered over, the customised door of the user is displayed in place of the default door, to improve visual identification of the selection.

A thick border is placed on all sides around a running application - any clicks on this border sends the user back to the main view, so they can select other applications. Alongside the border escape buttons, the "Esc" key can also be used to escape from a running application. I would like alt-tab to be a way of switching between objects inside habitat (probably only ones that have already been run, not all available), for more experienced users.

There's no reason habitat should be artificially made to be a "slow" alternative, even though some of the interaction concepts are geared towards "single-tasking".

We're trying to get away from the idea of the computer of a magical box which doesn't make sense to an underdeveloped or inexperienced environmental knowledge. I can easily imagine how windows which suddenly disappear and reappear could confuse children - this never happens in the physical world. So, we map activities onto defined locations in a room, and when you return to each location, everything is how you left it. So, we bring a physical and permanent dimension to computing.


Other Ideas
--------------
* Have a computer with an emulated KDE desktop to ease migration to standard desktop computing.
* Use function keys on the keyboard for quick switching to different applications.
* When a threshold number of objects is reached, unlock extra space in the room, adding pan buttons, and zoom out when adding/removing/moving objects.
* Visual passwords? (show a picture, and the user clicks on a sequence of points in the picture).