<div dir="ltr"><br><div class="gmail_quote">On Fri, Aug 1, 2008 at 10:29 AM, Erik Garrison <span dir="ltr"><<a href="mailto:erik@laptop.org">erik@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Fri, Aug 01, 2008 at 10:19:50AM -0400, Eben Eliason wrote:<br>
> Another potentially interesting solution is a pseudo-spring algorithm, by<br>
> which we detect some numbers of neighbors (O(n)) and then we "push" those<br>
> neighbors away with some force vector, the magnitude of which is weighted<br>
> based on the size of the nodes, and the direction of which is calculated as<br>
> the angle between them.  This solution doesn't, in theory, yield results<br>
> that are as good as the other options (since it pushes away at a fixed<br>
> angle, instead of towards nearby positions with ow weights), but it should<br>
> be really quick.<br>
><br>
> I'm sure there are other options, or combinations of these, that we could<br>
> explore as well.<br>
><br>
<br>
</div>Could we be positioning icons on the basis of prior usage patterns?  By<br>
this I mean that icons are spring'ed toward the XO icon with a force<br>
vector related to their recent usage patterns.  Additionally, activities<br>
which are started at similar times could be spring'ed together.  I'm<br>
envisioning a learning layout algorithm to distinguish the most-used<br>
activites.  This layout necessitates the collection of usage data which<br>
could also be shared with our developers.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><div>- Eben</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
Erik<br>
</font></blockquote></div><br></div>