105
edits
Changes
Jump to navigation
Jump to search
Line 2:
Line 2: − ''A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release.''+ Line 14:
Line 14: − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − Easy way which lets user provide full debug info after encountering a bug.+ − ''What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?''+ + − ''This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be.'' − ''Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.''+ − ''A good "how to test" should answer these four questions:''+ − * ''What special hardware / data / etc. is needed (if any)?+ − * ''How do I prepare my system to test this feature? What packages need to be installed, config files edited, etc.? − * ''What specific actions do I perform to check that the feature is working like it's supposed to? − * ''What are the expected results of those actions?'' − == User Experience ==+ − ''If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.'' − ''What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like python?''+ + − ''If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Sugar will not be in jeopardy.'' − == Documentation ==+ − ''Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved.'' − ''The Sugar Release Notes inform end-users about what is new in the release. An Example is [[0.84/Notes]]. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.''+ + − + − − [[Category:Feature Page Incomplete]] − ---- − ''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]''
no edit summary
== Summary ==
== Summary ==
Sugar should be able to support easy installation and distribution of books, multimedia, and other content.
== Owner ==
== Owner ==
== Detailed Description ==
== Detailed Description ==
It could be useful to provide as simple as possible method for non-tech users e.g. sugar could send info to predefined server instead of asking questions.
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]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[{{TALKPAGENAME}}|discussion tab for this feature]]
[[Category:Feature]]
[[Category:Feature]]