[Sugar-devel] [DESIGN] Re: PR comments on 'Save as
sam.parkinson3 at gmail.com
Tue Jul 12 06:20:04 EDT 2016
On Tue, Jul 12, 2016 at 7:52 PM, Tony Anderson <tony_anderson at usa.net>
> Hi, Sam
> Who are we to judge whether a user's name is good or bad? Suppose the
> user just decides to name his project a, b, c and so on. That is the
> user's decision and so be it.
Tony, you need to think from a user perspective. Think of a user who
didn't give the activity a title on their own, then just pressed "save"
when they were prompted to give the object a title. When the computer
then tells them that no, "Write activity" or "untitled" is not a good
enough title, the are probably not going to be happy. The type of user
who doesn't change the title when you prompt them once are probably
rushed and will not give it a meaningful title anyway!
> 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.
No, you need to do more testing. I emptied my journal and created a
new bibliography activity. When I quit the bibliography activity, the
"save/quit" alert comes up. I click quit, and the bibliography object
is still in my journal. Journal clutter was just created.
This is because Sugar does autosave. It is very intertwined with the
way that the toolkit saves stuff.
Now, don't say that "we should just remove the autosave". I don't
actually care that *sometimes* autosave means that *some* extraordinary
unfocused user didn't go the the journal and use the well named
"duplicate" function, and instead overwrote something.
Let me tell you what happens on a school when the software doesn't
autosave. I go to a school that up until recently used Microsoft
Office. Microsoft Office doesn't autosave - and classmates lost their
documents. My school now uses google docs, and I haven't herd 1
complaint about "i meant to duplicate something but I actually
overwrote it". Hell, Google Docs does autosave by default - so
evidently Google thinks it happens for adults too.
That is why we need 2 buttons "save" and "delete". None of this
fancy-worded "confirm" and "dismiss" stuff.
> 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.
Yes, of course. I'm sorry for any miscommunication.
> I believe the alert should offer two options: save and quit.
> Overwrite, delete, discard and so forth refer to the deveoper's
> perspective of what action is taken.
Delete is not the developers perspective. Many users grow up with
things like Google Docs, etc, where autosave is the default. In a
world of autosave, what does "quit" mean?
Delete makes it very obvious - the work the user just did will be
> Again, the jobject is overwritten by Sugar - a defect. This feature
> creates a 'clone' of the original jobject and so is able to save it
> or not at quit time.
> 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. Users
> will understand the value of this by using the Journal.
> 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. The modal alert gives the user a chance to give
> his project a title - I consider that very beneficial. 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'.
What we agreed upon so for, seems to be:
* GOOD Prompt for title if the user presses Quit and has not changed
the title from the default
Can we just merge that and argue about the rest separately? I think
that change will be great for users.
> Currently it is needed for all activities, because we are using the
> 'document' saving as a catch-all. I have seen activities whose
> 'write_file' writes a dummy file to satisfy the 'best practice' that
> all activities must have a write_file. Activities such as Memorize or
> Read, and Browse should save state information in the metadata which
> would allow them to be resumed. These activities do not save a
> meaningful document. Memorize is clear, it saves state. Read is
> clear, it does not alter the source e-book and only saves bookmark
> information - state. Browse saves the urls for open tabs - again
> state information.
> On 07/12/2016 12:59 AM, Sam Parkinson wrote:
>> 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:
>>> ("Sugar default naming scheme")
>>> 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 would
>>> seriously change (for the worse, IMO) the Sugar user experience.
>>> 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?
>>> 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 .
>>>> 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 -
>>>>>> 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
>>>>> 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.
>>>>> Sugar-devel mailing list
>>>>> Sugar-devel at lists.sugarlabs.org
>>>> Sugar-devel mailing list
>>>> Sugar-devel at lists.sugarlabs.org
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel