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

[Aleksey Lim]

On Tue, Jun 30, 2009 at 08:46:56AM -0400, Eben Eliason wrote:
> 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.
maybe we should keep action related maintenance only user driven
and do not let activities implicitly create new actions?

btw "action" and "activity" sounds similar
maybe using something like "record" or "session"?

erikos: and looks like these actions are the same that Dairy activity
should be

> > 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).
in my mind action like "making friends" goes rather to implementing undo
then to actions, I think its a good idea to keep actions only
DS-objects/activity-instances related to keep things consistent.

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

-- 
Aleksey