[sugar] journal is hard

[Yamandu Ploskonka]

This part of the thread is convincing me more and more of the great 
value of semi-transparent metatags.
I.e., the kid has no need to see in _his_ machine his own name, but 
everyone else needs it when looking at his file.

Part of our problem might be precisely our need to get out of our 
standard view of "filenames".  From the 'old world' view of them, a 
filename is biunivocal with a file.  Now, thanks to the Journal 
revolution, we might be able to see "descriptors" or 
whatever-y'all-wanna-call'em, that refer to the file/data instead of 
just being written-in-stone filenames.  Those 'descriptors' or 'file 
names' can be a dynamic thing, showing up differently as related to 
contents.

I agree autocompletion of titles is not _the_ way, but autocompletion of 
metatags definitelly would help a lot.

<future>
It would be way groovy that teacher would see an intelligent 'bag' of 
'files' in his desktop that all correspond to one given project, the 
'bag' filling up with files that get pulled from kid's computers as they 
arrive to class, easy to see, sort, already organized, or even better, 
that pick up the work as it is being done in real time even at home. 
With a simple change of 'view' (a button) he sees another form of sets: 
each individual kid's projects.

Yes, I am not going to code /that/ yet :-)
</future>


Eben Eliason wrote:
> On Fri, Oct 10, 2008 at 1:05 PM, NoiseEHC <NoiseEHC at freemail.hu> wrote:
>   
>>> We can do a little better than that, actually, by making it all one
>>> prompt.  It can have a name field, already filled out with the best
>>> darn attempt at a name we can manage, a tag field (and perhaps even a
>>> list of popular tags as well, to apply to it with a click or a
>>> drag/drop), and buttons for [Erase] (Or [Don't Keep]?) and [Keep].
>>>
>>>       
>> A little better solution would be if the words in the name would be treated
>> as tags and if the save "dialog" would offer autocomplete for those tags.
>>     
>
> I think tag autocompletion is a definite must, to get this system off
> the ground.
>
>   
>> Tagging via the Journal could just set words to "super" tags so they would
>> not be shown in the name but would be handled "harder" than "soft" tags in
>> searching or in the proposed tag submenu thing. If the user would type in
>> the tag via autocompletion then it should be treated as an explicit tag.
>>     
>
> I don't have a clear image in my head from this description, but I do
> see the direction you're heading, and it's interesting.  I'm not sure
> exactly how the titles are handled right now, but the idea of
> auto-completing within the title field, in some form, might have
> promise.
>
> An interesting twist on this might be to look for "related" Journal
> entries based on the title typed thus far, in order to provide a list
> of most likely tags to choose from for the entry (tags which are also
> applied to other things with similar titles, mime-types, etc.).  In
> this manner, once a base set of tags were in use in the Journal,
> tagging could become as simple as saying "yes, these three things you
> suggest actually do apply to this thing I made", and then optionally
> "and maybe this one other new tag, too".  In a sense, this means that
> tagging is almost free, since the process of creating a good title
> will provide a solid set of tags to choose from.  Tagging becomes an
> extension of naming, rather than a separate task.
>
>   
>> I am not sure if you can understand it so here is another try from the
>> opposite side:
>>
>> The problem with tagging is that it is painful to select something on the XO
>> from a drop down menu (the list of available tags). (Note that developing
>>     
>
> Right, this is why I think intelligent filtering of the list of
> suggested tags is also needed.
>
>   
>> Sugar on a Linux PC is cheating...) The whole notion of explicit tagging is
>> also a nuisance and requiring tagging at save time is painful. So this
>> proposal just tries to simplify the process from the user's perspective (and
>> makes coding the Journal very very hard, but since somebody other than me
>> will code it I do not care...). Autocompleting, not only tags but "soft"
>> tags too, would result in that if the user is doing some project lately then
>> the system would offer him the project's name since probably it would be
>> used lately a lot. Also it could be used for filesystem paths as well but
>> probably I should see that GNOME UI Hackfest video first.
>>     
>
> Hmm, I'm not sure that autocompletion on full titles is beneficial
> (that might not be what you're suggesting) because we want to
> discourage identical names, rather than encourage them.  On the other
> hand, offering completion of words within the title based on tags is
> interesting.  Would these "soft tags" (tags auto-completed in the
> title) also appear in the tag field?  How would we make the system
> evident?  Maybe it's still most clear if the title just serves as a
> seed for the recommended tags (some of which might be verbatim in the
> title) so that a few clicks can apply all those relevant.
>
> - Eben
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
>