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

[Sam Parkinson]

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>> wrote:
>>> 
>>>> 
>>>> On 11 July 2016 at 10:40, Tony Anderson <tony_anderson at usa.net 
>>>> <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160712/41e1d1cb/attachment.html>