Difference between revisions of "Features/Content support"

Latest revision as of 15:19, 5 November 2013

Summary

Sugar should be able to support easy installation and distribution of books, multimedia, and other content.

Owner

Current status

Targeted release: 0.100
Last updated: July 2013
Percentage of completion: 100%

Detailed Description

Content bundles have long been both a crucial part of the OLPC-Sugar offering (see http://wiki.laptop.org/go/Creating_a_collection), and a pain through having some deficiencies.

They are important because it is the only easy way for a deployment to add pre-made content to Sugar (e.g. books). The strong point of the design here is that beyond a not-too-strange library.info metadata file, you do not have to interact with anything too technical (e.g. python) beyond the HTML content itself. It is something that seems to fall within capabilities of deployment teams without much difficulty, whereas activity development is often a painful step up.

They are quite widely used and in my experience visiting deployments "how do we add our content to the laptop" is a very frequent question - I always ran training sessions on content bundles in response. Here are some examples of the kinds of bundles that exist:

World maps
Music (e.g., one album)
Grade 3 textbooks
Grade 5 textbooks
Collections of local historical tales
Multimedia about local culture (dance/music)

However they are a pain because Sugar never really supported them very well. Sugar can launch them from the Journal, but shipped content that the user has never opened before does not exist in the Journal, so there was something missing here.

To fill the gap, OLPC added a system (olpc-library) to produce a HTML index of content bundles and this is the Browse homepage, but that isn't great either - it's not part of Sugar where it should be, and users have to open the web browser as if they are going online when they are just looking to open some preinstalled content.

With my recent work on automatic activity updates, we had to add content bundles to the bundle registry so that they will be updated appropriately. Now that this is done, it is very easy to remove this deficiency.Content bundles now appear alongside activities, in the list and favourites views. They are launched as expected with a click.

Sugar's support for content is currently minimal. You are limited to shipping the content on USB disk to each computer, or through a website (one-click-per-file). The widely-deployed .xol content bundles only have minimal support (they can only be launched from the journal).

With this change, it is envisioned that the OLPC-specific way of providing a content bundle index (through olpc-library) would go away. The content bundle format has been tweaked to remove unused fields. However, it is fully compatible with existing content bundles.

Benefit to Sugar

Sugar deployers finally have a simple method of shipping content to all systems within a deployment.

Scope

A small Sugar patch is needed, to show content bundles on the home screen (rather than ignore them), and some tweaks to the ContentBundle class is needed so that it matches the API of the ActivityBundle class.

How To Test

Install content bundles and make sure that you can open them. Make them available on the favorites view and check they can be opened from there. Check that you can erase them and that they are then gone from disk.

Dependencies

None.

Release Notes

to be written after implementation and testing

Comments and Discussion

See discussion tab for this feature

@@ Line 1: / Line 1: @@
-<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>
+<noinclude>{{GoogleTrans-en}}{{TOCright}}
+[[Category:FeatureLanded|Content support]]
+</noinclude>
 == Summary ==
@@ Line 8: / Line 10: @@
 == Current status ==
-* Targeted release: (SUGAR_VERSION)
-* Last updated: (DATE)
+* Targeted release: 0.100
-* Percentage of completion: XX%
+* Last updated: July 2013
+* Percentage of completion: 100%
 == Detailed Description ==
-Sugar's support for content is currently minimal. You are limited to shipping the content on USB disk to each computer, or through a website (one-click-per-file). The widely-deployed .xol content bundles only have minimal support (they can only be launched from the journal).
+[[Content bundles]] have long been both a crucial part of the OLPC-Sugar offering (see http://wiki.laptop.org/go/Creating_a_collection), and a pain through having some deficiencies.
-A solution should have the following properties:
-* Easy for deployments to ship content as part of the OS and in packages
-** This means that the content may be installed before any of the Sugar profile or datastore exists
-* Easy for the user to install more content
-** e.g. single click from USB disk view in Journal, or website in Browse activity
-* Accessible through the home screen.
-** Content should become a first-class citizen in the Sugar shell, alongside Activities.
-** The OLPC-implemented solution of having to open your web browser to reach your local content does not make so much sense.
-* Going into the journal must be not a requirement.
-** It would be fine for the Journal event view to note that new content has been installed, but this should not be the primary way of accessing such content.
-* Precisely one copy stored on disk, except for when explicitly saved to Journal
-** It is not acceptable for a 2nd copy of the content (e.g. the originating content bundle) to be stored in the journal, even if it is compressed, unless the user has explicitly made this action (e.g. drag-and-drop .xol bundle from USB to Journal)
-* Full compatibility with existing .xol content bundles
-=== Content bundle format ===
+They are important because it is the only easy way for a deployment to add pre-made content to Sugar (e.g. books). The strong point of the design here is that beyond a not-too-strange library.info metadata file, you do not have to interact with anything too technical (e.g. python) beyond the HTML content itself. It is something that seems to fall within
+capabilities of deployment teams without much difficulty, whereas activity development is often a painful step up.
-Supporting .xol bundles is a must. They are already widely created and deployed in the field. Here are some examples of the kinds of bundles that exist:
+They are quite widely used and in my experience visiting deployments "how do we add our content to the laptop" is a very frequent question - I always ran training sessions on content bundles in response. Here are some examples of the kinds of bundles that exist:
 * World maps
-* Music (e.g. one album)
+* Music (e.g., one album)
 * Grade 3 textbooks
 * Grade 5 textbooks
@@ Line 40: / Line 30: @@
 * Multimedia about local culture (dance/music)
-Sugar's support for the .xol bundle specification has never been complete. It is important to meet the previous level of support, but it is not necessary to go any further. For example, the specification states that the library.info file can specify which activity is to open the library_index file. In reality, it only ever uses Browse to open such a file, mandating that each content bundle contains some kind of HTML index or starting page which lets you move through the bundle contents. It would be OK for Sugar to impose the same requirement again.
+However they are a pain because Sugar never really supported them very well. Sugar can launch them from the Journal, but shipped content that the user has never opened before does not exist in the Journal, so there was something missing here.
-The .xol bundle format is limited and does have its drawbacks and difficulties for deployments. These include:
+To fill the gap, OLPC added a system (olpc-library) to produce a HTML index of content bundles and this is the Browse homepage, but that isn't great either - it's not part of Sugar where it should be, and users have to open the web browser as if they are going online when they are just looking to open some preinstalled content.
-# Writing a HTML index file. Writing HTML is an order of magnitude higher than putting a few PDF files in a zip file, therefore can be challenging to deployments. Additionally, the process is prone to human error.
-# Writing an library.info file. These kinds of files are not human-intuitive. It can be challenging to explain the concepts of this file to deployments - the syntax, why the syntax is important, the specific meanings of each field, the fact that it must be stored at activity/activity.info and not any other name, etc.
-# The fact that everything is launched through Browse causes all accessed content to be saved (duplicated) in the Journal.
-So, I am absolutely an advocate of inventing a better content packaging system (for example, if Sugar was given a .zip of 4 PDF files, it could automatically generate an index listing to show on-screen, without requiring any special files in addition to the content). However, in the interest of keeping the scope of this feature manageable, future content packaging methods will be discussed as a separate feature to be implemented later. No matter what we come up with in the future, supporting .xol bundles for the next 5-or-so years is important, and provides a good starting point for the basic idea of content support in Sugar.
+With my recent work on [[Features/Automatic activity updates|automatic activity updates]], we had to add content bundles to the bundle registry so that they will be updated appropriately. Now that this is done, it is very easy to remove this deficiency.Content bundles now appear alongside activities, in the list and favourites views. They are launched as expected with a click.
-=== Accessing content from home screen ===
+Sugar's support for content is currently minimal. You are limited to shipping the content on USB disk to each computer, or through a website (one-click-per-file). The widely-deployed .xol content bundles only have minimal support (they can only be launched from the journal).
-Accessing content should be considered just like an activity in the Sugar shell. Opening a book should be the same class of action as opening the Write activity to write a letter -- in the classroom, these activities are certainly on the same level.
+With this change, it is envisioned that the OLPC-specific way of providing a content bundle index (through olpc-library) would go away. The [[Content bundles|content bundle format]] has been tweaked to remove unused fields. However, it is fully compatible with existing content bundles.
-This implies that we'd have icons in the Favorites and List views for content bundles, which is basically what I'm suggesting. However, we also need to be able to scale to having a lot of content installed, and we need to have some kind of categorization system for ease of browsing.
-My design thoughts, at least intended as food-for-thought:
-* Leave the Favorites view as-is. That is, it shows activities (and content) that have been marked as favorites.
-* Delete the list view.
-** It looks too much like the Journal -- this frequently confuses me, and I've seen it do the same to kids and teachers.
-** It ends up removing the central XO figure from the screen, which is needed for access to Shutdown and Control Panel. Explaining the shutdown process to new users is already quite difficult, having the extra confusing step of "oh, you're on the list view? no..that's not the journal, you are on the home view just in list mode, you have to go back to favorites mode in order to see the XO figure" is challenging.
-* Create a button in the top right of the home view, with the semantics of being an "advanced view" or "show all" or "More..." button
-** This button would open up a dialog.
-My ideas for the dialog design:
-* The dialog sits on top of the favorites view view, not full screen, styled like the control panel. Therefore it is obviously just another layer on the home view and doesn't present the confusing illusion that you're in the journal.
-* There would be a bar along the top, like the control panel. From left to right, it would have: the XO figure from the favorites view (mouse-over or click with either button to open the palette giving options like Shutdown and Control Panel), a search box, and an X to close the dialog.
-* Directly below, there would be another bar with tab-like buttons for the following categories: Activities, Books, Health, Images, Media, Science, Search
-** Actual activities (write, paint, record) would be listed under the Activities category
-** Content bundles would be shown under the category specified in their library.info file.
-** If any of the above categories would be blank, they can be omitted from the tabs list.
-** (side-project: It may make sense for activities themselves to allow themselves to be categorized this way too. e.g. TamTam would go under Media, Wikipedia under books, Maze under Games, etc.)
-* The remainder of the dialog would be a list view, of identical appearance and behaviour to the current List View on the home screen (star, name, version, last accessed time)
-* There would be room for changing/refining the design of this dialog in future, but hopefully the base idea would stay the same: it's an overlay over the home view, allowing you to select which things you want for easy access on the home view, and also allowing you to browse things by category.
-** Therefore we won't be shifting around design elements too much.
 == Benefit to Sugar ==
-Right now, Sugar is good at the interactive learning stuff but mostly misses the widely-adopted method of lesser interactive materials (books, videos, etc). Also, the OLPC model is great at solving problems related to paper books (expensive, heavy, get lost/torn) and sugar should capitalize on the possibility of greatly changing classroom life in these remote places.
+Sugar deployers finally have a simple method of shipping content to all systems within a deployment.
 == Scope ==
-This feature will likely involve a bit of brushing up of the Bundle abstraction in sugar-toolkit, and a fairly extensive rework of the home screen.
+A small Sugar patch is needed, to show content bundles on the home screen (rather than ignore them), and some tweaks to the ContentBundle class is needed so that it matches the API of the ActivityBundle class.
 == How To Test ==
-Install content bundles and make sure that you can open them. Make them available on the favorites view and check they can be opened from there. Check that you can shutdown the computer even when the new dialog is open. Check that you can erase them and that they are then gone from disk.
+Install content bundles and make sure that you can open them. Make them available on the favorites view and check they can be opened from there. Check that you can erase them and that they are then gone from disk.
-Test with a lot of the content bundles that already exist.
-== User Experience ==
-Content will become available like activities are now, and the home view will see a partial redesign at the same time.
 == Dependencies ==
 None.
-== Contingency Plan ==
-None necessary, revert to previous release behaviour. And be sad that it's very hard for distributors to distribute simple things like books on sugar systems.
 == Release Notes ==
@@ Line 107: / Line 62: @@
 == Comments and Discussion ==
 * See [[{{TALKPAGENAME}}|discussion tab for this feature]]
-[[Category:Feature]]