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

[Eben Eliason]

On Tue, Jun 30, 2009 at 8:20 AM, Aleksey Lim<alsroot at member.fsf.org> wrote:
> On Mon, Jun 29, 2009 at 08:59:30PM -0400, Eben Eliason wrote:
>> On Mon, Jun 29, 2009 at 8:14 PM, Edward Cherlin<echerlin at gmail.com> wrote:
>> > 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.
>
> A couple of related questions.
> How the process of "recording" these sessions/activities should look?

I think the standard procedure for creating an action is the usual
process of starting or resuming an activity, working with that
activity for some duration, and then stopping the activity again. This
series of steps will normally result in a single action. (Pressing
"keep" manually would introduce additional ones.) Most likely, the
Journal/DS would create an action and provide that to the activity to
add to as needed. Record, for instance, would periodically add new
image objects to that action. If it so desired, an activity could also
request a new action from the Journal.

> Should we treat current state of the shell like a current session and
> what would happen if we restore to this current state another session
> from Journal?

Less frequently, actions would be recorded by the shell for things
like making friends, copying/sending/receiving objects, etc. These
actions are basically just containers which reference the related
objects. Some, such as making friends, might not even reference an
object at all (though it might be nice to introduce people as objects
with entries in the Journal (like address book cards in the future).

I don't think the state of the shell as a whole is tied into these
types of actions. We might consider extending action-space to include
things like "backed up _your journal_ to school server." Here, I
suppose it could be possible to initiate some kind of restore
operation. Or, perhaps "deleted 12 objects" (where deletions within a
reasonable time span are aggregated). We could also have things like
"changed your colors from _this_ to _this" and "changed your preferred
language setting to _language_." But none of these are really
"resumable". Instead, they just convey a meaningful change of state.
We could think about ways to enable "undo" functionality from actions
like these, but that's a fundamentally different idea from resuming a
session.

Eben

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