<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi, Sam<br>
    <br>
    Perhaps we are converging on an understanding. i'll try again. <br>
    <br>
    My model of the alert is <br>
    <br>
    Choose a name for your project  [               ]   save quit<br>
    <br>
    If the user does not think the project is important enough to need a
    name, the user clicks on quit (and the document is not saved). If
    the document was important to the user, they will give it a name. <br>
    <br>
    I am not sure what you did, but if you created a document and then
    quit - it should not be in the Journal. However, the metadata object
    is there because that is the current Sugar requirement for a record
    of the use of the laptop. The intent is that, with a school server,
    the entry is saved on the school server to form a log and the local
    copy is deleted. <br>
    <br>
    One option is for the 'save as' feature to hide an object which does
    not have an associated document with a name suppled by the user. If
    it weren't for the desire to keep statistics, I would be very happy
    to have it deleted.<br>
    <br>
    I think this is getting repetitive, but let me repeat. The current
    'autosave' writes on the resume handle. This is wrong. The 'save as'
    feature creates a new jobject with a copy of the original's
    metadata. The autosave still works as before.<br>
    <br>
    Again to be repetitive. The user's action that triggered the alert
    was to click on the Stop button. This button terminates the
    activity. So the alert should offer two options save and quit. The
    first (with a title) saves and quits. The second just quits. (Keep
    in mind, I 'grew up' with punched cards). <br>
    <br>
    I really don't know what you are proposing by only using part.<br>
    <br>
    Tony<br>
    <br>
    <div class="moz-cite-prefix">On 07/12/2016 12:20 PM, Sam Parkinson
      wrote:<br>
    </div>
    <blockquote cite="mid:1468318804.2020.4@smtp.gmail.com" type="cite">
      <br>
      <br>
      On Tue, Jul 12, 2016 at 7:52 PM, Tony Anderson
      <a class="moz-txt-link-rfc2396E" href="mailto:tony_anderson@usa.net"><tony_anderson@usa.net></a> wrote:<br>
      <blockquote type="cite">
        <meta content="text/html; charset=utf-8"
          http-equiv="Content-Type">
        Hi, Sam<br>
        <br>
        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. </blockquote>
      <div><br>
      </div>
      <div>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!</div>
      <div><br>
      </div>
      <blockquote type="cite"><br>
        <br>
        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.</blockquote>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>This is because Sugar does autosave.  It is very intertwined
        with the way that the toolkit saves stuff.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>That is why we need 2 buttons "save" and "delete".  None of
        this fancy-worded "confirm" and "dismiss" stuff.</div>
      <br>
      <blockquote type="cite"><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.</blockquote>
      <div><br>
      </div>
      <div>Yes, of course.  I'm sorry for any miscommunication.</div>
      <br>
      <blockquote type="cite"><br>
        <br>
        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.</blockquote>
      <div><br>
      </div>
      <div>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?</div>
      <div><br>
      </div>
      <div>Delete makes it very obvious - the work the user just did
        will be deleted!</div>
      <br>
      <blockquote type="cite"><br>
        <br>
        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.<br>
        <br>
        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. <br>
        <br>
        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. 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'. </blockquote>
      <div><br>
      </div>
      <div>What we agreed upon so for, seems to be:</div>
      <div><br>
      </div>
      <div>* GOOD Prompt for title if the user presses Quit and has not
        changed the title from the default</div>
      <div><br>
      </div>
      <div>Can we just merge that and argue about the rest separately?
         I think that change will be great for users.</div>
      <div><br>
      </div>
      <div>Thanks,</div>
      <div>Sam</div>
      <br>
      <blockquote type="cite"><br>
        <br>
        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.</blockquote>
      <br>
      <blockquote type="cite"><br>
        <br>
        Tony<br>
        <br>
        <div class="moz-cite-prefix">On 07/12/2016 12:59 AM, Sam
          Parkinson wrote:<br>
        </div>
        <blockquote cite="mid:1468277995.2020.1@smtp.gmail.com"
          type="cite"> <br>
          <br>
          On Tue, Jul 12, 2016 at 8:37 AM, Martin Dengler <a
            moz-do-not-send="true" class="moz-txt-link-rfc2396E"
            href="mailto:martin@martindengler.com"><a class="moz-txt-link-rfc2396E" href="mailto:martin@martindengler.com"><martin@martindengler.com></a></a>
          wrote:<br>
          <blockquote type="cite">
            <div class="plaintext" style="white-space: pre-wrap;">On Mon, Jul 11, 2016 at 05:18:00PM +0200, Tony Anderson wrote:
<blockquote>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.
</blockquote>
This design decision of not forcing the user to name an activity has literally
been consciously made since the first deployment of Sugar:

<a moz-do-not-send="true" href="http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009151.html">http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009151.html</a>
<a moz-do-not-send="true" href="http://dev.laptop.org/ticket/3225">http://dev.laptop.org/ticket/3225</a>
<a moz-do-not-send="true" href="http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009157.html">http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009157.html</a>
("Sugar default naming scheme")
<a moz-do-not-send="true" href="http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009152.html">http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009152.html</a>

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.   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?</div>
          </blockquote>
          <div><br>
          </div>
          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.
          <div><br>
          </div>
          <div>I think that the current implementation of the "Choose a
            name" alert is fine.  It serves as a gentle reminder.</div>
          <div><br>
          </div>
          <div>Here are some of my questions about the design:</div>
          <div><br>
          </div>
          <div>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.</div>
          <div><br>
          </div>
          <div>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.</div>
          <div><br>
          </div>
          <div>Also, does the jobject get overwrite by the autosave
            functions in Sugar, regardless of the user's choice in the
            overwrite alert?</div>
          <div><br>
          </div>
          <div>Thanks,</div>
          <div>Sam</div>
          <div><br>
          </div>
          <div>
            <div>
              <div>
                <blockquote type="cite">
                  <div class="plaintext" style="white-space: pre-wrap;">

Martin

1. My interpretation of the hypothetical proposals in "Sugar Journal save
option" on <a moz-do-not-send="true" href="https://wiki.sugarlabs.org/go/Summer_of_Code/2016">https://wiki.sugarlabs.org/go/Summer_of_Code/2016</a> and the video on
the "Save As" patch at <a moz-do-not-send="true" href="https://www.youtube.com/watch?v=xcvBH7zzFBo">https://www.youtube.com/watch?v=xcvBH7zzFBo</a> .


<blockquote>
Tony

On 07/11/2016 04:56 PM, Martin Dengler wrote:
<blockquote>
On 11 Jul 2016, at 15:44, Dave Crossland <<a moz-do-not-send="true" href="mailto:dave@lab6.com">dave@lab6.com</a> <<a moz-do-not-send="true" href="mailto:dave@lab6.com">mailto:dave@lab6.com</a>>> wrote:

<blockquote>
On 11 July 2016 at 10:40, Tony Anderson <<a moz-do-not-send="true" href="mailto:tony_anderson@usa.net">tony_anderson@usa.net</a> <<a moz-do-not-send="true" href="mailto:tony_anderson@usa.net">mailto:tony_anderson@usa.net</a>>> 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.
</blockquote>
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
<a moz-do-not-send="true" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a>
<a moz-do-not-send="true" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</blockquote>
</blockquote>
<blockquote>_______________________________________________
Sugar-devel mailing list
<a moz-do-not-send="true" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a>
<a moz-do-not-send="true" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</blockquote></div>
                  <div class="plaintext" style="white-space: pre-wrap;">_______________________________________________
Sugar-devel mailing list
<a moz-do-not-send="true" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a>
<a moz-do-not-send="true" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</div>
                </blockquote>
              </div>
            </div>
          </div>
        </blockquote>
        <br>
      </blockquote>
      <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>