[Sugar-devel] [DESIGN] Re: PR comments on 'Save as

Gonzalo Odiard godiard at gmail.com
Mon Jul 11 20:11:50 EDT 2016

A few years ago, Sugar used to open a dialog to set the name, description,
etc when the activity was closed.
(The dialog was similar to the detail view in the journal)
A lot of users complained about this dialog.
The purpose of the dialog was stimulate the reflection, but the result that
the dialog
interrupted the user when wanted to do something else.

Then we added the feature Write_to_journal_anytime[1] [2]
and removed the dialog when the activity was closed.

Now the users can start a new instance or a previous instance of the
from the journal or from the Home, but is true that duplicate (or Save as)
is difficult to find, because is only in the Journal.

In my humble opinion, ask the user the options as is proposed is not a good
If I would implement a "Save as"  feature, I would just add a "Duplicate"
to the activity toolbar. Yes, the two will have the same name, but then you
can change
the name in the usual way.

Maybe you can set a empty name by default, and ask a name to the user if is

Anyway these changes would be tested in real users. Is too easy make
but no so easy find a good solution for a big group of users.


[1] https://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime
[2] https://wiki.sugarlabs.org/go/File:Write_to_Journal_Text_View.png

On Mon, Jul 11, 2016 at 7:59 PM, Sam Parkinson <sam.parkinson3 at gmail.com>

> On Tue, Jul 12, 2016 at 8:37 AM, Martin Dengler <martin at martindengler.com>
> wrote:
> On Mon, Jul 11, 2016 at 05:18:00PM +0200, Tony Anderson wrote:
> Hi Martin, It seems to be nostalgia week. The goal is to have the user
> supply a name. Whether the text says untitled, Write.activity, execrable,
> or is left blank. The user will not be able to save until a title is
> supplied. There would be literally no 'untitled' or 'Write.activity'
> documents in the Journal.
> This design decision of not forcing the user to name an activity has
> literally been consciously made since the first deployment of Sugar:
> http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009151.html
> http://dev.laptop.org/ticket/3225
> http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009157.html
> ("Sugar default naming scheme")
> http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009152.html
> The has many nuances, so I don't want to be the penut gallery too much, but
> it seems to me that forcing kids to name activity instances upon closing[1]
> would seriously change (for the worse, IMO) the Sugar user experience. The
> children I have observed using Sugar would for sure spend longer closing
> and switching between activities without any benefit from this modal alert.
> Is it only going to be some activities, like Write, that require (or
> default to) this? Are you sure you want to undo/change these very old
> design decisions?
> I agree with you.  I believe that there is a lot of value in reminding the
> user to set a name - showing the alert as the current patch does.  But I
> don't think that we should force the user to set a name - they will only
> set a bad name, and they will feel like Sugar is working against them.
> I think that the current implementation of the "Choose a name" alert is
> fine.  It serves as a gentle reminder.
> Here are some of my questions about the design:
> I would also propose that the "cancel" button in the "choose a name" alert
> change to being a "delete" button.  (This was my original understadngin of
> the project).  Having a delete button there helps reduce journal clutter by
> making it easy to delete the object if it is un-needed.  For example, if I
> made a write activity to take a note, and then decide that I don't want to
> keep it, I can just click "delete" instead of setting a title.
> What is the purpose of the "overwrite" alert?  I thought that the
> overwhelmingly most common use case would just be saving (or
> "overwriting").  Does overwrite seem a little scary?  It did to me.
> Also, does the jobject get overwrite by the autosave functions in Sugar,
> regardless of the user's choice in the overwrite alert?
> Thanks,
> Sam
> Martin 1. My interpretation of the hypothetical proposals in "Sugar
> Journal save option" on https://wiki.sugarlabs.org/go/Summer_of_Code/2016
> and the video on the "Save As" patch at
> https://www.youtube.com/watch?v=xcvBH7zzFBo .
> Tony On 07/11/2016 04:56 PM, Martin Dengler wrote:
> On 11 Jul 2016, at 15:44, Dave Crossland <dave at lab6.com <
> mailto:dave at lab6.com <dave at lab6.com>>> wrote:
> On 11 July 2016 at 10:40, Tony Anderson <tony_anderson at usa.net <
> mailto:tony_anderson at usa.net <tony_anderson at usa.net>>> wrote: I prefer
> 'Untitled' as it supports the intent of the alert - to request the user to
> supply a title. I also prefer Untitled, although I'm curious to hear why
> "xxx Activity" would be better.
> Actually, 500 "Untitled"s are so much worse than 5 sets of 100
> "Foo.activity", because (in my limited experience) kids who can read know
> that "Speak activity" is different than "Write activity". There are
> literally over a hundred emails about this design decision years back - it
> was not done lightly. I didn't even participate and I was exhausted by the
> debate. Martin _______________________________________________ Sugar-devel
> mailing list Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> _______________________________________________ Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> _______________________________________________ Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

[image: photo]
*Gonzalo Odiard*
Lider de proyecto
tel.: 4210-7748 | www.trinom.io    Av Calchaqui 4936ยท 2do Piso. Quilmes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160711/e31d44e5/attachment-0001.html>

More information about the Sugar-devel mailing list