<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi, Martin<br>
<br>
Generally six years and older accept that it works that way. The
users I am referring to are not American children with years of
experience at six with a smartphone. I am talking about children
whose first and only experience with a computer is the XO.<br>
<br>
By switch I assumed you meant opening the frame and clicking on a
different activity. The alert is triggered by the user clicking on
the Stop button.<br>
<br>
I am not sure you have used Browse recently. A download has a
progress alert which remains visible until the user clicks on an OK.
It is not modal, but it also stays open until 'OK' is clicked. I
have seen users build a stack several deep without knowing it (the
progress alerts stack).<br>
<br>
I can't see how switching to the Journal to change the name is more
'optimal' than giving the user an easy way to name the project
directly. Naturally, this is a value judgement, your is different
from mine. Note: the 'screenshot' feature which has not received
this sort of dialog uses the same alert. It gives the user a chance
to name a screenshot without having to switch (by the frame) to the
Journal and then back to the activity. <br>
<br>
Any learner who creates a document certainly wants to save it with a
meaningful name and will certainly appreciate be given that
opportunity in such a simple and easy way.<br>
<br>
Tony<br>
<br>
<div class="moz-cite-prefix">On 07/12/2016 12:28 PM, Martin Dengler
wrote:<br>
</div>
<blockquote cite="mid:20160712102828.GB13111@ops-13.xades.com"
type="cite">On Tue, Jul 12, 2016 at 11:52:10AM +0200, Tony
Anderson wrote:
<br>
<blockquote type="cite">Regardless of the wording, the alert does
not save a document until the user gives it a name. If the user
does not care about the document enough to give it a name, there
is probably a reason. For example, if I were to launch Paint to
show selecting a color for a brush, I would have no reason to
save the scribble.
<br>
<br>
To repeat, we need to consider this from the viewpoint of the
user. The user click on the Stop button to quit the activity.
The alert should result in terminating the activity whether the
document is saved or not.
<br>
</blockquote>
<br>
I think the <br>
<blockquote type="cite">This logic is used in the 'fiddler'
implementation. It takes a moment to move the cursor to the
entry, type an entry, and click save.
<br>
</blockquote>
<br>
Have you watched a six year-old wonder why their activity isn't
closing fast
<br>
enough on an XO-1 (which doesn't even have the enforced stop of a
modal
<br>
dialog)? Have you watched a child look away when talking to their
friend, then
<br>
look back and not notice that a small part of the the screen
changed and just
<br>
notice that they pressed quit and it hasn't? Have you watched a
small child
<br>
read some text that appears when they didn't ask it to, and then
decide what to
<br>
do, then look down at the mouse pad, look back up, look back down
to move, look
<br>
back up, move, miss the target button, look back down, move the
mouse pointer
<br>
to the correct button, and press the mouse button? Have you
watched a small
<br>
child complete this multi-second reading-and-decision-required
task without
<br>
distraction when they have already decided they want to be doing
another Sugar
<br>
activity? This "getting in the way of users" has been done to the
death -- for
<br>
example, see
<a class="moz-txt-link-freetext" href="https://blogs.msdn.microsoft.com/oldnewthing/20030901-00/?p=42723">https://blogs.msdn.microsoft.com/oldnewthing/20030901-00/?p=42723</a>
<br>
-- and we have good bugs with good alternatives.
<br>
<br>
<blockquote type="cite">The children I have observed using Sugar
would for sure spend longer closing and switching between
activities without any benefit from this modal alert."
<br>
<br>
The alert only appears when the activity is closed not when
switching between activities.
<br>
</blockquote>
<br>
By "switching" I meant "closing one and opening another". It
would not appear
<br>
every time Sugar decides the journal object should be saved,
right?
<br>
<br>
<blockquote type="cite">The modal alert gives the user a chance to
give his project a title - I
<br>
consider that very beneficial.
<br>
</blockquote>
<br>
Titles are beneficial, for sure. Are they worth a modal dialog?
No.
<br>
<br>
How about this alternative: similar to how Browse notifies you
that a download
<br>
has completed, let the activity exit *without* a modal dialog, but
when the
<br>
activity closes and the sugar shell is in focus again, show the
user the "name
<br>
or delete or whatever your journal entry" dialog in a non-modal
way. That way,
<br>
users that are prone to notice and care and name their work can
divert from the
<br>
"quit this activity" process and name it, but users that don't
notice or don't
<br>
care will not be interrupted.
<br>
<br>
<blockquote type="cite">The alternative is for the user to open
the
<br>
activity palette and change the name there. The other
alternative is for the
<br>
user to switch to the Journal and change 'Write.activity' to
'Bolivar report'.
<br>
</blockquote>
<br>
The journal might even put the focus or highlight the latest entry
and suggest
<br>
"Rename 'Write.activity' to 'Bolivar report'?".
<br>
<br>
<blockquote type="cite">Currently [the modal
on-quit-ask-to-name-journal-entry dialog] is needed for
<br>
all activities
<br>
</blockquote>
<br>
That sounds suboptimal :(.
<br>
<br>
<blockquote type="cite">Tony
<br>
</blockquote>
<br>
Martin
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Sugar-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>