Difference between revisions of "Activities/Library"

From Sugar Labs
Jump to navigation Jump to search
Line 1: Line 1:
 
<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}{{TOCright}}
 
<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}{{TOCright}}
  
== Purposes ==
+
= Purposes =
  
 
Cornerstone ideas:
 
Cornerstone ideas:
Line 8: Line 8:
 
* make this activity Sucrose version independent(0.82+)
 
* make this activity Sucrose version independent(0.82+)
  
== Objects model ==
+
= Objects model =
  
 
How it looks like from top-level point of view.
 
How it looks like from top-level point of view.
  
=== Everything is an object ===
+
== Everything is an object ==
  
 
So, journal objects, activities/activity-bundles, content/content-bundles are the same level objects.
 
So, journal objects, activities/activity-bundles, content/content-bundles are the same level objects.
Line 28: Line 28:
 
* all Journal objects
 
* all Journal objects
  
=== Tags ===
+
== Tags ==
  
 
Every Library object have finite quantity of predefined tags and infinite quantity of users tags.
 
Every Library object have finite quantity of predefined tags and infinite quantity of users tags.
  
===== Objective tags =====
+
=== Objective tags ===
  
 
Will be set by activity itself after including new Object.
 
Will be set by activity itself after including new Object.
Line 42: Line 42:
 
* ''remote'' link to remote object
 
* ''remote'' link to remote object
  
===== Subjective tags =====
+
=== Subjective tags ===
  
 
Will be set by activity authors or users
 
Will be set by activity authors or users
Line 50: Line 50:
 
* ''endless quantity of users tags''
 
* ''endless quantity of users tags''
  
===== Composite tags =====
+
=== Composite tags ===
  
 
User tags could consist of several child tags to represent tree of users tags.<br>
 
User tags could consist of several child tags to represent tree of users tags.<br>
 
See [[#]].
 
See [[#]].
  
=== Properties ===
+
== Properties ==
  
 
Every object can have:
 
Every object can have:
Line 67: Line 67:
 
By default, some properties could be filled from Journal fields or from object itself (like .ogg properties).
 
By default, some properties could be filled from Journal fields or from object itself (like .ogg properties).
  
=== Sharing ===
+
== Sharing ==
  
 
How users can share their objects.
 
How users can share their objects.
  
===== Type of shared objects =====
+
=== Type of shared objects ===
  
 
Library user could operate with three kinds of objects:
 
Library user could operate with three kinds of objects:
Line 78: Line 78:
 
* ''remote objects'' stored in the Journal of other(online) users
 
* ''remote objects'' stored in the Journal of other(online) users
  
===== Sources =====
+
=== Sources ===
  
 
Every Library object has list of known(not necessarily online) ''sources'' of objects:
 
Every Library object has list of known(not necessarily online) ''sources'' of objects:
Line 88: Line 88:
 
If ''source'' is online user can browse his objects(in separate way or merging them to the main set of objects) and download or download+start them.
 
If ''source'' is online user can browse his objects(in separate way or merging them to the main set of objects) and download or download+start them.
  
===== Synchronize/Upgrade objects =====
+
=== Synchronize/Upgrade objects ===
  
 
User can manually/auto synchronize ''local'' versions with ''remote'' versions from online ''sources''.
 
User can manually/auto synchronize ''local'' versions with ''remote'' versions from online ''sources''.
  
== UI ==
+
= UI =
  
 
Core UI components.
 
Core UI components.
  
==== Objects list ====
+
=== Objects list ===
  
==== Tags sidebar ====
+
=== Tags sidebar ===
  
==== Sources sidebar ====
+
=== Sources sidebar ===
  
== Usage scenarios ==
+
= Usage scenarios =
  
 
=== Room/Lesson mode ===
 
=== Room/Lesson mode ===

Revision as of 20:58, 4 May 2009

Purposes

Cornerstone ideas:

  • implement Unified Objects proposal to have unified method to create, reuse and share all Objects in Sugar
  • work with remote Sugar Objects in the same way like with local
  • make this activity Sucrose version independent(0.82+)

Objects model

How it looks like from top-level point of view.

Everything is an object

So, journal objects, activities/activity-bundles, content/content-bundles are the same level objects.

All object versions

  • by activity_id if it exists
  • by activity for activities/bundles

are represented in Library by one collapsed item.

Every Library object could include:

  • manually included Journal objects
  • auto included Journal objects
    • by MIME type
    • new version of object, if object was already included
  • all Journal objects

Tags

Every Library object have finite quantity of predefined tags and infinite quantity of users tags.

Objective tags

Will be set by activity itself after including new Object.

  • creator for activities
  • creation for objects that were generated by activity(activity_id field is not empty)
  • unbind for Journal objects w/o activity_id field
  • local objects are stored in Journal
  • remote link to remote object

Subjective tags

Will be set by activity authors or users

  • activity required and mutually exclusive for content
  • content required and mutually exclusive for activity
  • endless quantity of users tags

Composite tags

User tags could consist of several child tags to represent tree of users tags.
See #.

Properties

Every object can have:

  • summary short explanation
  • description longer explanation
  • icon of object
  • screenshot of object
  • rank

By default, some properties could be filled from Journal fields or from object itself (like .ogg properties).

Sharing

How users can share their objects.

Type of shared objects

Library user could operate with three kinds of objects:

  • local objects stored in the local Journal; they are regular Journal objects
  • remote objects stored in the Journal of other(online) users

Sources

Every Library object has list of known(not necessarily online) sources of objects:

  • Sugar users joined(if they are online) to this Library session
  • activities.sugarlabs.org
  • various sources that are provided by proper backend, for example books from gutenberg.org

If source is online user can browse his objects(in separate way or merging them to the main set of objects) and download or download+start them.

Synchronize/Upgrade objects

User can manually/auto synchronize local versions with remote versions from online sources.

UI

Core UI components.

Objects list

Tags sidebar

Sources sidebar

Usage scenarios

Room/Lesson mode

At the first approach it could look like:

  1. teacher prepares one or several Library objects for future lesson
  2. during the lesson teacher shares proper Library object for all students
  3. teacher could observe if all students were joined to proper Library object, to proper object inside of Library object

So, this mode should contain mini-neighbourhood view for Library object's items.