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