Re: [sugar] The limits of Mesh View
1) I don't understand how larger collaboration groups would increase scalability. I would think it's the other way around: larger circles - larger radius of unoccupied space - less icons Surprisingly, that's not quite the case. The groups provide organization, which makes visual parsing much easier. Moreover, the XOs within a given group can be drawn quite closely together, so a fair number of them can be packed into a fairly compact area. Check out the visual mockups linked below. In our early designs, we actually used a clustering algorithm (which is why the code is named snowflakelayout) instead of a simple ring. This, naturally, keeps things even more compact (that's πrr to our benefit). However, even the ring alone makes the view substantially easier to parse, visually, thus allowing mode overall XOs. It's really the space between icons that's so precious. http://wiki.laptop.org/go/Image:Neighborhood.jpg http://wiki.laptop.org/go/Designs/Frame#18 For reference, I think the first link above has about 35 icons on it, and the latter about 45. The clusters in the upper right of each contain 16, so you see that if you had nothing but clusters of 15 or so people, you could easily display 90 or so XOs and their (6 or so) activities, inching close to the 100 mark (which is where I topped out my previous estimate). ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] The limits of Mesh View
On Sat, Apr 19, 2008 at 1:18 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Polychronis Ypodimatopoulos wrote: | A full screen of icons would not be | legible either, but was I just trying to explore the limits. That's not exactly the limit. Although the current designs don't call for it, it would be easy enough to allow the mesh view to expand past the edge of the screen, once the number of icons gets too large to show them all. GTK has widgets designed for precisely this sort of infinite canvas. People with whom you've communicated more recently, or people who are geographically nearer to you, might migrate toward the center. Yes, this is precisely the type of scalability solution I alluded to before when I spoke of making the full neighborhood accessible via search. Effectively, we'd like to think of the screen area as a viewport into the broader neighborhood, which happens to contain a clustering of people and activities most relevant tot he user. Determining the heuristic for what's relevant needn't by very complex, thought it could be, and will likely begin with friends, recent collaborators, your favorite activities, etc. Naturally, the search and filter controls will serve as temporary adjustments to the relevance of the objects on the mesh, and so the view will change in response to them. The main reason we didn't jump directly to this model is because we'd very much like to emphasize the notion of the window, and of the neighborhood as a larger continuous space, by sliding the XOs, activities, and devices around the screen. This would also work well when illustrating XOs moving about the various activities on screen, but also serves as a way to slide negative matches radially outward, and positive matches inward, so as to always keep a relevant set of icons on screen at any time. - Eben PS. I think this brings up the point, by the way, that we have two different kinds of scalability limits with regard to the view. The first is what Pol was initially after, which is the hard limit for number of icons shown on a screen of a given size, and the second is the number of icons (and their presence info) we can realistically manage technically. The latter (once we fix the jabber server) shouldn't pose much of an issue until we start thinking about inter-school or world level communications. The former, of course, is still worth investigating, because even with the scalability solutions listed above for intelligently moving icons on and off screen, we need to know that limit and filter only the number through that we can realistically show at once. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] The limits of Mesh View
On Fri, Apr 18, 2008 at 11:29 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Sat, Apr 19, 2008 at 1:18 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Polychronis Ypodimatopoulos wrote: | A full screen of icons would not be | legible either, but was I just trying to explore the limits. That's not exactly the limit. Although the current designs don't call for it, it would be easy enough to allow the mesh view to expand past the edge of the screen, once the number of icons gets too large to show them all. GTK has widgets designed for precisely this sort of infinite canvas. People with whom you've communicated more recently, or people who are geographically nearer to you, might migrate toward the center. Yes, this is precisely the type of scalability solution I alluded to before when I spoke of making the full neighborhood accessible via search. Effectively, we'd like to think of the screen area as a viewport into the broader neighborhood, which happens to contain a clustering of people and activities most relevant tot he user. Determining the heuristic for what's relevant needn't by very complex, thought it could be, and will likely begin with friends, recent collaborators, your favorite activities, etc. Naturally, the search and filter controls will serve as temporary adjustments to the relevance of the objects on the mesh, and so the view will change in response to them. The main reason we didn't jump directly to this model is because we'd very much like to emphasize the notion of the window, and of the neighborhood as a larger continuous space, by sliding the XOs, activities, and devices around the screen. This would also work well when illustrating XOs moving about the various activities on screen, but also serves as a way to slide negative matches radially outward, and positive matches inward, so as to always keep a relevant set of icons on screen at any time. At some point it will be of interest to be able to view friends of friends in a network view, and to have a variety of social networking functions. - Eben PS. I think this brings up the point, by the way, that we have two different kinds of scalability limits with regard to the view. The first is what Pol was initially after, which is the hard limit for number of icons shown on a screen of a given size, and the second is the number of icons (and their presence info) we can realistically manage technically. The latter (once we fix the jabber server) shouldn't pose much of an issue until we start thinking about inter-school or world level communications. I'm not clear to me why we aren't thinking about that now. Earth Treasury's mission is to link whole schools and create global partnerships. This has educational, social, and economic consequences. There will be hundreds of schools using XOs by the end of the year, probably more than a thousand. The former, of course, is still worth investigating, because even with the scalability solutions listed above for intelligently moving icons on and off screen, we need to know that limit and filter only the number through that we can realistically show at once. Based on my suggestions above, I would suppose that we will need a way for users to select viewing modes and parameters themselves. I always hate software that tries to tell me what I want. ___ Sugar mailing list Sugar@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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] The limits of Mesh View
Eben Eliason wrote: On Fri, Apr 18, 2008 at 11:51 PM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: What are the practical limits at the moment? How many icons can we fit at a maximum? I'll give a somewhat vague response (mainly because even I'm not sure) to kick things off. To begin with, the answer depends in large part to the topography of the collaboration space. The view is much more scalable when the grouping factor of XOs is high, such that some activities cluster a number of them into a ring. This organizing factor makes things scalable, and was a key element of our design phase. If it turns out that most collaborations involve only 2 or 3 XOs, and very few involve 5 or more, we won't hit the type of layout we envisioned early on. That said, I think the rough limits are going to lie between 50 and 100 (I said I'd be vague!) icons in the view at any one time before it becomes to difficult to manage. In our initial sketches, which allowed up to 25 or so (class size) XOs to be in a given activity, we could handle 150 or more while retaining some visual clarity. Of course, we're working on ideas for improving scalability in general, such that the entire neighborhood is accessible via the search capability even when only a (potentially small!) subset of that neighborhood gets shown in the view by default. Additionally, we intend to add list views to all of the zoom levels, which will provide a sortable, searchable, filterable list of all activities, people, and devices present for the more extreme cases. - Eben 1) I don't understand how larger collaboration groups would increase scalability. I would think it's the other way around: larger circles - larger radius of unoccupied space - less icons 2) I also did a vague estimation of one exterme: the number of XO icons that can be packed in screen. I think it's about 13x26 icons (of course it's possible to do that by dividing the screen resolution with the svg size, but was too lazy for that ;-). A full screen of icons would not be legible either, but was I just trying to explore the limits. Pol ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
