Difference between revisions of "Features/Content support"
< Features
Jump to navigation
Jump to search
DanielDrake (talk | contribs) (Created page with '<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude> == Summary == ''A sentence or two summarizing what this feature is and what it will do. This information is used for the ov…') |
DanielDrake (talk | contribs) |
||
| Line 2: | Line 2: | ||
== Summary == | == Summary == | ||
| − | + | Sugar should be able to support easy installation and distribution of books, multimedia, and other content. | |
== Owner == | == Owner == | ||
| Line 14: | Line 14: | ||
== Detailed Description == | == Detailed Description == | ||
| − | It could be | + | 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). |
| + | |||
| + | 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 === | ||
| + | |||
| + | 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: | ||
| + | * World maps | ||
| + | * Music (e.g. one album) | ||
| + | * Grade 3 textbooks | ||
| + | * Grade 5 textbooks | ||
| + | * Collections of local historical tales | ||
| + | * 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. | ||
| + | |||
| + | The .xol bundle format is limited and does have its drawbacks and difficulties for deployments. These include: | ||
| + | # 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. | ||
| + | |||
| + | === Accessing content from home screen === | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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 == | == 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. | |
== Scope == | == 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. | ||
== How To Test == | == 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. | |
| − | + | 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 == | == Dependencies == | ||
| − | + | ||
| + | None. | ||
== Contingency Plan == | == 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 == | == Release Notes == | ||
| − | + | ||
| + | to be written after implementation and testing | ||
== Comments and Discussion == | == Comments and Discussion == | ||
| − | * See [[{{TALKPAGENAME}}|discussion tab for this feature]] | + | * See [[{{TALKPAGENAME}}|discussion tab for this feature]] |
| − | |||
| − | |||
[[Category:Feature]] | [[Category:Feature]] | ||
| − | |||
| − | |||
Revision as of 05:13, 18 August 2009
Summary
Sugar should be able to support easy installation and distribution of books, multimedia, and other content.
Owner
DanielDrake dsd@laptop.org
Current status
- Targeted release: (SUGAR_VERSION)
- Last updated: (DATE)
- Percentage of completion: XX%
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).
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
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:
- World maps
- Music (e.g. one album)
- Grade 3 textbooks
- Grade 5 textbooks
- Collections of local historical tales
- 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.
The .xol bundle format is limited and does have its drawbacks and difficulties for deployments. These include:
- 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.
Accessing content from home screen
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.
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.
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.
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.
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
to be written after implementation and testing