journal is hard (was Re: notes from the field - Mongolia)
eben.eliason at gmail.com
Fri Oct 10 13:24:08 EDT 2008
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
> 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
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.
More information about the Devel