[Sugar-devel] Journal feature request--more data in main display

[Eben Eliason]

On Mon, Jun 29, 2009 at 7:32 PM, Michael Stone<michael at laptop.org> wrote:
>
> Gary C. Martin wrote:
>
>> I like the intent, but I don't think the "activity centric" view has
>> concrete enough spec to consider implementing yet.
>
> I want to convince you that we actually have enough detail to make forward
> progress with.
>
> To that end, I'm going to offer a bunch of text on how I think this display is
> supposed to work.
>
> You should go through it to identify
>
>   a) things that don't make sense
>   b) things that are disputed or where I'm obviously wrong
>   c) things that are insufficiently specified
>
> and we should try to fix those.
>
> Then we'll be ready to do another round of discussion and prototyping.
>
> Regards,
>
> Michael
>
> ---------------------------------------
>
> The best picture I've ever extracted from people on this subject looks like
> this:
>
>   Mental Picture of the Experience of Recording Butterflies
>
>
>                          *         - action
>                         / \
>           instance -   /   \
>                     \ /     \
>              *--/ /--*-------*       - object container
>             /    |         //\\\
>         bundle   |        / | \\\
>                  /       /  | | \\
>         prototype       /   | | | \
>                        *    * * *  *    - objects
>
>
>   This diagram represents the action of recording a roll of 10 photos of
>   butterflies in an instance of a recording activity derived from a specified
>   bundle.
>
>   Key points:
>
>     * I can paint on a photo but not on a record instance.
>
>     * On the other hand, I can use the instance to
>
>         a) resume recording butterflies or
>
>         b) to locate an activity prototype suitable for beginning a new
>            recording action on a different theme.
>
>       (The instance functions a bit like a UI continuation.)
>
> -----------------------
>
> Analyzing
>
>   http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#02
>
> we see that
>
>   * Each top-level entry in the display depicts an "action".
>
>   * Each top-level entry can be zoomed in or out (i.e. "contracted" or
>     "expanded", but as part of a large-scale zoom metaphor).
>
> When contracted, each entry displays a horizontal summary of the action
> containing:
>
>   1) the past tense of a verb
>   2) an "action resume display", consisting of
>
>        a) an initiator-colored activity icon,
>        b) a bold label with the action title, and
>        c) a resume button
>
>   3) an optional iconic summary of the actions's participants,
>
>         [Eben -- how do we abbreviate this summary if there were lots of
>          participants?]

We show 3 "key" participants (these could be the first 3, or perhaps
the 3 who participated the most, for some definition of "most"), and
show the total number of participants as a little badge following them
(as shown here:
http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#03). Hovering
over the number badge would reveal a palette listing all participants.

>
>   4) and a mandatory "freshness" indicator.
>
>   [In Scott's journal2 work, we'd also have a tag cloud.]
>
> When expanded, we vertically concatenate the "brief summary" display described
> above with a second "details view" that is inadequately fleshed out.
>
> In the single example suggested by Eben, this details view appears to consist of:
>
>   5) a grid of cells, each containing

Notably, this is a slightly simplified version of the proposed grid
view of objects. Compare:
http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#03
http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#10

>   6) a star-shaped colored selector
>
>      [Eben -- is this used for favoriting or for acting on object-sets?]

The star is for marking items as favorites.

>   7) a summary display, which, for images, displays the image object and its title

The intent here was to always show whatever the "preview" for that
object might be. If there is no preview, we'd show a framed
representation of the icon instead.

>   8) some sort of arrow-labeled button

This is the "details" button. One of these exists for each object, and
reveals the details page for that object. From the details page it
would be possible to edit, describe, tag, and act on the object.

>      [Eben -- I imagine that each of these buttons is supposed to represent
>       some sort of "act on ____ with ____" button with both holes filled in,
>       per our prevoius discussion:
>
>       http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2#.22Act_on_____with____.22
>
>       Perhaps you could flesh this out a bit, but explaining the interaction
>       design you imagine for multi-object cross-action "act on ___ with ___"?

Perhaps the "open" button should always reveal a list of compatible
activities so that you can always "act on ___ with ___." Then,
resuming an activity would always happen only when clicking on the
action (resume as usual), or on the object icon itself (open with
default activity). THoughts>

>       Also, could you think about giving it a different icon from the "resume"
>       icon?]

Yes, that would definitely be a reasonable idea to explore.


>> The still raises lot's of questions, what happens when you resume some
>> image you painted from way back to take a quick look?
>
> We need to be more specific.
>
> You can either
>
>   1) resume the /action/ containing that image, or you can
>
>   2) incorporate the image into a new action, (i.e. acting on the image with
>      some selected activity+mode)

As I see it, resuming that image IS the action. Every "session" with a
given activity represents a new action in the history of all actions.
Those two actions happen to reference the same object, though more
specifically, they reference different versions of the same object.

> You tell Sugar that you want case (1) by clicking the resume button [or the
> activity icon?] in the "activity resume display" that I described above.
>
> Eben hasn't spelled it out, but I imagine that you indicate case (2) by one of:
>
>   a) selecting the object and clicking the "add new entry" button in the
>      Journal, which presumably prompts you, at some point, for an activity+mode
>      with which to act on your objects
>
>   b) copy-pasting a set of selected objects into a running instance or into a
>      selected action
>
>   c) dragging a set of selected objects object into an action or an instance
>      icon
>
>   d) selecting an activity+mode as a "current tool" [think of Photoshop] with
>      which to process a sequence of objects that you're about to indicate
>
> [By "activity+mode", I'm referring to issues like "do you want this activity to
> display the object, a summary of the object, the object's source code, its own
> self-test results, etc."]
>
>> Where does it now show in activity centric view? Does it get removed from its
>> old block positioning and to some new active block; perhaps it get multi-
>> linked so now appears twice (you can still find it in the original old
>> place and also find it in new place)?

Yes, in a sense, the idea was to expose versioning directly in the
actions view, where you can follow your history of actions
chronologically. Looking back in time would show earlier actions,
referencing earlier versions of objects. The object view, on the other
hand, would provide a "collapsed" view with each object "history"
represented only once. Going into the details view for any object
would allow one to see other versions.

We could also explore expand/collapse controls in object view for
revealing versions...

> The question of the proper versioning and ownership semantics of the links
> between these icons and the underlying objects is a hard question which we have
> all agreed to ignore in favor of making some progress on other problems.
>
> For the time being, I think that everyone would be happy with if the icons in
> the display were treated as simple hardlinks.

Yes, that works.

> (In other words, the object goes away when you delete all its links and any
> modification to the object is immediately visible in all the actions containing
> that object.)
>
> [I believe we agreed that there should be a "fork" action on objects which
> copies its subject into a new history-stream, but good luck finding further
> documentation.]

If I recall, we discussed a "Keep a copy" action which would have this
basic effect.

>> - Better Anything toolbar filter palette (use a grid layout to
>> minimise scrolling)
>
> How do you think
>
>   http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars
>
> would work out here?

I'm not sure if the toolbars would actually help much in this
particular instance. I can definitely see tossing the textual popup
menus in favor of a single icon, which when clicked revealed a palette
listing all possible icons in a grid. (We'd probably still want names
adjacent the icons, though.) We could do similarly nice things with
the date, offering a calendar, or a timeline. We've always wanted
something more visual there anyway.

>> - Perhaps a Tag toolbar filter palette (could be a mini tag cloud)

That's a possibility. In the short term, it might be enough to hook up
some auto-completion to suggest popular tags. Having a contextual tag
cloud that shows common tags among the items matching the current
search would also be nice. It doesn't have to be a cloud, per se. This
can just be a list so that the control is easy to manage by pressing
up/down in the list to select suggestions.

I'm really excited about exposing tagging more readily in the UI,
though we'll have to do it with care so it doesn't feel cluttered or
overwhelming.

Eben

> What do you think of Scott's journal2 design here?
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>