Amiko is a piece of software targeted to run on the One Laptop per Child. The concept of Amiko was inspired by the Tamagotchi toys, and its purpose is to allow kids to interact with the control of the computer in a simple and fun way.

About this specification

This specification is an early draft for the Amiko project. Nearly all elements are still up for debate and revision. Updates will be released frequently as necessary.

Project Overview

Amiko (named from the Esperanto word for “friend”) is the name of a character which can be called onto the screen by pressing the “Status” button on the keyboard. Various features of Amiko’s physical appearance will portray system status. Such elements as monitors of battery life, available memory, and wifi signal strength, and toggles for the microphone, speakers, and camera will be integrated into Amiko.

Design Goals

The first and foremost goal of this project is to make the user’s interaction with the computer fun. Kids should enjoy using Amiko to control and monitor system behavior. Implementation should be as efficient as possible to avoid taxing system resources.

Major Components

System Level: The internal code which monitors system properties is effectively hidden from the user. These monitors return values which are interpreted by the graphics interface, which responds appropriately.

User Level: The graphics interface with which the user interacts is kept simple to use and read. Most toggles should be operatable by both mouse and keyboard input.

Coding Conventions

The Amiko project is using the standard Python coding conventions, such as those outlined at

Internal Function Details

The following system behaviors will be monitored. This list is subject to revision.

  • Wifi signal strength
  • Mesh presence
  • Packet traffic
  • CPU usage
  • Battery life
  • Available flash
  • Microphone toggle
  • Camera operation
  • Speaker operation
  • Etc.

For initial testing, the code will get system information from proc and parse it to analyze the system. Elements of vitality and happiness will be generated from this information and used to encourage proper treatment of the system.

Suggestion: We want to ensure that making Amiko unhappy or die is not fun. It is probably better to have a simple behavior monitor without an insultable personality or vitality so that kids focus on the system properties rather than maltreatment of the character.

Data Mapping

For the monitored system properties, data will be collected into Queues which will be used to calculate the average value over a given amount of time, such as a few seconds. This is intended to minimize the effects of minor fluctuations on Amiko's appearance.

This applies mostly to the following properties:

  • Wifi signal strength
  • Mesh presence
  • Packet traffic
  • CPU usage
  • Battery life

The return values, calculated from the average value stored in the Queue, should be sent Amiko's graphic frequently so that, for example, there is a minimal delay between a laptop joining the mesh and appearing on Amiko's display. The return values should reflect appropriate treatment of the computer, not a linear scaling; for example, the battery should claim to be dead or full based on the optimal times to be recharged.

  • Available flash

The available flash is more stable than the properties above, but when changes are made they should be recorded promptly. For example, a user downloading a large file should be able to see the change in Amiko if the file size is significant enough to affect its appearance.

  • Microphone toggle

The on-off component of the microphone should be stored as a boolean or an int.

  • Camera operation

This element could be as simple as an on-off boolean or int switch, or be a toggle between still, video, and different resolutions. Probably a separate camera interface is more appropriate, which would open automatically when the camera is turned on.

  • Speaker operation

An int or a list holds values for the volume control. A separate boolean or int switch activates or mutes the speakers so that the volume setting is not lost when the speakers are muted.

Graphical Function Details

Amiko's graphical interface will be built using Cairo.

The graphical component should not have to worry about what system property it is reflecting. It will behave solely on the return value of the monitor that is mapped to a particular component.

Following is a list of available graphical behaviors and ideas. Keep in mind that we must carefully avoid any behavior which carries negative cultural connotations; this component might have to be customized for each regional distribution.

  • Eyes toggle camera
  • Ears toggle speakers (and slider buttons on keyboard, ears change size according to volume level)
  • Mouth toggles microphone
  • Transparency (or just brightness) indicates battery life
  • Width or height can signify some behavior such as available flash
  • Physical activity (such as walking/running) represents CPU usage
  • For mesh participation, the heads of other users on the mesh should be seen in the background
    • head size, brightness, and position of the heads indicate their relative distance from the user
  • Some form of visual transmission (ie waves) from Amiko's head into mesh background can represent packet traffic

Some special physical behavior should result from critical system status, such as a low battery, to encourage proper treatment of the computer.

Fun Elements

Amiko’s functionalities should be reprogrammable through custom skins for the character. For example, a child should be able to easily change Amiko’s look to approximate his or her own appearance through skin and clothing style and color. Additionally, these customized appearances should be sharable over the mesh so that kids can download other kids’ Amiko appearances. Each head in the mesh background can be clicked on to download that user's skin and/or behavior mapping or start a chat conversation. (In a later version perhaps a particular mesh participant’s appearance can be customized by the user)

Application Interaction with System

Pressing the keyboard "Status" button will call Amiko up from a corner into a transparent box approximately 200 x 200 pixels, perhaps larger. Smaller version(s), on the order of 50 and/or 10 pixels should float somewhere on the screen or in a systray at all times.

Color and black-and-white versions will be needed. Perhaps the toggle between these modes, as well as backlight intensity, should be integrated into Amiko as well.

There should be a more advanced version of Amiko as well with bars and graphs to explicitly describe the system status rather than just visually on the Amiko figure.

Suggestion: Not all system monitors have to be active at once; the user can decide which monitors to have activated by mapping to a graphical output.

Last modified 11 years ago Last modified on Aug 24, 2006, 3:15:10 PM

Attachments (1)

Download all attachments as: .zip