Sugar Network/Concept

This page is a guide to basic Sugar Network concepts. See also introduction page and technical implementation pages.

Overview

The whole initiative is tailored by the following decisions:

• The Sugar Network should be useful in off-line environments;
• The list of provided resources should cover the full circle of low level collaboration behavior between Network participants; when low level means that resources are all time the same kind for all types of collaboration contexts;
• The list of provided resources should be thought out so that the Sugar Network is equally useful operating on-line;
• Stimulate a "doing" workflow.

The whole Sugar Network picture is described on the following graphics.

Where: Server Server side in general. It might be a server accessible from the Internet (on-line case) or various distributed servers located, e.g., at schools (off-line case). See technical pages for more details. Conceptual level What this page is exactly about. This is how Sugar Network looks like on conceptual level. From the technical side, this level is represented by Server application programming interface (API). Client This is what Network participants are interacting with. This is a software that let people get access to the Sugar Network. User experience, that these clients provide, might be too different from client to client. Starting from a couple of elements in GUI (when people even don't suspect they are interacting with the Sugar Network) and ending with clients that represent conceptual level as close as possible.

Summary

The Sugar Network is all about:

• Players,
• in different Contexts,
• interacting with Resources,
• to accomplish their Needs,
• 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:

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 on 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 Context by defining a name, the type of Context and the Context objective(s). A Context creator may be able to invite other players to follow/contribute to his Context.

Players

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

Attributes:

• nickname,
• Sugar colors.

Actions:

• Send private message.

Reputation

Any particular Resource, i.e., contributions of some Players, might be voted by another Players. The Reputation of particular Player depends on how other Players appreciate him.

Statistics

Basing on Events, it is possible to measure particular Player's behaviour. It might be useful, e.g., for researchers.

Contexts

This is exactly the context of Players' behaviour. Being in the current Context, Player are interacting with Resources associated with this Context (or, Contexts linked to the current one).

There is a predefined Context, the Global Context that contains all other Contexts (according to the current zoom level). So, Players can interact with all Resources accessible on this zoom level.

Context types might be too different. But for now, these are only:

• Sugar Activities,
• Various content (might be .xol libraries).

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, accessible only if observer connected not to global server, e.g., to the one localed in school;
• Private, observer himself.

The whole Contexts are associated with particular Zoom level, i.e., can be visible only on this particular level and all levels below. This level is also applied to all of the Context's resources.

Resources

The whole experience within the Sugar Network is about Player's interaction with resources. Resources are tied to the current Context and might be different types:

• Feedback related:
  • Questions,
  • Ideas,
  • Problems,
• Wiki,
• Gallery,
• Development related:
  • 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.

Questions

General question about the Context. A user-friendly interface for asking questions about the current Context. The workflow is much simpler when compared to typical bug trackers (Trac, RT, etc.). It is intended to be more like "forums" or wiki "discussion" pages, just ask your question and wait for answers. Besides, Questions might be treated as a kind of simple knowledge base for the Context (in comparing with bug trackers, Questions are not being closed after getting answers). The most useful Questions might be picked up to compose the FAQ for the Context.

The rest of non-developers needs are covered by Ideas and Problems. The developers needs are covered by the Objectives and its advanced view in particular.

Attributes:

• Title, one line;
• Description, multi-lined text;
• A list of solutions provided by any Players.

Actions:

• Create a Question;
• Discuss the Question;
• Vote for the Question;
• Create a Solution;
• Discuss a Solution;
• Vote for a single Solution;
• Vote given by Question creator means an answer for the Question.

Ideas

Any ideas regarding the Context. A user-friendly interface to propose your idea to the current Context developers. The workflow is much simpler, compared to typical bug trackers, just offer your suggestion, look how other people will rate it and wait for the implementation.

The rest of non-developers needs are covered by Questions and Problems. The developers needs are covered by the Objectives and its advanced view in particular.

Attributes:

• Title, one line;
• Description, multi-lined text;
• A list of solutions provided by any Players.

Actions:

• Create an Idea;
• Discuss the Idea;
• Vote for the Idea;
• Create a Solution;
• Discuss a Solution;
• Vote for Solutions;
• Context team member attaches one of Objectives to one of Solutions, the Idea's status becomes the same as Objective's.

Problems

Report a problem with the Context. A user-friendly interface to complain about an error that the Player encountered when working with the Context. The workflow is much simpler, compared to typical bugs trackers, just complain and wait for a fix.

The rest of non-developers needs are covered by Questions and Ideas. The developers needs are covered by the Objectives and its advanced view in particular.

Attributes:

• Title, one line;
• Description, multi-lined text;
• A list of solutions provided by any Players.

Actions:

• Create a Problem;
• Discuss the Problem;
• Vote for the Problem;
• Create Solution;
• Discuss a Solution;
• Attach one of Releases as a Solution;
• Vote for a single Solution;
• Vote given by Problem creator means a fix for the Problem.

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.

Attributes:

• Title, one line.

Actions:

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

Todo:

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

Gallery

A collection of activity objects of types depending on Context 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:

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

Actions:

• Create new Exhibit.
• Discuss the Exhibit;
• Vote the Exhibit;

Todo:

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

Releases

For software Contexts, this Resource is about released versions of this Context 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:

• Context owners can create new Version;
• Launch.
• Discuss the Release;
• Vote for the Release;

Todo:

• Support Experiments workflow when people can make a copy of existing Context and start experimenting with the code and use on regular basis, e.g., share with the rest of Sugar Network.
• Convenient method to attach log reports with errors to the particular Release, e.g., "Share the log" button on activity fail dialog.

Objectives

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

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

Attributes:

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

Actions:

• Create by Context owners;
• Discuss the Objective;
• Vote for the Objective;

TODO:

• Context 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.

Workflows

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

Support

A need for general help from the local community supporters.

• You need to be a part of a community with local support, thus, you will have the default place to complain, the Home Context;
• Go to Browser and click Home Context button;
• Try to search if your problem was already reported using text search string or tags;
• If search is not successful, describe your problem in Problem (as well for Questions and Ideas) entry widget as full as possible;
• The supporters will be notified and and will reply with request for further information or with an answer;
• On the Network screen, you will be notified about gotten reply.

Something goes wrong with the system and it is not clear where the problem is.

• You need to be a part of a community with local support, thus, you will have the default place to complain, the Home Context;
• Since there is no any ideas what the place in the system is affected, thus, no way to decide what Context to choose to complain, go to Browser and click Home Context button;
• Try to search if your problem was already reported using text search string or tags;
• If search is not successful, describe your problem in Problem (as well for Questions and Ideas) entry widget as full as possible;
• The supporters will be notified and and will reply with request for further information or with an answer;
• On the Network screen, you will be notified about gotten reply.

Something goes wrong with the system and it is possible to specify the place where it happens.

• Go to the Browser and try to find the Context that is associated with problem place; use Tags and full text search; after finding, click its Home button;
• Try to search if your problem was already reported using text search string or tags;
• If search is not successful, describe your problem in Problem (as well for Questions and Ideas) entry widget as full as possible;
• Any Context Contributor can reply with request for further information or with an answer;
• On the Network screen, you will be notified about gotten reply.

Provide supporting materials.

• Skilled people, somewhere on the Mothership level, create a set of Wiki pages;
• Since initial Sugar Network won't support Wiki editing, using special tools these wiki pages will be uploaded to the Sugar Netowork to some Context, e.g., to Home Context;
• Teachers/students can all time get these materials going to the Home Context and click Wiki.

Sugar activity fails to start or fails on exit.

• The activity fail dialog should have a complain field, describe your problem in there as full as possible;
• If Submit button was clicked (might be default), the repost with text message and activity logs will be attached to particular Release of the Context;
• Context Contributor, browsing uploaded reports, can reply with request for further information or with an answer;
• On the Network screen, you will be notified about gotten reply.

Content

Sharing arbitrary education related media content.

• Teacher (or any other Player) creates new (or reuse existing) Wiki Context;
• Set appropriate, to the purpose, Tags and Context description;
• Create initial Wiki page, populate it and attach media content;
• Students, using Tags and full-text search, explore the Context in the Browser;
• Being in the Browser, activate the found Context and being moved to the Wiki page.

Sharing Activity object.

• In after-creation dialog, there should be a button to share newly created object with the Network;
• Journal should have a way to share any object by one click.

Sugar activities

Fast launch of an activity.

• Go to the Browser and explore the activity you want to start, maybe using the Activity Tag or full-text search;
• Click found entity.

Launch particular activity version, e.g., to help with testing non-stable version or fallback to previous one because the recent doesn't work for you.

• Go to the Browser and explore the activity you want to start, maybe using the Activity Tag or full-text search;
• Click Home button for found entity;
• You should find the list of Releases with the recent stable Release chosen, select any version you want;
• Click the Launch button, or run it from the Browser, to run newly selected Release.

Networkless

Sugar Network is all about being connected to a Sugar Network server, placed in the Internet (on-line case) or in a schoolserver (off-line case). But limited workflow is supported for server-less case.

Being at school and connected to its Network server, prepare Contexts to work at home when Network won't be accessible:

• Go to the Browser and explore the Context you want to work at home;
• Pick up these Contexts (depends on implementation);
• Being at home when Network is not accessible, you will see all picked up Context in the Browser;
• Limited functionality (depends on implementation) will be supported for these Contexts.

Teaching

TODO

Developing

Fork me.

• Go to the Browser and explore the activity you want to start, maybe using the Activity Tag or full-text search;
• Click Home button for found entity;
• TODO

Todo

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

Getting involved

• Submit your bug report or feature request.
• Browse our implementation discussions, and post your feedback. (You should join this discussion list in order to avoid having your messages postponed for moderation.)

See also

• Stack Exchange family of Q&A websites.
• Get Satisfaction technical support platform.
• IdeaTorrent.
• Curriki, Open Curricula Community.