[IAEP] GPA Report - Feedback on using the Journal

Wade Brainerd wadetb at gmail.com
Fri Oct 9 10:14:24 EDT 2009


Hi Gary,

I for one agree with everything you say here!!

On Fri, Oct 9, 2009 at 9:38 AM, Gary C Martin <gary at garycmartin.com> wrote:

> 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.
>

I don't quite get 'manual merging', but I agree that the Keep and Stop
buttons have serious issues.  The first is of course the complete lack of
user feedback for Keep.  The second is that its icon and description make it
more inviting than the Stop button.

The word "Stop" and the cross-cultural "Stop sign" icon seems like a warning
to me; i.e. "Stop, you're doing something wrong!"  Caroline's intuition that
Keep is being used instead of Stop reinforces this.

My design instincts say that what we should really have is a single
[Finished] button.  Its icon would looks roughly similar to the current Keep
icon.

When [Finished] is clicked, if the activity has not been named, it will
bring up the Naming dialog with Walter's "What did you make?" and [Keep] and
[Discard] buttons.  If the activity has been named, no dialog appears and
you return to the Journal.

> 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).
>

My option, stated before, is that the Journal should not be an activity; it
should be another view of the Home screen.

Since the Home screen defaults to resuming Journal entries, the Home screen
has already become specialized view of the Journal.

Proposal: replace the Activity list view button at the top of the Home
screen with a button that changes to the Journal list view (the Activity
list view can be removed, per Unified Bundles feature).  We would also need
a way to create new activity instances from the Journal list view.

Sugar would remember which way you booted up last time.  So new users will
prefer the Home view, experienced users can boot straight into the Journal
list view.

>       • 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"...
>

I was worried about this; the way the home view resumes by default is
confusing the difference between an "Activity" and an "Activity instance".

My full critique of this is here:
http://wiki.laptop.org/go/User:Wade/Ideas/Activity_Management.

>       • 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.
>

It breaks my workflow too, although a Discard button would make it better.
 And I like the concept of forcing people to name their work; as a
developer, I'm just usually testing something instead of "creating work".

Best,
Wade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20091009/7bd0ac79/attachment-0001.htm 


More information about the IAEP mailing list