I'm stuck on a plane, so:
Johan Sundström wrote:
> On 1/6/07, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>
>> NOTE: RT stands for "random thoughts". This is a tradition that I
>> initiated in the Apache Cocoon community back in the days and I would
>> like to initiate it here as well now that we are reaching a fairly large
>> pool of talented readers.
>>
>
> Lovely practice. Do tell if I'm fluctuating too far off core topic --
> I tell myself that sharing relevant background, context and
> experiences could be useful both for the subject matter and as bits of
> a character portrait of us (as, frankly, I'd be interested in the same
> spotlight peek at most of the talent gathered here). I realize there
> is a sweet-spot between that and not swamping the list, though, but
> presume our friendly neighbourhood moderators will poke us if we lead
> it too far astray. :-)
>
>
>> A few weeks ago, we reached the limit of how many 'datapoints' ploticus
>> can handle and we had to turn off the plotting stage... meaning that the
>> data is being updated, but the plots are not (they are lagging behind).
>>
Easy fix: give a random subset of half the points to ploticus. If there
are too many points for software to handle then there must be more than
one data point per pixel---pointless to plot at this level of detail.
>
> Curiosity query: in which way did you hit the roof? It does not strike
> me as a tool that should be much harder to make scale than, say,
> rrdtool, which handles impressive data sets beautifully. I'm
> interested, not for challenging the statement, but on grounds of being
> able to change that, or understanding the situation enough to get a
> clear picture of whether it would even be a good idea in the first
> place.
>
> Thanks a ton for opening (and/or pointing to) the repository to
> introspection, by the way; I'm *very* interested in visualization
> engines, emergent behaviour around their adoption and how they help
> empower development processes.
>
> The (commit timeline centric) cvs browser we made for the Pike
> programming language and Roxen repositories (later adopted and refined
> as Opera Software's internal ditto) quickly rose to become essential
> infrastructure, and does marvels for productivity and (geographically
> dispersed) devs to stay on top of what happens in the codebase.
>
> http://pike.ida.liu.se/development/cvs/pike.xml
>
>
>> Ploticus is fast and relatively easy to use, but it is clear that it
>> would be way better to have more interactivity in such time charts.
>>
>
> Agreed; the interconnectedness of views typically counts for a
> substantial fraction of the usefulness of tools like these (once
> implemented). Even very rough and sketchy matches between a graph and
> the data it pictures (if available as other information systems) can
> be very useful -- the initially-eye-candy-obly "new source code"
> graphs at http://pike.ida.liu.se/ suddenly got thoroughly useful once
> I linked them up with the checkin view they are metrics of.
>
>
>> So now I wonder: should we incorporate time series plotting into
>> Timeline or write something else entirely?
>>
>
> I'm somewhat biased towards growing these things into Exhibit rather
> than Timeline, but that might be exploding scope? IMO, as long as user
> interface concerns are not compromised, usefulness grows with your
> options to operate on data, filtering, resorting, reconnecting and
> situating data sets.
>
From the exhibit perspective, which technology you are using to
generate the plot ought to be invisible to the end user. As with
timeline, I would say the key is to offer a simple syntax for someone to
specify plotting of data from a json file, eg (my syntax made up since I
have no connection to check correct syntax):
<ex:view
type={line-graph, scatter plot, histogram,...}
x-coordinate=".the-x-facet"
y-coordinate=".the-y-facet"
marker = ".the-color-facet"
>
in the spirit of off the wall, I could imagine using this syntax to
specify both google maps and timeline as special cases of this type of
view. After all, google maps are basically a scatter plot of
(latitude/longitude) pairs on "paper" with the world map as a
background---so if we could replace the background with a blank one (eg,
by plotting in the middle of the atlantic ocean) we could get the nice
interactions of google maps---drag scrolling, zoom, baloons on markers,
etc---for free. Even better if we could also put axes on the paper.
Similarly for timeline: that is a "scatter plot" of <time, i-dont-care>
pairs, with nifty simultaneous multi-resolution display and scrolling.
Imagine being able to get such multi-res display/scroll in two
dimensions, so as too quickly move around a google map scatter plot
without zooming in and out (google maps kind of offers this with their
little box in the corner, but timeline suggests and alternative approach).
>
>> And if we incorporate it, how? and what technology should we use? flash,
>> canvas, svg, java?
>>
>
> The lighter-weight for end users, the better. I'd preference-rank the
> above (first most preferred) svg, canvas, flash, java, svg winning
> with a very small margin over canvas for being reactive to model /
> view / controller style programming on a technical level, where canvas
> is more of a throw-away etch-a-sketch surface.
>
>
>> And what features should we have? I think some sort of zooming is a must
>> as plots tend to exhibit different features on different scales... how
>> about toggling between linear and logarithmic scales?
>>
>
> Both very interesting ideas. I'll probably noodle on the issues and
> questions you raise for some time and get back with more thoughts and
> reflections as the thread progresses.
>
>
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
