[IAEP] [Sugar-devel] feature freeze issue #2: making easier for people to title their activities

[Eben Eliason]

On Sun, Jan 18, 2009 at 10:51 AM, Simon Schampijer <simon at schampijer.de> wrote:
> Walter Bender wrote:
>> Looks good. I am hoping that the description field will start to see
>> more use, as I leverage it directly ion the Portfolio tool.
>
> pushed to git now.
>
> One
>> comment: I don't see the option to not save the entry.
>
> Tomeu and myself decided that the 'don't keep' button does not make
> sense in the dialog. The argument was, that the entry is saved already.
> And don't keep would mean that the entry needed to be erased. With the
> added 'resume by default', we don't have the proliferation of useless
> entries we used to have.
>
> Happy to keep on arguig about it.

Honestly, I think we'll make a lot of people happier by offering this
option.  Additionally, the argument that the entry is saved already is
strictly false in an experiential way (technical details and/or
current implementation aside): The whole intent of this dialog is that
it only appears when a given entry has /never/ been saved before. That
is a) this entry was not resumed, b) this entry hasn't been manually
kept, and c) this entry has not yet been named.

This might mean that the creation of a Journal entry at the time an
activity starts is a poor idea, since it doesn't reflect the desired
paradigm.  Of course, this issue has been confused in the past because
it differs for "action" and "object" views.  With the action/object
split, we wouldn't create an object until a keep operation happened,
though we would clearly have taken an action by starting an activity,
regardless of whether or not we keep it.

Finally, I want to convey again that the preferred model of the
save/keep action includes the notion of tagged keeps.  In this manner,
an activity can be started (new), the activity can make any number of
untagged keeps (autosaves) which the Journal (well, DS) silently keeps
track of.  Tagged keeps occur only when a) an activity is stopped (and
kept), and b) when the keep button is explicitly pressed.  The Journal
exposes tagged keeps as versions (or separate entries, if we don't
have versions?), and can also promote an untagged entry to a tagged
one after an unexpected crash of either the activity or Sugar, so work
is not lost.  This model treats untagged keeps as hidden, so to the
user, the entry has not yet been kept/saved when the first-time
instance is stopped.

> Another
>> comment: maybe we should have a feature where by tags are also
>> suggested, either by the activity or by tags previously assigned.

Yes, absolutely.  This is a really important aspect of this dialog,
but one we may need to wait on to get right.  I'd like to offer a
separate field of tag suggestions below the tag field.  This, really,
requires a tokenized field (tags treated like buttons), so that one
may simply click on the tags that apply to add them to the tags for
the entry.  We should be intelligently suggesting tags that the child
has already used in the past, and perhaps also exposing some API so
the activity can suggest tags as well.

- Eben

>> -walter
>
> Yeah, those tags could be generated based on content. In write or browse
> this looks like a quite logic thing to do.
>
> Thanks,
>    Simon
>
>> On Sat, Jan 17, 2009 at 4:29 PM, Simon Schampijer <simon at schampijer.de> wrote:
>>> Tomeu Vizoso wrote:
>>>> Hi all,
>>>>
>>>> yesterday we entered in feature freeze, meaning that no new features
>>>> can be committed without prior discussion in the community.
>>>>
>>>> The journal's search and browsing capabilities are less useful if all
>>>> entries are named the same regardless of their actual content or
>>>> meaning to the user.
>>>>
>>>> That's why has been proposed to make easier to the users to title and
>>>> tag their entries by showing a dialog when they close their activity
>>>> for the first time.
>>>>
>>>> We have now a quite crude implementation in, but is quite
>>>> disconcerting to users because it's not very clear why is that
>>>> appearing now.
>>>>
>>>> Simon is working on several enhancements that will make it clearer
>>>> (Simon, can you paste a link to a screenshot?).
>>> http://dev.sugarlabs.org/ticket/215 contains patch and screenshot.
>>>
>>> Cheers,
>>>    Simon
>>> _______________________________________________
>>> IAEP -- It's An Education Project (not a laptop project!)
>>> IAEP at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/iaep
>>>
>>
>>
>>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>