Sugar on a Stick/Goals
From Caroline Meeks post, http://email@example.com/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 is 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 its 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:
- Lesson specific facilitators
- 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.
- 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:
- Computers on same LAN segment
- Computers on same LAN no VLAN or bridge segment restrictions (aka bug 1012 resolved).
- Computers IP connected to a server inside the firewall only. e.g. School Server in school.
- 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)
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?
- 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
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.