Sugar on a Stick/Goals

Project Home   ·   Get Involved   ·   Contacts   ·   Resources   ·   FAQ   ·   Roadmap   ·   To Do   ·   Meetings

Introduction

See Sugar on a Stick/Resources for some background on the project and a description of the core goals.

In July 2009, Caroline Meeks posted some goals for v2 SoaS, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg05998.html:

I am going to try to answer this, or actually I hope start a brainstorming session that will get us towards a feature list.

I am going to try to use the Customer Role of an Agile process. That means I'm going to try to talk as much about the result I want to see as I can and as little as I can about how to get to it. I do know that some of this is in the works. I also know that some of it will require the heavens to deliver us yet another genius programmer with a new skill set to accomplish by September. But the job of the role of Customer in my mind is to talk about what I'd like to see, what the business case for it is, and what the priority is. I hope other people will join me in this role as I think it's crucial information for the technical team to have.

Types of Requests

Gregorio 13:20, 21 July 2009 (UTC)
I suggest we break out feature requests in to two types:

1. Lesson specific facilitators
2. Class management

The first are barriers and bugs to executing the desired lesson plans. The second are tools and technologies to manage many students and allow them to work together. The major headigs below fall in to the second category. We should add any lesson specific bugs or features here as well.

For lesson specific features priority will be given to the following kinds of issues:

• SW is hard to explain and/or its not discoverable so kids need 1 - 1 help.
• SW is time consuming, slow or requires too many clicks.
• Something we want to do is not possible.
• New or updated activity is needed.
• Crash or failure to perform as intended, especially if it entails data loss.
• Class management is too time consuming for the teacher.

Time is extremely precious in class. You get one hour with the kids so every second counts. If something is not clear to kids and you have to explain it to each kid or touch each computer, that is very costly. If it takes 1 minute to show a kid how to do something, there are 20 kids and you have lost 1/3 of your class!

Solid Collaboration

• Priority A for GPA Project. - Defining what this looks like and how we get there is an important discussion and i don't have all those answers. This encompasses local and jabber collaboration.
• Priority(?) Switch on sugar control panel to turn on/off jabber and use only local network for collaboration [satellit07/05/2009]

• Four network configurations are envisioned for use of this feature at GPA:

1. Computers on same LAN segment
2. Computers on same LAN no VLAN or bridge segment restrictions (aka bug 1012 resolved).
3. Computers IP connected to a server inside the firewall only. e.g. School Server in school.
4. Computers anywhere on the Internet accessing publicly addressable school server (or any Jabber implementation)

The GPA school will use option 1 above. It will also use local collaboration with no Jabber server. Gregorio 13:20, 21 July 2009 (UTC)

This feature should still be tracked for the fall so that kids can collaborate from home. In that case number above will be used.

Straightforward Teacher "Assignment" -> Student -> Teacher workflow

• Priority B for GPA. For example. Teacher creates a template to scaffold student writing. Students do the writing assignment and the teacher "collects" them. Maybe this happens with Moodle or maybe its done all in Sugar?

Straightforward Sugarization

• Priority A for Sugar. By this I mean that a programmer who has created a game for linux or the web could look at our documentation and examples and tell his/her boss, "yes I see how we can make this available for Sugar and it will be a better experience for kids in a classroom through Sugar." Sugarizing should not mean giving up aggregating data for the teacher. It should be a better user experience because: automatic saving, cooler collaboration, easier installation and more consistent performance, easier for teachers to find, available to the million kids with XOs.

Backup and Restore with School Server

Sugar on SoaS and Netbooks backs up and restores with XS

• Priority A for GPA,

Now also tracked here: http://wiki.sugarlabs.org/go/Features/Back_Up_and_Restore

Combine Sugar Live CD, Boothelper, & USB Creator on one image

• Priority B for SoaS
• Priority(?) Down-loadable Application to clone sugar.iso files and USB sugar on a sticks from a running sugar desktop [satellit 07/05/2009]

Sugar on a Stick works with a VM

• Priority B for GPA - it still has to boot on its own also.
• Priority(?)Custom Boot CD with autostart VMPlayer (in sqfs) to run USB "VM's on a stick" on insertion [satellit 07/05/2009]

A Sugar machine can also run a SoaS

• Priority C - Use case. Say you are in a 1-1 Netbook deployment. Your netbook breaks and it'll be a week till its repaired. It would be cool to burn a Stick for that kid from the XS backup and they could then use a teacher's netbook or some kid who is in Gym that period's netbook and still get to participate in the lesson.

Sugar works on preIntel Macs

• Priority C for GPA, Priority B for Sugar.

Sugar works on lesser hardware, say Pentium III 256M

• Priority C for SoaS

Avoid surplus Activity launching

Don't let the user keep opening activities until the machine crashes or is driven to its knees. Make it less likely that a user who is impatient will end up opening multiple copies of an activity.

• Priority C for GPA

Less cluttered, more consistent neighborhood view

• Priority C for Sugar

Better Paint Program

The Paint program was very slow at GPA. It especially slowed down when trying to fill or draw shapes.

See more discussion on improvements needed here: http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016344.html

A new paint program (e.g. TuxPaint) or fixes to the existing one will both be considered.

Original e-mail ending

I am copying the Server list because I think many of the things I think are the most important next steps for Sugar require interfacing with, and improvements in the XS.

Priorities are my current opinions and I tried to not bias them with how hard I think the tasks are. They are about how important I think they are, in my opinion, with my customer hat on, to either the GPA pilot, Sugar and its marketing, and partnerships and adoption, or the Sugar on a Stick project. I don't think for a second that things should be done in priority order.

So I hope everyone else sticks their necks out and says what features they want, what the use cases are and what they think their relative importance are. Then we can narrow our focus back down to what we can do for September.

Incoming Ideas

Parking this e-mail here until I can analyze it and break it out in to features. Gregorio 14:24, 21 July 2009 (UTC) http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016909.html

For the fall - here is a brainstorm

- Reliably working on the Macbooks in the laptop cart.
- Faster user setup.
-Easier setup in the computer lab - We can try upgrading the BIOS and see if we can get it to boot directly from USB. We could have a floppy boot helper that could just stay with the computer.
- Communication plan for helping people to get their sugar sticks to boot at home
-More robust sticks, I think there is a ticket in on the goes to user login but with no user name but we've seen on a few sticks now.

I think the 4 items above will all be much easier if we are using a stick format where you can see the files rather then one squash image file. there is at least one ticket in for that. I'd like some technical opinions on that, but my sense is the underlying reformat of the stick is what should be to top priority item.

-Prettier reboot. Reboot takes you to a nonsugar screen where you have to press return when it says user name is liveuser. Sometimes it fails completely as above.
-Grouping collaboration by class on the jabber server (clearly this is for after we goto Jabber based collaboration.)
-Teacher collecting homework and assessing workflow. Right now it looks like the fall early adopters will be doing a lot of writing so think of a student writing an essay and the teacher being able to take all those essays home, read and comment on them, and return them.