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

[Eben Eliason]

On Mon, Jun 29, 2009 at 8:14 PM, Edward Cherlin<echerlin at gmail.com> wrote:
> Oh, Michael, you're in trouble now. ^_^
>
> You risk reinventing the data-centric Ontology in an Object-Oriented
> Programming form. This is one of the worst sinks for time and mental
> energy that I know of. It saps the will, because soon users become
> obsessed with making the map match the territory, when in reality
> everybody wants to make different maps in different territories.
>
> Still, we have to do something along these lines. If we actually do it
> as OOP, not just in OOP, so that users can redefine the classes, we
> might get somewhere without turning our minds to stone. Maybe we can
> make it into a pattern language?
>
> On Mon, Jun 29, 2009 at 4: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
>
> I'm with you on actions, object containers and objects, but I don't
> know what the instance arrow is pointing to, nor what bundles and
> prototypes would be here. Is a prototype a structure for a particular
> kind of collection, such as a portfolio outline?

The bundle is a reference to the activity bundle used to create the
action. The distinction between instance and prototype here is blurry
to me, but the general idea is that we have something which represents
the "session continuation" which, when clicked, restores the session
by resuming object with the activity used to create it along with any
relevant metadata. This is basically the description of what we
*currently* do with activity icons in entries.

> I would be interested to see this applied to a few dozen common
> workflows, such as student portfolios, a business plan, a lesson plan,
> a textbook incorporating software models, a research report, a photo
> album with pictures extracted from different sessions by different
> people, or downloaded from somewhere, and so on. If we knew what
> workflows our teachers and students needed, we would have a better
> chance of designing something that met their needs.

We weren't trying, while designing this, to get too deep into lots
organizational models. Instead, we were trying to capture "sessions"
as actions which reference one or more objects, where a session, or an
action, is basically one continuous use of a given activity. In the
case of record, this might create several photos (separate objects),
which get grouped into the action. Most activities would have a 1-1
association with objects, but not all.

This also gives us a way to describe actions other than "working in an
activity." For instance, we might have an action for "copy _object_ to
_flash_", "sent _object_ to_person_", or "received _object_ from
_person_". Also, things like "became friends with _person_" and
"joined _group_" would be great to have. We could have "installed
_activity_" and "updated _activity_" actions. Etc.

Browse might reference any downloaded objects, in addition to it's
session "instance". We can give activities the freedom to use this as
they see fit.

As seen here (http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#01),
we might also distinguish between viewing and modifying objects. If I
read a document without making edits to it, we could say as much, and
that action would reference the same version of the same object as
another action.

>>   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.
>
> Is that an XO software 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.)
>
> The continuation for resuming, yes, with the prototype like a factory
> class, spawning instances as needed.
>
>> -----------------------
>>
>> Analyzing
>>
>>   http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#02
>
> Aha! The object-oriented view is just what Tomeu and I were talking
> about, but better. Except that the sample screens don't have a place

Actually, you're referencing the action view! The actions are listed,
and reference any number of associated objects.

> for tags. I vote for objects rather than actions, which I find to be
> too wordy and uninformative. I want titles of documents and other

Perhaps not, if you're in favor of the view you referenced!

> objects. Don't tell me how I made it, let me tell you what it's for,
> or about.
>
> I also want the object view so that I can apply any appropriate
> Activity to the object. I don't want it tied to the Activity used to
> create it. I should be able to write a program or a Web page in a text
> editor, and then run or open it. I should be able to save a PDF from

Yup. I think the point here is that the action view, by default,
restores the session/instance as it was, by default. This is similar
to the current behavior. However, it should be possible to act on
individual objects (represented within the actions, or in the separate
object view) with any activity of choice.

> any appropriate application, and then view or edit it in some other
> program. I should have an easy way to create graphic files, and then
> hand them over to some bundle structure as artwork for a program. And
> so on.
>
> OOP as Alan intended it.

Yes, we have a way to go to get things right. The clipboard is another
space that needs a lot of love in this area.

Eben


>> 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?]
>
> Click to expand?
>
>>   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
>>
>>   6) a star-shaped colored selector
>>
>>      [Eben -- is this used for favoriting or for acting on object-sets?]
>>
>>   7) a summary display, which, for images, displays the image object and its title
>>
>>   8) some sort of arrow-labeled button
>>
>>      [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 ___"?
>>
>>       Also, could you think about giving it a different icon from the "resume"
>>       icon?]
>>
>>
>>> 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)
>>
>> 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)?
>>
>> 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.
>>
>> (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.]
>>
>>> - 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?
>>
>>> - Perhaps a Tag toolbar filter palette (could be a mini tag cloud)
>>
>> 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
>>
>
>
>
> --
> Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
> And Children are my nation.
> The Cosmos is my dwelling place, The Truth my destination.
> http://earthtreasury.org/worknet (Edward Mokurai Cherlin)
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>