Make 'not resume by default' in Home, or make available a way to switch it

[HoboPrimate]

I prefer not to have in Home the icons resuming their last entry by default. It takes an extra step of opening its palette to start fresh instances, and even when I want to resume a past activity, I never really know if its the last I ran, so I also have to open its palette. I don't know if you agree with me, if not, you could bring back the option to change this behavior.

[garycmartin]

FWIW: Hold <Alt> and click a fav icon to start a fresh instance, no need to open the palette if you're an advanced user ;-)

[HoboPrimate]

In the sugar-devel list, the post titled "[Sugar-devel] UI thoughts from today's session at the GPA" says:

"Resume by default should happen if the activity is already open.
Start new should be the default if there is no instance of that activity already open. It was very confusing and distracting to have to clear out previous work, from 2 weeks ago, out of turtle art before they started on today's assignment."

[HoboPrimate]

ALthough that last sentence means that they didn't know about the secondary palette, where there is a "Start New" option.

[HoboPrimate]

Eben also agrees with me, in the Sugar mailing list he said:

"
Incidentally, one of my major complaints with the "resume by
default" behavior is that it makes starting new activities hard to do,
and virtually impossible to do without using a secondary action, which
is the wrong approach in my mind. I think starting from home, with the
option to resume, while encouraging one-click resume from the Journal
is still the correct approach. I think offering the option to enter
"resume by default" mode is great, but I'm not sure it should be,
itself, the default for Home view.

In practice, it seems it has worked too "well". It used to be that
kids never resumed activities. Now, it seems, they never start new
ones. The solution seems to be in encouraging use of the Journal and
the Home view for these different default actions, and in clarifying
the UI such that kids understand and desire to do so.
"

[garycmartin]

Mockup of possible home design feature revert, after some initial kids/teachers feedback.

[garycmartin]

Just attached a mockup of a home view palette showing what it could look like if we revert the resume by default feature/design. "Start new" becomes the new default click (and top palette item); Activity favourite icons are always shown in grey; Alt key no longer used as new/resume toggle as the resume case has N potential items and the affordance is to reveal the secondary palette so you can see all available titles and activity icon colours (sorry Tomeu). If we decide to do this, I guess one nagging question from me is if the change should be 'back ported' to 0.84-0.86. The home view for 0.84-0.86 was a considerable feature change from 0.82, if real deployments start using 0.84, it's going to be miserable to have this primary view change yet again for 0.88. I guess it depends on how many months it'll be before OLPC lockdown their next release, but this could be argued as a design regression needing patched (trusting that we are getting reliable/valid feedback on this point).

[eben]

This looks pretty good. The primary palette shouldn't have the "start new" label on it, though. The primary palette, when attached to an object (as opposed to a button) is meant to serve as an identifier of that object. This was true in the design for resuming recent, since the activity name and the instance name identified it. Here it just shows a generic action, and should be omitted.

I'm not sure why we'd need to remove the alt key behavior. The intention was to allow kids to choose their preferred mode, and then access the other mode temporarily by holding the alt key. If we change the default, and even if we don't allow a choice, that behavior could stay.

I won't hold my breath for menu grouping labels as in the original designs....some day...

[garycmartin]

Replying to eben:

This looks pretty good. The primary palette shouldn't have the "start new" label on it, though. The primary palette, when attached to an object (as opposed to a button) is meant to serve as an identifier of that object. This was true in the design for resuming recent, since the activity name and the instance name identified it. Here it just shows a generic action, and should be omitted.

OK, I'd missed that one, did think it looked a little woordy :-)

I'm not sure why we'd need to remove the alt key behavior. The intention was to allow kids to choose their preferred mode, and then access the other mode temporarily by holding the alt key. If we change the default, and even if we don't allow a choice, that behavior could stay.

I'd not stand in the way if the extra alt key behaviour code path was trivial, but even the latest 0.86 still has some minor key event behaviour anomalies so it seems to have been more difficult than anticipated. Was just looking for the simpler path given perhaps ~50% of my usage (non target demographic) of the home resume (i.e. some activities like Terminal, Log, IRC, etc that have weak or no Journal usage I single click resume the icon, for other activities with significant Journal state I use the full palette to choose a recent instance).

I won't hold my breath for menu grouping labels as in the original designs....some day...

Could you point to any mockups/descriptions of this design concept? Doesn't immediately ring any bells for me (but always fascinated by original design concepts).

[walter]

I think we need to catch our breath here. (1) How much evidence do we have that kids cannot find the secondary palette for starting a new instance? (In my observations, at least some of the problem is navigating the secondary menu--with a jumpy track pad--to get to the start new at the bottom of the list is the difficult part, so perhaps just moving start new to the top of the list is enough.) (2) As mentioned above, some activities almost certainly want resume as a default behavior: terminal, log, ruler, sliderule, etc. Others would at a minimum strike a balance between the two behaviors: write, turtle art, read, browse, etc. I can think of no activity that would want a fresh instance every time. (3) If we do go with the plan above, we need to consider how to make more facile access to the journal; except on the XO, which has a dedicated key, it is quite tedious to get to the journal for something as mundane as resume.

Regarding the proposed backport, how many schools made an upgrade from 0.82 to 0.84? I cannot think of any off hand. I think 0.84 will largely be skipped in favor of 0.86 or even 0.88.

[wadeb]

Good point Walter... This issue seems like it could be a cause for significant disagreement and angst. Perhaps a DP would be appropriate now that the procedure has been hashed out by the SLOBs?

It's less about finding the menu and more about understanding the concept of starting a new one versus resuming an old one. With the same icon doing both under different circumstances - first time versus all future times - it gets very confusing.

I personally feel that the best choice is to make the Journal more accessible, instead of bringing parts of its functionality (Resume) into the Home screen. Perhaps making the Journal more accessible should be the main focus of 0.88.

[tomeu]

I'm with Walter as well, if Sugar is something to be widely deployed and used, we should make UI changes thinking of a broad selection of deployments and users.