[sugar] notes from the field - Mongolia

[Erik Garrison]

On Tue, Oct 07, 2008 at 10:49:25AM -0400, Eben Eliason wrote:
> On Mon, Oct 6, 2008 at 6:17 PM,  <pgf at laptop.org> wrote:
> > mikus wrote:
> >  >   -  First off, every Activity has a 'Name Field' in its top menu.
> >  > When running any Activity, the user should enter there a short
> >  > "Title" to identify the resulting Journal entry from all others.
> >  >
> >  >   -  Then, upon leaving that Activity, the user should "reflect" on
> >  > what was done, and "update" the corresponding Journal entry to make
> >  > it easier to find later.  This is particularly desirable if the
> >  > "Title" is not meaningful enough by itself for later locating what
> >  > the user is looking for:
> >
> > in a traditional system, when a user saves their work, they are
> > pretty much forced to enter the (hopefully) useful name by which
> > that work will be retrieved.
> >
> > if searching is the fundamental retrieval mechanism (which i think
> > is fine), then my first reaction to mikus' advice is that
> > activities and/or sugar should be more emphatic about asking for
> > the descriptive information which be useful later.  i.e., adding
> > search tags shouldn't be an optional extra step, but a "usual"
> > step which must be explicitly skipped by the user.
> 
> Indeed.  I had brought this issue up in the past thinking it might
> happen for 8.2, but it's definitely on the plate for 9.1. I have a few
> ideas about how we can make this system better, and encourage names
> and tags, without becoming a hassle.  We also, down the road, have
> ideas about how to better expose the tagging system, and perhaps even
> make it fun, so that describing things becomes a natural part of the
> interface.  Kids learn to speak by describing things around them; we
> should be able to tap into this to both help them learn and make the
> Journal a useful and searchable space.
> 

I am concerned that focusing on such systems is breaking simple use
cases and causing problems for users in the field.  I believe that this
functionality is important, but do not agree that it should comprise the
base layer of data access on a real-world system.

Search is extremely powerful, but technically complicated to implement,
and equivalently complex to learn how to use.  Remember that almost all
of us involved in this discussion have been using search on the web for
at least the past decade, and while we now understand it as an intuitive
process I contend this is not the case for new users.  (I can remember,
but not locate, at least one study which noted that uninitated users
used search engines in extremely strange ways, for instance, running all
their search terms together because it mirrored the typical format of
DNS names.)

Fully qualified names (file names) are simple.  They are misused to the
extent that users give things strange or confusing names.  But, the
names are qualified and the users can encounter their work simply by
remembering most components of the name.  The concept is
straightforward: given this key I will always find the data I need, and
only that data.

Note that in prior art, notably the web and desktop systems, a layer of
fully qualified names for resources has always come long before, and
provided a base layer for search systems.  Despite the fact that links
can break, if resources are renamed, we have not yet replaced URLs with
search queries to search engines.  URLs are quite reliable in comparison
to the databases and algorithms required to drive search systems.

Erik