[sugar] The futur of the mesh view

[Eben Eliason]

> - Friends will always be displayed in the mesh view when they are
> online.  Do we want to show: them, them and their current activity, them
> surrounded by all their activities, their current activity surrounded by
> everyone in that activity?

The Neighborhood view should have a consistent visual design, in which
activities have their participants clustered around them.  Friends
should be shown with their active activity, along with its other
participants.

> - Do we want any extra information for the friends screen, for example
> your friend surrounded by all of his activities?

This screen is less defined.  My current thought is that it should
really just be a filtered version of mesh view, obeying the same
grouping logic, but perhaps not including the "other participants."
That said, it seems that we could show all of their shared activities
(not private ones) in this view if we choose to move to a
representation different from the Neighborhood.

> - Users will be able to search for buddies (using search keys as color,
> alias, name, email, etc.). The result of this search will be displayed
> on the mesh view. Same question, what about their activities? Should we
> display them too?

Yes, the view should be the same (participants clustered around
activities) regardless of the search term or type.

> - Kids will also perform activity searches (using keys as name, type,
> color, maybe participants?). Here again, the result will appear on the
> mesh view. Do we plan to display buddies who are in these activities
> too?

Absolutely.

> - Which kind of search method will be proposed in the GUI? Should we
> support different options in our search protocol (as substring,
> equality, case insensitive,...)?

Case insensitive search is a must.  Substring matching is also a good
idea.  In general I feel that it's a good idea to make this implicit,
though that obviously results in more matches.  Of course, I suspect
we'll still need to perform a loose ranking and only return the best
results anyway, so that shouldn't be a problem.  In this model,
equality would simply be ranked higher.

In general, I think we'll use OR implicitly for search terms, though
again that results in more matches.  Maybe that's a bad idea;
thoughts? If it doesn't increase complexity too much, I'd be happy to
have transparent support for logical grouping and boolean operators as
well.  In a large pool of people and activities, explicit AND and NOT
operators would be really useful for more advanced users.

> How do we plan to distinguish a search for users from a search for
> activities? Should we show all matching activities and all matching
> buddies?

There are two types of input planned:  a search, and several filters.
The search field provides freeform input and should match on all
types: buddies, activities, and devices.  The filters will be
specifically for activities and buddies, individually.

We basically want to show everything that matches any of these.  What
would be nice to have is "simulated" support for metadata.  That is,
in the Journal we intend to allow searches for key:value pairs which
will return only entries which match on that particular metadata
field.  In the Neighborhood, we could support keys such as:  name,
email, group, activity, title, etc.  This would target the search and
limit the number of undesired matches.

- Eben