[IAEP] 2 design proposals: home view, discoverable shortcuts

Eben Eliason eben.eliason at gmail.com
Sun Mar 22 18:37:31 EDT 2009


On Sun, Mar 22, 2009 at 6:06 PM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jameson Quinn wrote:
>> Proposal 1: home view: "Filtered ring w/ side panels"
>>
>> http://wiki.sugarlabs.org/go/User:Homunq/activity_ring_filters_and_sidepanes
>
> I'm glad that you're thinking about tagging.  For all of our talk about
> tags, we have yet to implement anything like a usable tagging system, and
> without it we have essentially no organizational tools at all.  It should
> be a high priority.  However,...
>
> I don't like this design, though it does force me to think.  Opinions
> about design are always mostly intuitive, so it's hard to justify any
> particular opinion. However, let me try a few suggestions:
>
> 1.  Is this really necessary?  The tagging system's purpose is for
> categorizing all Journal entries, as a student easily generates thousands
> of entries.  However, the total number of Activities in existence is
> relatively small (there are what, maybe about 50 that actually run in a
> given build?).  Are we anywhere near the point where students have so many
> Activities installed that the favorite/star system is insufficient?  Does
> such a point even exist?

Good question.  I tend to think the design proposed is
overcomplicating tagging quite a bit, but I also think that activity
tags should be an important part of the system.  I've long advocated a
system for providing a list of default tags in activity.info, which
could be used for default filter sets.

Additionally, it's good that your design matches the intent for the
search field, in that any number of tags could be provided as a filter
on the set of activities shown in Home.  I think that's a solid goal,
though I don't think you should have to add a "tag:" syntax for this
purpose.  Every search should search tags by default.  The "key:"
searches should be used to search within specific metadata keys
instead.

We tried a number of designs in the past using these "trays" of
various kinds, an none seemed very successful, in part because they
compete with the frame.  It also seems to confuse a screen which
should be as simple as possible: click to launch an activity, and
perhaps search to filter if necessary.

> 2.  I find these filters confusing, and I think users would do.  "Star"
> makes sense; it filters the Activity bundles themselves.  "Recent" and
> "Mine" seem to be filters not on the bundles, but on other Journal
> entries.  I think placing them on the Home View, where the only items
> shown are Activities, is tremendously confusing.  Those filters should
> live in the Journal.

Agreed.  I'm not even sure we need a notion of "favorites", myself.  I
think, instead, that organic tagging would produce natural groupings
of activities (eg games, science, programming, etc), and we should
strive for that.  This also lets developers such as MaMaMedia or
GCompris group their activities under these tags.  It also lets
educators create clusters of activities for specific classes or
projects, etc.

> The purpose of the Home view is to allow users to launch new, empty
> Activity instances in a convenient way.  Are you proposing a change in the
> purpose of the Home view, and if so, why is your proposal better than
> simply replacing the home view with the Journal?

I agree. I think that the primary interface for tagging should be
built into the Journal, which definitely needs a rich interface for
this anyway.

> 3.  Selecting filters by dragging them is unnecessary.  A click should
> suffice.
>
> 4.  There is no provision for filtering by multiple tags, without which
> tagging is a very weak organizational system.

Agreed. I think the search field should provide this functionality,
though.  It should be possible to narrow the result list simply by
adding tags to the field.  Additionally, what's really needed is
tag-completion within the search field, as well as a robust tag popup
while searching, which suggests related tags (common tags for items
which match the current filter).  This should be used in the Home view
(all views, really), the Journal, and for naming/tagging activities
for the first time.  That consistency and ubiquity would be a big win.

To sum up:

I think that a properly implemented search field, default activity
tags in activity.info, and a tag auto-completion palette (which would
be used throughout the UI) is necessary, and perhaps sufficient, to
make Home and activity grouping functional.

- Eben


> 5.  The distinction between "Start tagless" and "Start with current tag"
> seems unnecessary and confusing.  Assigning or removing a tag should be a
> trivial operation.
>
> 6.  The "Leftovers panel" does not seem to add any value.  Instead, we can
> simply grow or shrink the number of items shown on the home view itself,
> changing the ring into a sunflower, or eventually even a grid with scrollbars.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAknGtmoACgkQUJT6e6HFtqQo3QCgg2FLeVBpRPD5eZniEOUoKGjV
> fv0AnRreB2pLCgjNU/BmuRghHiljPvGs
> =g5nL
> -----END PGP SIGNATURE-----
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>


More information about the IAEP mailing list