On Sun, Jan 18, 2009 at 10:51 AM, Simon Schampijer <[email protected]> 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 <[email protected]> >> 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!) >>> [email protected] >>> http://lists.sugarlabs.org/listinfo/iaep >>> >> >> >> > > _______________________________________________ > Sugar-devel mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
