Talk:Designs/Activity Management

Hierarchical Launcher Ring

Why is 'hierarchical presentation' being shunned? To me, there exists the problem of "real estate" (i.e., room on the display). The presentation ought to allow for 400 (not just 40) activities. [And no, to me the current design of 'trays' does not cut it.]

My suggestion: expand on the "pie slice" metaphor. Allow either 'Tab' icons or 'Activity' icons in the inner circle. When the cursor hovers (or clicks) on a Tab, an "outer semi-circle" is shown adjacent to the Tab -- it is this "outer semi-circle" that now shows 'Activity' icons displaced by that Tab from the inner circle. [If need be, more levels can be added to the hierarchy by putting Tabs in the "outer semi-circle", etc.]

I myself would not normally use TamTam Activities - yet their icons take up on-screen real estate (both in the old and in the new presentations). What I am proposing is letting me move TamTam icons from the inner circle and putting in their place a 'Tab', which "expands outward" into the icons I've moved. [A child, to whom TamTam Activities are important, would have left those 'Activity' icons in the inner circle.] --Mikus 18:08, 28 February 2008

The big difference in the new approach, designed to minimize if not eliminate this problem, is the juxtaposition of the radial (ring) and list views. The list view is "infinitely" scalable, and shows all activities installed on the laptop. Items in the list view can be starred as favorites, and only the favorites appear within the activity ring. If you're not into TamTam, then you could un-star it within the list, reserving the ring for the things you do most. Do you think this approach offers enough flexibility? -Eben

In the new approach, judicious use of starring could achieve much of my aim of uncluttering the process of launching an application.

The problem with the current (came with G1G1) activity list is that it treats all activities as equally important. [To separate out my favorites, I've re-ordered (i.e., prioritized) the list.] I suspect that even in the new approach (where favorites can be starred) I will want to re-order the list view to in effect "put into a lower hierarchy" those activities I consider of low priority (to keep their entries from cluttering up that part of the list that I visit frequently).

Journal, a core of Sugar Shell, not an activity

I'd like to raise the question of whether the Journal should really be using an 'activity' metaphor (and implementation). This came up in a #sugar irc meeting earlier this week. Right now, and in the new designs, the Journal feels split between two worlds, that of a core intrinsic sugar feature (which it is), and that of just another regular activity. I'd like to suggest that it be presented and implemented as part of the new shell, for both efficiency and usability, as a peer of the Neighbourhood/Friends/Home/Activity zoom views. It's not just another activity to be switched to, it's a another XO view. See below mock-up for a rough idea of presentation. --garycmartin 00:32, 29 February 2008

This is a nice presentation of the idea, and you point out some merits, such as the mapping to the keyboard layout. My two main uncertainties regarding this design are as follows:

1 I think that the Journal is perhaps the most personal aspect of the laptops, and as such I feel that it should retain the book-like Journal icon, and also that it needs to retain its colors, as it goes hand in hand with the identity of the XO. -Eben

I do like the reporters note book icon from an aesthetic point of view, but the existing keyboard glyph for journal searching is already a reality and harder to change to get HCI consistency (always felt Journal key should have been as one with the existing 'zoom' view keys), but playing devils advocate here, if the colours give identity/ownership to local XO entities, perhaps the four zoom frame icons should also be in the users personal colours of choice? This is my neighbourhood, these are my groups, my home and my current activity (though you could be sharing someone else's instance so it's colours could could be from them) --garycmartin

2 The four zoom levels (we may start referring to these as "spheres", to clarify some terminology) are very closely tied to a spatial metaphor which goes from "tight" to "wide" from right to left. The Journal, as the most private part of the interface, really belongs as a member of the "nearest" sphere: Activity. -Eben

The journal has always given me the feeling of the most distant/wide view of the XO, obviously not with a particular spacial mapping as it contains more abstract meta information - showing you items you've downloaded, past activity states, and the users you shared them with. --garycmartin

Example mock-up of what the Journal could look like as part of the core sugar shell UI rather than as a 'special' activity hanger on. The Journal Search icon matches the XO keyboard layout, icon style, and colouring of the other zoom views. The Journal is another core XO view and should not be confused with the activity metaphor --garycmartin 01:28, 29 February 2008.

Home view like Quartz Composer

I hope this is not terribly off-topic, since it isn't about activity management but is about the home view. Some time ago I had a crazy idea of the Home view being a sort of workspace. I explained the idea at Vision_for_a_numeracy_activity under "Comments would be most welcome". It was with surprise that I found out that there is an programming environment in MacOSX that works like that, Quartz Composer. I think the idea of having the activity icons in the home view have inputs/outputs/variables would allow for very clever mixes of multiple activities, and because of it, decrease code and feature duplication (for instance, even if there wasn't a system-wise speech feature, you could plug-in Speak with Chat, for blind kids. Or if there ever exists a "Trainable language AI" activity, you could also plug it into a Chat to make a bot. Kids could come up with other solutions which aren't solved by just one activity, but are solved when programmatically using them together).HoboPrimate 22:25, 16 March 2008 (EDT)

Activity title on The Frame

Why not bring back the original concept of having the activity title on the Frame? This would reduce the need to switch tabs to act on such an important action, naming the activities. The Activity toolbar then could be seen as a more advanced area. There would be plenty of space for the other activity icons in the frame as well (and even if they overflow, there could appear a scroll button), and since the active activity will always be on the left, the activity title text box can stay fixed next to it. HoboPrimate 22:59, 16 March 2008 (EDT) P.S.-This would also reinforce that buddies on the Frame are related to the active activity.HoboPrimate 23:20, 16 March 2008 (EDT)

Prompting for a title

We've been discussing the possibility of removing the activity toolbar from activities, instead attaching related functionality to the palette for the activity, including the ability to name/tag. We're also trying to decide the best (and least obtrusive) way to prompt for a title when none exists. The two basic options are as follows:

1. Prompt using a non-modal alert immediately after a new activity instance is created. The important thing to note here is that this would only occur the very first time an activity is started from scratch (never when resuming or joining). The non-modal alert would include a text entry with focus, so that simply typing a title and pressing enter would give the activity instance a name. If the user doesn't care to title it, they can ignore the alert which will time out, or begin interacting with the rest of the activity to dismiss it. This approach has the advantage of ensuring that shared activities on the mesh are likely to have titles which help describe them, and of course entries in the Journal will also have meaningful titles. The disadvantage is that someone might not have an idea what they intend to title something before they work on it, though they could of course ignore it in these instances and name it manually later.

2. Prompt using a modal alert when stopping an activity instance that has not yet been titled. Taking this approach, the alert needs to be modal to confirm a name before writing an entry to the Journal. Here again, the alert will only appear if the activity was started as a new instance, and if the activity hasn't since been given a non-default title. This has the advantage of making the process of diving right into the activity immediate, without needing to think about titles/tags. The disadvantages, of course, are that it slows down the process of stopping an activity by requiring a modal alert, and it doesn't encourage kids to title activities before they are shared on the mesh, yielding a lot of "Write Activity"s without meaningful titles.

We feel strongly that we need one of these two approaches (or a variation thereof) in the not too distant future. Comments on their pros and cons would be appreciated. -Eben

I prefer the 2nd option. The major reason is that Titling anything you do is usually very hard. Let alone before you start creating it. Asking for a name at this point, in the beginning of a fresh activity, will be bothersome and rarely will a kid have a concrete name in mind. The problem of having activities in the neighborhood with default names will be taken care of by kids. I think once they see that telling their friends to join the "Write Activity" isn't very helpful when there are 3 of them, they will be quick to start naming them. So it is most important that naming the activity is easy and up-front, hence my suggestion of having the title visible on the side of the activity icon on the frame.

As far as slowing down the stopping action, I agree. In fact, I would even remove any idea of requesting from the user to name their activities, be it at the beginning or end, and try best to make that feature be visible.

Slightly off-topic, but the only reason I can imagine some dialog to appear when stopping a fresh unnamed activity, is to ask if the user wants to delete it or not (to keep it or not). I asked you on IRC about it, and you said you didn't get a good reception for the idea. I suggest then to keep it on the back of your mind, and see what the feedback from school kids say. Do they have to regularly "clean" the clutter of their Journals? Either way, if some decision is made about the possibility of not keeping unnammed fresh activities in the journal, it shouldn't be done automatically or invisible, otherwise the user will never be assured of what is kept and what isn't. HoboPrimate 03:22, 27 March 2008 (EDT)

Which instance ?

Given that the guideline for activities is to have just one screen, I currently often start more than one instance of an activity (to be able to open new work without having to close the previous work). Today when I click on an activity icon, that starts a new instance.

There has been discussion in trac that a child should *not* accidentally start a new instance of an activity, for example when he had left an activity to go to the Neighborhood view, but was coming back via the Home view. To that end, it has been proposed that if (now in the new circle) an activity icon is clicked, but that activity is already "running", what should be done is to resume the current instance. [ Will the new 'Activity Management' let him do that, or does he need to use Frame (or F4)? ]

[Note that the example screenshots give a drop-down 'Resume' list of instances of this activity as they appear in the Journal. What if the child was too lazy to uniquely label each use of this activity -- the list would unhelpfully show multiple instances with the same Title.]

I presume that in the drop-down menu the section labeled 'Start' means "start brand new". Changing the section label to 'Start new' might make things more clear.

Should "non-launchable" Activities appear in list ?

Now that there is a Joyride available which implements much of this design, I noticed that the "list view" showed installed Activities such as 'Read', which in my understanding do *not* have an "input location field" that the user can fill. Given that launching such an activity will not be helpful to the user (it just sits there without doing anything), is any purpose served by including such an Activity in the "list view" ? [Or are there future plans, which would make use of the 'Activity Management' screens to delete/update the currently installed Activities ?]