1. One Laptop per Child Building XO User Developer Relationships November 20, 2008 Greg Smith OLPC Product Manager greg@laptop.org One Laptop per Child

2. Agenda ● Building fruitful user developer relationships – Examples of user feedback and responses – Confirming your new app is really killer ● Working with XO deployments

3. User Developer Relationships ● Its all about the relationship ● Understand the roles, perspectives and desires ● Examples: – Programmer wants to make a better program which lots of kids will use. – Deployment lead wants to roll out 5K Xos by Wed. – Teacher wants to teach better – Student wants to play youtube video

4. User Developer Relationships ● Long term, they help more than you help them – Be nice, be appreciative, listen more than you talk – Don't ask for user input if you don't plan to spend any time responding to it. ● Responding to the user builds the relationship – If the first request is easy, just “do it”. – Ask for context early (who is asking and why) ● Later you can get better feedback and have richer interactions ● The first question is never enough detail for development's needs.

5. Examples Real questions from a recent training ● Connectivity went off, a couple of times, we were all connected to "ml1cc" ● Two of them opened many activities and besides slowing down a lot, once they finally closed all but one, it kept being very slow ● One photo taken with Record could not be imported into Write. Neither through Clipboard nor through the import button on Write. We erased it, took a different photo and then it was Oked. ● text disappeared from Paint, and could not get it back ● One said the sound was to low in general ● Scratch doest close from Home (only from the "Quit" button) ● Inserting photos from the Internet is not as simple ● Distance was not not getting activated. We had to switched Mesh and try for a couple of times until they could connect.

6. Examples Possible answers and benefits to user and developer ● Q - Connectivity went off, a couple of times, we were all connected to "ml1cc" – A - Wireless is congested in 1CC. – Benefit to user - Scale of Xos/APs is important. More successful roll out. – Benefit to developer – Check again for bugs. Maybe fail more gracefully. ● Two of them opened many activities and besides slowing down a lot, once they finally closed all but one, it kept being very slow – A – There is a limit to how many apps can be open. – Benefit to user – Learn limits of XO and work around (don't do that) – Benefit to developer – Maybe fail more gracefully. ● One photo taken with Record could not be imported into Write. Neither through Clipboard nor through the import button on Write. We erased it, took a different photo and then it was Oked. – A – Sounds like a bug. Try to reproduce – Benefit to user – Possibly fixed if reproduced – Benefit to developer – Teach user to file better bugs or create use case and improve product

7. Examples Possible answers and benefits to user and developer ● Essentially the same idea from all of these: ● User learns work around or gets a bug fixed. ● Developer learns this is important to the user, teaches them and improves the product – text disappeared from Paint, and could not get it back – One said the sound was to low in general – Scratch doest close from Home (only from the "Quit" button) – Inserting photos from the Internet is not as simple – Distance was not not getting activated. We had to switched Mesh and try for a couple of times until they could connect.

8. Examples Developer wants proof of their great idea ● Developer wants to know if user will say: ” This new Journal GUI is the greatest thing since sliced bread” ● Can just build it and hope you are right. ● Better would be to get user buy in and a chance to improve the design based on user input ● First you need a relationship (see above). Then can choose qualified user who gives meaningful input ● You need to explain the feature in a way users can understand. A way that's meaningful to them. ● Nothing beats a prototype you can play with. ● Beware: users will almost always say: “that's looks great” even if they never plan to try it again.

9. Working with XO deployments ● There are two main types of people we interact with at deployments. ● Technical leads – Usually contact us for help when they are under deadline and have to get 10Ks of XOs in schools in a matter of weeks. ● Education people and teachers – Do not often contact technical lists. Come in slowly and haphazardly via user lists or blogs.

10. Working with XO deployments ● Technical leads – Urgent problems or questions needing a fix or workaround ASAP – Come in to OLPC tech support – Can request features for roadmap – Often do whatever they think they need without regard to intended design ● e.g. add RPMs or make other modifications to OS – Easier for us to talk to but need to be convinced that we can respond to their needs

11. Working with XO deployments ● Education people and teachers – General and less urgent questions – Interested in how to teach with the XO – Often have technical concerns (bugs) but not often able to explain the issue in a reproducible way – Need to work with their deployment technical leads ● e.g. in Uruguay cannot access root so can't always use suggested work arounds – Need polished, supportable and usable responses

12. Final word ● If Kim, Reuben or Greg S are asking for something specific, its often a short term critical need for a deployment. ● Suggestions and open discussion... or ● I can give a brief overview of the requirements I'm tracking at our top deployments... ● http://wiki.laptop.org/go/Feature_requests