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

[Edward Cherlin]

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?

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.

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

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