<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi, Martin 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. 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. 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). 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. 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. Tony <div class="moz-cite-prefix">On 07/12/2016 12:28 PM, Martin Dengler wrote: </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: <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. 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. </blockquote> I think the <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. </blockquote> Have you watched a six year-old wonder why their activity isn't closing fast enough on an XO-1 (which doesn't even have the enforced stop of a modal dialog)? Have you watched a child look away when talking to their friend, then look back and not notice that a small part of the the screen changed and just notice that they pressed quit and it hasn't? Have you watched a small child read some text that appears when they didn't ask it to, and then decide what to do, then look down at the mouse pad, look back up, look back down to move, look back up, move, miss the target button, look back down, move the mouse pointer to the correct button, and press the mouse button? Have you watched a small child complete this multi-second reading-and-decision-required task without distraction when they have already decided they want to be doing another Sugar activity? This "getting in the way of users" has been done to the death -- for 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> -- and we have good bugs with good alternatives. <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." The alert only appears when the activity is closed not when switching between activities. </blockquote> By "switching" I meant "closing one and opening another". It would not appear every time Sugar decides the journal object should be saved, right? <blockquote type="cite">The modal alert gives the user a chance to give his project a title - I consider that very beneficial. </blockquote> Titles are beneficial, for sure. Are they worth a modal dialog? No. How about this alternative: similar to how Browse notifies you that a download has completed, let the activity exit *without* a modal dialog, but when the activity closes and the sugar shell is in focus again, show the user the "name or delete or whatever your journal entry" dialog in a non-modal way. That way, users that are prone to notice and care and name their work can divert from the "quit this activity" process and name it, but users that don't notice or don't care will not be interrupted. <blockquote type="cite">The alternative is for the user to open the activity palette and change the name there. The other alternative is for the user to switch to the Journal and change 'Write.activity' to 'Bolivar report'. </blockquote> The journal might even put the focus or highlight the latest entry and suggest "Rename 'Write.activity' to 'Bolivar report'?". <blockquote type="cite">Currently [the modal on-quit-ask-to-name-journal-entry dialog] is needed for all activities </blockquote> That sounds suboptimal :(. <blockquote type="cite">Tony </blockquote> Martin <fieldset class="mimeAttachmentHeader"></fieldset> <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> </body> </html>