[sugar] Journal: two quick suggestions

[Eben Eliason]

On Thu, Feb 28, 2008 at 3:11 PM, Edward Cherlin <echerlin at gmail.com> wrote:

> On Thu, Feb 28, 2008 at 11:41 AM, Eben Eliason <eben.eliason at gmail.com>
> wrote:
> >
> > > while toying around with the Journal today I had two ideas about the
> > > "anything" and "anytime" filter functions:
> > >
> >
> > Both interesting ideas...
> >
> > > "anything": Apart from offering activities and file-types as
> > > filter-options I'm thinking that it might make sense to also offer an
> > > option for different subjects that kids will have at school. So things
> > > like "Maths", "English", whatever... My thought is that many
> activities
> > > will be started and resumed in a certain class-context and offering
> > > such a filter could help them to quickly find related matters.
> >
> > One of our fears here is the proliferation of options within this menu,
> > which could eventually limit its usefulness, and is the reason we chose
> to
> > limit to some "primitive" types and the installed activities.
>
> A common way to address this problem is to make the menu customizable
> with user-defined filters and the ability to remove unneeded filters
> (but keep the option to restore them later). Google mail is an
> example, where users can create their own tags and set filters to
> apply them automatically.


Indeed.  The implied hypothetical at the end of my response alluded to the
fact the almost anything is possible, assuming you add additional
UI/management tools, but we're trying to find a balance between
functionality and management overhead. I'm using Gmail to write this, and
their system does work pretty well, but naturally has an entire screen
dedicated to both creating labels and assigning filters.

We've also discussed the possibility of adding "saved searches" or the like
(there are 15 names for this basic idea...) in the future, but there is a
lot of basic functionality left to add before we add this form of
meta-functionality.  Perhaps the "What" list is the appropriate place for
these saved filters to live, eventually.  Thanks for offering that idea.

- Eben

The usual alternative is folders, as in Moodle.
>
> > One can
> > imagine that the "subject" of an activity is actually subjectively
> defined,
> > and even when it's relatively clear, we might wind up with some for each
> of
> > "math", "geometry", "trigonometry", "algebra", etc.
> >
> > To make a similar functionality available, though, we've chosen to allow
> > developers to supply a list of tags within the .info file for any given
> > activities, which could include several subject related words, as well
> as
> > more abstract or general terms like "game", "simulation", or "language".
>  We
> > hope that the ability to search by broad terms such as "math" or "games"
> > will then turn up a list of appropriately related activities.
> >
> > Having just typed this and then reviewing the wiki, I notice that this
> part
> > of the spec doesn't appear to be there yet!  Can those familiar with
> this
> > respond about the presence or absence of this capability?  If this isn't
> > there, it should get a ticket.  It should be a pretty straightforward
> > addition and simple to implement, it seems.
> >
> >
> > > "anytime": Here it might make sense to add more informal filters such
> > > as "5 grado", "2nd semester" or something along these lines.
> >
> > This one is actually much harder to do in a general way.  We chose, on
> > purpose, to treat time in the relative sense with respect to the
> Journal.
> > Instead of seeing a story you wrote on November 28, 2007 you might find
> a
> > story you wrote "3 months ago".  This approach was chosen, in a sense,
> to
> > internationalize (or perhaps simply generalize) the Journal with respect
> to
> > time, so that school systems with widely different schedules (some might
> > have class daily for one of every 3 months, for instance) can all take
> > advantage of it.
> >
> >
> > > Of course one could also argue that such information could be
> > > explicitly added via the tags but I think a more implicit mechanism
> > > could potentially make more sense.
> >
> > You can see how, in the former case, the tag model is still implicit, in
> a
> > sense, when installing an activity.  In the latter case, I don't see any
> > good way other than explicit tagging that doesn't have additional UI
> > overhead/management to function.  I'm open to ideas here.
> >
> > Thanks for your feedback!
> >
> > - Eben
> >
> >
> > _______________________________________________
> >  Sugar mailing list
> >  Sugar at lists.laptop.org
> >  http://lists.laptop.org/listinfo/sugar
> >
> >
>
>
>
> --
> Edward Cherlin
> End Poverty at a Profit by teaching children business
> http://www.EarthTreasury.org/
> "The best way to predict the future is to invent it."--Alan Kay
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080228/fd20dae1/attachment.html>