User:Benjamin Mako Hill/Dynamic content library plan: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
m (.)
 
(One intermediate revision by the same user not shown)
Line 24: Line 24:
=== Share.Activity ===
=== Share.Activity ===


Perhaps we want a Share activity that allows users to be able to connect to each other and to share not content but actual activities so that users can download these and put them in their own Journal/Datastore.
We want a Share activity that allows users to be able to connect to each other and to share not content but actual activities so that users can download these and put them in their own Journal/Datastore. In particular, this activity should be able to pull together media and files that come on a USB key or on the XO with subelements of a [software] activity or [content] collection.

=== Publish.Activity ===

We want a Publish activity that allows users to actively push works they have done/collaborated on to others: to their whole school, or to the whole world. There should be little other than the desire to publish, context, and metadata needed [perhaps a proper name to find it again later. "are you sure you want to publish 'untitled-35'/'sara'/'tree'/'January, 2008'? that is a common name..."] to send their work on its way the next time a connection is available.

== Other uses of the browser ==
;Walkthroughs: access help files and screencasts about the XO and its installed activities. I can best imagine this as reading all activity and collection directories looking for specially-named files, which might or might not also have a view within the context of that activity. We certainly want the help files to be editable, and for the updated/edited versions to make their way around the local network so a class can develop a great set of shared help/info files
* you want to be able to create new 'help' sections for things that don't have an explicit bundle of their own. For instance an individual pippy program or etoys project, or a certain aspect of the XO that has come to have a well-defined name in your local troubleshooting dialect.
* you want to have a dynamic view of the set of help pages, and a way to search through their targets (perhaps a bit more than bundle title).

;Troubleshooting: similar to the above, can include the above, but especially for hw repair and sw hacking information. Include detailed info about how to get full Linux man pages and a dev environment, for instance, and perhaps a set of "how to use" cheatsheets for the core supported languages and for [fedora] itself.

;About OLPC: find out about the project and its contributors. Something more elaborate than a simple 'thanks' program in Pippy and the "getting started" section, but including both.

;Reference: find out about a word or topic. This can be displayed as a bundle, in the same way that you can "check out an encyclopedia" from a wealthy library. But you normally just want to look up one thing. [this wants to be tied into a system level service, similar to text-to-speech.]

;Mail: people want to send email to one another. right now we ask them to use the browser. definitely not a standard 'library collection' even in a dynamic library. again similar to a service; wants to be closely tied to anything that might generate something to send via email.

Latest revision as of 02:36, 10 February 2008

The following is my current braindump and random ideas for features. Feel free to add to them.

On-laptop verification of library content

We should be able to verify library content bundles automatically and test for the following things:

  • Required/optional fields;
  • Correct encodings on index.html and sub-files;
  • Look for broken links;
  • External links (note these);

This verification library should be able to run in two contexts:

  • on a webserver where it can be used a method to test uploaded content bundles and provide verbose output;
  • on the laptop where it runs a less resource intensive subset of essential checks and can skip or not include certain bundles in the index;

Other Content Features

  • simple index and search
  • tag/based browsing of content -- both user-tagged and not
  • simple annotation of content library
  • simple interface for browsing

Share.Activity

We want a Share activity that allows users to be able to connect to each other and to share not content but actual activities so that users can download these and put them in their own Journal/Datastore. In particular, this activity should be able to pull together media and files that come on a USB key or on the XO with subelements of a [software] activity or [content] collection.

Publish.Activity

We want a Publish activity that allows users to actively push works they have done/collaborated on to others: to their whole school, or to the whole world. There should be little other than the desire to publish, context, and metadata needed [perhaps a proper name to find it again later. "are you sure you want to publish 'untitled-35'/'sara'/'tree'/'January, 2008'? that is a common name..."] to send their work on its way the next time a connection is available.

Other uses of the browser

Walkthroughs
access help files and screencasts about the XO and its installed activities. I can best imagine this as reading all activity and collection directories looking for specially-named files, which might or might not also have a view within the context of that activity. We certainly want the help files to be editable, and for the updated/edited versions to make their way around the local network so a class can develop a great set of shared help/info files
  • you want to be able to create new 'help' sections for things that don't have an explicit bundle of their own. For instance an individual pippy program or etoys project, or a certain aspect of the XO that has come to have a well-defined name in your local troubleshooting dialect.
  • you want to have a dynamic view of the set of help pages, and a way to search through their targets (perhaps a bit more than bundle title).
Troubleshooting
similar to the above, can include the above, but especially for hw repair and sw hacking information. Include detailed info about how to get full Linux man pages and a dev environment, for instance, and perhaps a set of "how to use" cheatsheets for the core supported languages and for [fedora] itself.
About OLPC
find out about the project and its contributors. Something more elaborate than a simple 'thanks' program in Pippy and the "getting started" section, but including both.
Reference
find out about a word or topic. This can be displayed as a bundle, in the same way that you can "check out an encyclopedia" from a wealthy library. But you normally just want to look up one thing. [this wants to be tied into a system level service, similar to text-to-speech.]
Mail
people want to send email to one another. right now we ask them to use the browser. definitely not a standard 'library collection' even in a dynamic library. again similar to a service; wants to be closely tied to anything that might generate something to send via email.