sugar start-up profiling

[Erik Garrison]

On Fri, Aug 01, 2008 at 10:41:41AM -0400, Eben Eliason wrote:
> On Fri, Aug 1, 2008 at 10:29 AM, Erik Garrison <erik at laptop.org> wrote:
> 
> > On Fri, Aug 01, 2008 at 10:19:50AM -0400, Eben Eliason wrote:
> > > Another potentially interesting solution is a pseudo-spring algorithm, by
> > > which we detect some numbers of neighbors (O(n)) and then we "push" those
> > > neighbors away with some force vector, the magnitude of which is weighted
> > > based on the size of the nodes, and the direction of which is calculated
> > as
> > > the angle between them.  This solution doesn't, in theory, yield results
> > > that are as good as the other options (since it pushes away at a fixed
> > > angle, instead of towards nearby positions with ow weights), but it
> > should
> > > be really quick.
> > >
> > > I'm sure there are other options, or combinations of these, that we could
> > > explore as well.
> > >
> >
> > Could we be positioning icons on the basis of prior usage patterns?  By
> > this I mean that icons are spring'ed toward the XO icon with a force
> > vector related to their recent usage patterns.  Additionally, activities
> > which are started at similar times could be spring'ed together.  I'm
> > envisioning a learning layout algorithm to distinguish the most-used
> > activites.  This layout necessitates the collection of usage data which
> > could also be shared with our developers.
> >
> 
> This is a good point, and I have to say "yes" and "no" at the same time.  I
> think your solution (I could be wrong!) is somewhat biased toward the
> particular case of the Home view, but this algo needs to work on the Groups
> and neighborhood views too.  Perhaps there are some (non-historical) ways to
> compare data in those views, but I'm not sure.
> 

I am thinking of a generalizable layout algorithm which can be invoked
on any set of icons with a list of weights.  The icons could be buddies
or access points.  We could weight them on the basis of the number of
(successful?) collaboration or connection events.  The same pattern
could be used for the group view.

> In any case, there is another variable I would like to propose, which is a
> suggested distance from the center of the screen -- or, if you'd like, a
> spring of a particular k value between the center of the screen and the
> object.  My particular use case is that of search.  I'd like to see a bunch
> of search results slide onto the screen (and non-results slide off), and I'd
> like it even more if the most relevant matches moved closest to the center.
>  This is essential for scalability in the Groups and Neighborhood views.

This is interesting and snazzy.  I should note that I was thinking of
static views.

> I could also see this working to bring frequently used activities to the
> center of the screen, and less frequently used ones to the edge (thought
> that interferes with free placement).  I also see it making for an intuitive
> activity search in the favorites view.  Even though only favorites are shown
> on screen by default, anytime a search is entered, the non-favorites (which,
> I propose, lay beyond the screen edges) which match can slide in, and
> non-matching favorites slide off, presenting this weighted view of matches.
> Clearing the entry, of course, returns the view to its natural state, with
> only favorites showing.

Seems like the inerference with free placement means that such a
placement algorithm is its own beast.  Not sure how you can easily
rectify 'user-directed placement' and 'usage-directed placement'.

Erik