[Trac #1108] network view should give topology, freshness, and strength info
Zarro Boogs per Child
bugtracker at laptop.org
Tue Mar 20 11:18:14 EDT 2007
#1108: network view should give topology, freshness, and strength info
------------------------------+---------------------------------------------
Reporter: AlbertCahalan | Owner: Eben
Type: enhancement | Status: assigned
Priority: high | Milestone: BTest-3
Component: interface-design | Resolution:
Keywords: |
------------------------------+---------------------------------------------
Changes (by Eben):
* cc: mpg at redhat.com (added)
* status: new => assigned
Comment:
Replying to [ticket:1108 AlbertCahalan]:
> Put the self-XO in the middle.
This is a definite. Keeping the point of focus around the XO in the
center is critical to conveying the "zooming" metaphor we are shooting
for. I'm not sure why that hasn't been implemented yet, but it's an easy
fix. That will be of most importance when the subtle zooming animations
interpolate between views.
> Draw other devices in locations according to signal strength. A device
with a strong signal goes near the self-XO, while a device with a weak
signal goes farther away. Devices that are not directly reachable (must
route through other machine) go farthest away. Share signal strength info
with peers so that well-connected peers can be drawn near each other. Move
devices smoothly as signal strength and other attributes change; it is not
good to have devices leap from one side of the screen to the other.
There is some thinking to this effect, but there are many technical
difficulties and also some visual ones that may prevent this. We could
certainly take care of the "jumping about" of the activity and XO icons if
we apply a steep exponential moving average function to the data. The
drawback is that the actual positions might lag behind the true data a
bit, but it would be better than nothing while keeping a continuous view
of the mesh.
> Draw lines to show network routing. Information about indirectly visible
devices (seen via mesh) is less trustworthy than directly visible devices;
the diagram should indicate this by making them blurry.
This could get quite complex very quickly, and the view will already be
complex even without such additions. We're doing a lot to make these
kinds of things secure, and additionally the routes will be changing
frequently. I'm not sure anything useful could actually be derived from
this view except in very simple cases.
> As the info about a device or route gets stale, it should fade away.
We do have the idea of present vs. absent XOs and devices. While fading
the icons isn't really feasible, we might have some more discrete ways of
indicating this. Clearly when a signal goes away, the XO should disappear
from the mesh. Perhaps we should also pick a threshold below which an XO
is rendered as absent (white stroke, no fill), so that XOs first
transition to an outline, but remain present (filling back in with color
if the signal gets stronger), and only actually disappear once the signal
is gone.
--
Ticket URL: <http://dev.laptop.org/ticket/1108#comment:3>
One Laptop Per Child <http://laptop.org/>
More information about the Bugs
mailing list