Project guidelines: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
 
(One intermediate revision by one other user not shown)
Line 68: Line 68:
* Style guidelines : see [[#style]] above.
* Style guidelines : see [[#style]] above.
* Educational guidelines : see [[#education]] above.
* Educational guidelines : see [[#education]] above.
* User review and input : to discuss and review projects for brilliance, see [[OLPC:Featured content
* User review and input : to discuss and review projects for brilliance, see [[OLPC:Featured content]].


{{stub}}


[[category:peer review]]
[[category:peer review]]
[[category:activities]]
[[category:Activity development]]

Latest revision as of 01:45, 19 August 2008

Activity guidelines | Featured content  ·  Peer review | Brilliant wiki-pages

This page contains guidelines for good OLPC projects, software activities or content collections or descriptions for how to engage in collaboration in a class or a school, to follow. They are guidelines to help people pursue the OLPC mission...

Some proposed criteria for inclusion:

Education

  • Epistemological impact—to what degree does this activity positively impact learning? (This is of course the most important criteria.)
  • Fun—is it fun? engaging?
  • Sharable : Is it sharable locally? Over time? Does it lead to long-term collaborations?
  • Discoverable : is the core activity discoverable? (This is not to say that it shouldn't be hard work to fully exploit the power of an activity, but it should have a low barrier to entry.)
  • Constructive : does it help children learn long-term skills? does it promote an attitude of violence?


Style

see also the human interface guidelines pages.

  • System quality — is the activity sufficiently robust in its implementation that it will not compromise the integrity or supportability of the system? Is the overall quality of the implementation adequate to meet our standards? Can the community be engaged in the process of testing and "certifying" and maintaining the activity?
  • Sugarized—to what extent has the activity been integrated into Sugar, including UI, Journal, security, internationalization, etc.? Does the activity require the folding in of additional libraries and resources? (This has impact on robustness—positive and negative—support, bloat, and the overall usability, aesthetics, and perception of quality of the machine.)
  • FOSS—is the activity and all of its dependencies free and open?
  • Extensible—is the activity something the community can extend? Does it span multiple needs? (And does it have—or the potential of having—an upstream community of support?)
  • Uniqueness—does the activity add a unique feature to the core?
  • Expectations—does the activity meet the expectations of (children, teachers, parents, G1G1 audience, etc.)?

Age rating

This tag is a cross between the target audience and an age appropriate rating system. The rating system could be similar to one of the following:


Some have suggested the following, but these ratings are not usually applied to software:


We cannot use the ESRB per se, because we cannot follow the official ratings process (there is no "final copy"), and I doubt whether developers would want to pay their fees.

The PEGI system may be a good fit, since participation is usually voluntary. However, it is not clear what their process is, or whether we can use their ratings without paying a fee.

A long and emotional mailing list thread centered around the [in]appropriateness of DOOM for many of the xo's users. The ability to link to a list of activities that fall under certain rating subsets is important.

Functional user critera

Aside from age, another set of evaluation/marking criteria can be the set of skills a user is expected to have, gain, or improve before/during use of the activity. Some of these include:

  • Literacy (in various languages, on various topics)
  • Fine motor manipulation and reaction time (for keyboard/mouse/peripherals, and software that requires acting within a time limit)
  • Auditory capabilities (both perception and discrimination)
  • Visual capabilities (both perception and discrimination)
  • Memory and cognitive abilities (do users have to be able to remember information taught earlier in the activity? how much concentration does it require and for how long? will children with ADHD, dyslexia, etc. have difficulty playing?)
  • Subject background (does the activity presuppose certain content knowledge - that the user has been exposed to certain topics in mathematics, music, etc?)
  • Abstract thinking (what level of abstraction does the user have to be able to handle?) This is vaguely worded and intended to be a reference to the Piagetian shift towards abstract thinking that usually occurs around the age of 7-8, and again in the very early teens. Please rephrase if you can.

Notes

  • Security guidelines : (1) file-path compliance; (2) a cryptographic signature; and (3) a permissions declaration. (see "Bitfrost compliance) in mailing list archives
  • Style guidelines : see #style above.
  • Educational guidelines : see #education above.
  • User review and input : to discuss and review projects for brilliance, see OLPC:Featured content.
This article is a stub. You can help the OLPC project by expanding it.