Sugar Network/Concept

Overview

The Sugar Network is all about:

• Players,
• play Roles,
• with Resources,
• to accomplish their Needs,
• and increase their Reputation,
• being changed, Resources broadcast Events,
• the regular Players' behaviour might be described by the Workflows.

Needs

The needs that Sugar Network is trying to solve. They might be explained by the following selection from the Fundamental human needs:

Need	Being (qualities)	Having (things)	Doing (actions)	Interacting (settings)
Understanding	critical capacity, curiosity, intuition	literature, teachers, policies, educational	analyse, study, investigate,	schools, families, communities,
Participation	receptiveness, dedication, sense of humour	responsibilities, duties, work, rights	cooperate, dissent, express opinions	associations, parties, churches, neighbourhoods
Leisure	imagination, tranquillity, spontaneity	games, parties, peace of mind	day-dream, remember, relax, have fun	landscapes, intimate spaces, places to be alone
Creation	imagination, boldness, inventiveness, curiosity	abilities, skills, work, techniques	invent, build, design, work, compose, interpret	spaces for expression, workshops, audiences
Identity	sense of belonging, self-esteem, consistency	language, religions, work, customs, values, norms	get to know oneself, grow, commit oneself	places one belongs to, everyday settings
Freedom	autonomy, passion, self-esteem, open-mindedness	equal rights	dissent, choose, run risks, develop awareness	anywhere

Identity

Each player should be able to create and manage a unique identity in the network. Every interaction of the player with the network should be accounted on the player's metrics, as eventually this may be part of the player dashboard. Each player may have an individual reputation, according to other players ratings made to his contributions.

Understanding

A player should be able to view all objects and apply the optional filters including the resource type, the Network Zoom level, tags or the associated player/team. In this preview, we may be able to offer basic statistics of the object in order to give analytical perspective to the selection. The player should be able to select the object in order to participate in a deeper level where he should be able to explore the associated resources. As a player, I might receive events from the objects I'm subscribed to as well as personal events like invitations made by other players.

Participation

Any player might be able to comment any object, rate any contribution, edit any wiki, create any issue, attach any object to any gallery, become a follower of any object.

Creation

Any player might be able to create a new project by defining a name, the type of project and the project objective(s). A project creator may be able to invite other players to follow/contribute to his project.

Freedom

Once an object have been selected by the player, he should be able to filter any type of contributions according to its ratings.

Players

These are real people that take part in the Sugar Network.

Attributes:

• nickname, set by Sugar Shell;
• colors, set by Sugar Shell.

Actions:

• Send private message.

Events:

• Attribute is changed.

Resources

The whole experience within the Sugar Network is about Player's interaction with resources. The major resource is Projects that contain all other resources:

• Questions,
• Ideas,
• Problems,
• Wiki,
• Gallery,
• Releases,
• Objectives.

When it is possible, Resources support the history. Resources can't be physically removed, only stated as removed and hidden from the default observing.

Network Zoom

A basic conception that should allow the Sugar Network to better scale depending of Player's purpose. The Network Zoom levels are similar to The Shell Zoom levels (only the first three levels) and describe exactly the current zooming level of Sugar Network from an observer point of view. There are three Network Zoom levels:

• Worldwide, the whole Network;
• Neighborhood, the same name Zoom level from the Sugar Shell, for one-teacher schools it is the whole school;
  TODO needs to be changed to have arbitrary group of Players to avoid clashing with the Worldwide if Sugar Shell connected to the collaboration server hosted in the Internet and Neighborhood Shell Zoom level looks like Worldwide;
• Friends, only friends from Sugar Shell Group view;
• Private, observer himself.

The whole Projects are associated with particular Zoom level, i.e., can be visible only on this particular level. This level is also applying to all Project's resources.

Projects

The composite Resource that is a container for the rest types of Resources. Projects might be created with highlighting some particular type of Resources. It might be useful to, e.g., simplify usage when it will be possible to activate particular sub-Resource directly from the Browser.

Attributes:

• Type:
  • General;
  • Activity, Sources is the default Resource when activating this Resource mean launching this activity;
  • Wiki, Wiki is the default Resource;
  • Gallery, Gallery is the default Resource;
  • Support, Objectives is the default Resource.
• Network Zoom level:
  • Worldwide;
  • Neighbourhood;
  • Friends;
  • Private.

Actions:

• Create new Project;
• Change Zoom level attributes;
• Owner of project (initially, creator) can add/remove another Players from owners list;
• Delete Project;

Events:

• Attribute is changed.

Questions

General (not an Idea or a Problem) question about the Project.

Attributes:

• Topic, one line;
• Description, multi-lined text.

Actions:

• Create;
• All Players can Vote for a comment with "Works for me"/"Doesn't work for me", might be multiple.
• "Works for me" Vote given by Question creators means having an Answer for the Question.

Events:

• Created.
• A vote is added/removed;
• An answer is added/removed.

Ideas

Any ideas regarding the Project.

Attributes:

• Topic, one line;
• Description, multi-lined text.

Actions:

• Create;
• Idea creator choose one of Releases as a solution for the Idea;

Events:

• Created;
• Solution is added/removed.

Problems

Any problem Player met working this this Project or using it.

Attributes:

• Topic, one line;
• Description, multi-lined text.

Actions:

• Create;
• Any Player can choose one of Releases as a Solution for the Problem, which means "This Release works for me";
• Any Player can Vote for chosen Releases to Vote for "Doesn't work for me";
• Releases chosen by Problem poster will mean having a Solution for the Problem.

Events:

• Created.
• Release is added/removed.
• Solution is added/removed.

Todo:

• Simplify logs attaching, e.g., "Share the log" button on activity fail dialog.

Wiki

A collection of Wiki pages that use MediaWiki markup language, wikitext. Pages might be represented by a tree of pages. There is all time the root page. The idea to have a root page is to let it possible to merge these wiki pages to the standalone MediaWiki server. It might provide similar functionality to Google Sites.

Attributes:

• Topic, one line.

Actions:

• Create new Wiki page in hierarchy of pages;
• Upload arbitrary file to place a link on it on Wiki pages.

Events:

• Created;
• Modified;
• File uploaded.

Todo:

• Modify existing page;
• View the history of modifying.

Gallery

A collection of activity objects of types depended on Project type. This is exactly the gallery to share your creatures. Using the Browser it will be possible to explore Gallery entities directly on the top level.

Attributes:

• Topic, one line;
• Description, multi-lined text.

Actions:

• Create by Project owners.

Events:

• Created.

Todo:

• Simplify creating new Gallery entries having a UI way to fast share just created activity object, e.g., from in Naming alert or from Journal.

Releases

For software Projects, this Resource is about released versions of this Project software. This is exactly what Player can execute. There might be several versions with different stability levels. By default, Players execute only recent stable version, but it is possible to choose any version.

Attributes:

• Version number;
• Release date;
• Stability level.

Actions:

• Project owners can create new Version;
• Launch.

Events:

• Created.

Todo:

• Support Experiments workflow when people can make a copy of existing Project and start experimenting with the code and use on regular basis, e.g., share with the rest of Sugar Network.

Objectives

These are the exactly objectives that Project is trying to achieve. This type of Resources has two faces:

• The view for Players that are not the part of Project implementers, they see this Resource as a list of, e.g., features that project is trying to provide;
• The full functional project management interface for people who are owners of the Project and take care of implementation.

Attributes:

• Topic, one line;
• Description, multi-lined text.

Actions:

• Create by Project owners;
• Any user can Vote for Objectives.

Events:

• Created;
• Implemented.

TODO:

• Project management functionality.

Comments

All kinds of resources might be commented by any users. The Sugar Network does not provide any restrictions or permissions, the model is leaving responsibility to a viewer.

Events

If some Resource has been changed, e.g., as a result of Player interacting, Resource sends global notifications. These notification might be seen while investigating this particular object or by Following this Resource. In the last case, events will go to followers' queue of global events.

Events might be personal, e.g., personal invitations or personal messages.

Reputation

Any particular Resource entities, i.e., contributions of some Players, (including Comments) might be rated by any Player. The number of all contributions made by some Player and the sum of all rates that other people gave to these contributions, is the Player's reputation.

Roles

These are roles, not the definition of particular people. Each person can play different roles in different time.

Workflows

These are kinds of workflows that Roles can take part in. The particular activity might involve several Players and several Roles.

Users Interface

From users point of view, The Sugar Network is represented by several kinds views:

Player's page

• Global events queue;
• Personal events queue;
• Send personal events;

Browser

• Will be useful to a special state of the Browser to let people see a summary, hints, etc.
• Switch between Network Zoom levels, e.g., similar to Shell's Zoom levels;
• Expose additional metadata about currently selected item;
• Home/default project, might be useful to, e.g., having default support project for this deployment to point any questions there.

Project view

• The top of participants
• View for particular Project resource, Wiki, Tracker, Gallery, etc.
• (?) Having fast widget to start typing new Question/Idea/Problem

Resource view

• The top of participants
• See the full history of resource changes (no need all time have history like Wiki pages have);
• Follow/NotFollow the Resource changes;
• Send personal invitation events to Players to make them Followers of this Resource;
• Two audience view for Objectives Resource;

Comments view

• Restrict comments by Player's rating;

Technical Overview

The Sugar Network consists of different types of parts:

• Client application that runs in Sugar learning environment on machines of people who take part in the Sugar Network;
• Server that runs either in the Internet (if connectivity is not a problem for clients) or on a school server (that is being synchronized with the Internet, thus, with the rest of school servers).

The Sugar Network supports Internet and Internet-less environments. In both cases, the participant's experience is the same. The only difference is the amount of time when all contributors will see the same picture, in case of the Internet, it will happen in live mode, for Internet-less cases, after synchronizing all school servers.

The particular technical implementation is tailored by the following decisions:

1. Using Web technologies to implement the front end;
2. Keep front end as a local Web application on a client side, it sounds converse regarding the #1 decision but this decision is based on #4 and #5;
3. Front end is implemented as a Falsk application using WebSDK to accomplish the #4 and #5;
4. Local Web application serve only one user and are much simpler than singular applications that are intended to serve thousands of users simultaneously;
5. Having simple and clean designed (see the previous point), it will be easy for doers to learn, change, reimplement the front end;
6. Implementation should be decentralized to support off-line workflow.

Todo

• Support translation workflow for Projects, it might be different workflow, e.g., for Wikis, and Sugar Activities;
• Class type for projects to support regular class behaviour from teachers' pov.
• Support coding workflow for projects.