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

[Tony Anderson]

Hi Martin

Certainly we can move on and consider how the design of Sugar can be 
improved.

The keep button was valuable, but was somehow 'deprecated' as modern 
jargon has it. It had the function of saving the working document while 
allowing the user to continue working. Apparently, the designers thought 
this should be done automatically, so a button was not needed.

'Save as' is used to allow the user to open a document and then give it 
a new name (or in most systems, a location). The keep button, to my 
recollection, never had the ability to change the title since that could 
be done at any time in the 'activity' entry. This entry subsequently 
moved down to the activity palette.
In the current sugar-web-activities it is only a label. So the 'save as' 
alert is certainly needed for sugar-web-activities but is beyond the 
current scope.

In general design discussions should depend heavily on input from users. 
The stop button was restored when the mistake of subordinating it was 
recognized.
However, the problem with the frame popping out when the XO-1 user moves 
the cursor to the stop button has seems never to have been recognized.
The alert requiring a description was also removed after user complaint. 
This feature stopped the user for a description of a project entitled 
'Write.activity' when it could have been used to get a user-supplied title.

My recollection is that this decision was based on a sense that the 
Journal was under-utilized. I wish more attention had been paid to 
exploring the problem before implementing a solution. At one of the 
Uruguay summits, the developers decided on a Journal hackathon and 
repaired to a separate room. This was remarkable because there were many 
users of Sugar at the Summit available to discuss the Journal and give 
feedback on its use, provide suggestions for improvements, and give 
opinions on the changes the developers planned to hack on.

There may have been discussion about the change to resume from the Home 
View. I don't remember it, the feature just appeared. It violated one of 
the first principles of design: compatibility - the new mode was made 
the default instead of a user-selectable option. I have been in several 
classrooms where the teacher asked the students to open Browse only to 
have several laptops start playing one of the locally-stored tunes they 
were listening to before class.

The original concept that resume was done from the Journal and new 
starts from the Home View was simple and logical. The activities are 
tools which support user creation. Items in the Journal are instances of 
using a tool. Calling them 'Write.activity' is misleading at best. The 
item is not a Write.activity, it is a document created by the 
Write.activity which should have a meaningful and relevant title. 
Opening from the Home View is using the tool for a new project, resuming 
an activity is just that, resuming work on an on-going project. This 
difficulty in distinguishing the object from an instance is also seen in 
object-oriented programming.

If you look at the current Journal, it puts significant information in a 
'details' screen. This is accessed from a small arrow at the far right 
of the line. This would be much more useful and used if the button were 
to the left of the item title where users are looking.

Originally, the Journal worked by clicking on the item icon to launch 
the associated activity. Today, moving the cursor to the icon pops up a 
complicated menu.  The timing is such that you have to be very careful 
and quick to select an option before the menu disappears. If the cursor 
moves off the black for a millisecond, you have to start over.

A simple and common alternative, of course, is to open this menu by 
toggling the right-click button. This would, of course, return the 
user's click on the icon to launch the activity. Hover is great for 
tooltips. However, I have never seen a reasoned explanation of why Sugar 
doesn't want to use right-click.

My eyes are getting old, along with the rest of me. However, the XO 
colors in the Home view prevent me from recognizing icons because of the 
poor contrast in some of the color combinations.  I generally first 
press alt to eliminate the colors to find the activity I am looking for. 
While a clever trick with svg, I have never seen a discussion of the 
learning benefit of this feature. I believe it is considered as a 
identifying feature of Sugar like the Home View; however, this only 
applies to the XO.

Tony

On 07/12/2016 12:10 AM, Martin Dengler wrote:
> On Mon, Jul 11, 2016 at 11:10:13AM -0400, Dave Crossland wrote:
>> On 11 July 2016 at 10:56, Martin Dengler <martin at martindengler.com> 
>> wrote:
>>> On 11 Jul 2016, at 15:44, Dave Crossland <dave at lab6.com> wrote:
>>>> On 11 July 2016 at 10:40, Tony Anderson <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".
>
> Hopefully this point is clear.
>
>>> 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.
>>>
>>
>> I'm totally confused :) I thought this has only been discussed since 
>> June,
>> for this year's GSOC?
>
> I don't want to derial the GSOC projec.  If people are aware of all the
> previous discussions and designs about save as / keep, sorry for the 
> noise.  It
> didn't sound like that to me.  Keep and something akin to "save as" 
> has been
> thought about and designed in to Sugar since [the original Human 
> Interface
> Guide](http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience/The_Journal): 
>
> the principles deprecating "save" and "save as" replaced it with 
> "Keep", the
> "keep button", or the idea of "keeping".  I will be flamed for suggesting
> "Keep" is the same as "save as", but it's darn close.  Some design 
> documents
> and discussions, including the ones with the original sugar designers 
> about
> *removing* "Keep" and/or "Keep As" buttons, include:
>
> http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Laptop_Experience/The_Journal#The_Notion_of_.22Keeping.22 
>
> http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023401.html
> http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023404.html
> http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023406.html
> http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023441.html
> http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023439.html
> http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023480.html
> http://lists.sugarlabs.org/archive/sugar-devel/2010-September/026474.html
> http://lists.sugarlabs.org/archive/sugar-devel/2011-May/031316.html
> http://lists.sugarlabs.org/archive/sugar-devel/2011-July/032438.html
> http://lists.sugarlabs.org/archive/sugar-devel/2011-July/032486.html
>
> etc.
>
> Martin