[IAEP] GPA Report - Feedback on using the Journal

[Gary C Martin]

Hi Caroline,

On 9 Oct 2009, at 02:42, Caroline Meeks wrote:

> Today we worked with two groups on multiplication. They made squares  
> with each side being a different multiplication problem that had the  
> same answer.
>
> http://screencast.com/t/sUbiof2H
>
> We also had them reflect in their Journals about what they did.
>
> All of this went well.
>
> What was horrible was trying to get the right point in the project  
> saved to the Journal and then navigating to the correct place to  
> write.

Sorry if this sounds a little terse, but it seems you decided to  
completely avoid using the "Stop" button at the end of each of your  
tasks:

1) Start a new Activity
2) Do stuff
3) Stop Activity
4) Name it
5) Goto 1

The "Keep" button, as currently implemented, will come back to haunt  
you when you return to work on those activities later (I've tried to  
explain this in all its gory detail in previous emails). None of the  
issues you mention above have yet hit the gory Keep versioning issues,  
so you'll have that joy to come when kids want to resume a couple of  
old kept activities for reference when working on a new one.

I'll be happy the day that the "Keep" button is removed, it's clearly  
causing you and others horrible confusion. I smiled the day I realised  
the new toolbar designs at least demoted that darn button to a second  
class UI component (i.e hidden in a secondary toolbar) :-) It would be  
better if it just died even if we have no better replacement. For the  
engineers reading, the "Keep" function actively prevents users from  
'manual merging' of their work, so as an intended method for exposing  
a versioning system, it is actually having the reverse effect.

> The solution I suggest is when you click the Keep button (Journal  
> Icon) from an activity that the Journal reflection dialog box appears.
>
> Here are the problems we had.
>
> 	• Hard to get to the Journal, no easy F# short cut.

There's been lot's of discussion (feature proposals, email threads,  
trac ticket comments) trying to find a free F# key that is not gong to  
conflict. F5 seemed a good candidate but is a poor choice for XO  
hardware. Likely we need a control panel that allows distros/ 
deployments to make their own choice and for the user then to have the  
ability to change if needed (perhaps the current frame CP module would  
be a place for changing Sugar shortcuts).

> 	• Hard to find the little arrow that gets you to where you can  
> write. Especially since if the Frame is active, which it has to be  
> to get to the Journal, the little bitty arrow you need to click is  
> covered.

There's a recent deployment (Mexico I think) ticket reporting this,  
I'm sure a design solution can be found. Note that you could direct  
kids to use the palette menu on the icon and select "View Details" as  
an alternative.

> 	• When students did their assigned task they were eager to go back  
> to exploring with Sugar and wrote over their work without it being  
> saved, or using the same name as the assigned activity.  This was  
> probably the worst outcome because then it was like they hadn't done  
> the assignment, they had nothing to show for their work and we'll  
> want to use it later for a portfolio.

Get them to "Stop" when complete, and then "Start new".

> 	• clicking the Activity Tab to write down the name is a PITA (this  
> one is fixed in .88 I think).

The 0.86 new toolbar design still requires you to click the Activity  
toolbar icon to show the title input box, but at least you're not then  
lost at that point (i.e. primary toolbar still visible and usable).

> 	• After they reflected they wanted to immediately go back to  
> exploring in TA and we had to stop them, make them change the name  
> again. They were very perplexed by this because they didn't know  
> what to name their new file because they hadn't done anything yet.

Get them to "Stop" when complete, and then "Start new"...

> 	• The word "Description" is not very friendly. I like "What did you  
> do?" Walter wants to expand it even further, I'm not sure about  
> that, its pretty challenging for the students to type so I'm not  
> sure we want more boxes.

No comment, I don't like this whole dialogue to be honest (it breaks  
my working flow and distracts me from whatever I'm trying to achieve),  
but I'm not a pedagogic type so don't feel I have a say in this  
design. I get the impression most (adults and kids) will just skip  
past this dialogue anyway give half a chance. There's been some noises  
to remove this dialogue completely, or at least let folks easily  
disable it from within Sugar.

> 	• Confusion between the Keep button and the samples and the  
> snapshot icons.

This is pretty much a TA design issue (and also that everyone still  
seems to be completely confused as what the "Keep" button actually  
does).

> 	• No feedback when you click Keep so there is a tendency to click  
> it repeatedly.

Yea, that's always bad.

> I usually try to stick with reporting my observations and not giving  
> specific usability advice but this time I really have an opinion. I  
> think it would be much much more useful to have the Keep button  
> popup the Journal Dialog box. That would let me reflect and also  
> rename if I want to.
>
> What are the downsides of this?


If we kill "Keep" and replace it with the actually useful "Keep a  
copy" function (i.e. no attempt at versioning), there would be merit  
in considering a naming dialogue; however I think we'll have confusion  
as the naming dialogue would now be for the new copy i.e. users would  
be asked to name and describe an activity before actually doing it;  
currently when you click "Stop" you are asked to name and describe the  
activity you have just done.

Regards,
--Gary

P.S. Pretend "Keep" is not there, 1) Start a new Activity, 2) Do  
stuff, 3) Stop Activity, 4) Name it, 5) Goto 1 ;-)