User:Cjl/Sandbox

I.M.A.G.E.

If you are taking the time to write a Sugar activity or "sugarizing" some open-source software to run in the Sugar environment, you will want to take some extra time to give it the best IMAGE you can. The I.M.A.G.E. rubric does not represent the only factors that you should take into account when writing your activity, the Human Interace Guidelines represent a more complete discussion of design considerations. IMAGE represents a few important factors that too often are overlooked that sometimes presents barriers to the wider use of a Sugar activity and therefore deserve to be pointed out specific attention.

I is for Internationalization (I18n)

Writing an activity is good, writing an activity that has been internationalized so that the user interface strings can be readily extracted using GNU gettext tools and deposited into the main Pootle server (probably in the Honey project) as a POT file for the Sugar / OLPC localization community to translate will allow your work to reach the widest possible audience around the world.

M is for Manual

Ideally activites should be self-explanatory, but that is not always going to be the case. It can be very helpful to develop some user documentation in the form of a user manual. The preferred means of doing this is the FLOSS Manuals toolset which allows for mixing and matching of chapters and has tools for allowing translationof those chapters.

A is for Activity testing

Activity authors generally want feedback from testers on many different platforms and environments. The best way to get your activity tested thoroughly is to provide some initial testing scripts that cover the primary or essential functions of the activity. At present the best way to do this is to use the Semantic MediaWiki templates on the OLPC wiki that are being developed by the [Community Activity Testing group. Drafting your own testing scripts is the best way to get useful feedback from as many testers as possible as Sugar evolves through multiple releases over time. Writing these testing scripts while your activity is in early phases of the development process and the various key features are fresh in your mind will be much easier than trying to produce them later.

G is for Generalization

Many early activities were developed with the constraints of running on XO hardware in mind, some taking that too far and actually hard-coded features like screen resolution. With the development of Sugar packages in upstream distros and Sugar on a Stick, Sugar is now running on a far wider variety of hardware.

Note: Developing activities that take advantage of the unique features of the XO laptop is encouraged where it makes sense to do so. XO laptop users (hundreds of thousands of children in deployments) represent the largest single group of Sugar users and probably will for some time.

E is for Educational content

Porting a first-person shooter like Doom to run in Sugar may be a fun trick, but it has realtively little redeeming social value. Sugar is meant to be focused on learning, so writing an activity that has a strong learning element by itself is good, writing one that integrates with some additional learning content or lesson plan materials that can be packaged with it may be even better.