Frame Decision (was [sugar] OLPC priorities for Sugar in

[Greg Smith (gregmsmi)]

Hi All,

A few more comments:
- I read the new design more carefully:
http://wiki.laptop.org/go/Designs/Frame I see how important the frame
will become in the future! I left a bunch of questions and comments on
the talk page. My time will be severely constrained so don't spend a lot
of effort answering the questions unless you think they help you make a
decision.

- In build 656, everything in the frame is also on the keyboard or
within the activity. Be 100% clear if that is going to change. E.g. can
I do everything I need without the frame or do I need the frame? The
answer to that gives a lot of direction about when and how the frame is
available.

- Unless someone says otherwise assume the cursor control wont get a lot
better. Ask the lead on HW or mouse pad engineer if anything beyond
severe bugs will get fixed. Then pick a variance in pixels between where
user wants the cursor and where it will end up. Use that as working
assumption for design. You're lucky to develop for a single, specific HW
platform, take advantage of that.

- I believe the new design implies some changes in the whole application
centric vs. document centric vs. activity centric paradigms. Activity
focus is interesting but make sure the activity development is in synch.
The current data store <-> activity development challenge is an
important lesson about what it takes to change the user paradigm.

- Input from one user: My 8 year old son picked up the XO Saturday. I
saw him playing cartoon builder (btw kudos to MaMa Media, great apps!).
When the frame popped up I asked him "what is that and do you want to
keep it or should we get rid of it?" He immediately said "its where the
options are" and he said "I like it". I should have asked him "when does
it come up and what does it do?" :-( 

- Definitely must reduce the frame on/off time. Performance is a
consistent complaint (e.g. see: 
http://sextosdela37.blogspot.com/2008/04/analizando-el-uso-de-las-laptop
-en-el.html ). Sounds like Tomeu has a plan for that. If performance is
the same as now or still slow on accidental frame flap, that's a deal
breaker.

- If the frame pops via a key stroke, people may not find it. The GUI
will train the user, but if its not visible and no one tells you, people
will miss a whole set of functionality.

- Having lots of complex and confusing options is a pain. I hate to
waste time reading and thinking about the endless MS check boxes that
say "do not show me this dialog box in the future".

- If you aren't ready, give yourself more time. Pick a small pilot to
try the new design. To buy time, figure out the pressure to release now
(e.g. must fix bugs) then see if you can address only those and roll out
the rest later. There's cost to "forking" but it may be worth it. As the
carpenters say: measure twice, cut once.

- That said, usability discussions never end and everyone has an
opinion. Usability tests help but they aren't definitive. Get the input,
add your design sense, warn the customers and then call it closed until
the next round. 

- I need to learn more but as it stands I vote install default off, key
stroke enable, GUI option to change default, great documentation,
training and user outreach effort :-)

HTHs.

Thanks,

Greg S