Opened 12 years ago

Closed 6 years ago

#1382 closed defect (obsolete)

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

Reported by: HoboPrimate Owned by: eben
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: design Version: Git as of bugdate
Severity: Unspecified Keywords:
Cc: Eben, tomeu Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

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.

Attachments (1)

home_mockup_with_start_new_as_default.png (23.5 KB) - added by garycmartin 12 years ago.
Mockup of possible home design feature revert, after some initial kids/teachers feedback.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 12 years ago by 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 ;-)

comment:2 Changed 12 years ago by 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."

comment:3 Changed 12 years ago by HoboPrimate

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

comment:4 Changed 12 years ago by HoboPrimate

  • Component changed from sugar to design
  • Owner changed from tomeu to eben

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.
"

Changed 12 years ago by garycmartin

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

comment:5 Changed 12 years ago by garycmartin

  • Cc tomeu added

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).

comment:6 follow-up: Changed 12 years ago by 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...

comment:7 in reply to: ↑ 6 Changed 12 years ago by 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).

comment:8 Changed 12 years ago by 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.

comment:9 Changed 12 years ago by 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.

comment:10 Changed 12 years ago by 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.

comment:11 Changed 6 years ago by godiard

  • Resolution set to obsolete
  • Status changed from new to closed

Press Alt + click open a new instaance.

Note: See TracTickets for help on using tickets.