71
edits
Changes
Jump to navigation
Jump to search
Line 7:
Line 7: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Activity Library/Editors/Policy (view source)
Revision as of 20:21, 18 February 2011
, 20:21, 18 February 2011no edit summary
== Non-technical policy ==
== Non-technical policy ==
{{:{{PAGENAME}}/Non-Technical}}
{{:{{PAGENAME}}/Non-Technical}}
== Guidelines for accepting an activity ==
* Must Start/Stop cleanly
o When stopping must stop gracefully - not stay in memory.
* CPU and Memory usage
o Usage must be proportional to functionality
o Must not completely tie up the machine
* Interface
o Conform to Sugar standards?
o Icons to meet sugar colour guidelines
o Frame key must work from within the activity
o Must fit within screen size of the XO’s
* Journal
o Is there save functionality and does it interact with the Journal well?
o Are file types registered with SugarOS correctly?
* Checks
o Black and white (high contrast screen)
o Sound
+ Does sound behave?
# Stutter
# lock up sound card
o Collaboration
+ Must work if button is there
+ Maximum number of collaborators
+ Test with 3 or more?
* Bugs (for updated activities)
o Are there any regressions in old functionality?
o How functional is new functionality?
* Download size of application must be reasonable compared to
o similar applications
o functionality
* For activities webpage
o Must have reasonable explanation of purpose for the “more about this activity” field
o Must have release notes
o Must be categorised correctly
* Versions of Sugar
o Do we assume the developer has tested on all versions they say it works on?
o Tester approving activity tests on olpc stable builds?
o Who tests on SoaS and what version?
* Must tell user if the activity is using web? collecting user data?
== Resources ==
== Resources ==