Activities for base build

[kimquirk]

Here is the list of activities that we are currently supporting at OLPC and should be part of builds going forward:

chat, browse, write, record, paint

[cscott]

In addition, bootanim-0.15 (in joyride) adds the customization hook for pretty boot; it should go into both ship.2.3 (657) and update.1.

[cscott]

As it turns out, we probably want the Journal, too. (!)

[tomeu]

And Read, perhaps?

Could someone please explain what's behind this ticket?

[walter]

I am all for a core build and separate activity bundling, but we need to have a discussion about what is core. The above list seems a bit ad hoc to me and not all that well tuned to the core mission of learning. Also, until we have an established mechanism for in-country customization, this seems a bit premature.

[bert]

Replying to kimquirk:

Here is the list of activities that we are currently supporting at OLPC and should be part of builds going forward: chat, browse, write, record, paint

Kim, are you implying that those activities that distinguish the XO as a learning machine like Etoys, TurtleArt, and TamTam, are unsupported by OLPC suddenly?

[AlbertCahalan]

Replying to bert:

Replying to kimquirk:

Here is the list of activities that we are currently supporting at OLPC and should be part of builds going forward: chat, browse, write, record, paint

Kim, are you implying that those activities that distinguish the XO as a learning machine like Etoys, TurtleArt, and TamTam, are unsupported by OLPC suddenly?

One should admit that all three are overcomplicated and generally hard to use. Etoys is additionaly quite slow, especially at shutdown.

The five activities that Kim listed are all easy to use, and all five provide critical functionality.

[walter]

let's at least start the conversation form where we left off last summer:

Core activities: There has been a discussion on the devel list about the criteria for inclusion of core activities on the laptop. We'd like to broaden the discussion. Some proposed "Criteria for Inclusion":

1. Epistemological impact—to what degree does this activity positively impact learning? (This is of course the most important criteria.)
2. Fun—is it fun? engaging?
3. 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?
4. 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.)
5. FOSS—is the activity and all of its dependencies free and open?
6. 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?)
7. Uniqueness—does the activity add a unique feature to the core?
8. Expectations—does the activity meet the expectations of (children, teachers, parents, G1G1 audience, etc.)?
9. 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.)

[bemasc]

The concept of "core" is not useful. It causes us to have the wrong debate.

Currently, OLPC does not have any easy way for school systems to generate custom images. Therefore, OLPC is stuck producing OS images that contain enough functionality for everyone. If those images include only a handful of "core" activities, then they are virtually useless. Therefore, many non-"core" activities must be included in those images.

Once OLPC does have any easy way for each school system to choose its own activity set, the "core" designation is irrelevant. A school system could easily drop Paint if it feels Colors! is better, or replace Browse by an implementation based on Webkit or Opera.

[cscott]

This discussion has gotten way off track.

Our problem is actually the *opposite* of what bemasc claims. We provide easy mechanisms to install new activities in a build, but no way for countries to *remove* activities. Our deployment countries have their own lists of activities, and they don't want to be forced to ship activity X or Y. Our 5 activities listed are just those activities that we will insist go into every country's image. We have a larger set of 'core' activities, which are the ones we actually test and verify to function correctly with every stable build. That activity set has not changed.

[cscott]

Replying to bemasc:

Once OLPC does have any easy way for each school system to choose its own activity set, the "core" designation is irrelevant. A school system could easily drop Paint if it feels Colors! is better, or replace Browse by an implementation based on Webkit or Opera.

This "easy way" is http://wiki.laptop.org/go/Customization_key

[bemasc]

Replying to cscott:

Our 5 activities listed are just those activities that we will insist go into every country's image.

Why insist on this?

I'm very glad that customization keys have been worked out. I then see no reason for /any/ Activity to be included in the base build, and not subject to customization. Nobody is going to run base builds anyway, so there's no need for them to be functional.

Also, if Update.1 is to be the base build, then there will need to be a different build for G1G1 owners. Otherwise, they will be rudely surprised to find all their Activities gone after the upgrade.

[cscott]

Because (a) the system won't work if the Journal isn't present, (b) Read can't be installed by other means, and (c) we don't satify our legal requirements unless Browse is present to enable the dev key mechanism. Write, Record, and Chat may be debatable; I'm sure we'll consider removing them when/if a country makes a strong case that they don't want them.

When update.1 is released, we will have an 'activity pack' available for download from the front page that will allow G1G1 users to keep their current activity set. There will not be a separate build for G1G1 users.

[bemasc]

Replying to cscott:

(b) Read can't be installed by other means

Really? evince-olpc needs to be in the system, but I'm pretty sure Read is just a python activity like any other.

The rest of your points I can't argue with. I still don't see the utility of marking Chat, Write, Record, or Paint as "core". It seems that "core" activities should be only those that OLPC is actually unable to remove, for technical or legal reasons.

Ideally, I'd like to get rid of /usr/share/activities/ altogether, thus simplifying that bit of Sugar considerably.

[cscott]

Replying to bemasc:

Replying to cscott:

(b) Read can't be installed by other means

Really? evince-olpc needs to be in the system, but I'm pretty sure Read is just a python activity like any other.

It's a little special in that it doesn't show up in the activity toolbar; it is solely a helper application for Browse. I don't know why that is, and I guess if I had to speculate I'd say that (a) it's probably treated specially because it's a "view only" application; it can't be used to create content, and (b) that's probably a bug: it would be nice if our PDF reader was (say) an annotation tool, or integrated into Write, or somesuch, so that it was actually a full-fledged activity. But again, I'm only guessing.

The rest of your points I can't argue with. I still don't see the utility of marking Chat, Write, Record, or Paint as "core". It seems that "core" activities should be only those that OLPC is actually unable to remove, for technical or legal reasons. Ideally, I'd like to get rid of /usr/share/activities/ altogether, thus simplifying that bit of Sugar considerably.

Again, I wasn't around when that part of Sugar was implemented, but Journal and Control Panel (whenever it gets implemented) will likely always be special, because they get special exceptions to the security policy. That means that updates to them have to be special-cased. Browse, Terminal, Log Viewer, and Analyze also fall in this category at the moment. Browse is fixable. Terminal, Log Viewer, and Analyze need activity signing to be safely installable. Maybe Control Panel could be handled like that, too. That leaves Journal.

So, other than Journal, I completely agree with you, but it's unlikely to happen soon -- moving the rest of the activities out of /usr/share/activities was only forced by immediate needs of our Mexico, Peru, and Nepal. If the community adopts the other applications and starts cranking out new and better versions, deployments might pressure us to move them out of the core build and into their customization keys, but the pressure isn't there at the moment, and there's an aesthetic benefit to be had by keeping at least the left hand side of the activity toolbar consistent across all XOs.

[gnu]

I suggest that once the team has some clarity about why it wants a "core" and what this will mean, bounce the idea through the support team before implementing it. For example, most current instructions for support interventions require bringing up a Terminal, or a Log Viewer. Indeed, for update.1 we added easy root capabilities to Terminal to reduce the support load. Now we're removing the whole thing and making people go back to the text console?

Another way to handle the issue of "people can't remove core activities" is to move these activities from /usr/share/activities into /home/olpc/activities in the OS release. Then ordinary Sugar GUI menu items will work to remove and/or upgrade them.

[cscott]

See trac #2064 for the "move all activities to /home/olpc" idea. There's also lots of discussion on devel@ by this point. Gnu's right that the support-team needs to be notified of the documentation changes required. Because we are under time pressure, we have perhaps naively assumed we could wait to update the documentation until we did an actual public release candidate with these changes.

[kimquirk]

I'm closing this ticket now as the decision was made to put all activities in /home/olpc, which means not in the base OS. Then customize the taskbar to include the activities that a specific country, or G1G1 needs. Other tickets are used to track the automatic customization.

[ixo]

I have created a wiki page (a bit more accessible and user friendly ... for non-trac users) for ideas of 'core/bundled activity packs'.

I started to list a few, and folks are welcome to add more...

http://wiki.laptop.org/go/G1G1_bundled_activities

and a similar idea for Peru (or other deployment locations)

http://wiki.laptop.org/go/Peru_bundled_activities