New Visualizer is insufficiently labelled/documented (plus layout problem) #1265

Open
opened 2010-11-20 15:59:52 +00:00 by zooko · 17 comments

I'm looking at the output of Brian's New Visualizer, which output François attached to #1264. Attached is a screenshot of what I'm looking at. It is insufficiently labelled and documented, so I can't tell what it means.

(Also there is a problem with layout so that things are scribbled on top of one another into illegibility.)

As far as I know, the only way to learn what this graph means is to read this comment from Brian on ticket #1170:

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1170#comment:90

I'm looking at the output of Brian's New Visualizer, which output François attached to #1264. Attached is a screenshot of what I'm looking at. It is insufficiently labelled and documented, so I can't tell what it means. (Also there is a problem with layout so that things are scribbled on top of one another into illegibility.) As far as I know, the only way to learn what this graph means is to read this comment from Brian on ticket #1170: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1170#comment:90>
zooko added the
unknown
major
defect
1.8.0
labels 2010-11-20 15:59:52 +00:00
zooko added this to the undecided milestone 2010-11-20 15:59:52 +00:00
Author

Attachment Screen shot 2010-11-20 at 08.56.32-0700.png (61512 bytes) added

**Attachment** Screen shot 2010-11-20 at 08.56.32-0700.png (61512 bytes) added
Author

Now that we've finally committed #1200 (package up Brian's New Visualization of immutable download) to trunk and it is destined to be included in Tahoe-LAFS v1.9.0, we should (re-)visit this ticket. Probably the next step is for me to re-evaluate and make my complaints more precise, so I'm assigning this to me and putting it into 1.9.0 Milestone.

Now that we've finally committed #1200 (package up Brian's New Visualization of immutable download) to trunk and it is destined to be included in Tahoe-LAFS v1.9.0, we should (re-)visit this ticket. Probably the next step is for me to re-evaluate and make my complaints more precise, so I'm assigning this to me and putting it into 1.9.0 Milestone.
drewp commented 2011-07-08 21:37:07 +00:00
Owner

This is a type of thing I like to hack on. I even did a layout-lots-of-overlapping-labels project recently which might be relevant. Adding myself to the list in hopes I will be able to contribute.

This is a type of thing I like to hack on. I even did a layout-lots-of-overlapping-labels project recently which might be relevant. Adding myself to the list in hopes I will be able to contribute.
Author

drewp: Awesome! If you do it soon then it can go into v1.9.0 (being the first release with Brian's New Visalizer). I'm hoping v1.9.0 will go into Ubuntu Oneiric Ocelot 11.10 -- deadline coming up soon. I'll post to the tahoe-dev list about this.

drewp: Awesome! If you do it soon then it can go into v1.9.0 (being the first release with Brian's New Visalizer). I'm hoping v1.9.0 will go into Ubuntu Oneiric Ocelot 11.10 -- deadline coming up soon. I'll post to the tahoe-dev list about this.
Author

drewp: if you are waiting for me to post my ideas/complaints about the current trunk Brian's New Visualizer, then leave this ticket assigned to me. If you are intending to start editing it yourself without waiting for me, then please accept this ticket so that it will be assigned to you.

drewp: if you are waiting for me to post my ideas/complaints about the current trunk Brian's New Visualizer, then leave this ticket assigned to me. If you are intending to start editing it yourself without waiting for me, then please *accept* this ticket so that it will be assigned to you.
Author

drewp: we're probably going to freeze tahoe-lafs trunk and stop accepting new non-bugfix patches for v1.9.0 in about a week.

drewp: we're probably going to freeze tahoe-lafs trunk and stop accepting new non-bugfix patches for v1.9.0 in about a week.
drewp commented 2011-07-17 22:53:08 +00:00
Owner

Here is my plan:

  1. Extend the event_json payload to include all the strings that DownloadStatusTimelinePage is generating for its template, so that the /timeline page doesn't have to be a template at all. This makes the page render use fewer technologies, and it simplifies the other things I'm going to try.

  2. Make another /timeline page that doesn't use protovis. I believe that with plain old divs and some jquery magic, I can render a similar timeline but have an easier time doing more elaborate layout. I intend to model it after the firebug 'net' tab, where each event is on its own row (which may be subdivided into the "phases" of the event as appropriate). The rows can be expanded to show details underneath. I also intend to mimic the mouseover behavior of the firebug timeline bars. Firebug has immediate, multi-line tooltips that should be more usable than simple 'title'-attribute tooltips.

  3. Depending on the success of #2, I'll see about folding the good parts into the protovis timeline, replacing it, providing links to both, etc.

  4. I hope for my all-javascript normal-divs timeline page to be a model for people who want to try other displays, such as a node-centric one showing all the blocks I'm giving out, or a super-compact one that can be superimposed on normal directory pages as a fancy status bar.

I'm trying not to be NIH about this, but after doing a project with D3 (protovis successor) and many other charts with divs, I think I can be much more effective if I port the protovis piece. As a small bonus, the divs layout will work on more browsers.

Here is my plan: 1. Extend the event_json payload to include all the strings that [DownloadStatusTimelinePage](wiki/DownloadStatusTimelinePage) is generating for its template, so that the /timeline page doesn't have to be a template at all. This makes the page render use fewer technologies, and it simplifies the other things I'm going to try. 2. Make another /timeline page that doesn't use protovis. I believe that with plain old divs and some jquery magic, I can render a similar timeline but have an easier time doing more elaborate layout. I intend to model it after the firebug 'net' tab, where each event is on its own row (which may be subdivided into the "phases" of the event as appropriate). The rows can be expanded to show details underneath. I also intend to mimic the mouseover behavior of the firebug timeline bars. Firebug has immediate, multi-line tooltips that should be more usable than simple 'title'-attribute tooltips. 3. Depending on the success of #2, I'll see about folding the good parts into the protovis timeline, replacing it, providing links to both, etc. 4. I hope for my all-javascript normal-divs timeline page to be a model for people who want to try other displays, such as a node-centric one showing all the blocks I'm giving out, or a super-compact one that can be superimposed on normal directory pages as a fancy status bar. I'm trying not to be NIH about this, but after doing a project with D3 (protovis successor) and many other charts with divs, I think I can be much more effective if I port the protovis piece. As a small bonus, the divs layout will work on more browsers.
drewp commented 2011-07-18 07:38:05 +00:00
Owner

Here is how far I got:
http://bigasterisk.com/post/tahoe/timeline2.jpg

The first 'read' line has been expanded to show more detail. Mousing over any timeline row currently shows the whole JSON payload I got for that row.

My row sorting is still weird, but that's because I don't understand data like this:

segment: start: 0, length: 131073, start_time: 1310960867.0037, finish_time: 1310960867.694093

block: start: 87418, length: 43691, start_time: 1310960868.006524, finish_time: 1310960868.03249

The block is read completely after the segment is done? Furthermore, my biggest block offset is only 264047(+170) for a 700kB file. The segment start/length spans look fine.

Here is how far I got: <http://bigasterisk.com/post/tahoe/timeline2.jpg> The first 'read' line has been expanded to show more detail. Mousing over any timeline row currently shows the whole JSON payload I got for that row. My row sorting is still weird, but that's because I don't understand data like this: segment: start: 0, length: 131073, start_time: 1310960867.0037, finish_time: 1310960867.694093 block: start: 87418, length: 43691, start_time: 1310960868.006524, finish_time: 1310960868.03249 The block is read completely after the segment is done? Furthermore, my biggest block offset is only 264047(+170) for a 700kB file. The segment start/length spans look fine.
drewp commented 2011-07-19 04:38:17 +00:00
Owner

darcs pull http://darcs.bigasterisk.com/tahoe-lafs

will now get my patches, after which you should be able to go to the old /timeline page and append a '2' to the URL. I'd like more feedback about the block issue and also on what else should be shown. Should the 'segment' rows expand to show an explanation of the blocks they used? Can someone write a verbose story template for a DYHB request (e.g. "We contacted _ and asked if it had _; it said it has _ which means we can _")?

darcs pull <http://darcs.bigasterisk.com/tahoe-lafs> will now get my patches, after which you should be able to go to the old /timeline page and append a '2' to the URL. I'd like more feedback about the block issue and also on what else should be shown. Should the 'segment' rows expand to show an explanation of the blocks they used? Can someone write a verbose story template for a DYHB request (e.g. "We contacted _ and asked if it had _; it said it has _ which means we can _")?
Author

drewp: I like the plan from comment:81289. Still hoping to get time to review this patch soon.

drewp: I like the plan from [comment:81289](/tahoe-lafs/trac-2024-07-25/issues/1265#issuecomment-81289). Still hoping to get time to review this patch soon.
Author

Brian: what do you think of this ticket -- is it worth putting in an additional visualizer for 1.9? Personally I definitely like the idea, but your Release Manager and deadlines are upon us...

Brian: what do you think of this ticket -- is it worth putting in an additional visualizer for 1.9? Personally I definitely like the idea, but your Release Manager and deadlines are upon us...
zooko modified the milestone from undecided to 1.9.0 2011-07-23 20:57:42 +00:00
zooko removed their assignment 2011-07-23 20:57:42 +00:00
warner was assigned by zooko 2011-07-23 20:57:42 +00:00
warner added
code-frontend-web
and removed
unknown
labels 2011-07-25 06:18:02 +00:00
Author

Per Brian's mail to tahoe-dev, this ticket didn't make the cut for 1.9. I really hope that drewp works on it some more soon though, so that it can be one of the tickets which kicks off the Tahoe-LAFS v1.10 project. :-)

Having interesting new features in trunk early on in a development cycle really helps, IMO, with making the next release happen sooner and easier.

Per [Brian's mail to tahoe-dev](http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006577.html), this ticket didn't make the cut for 1.9. I really hope that drewp works on it some more *soon* though, so that it can be one of the tickets which kicks off the Tahoe-LAFS v1.10 project. :-) Having interesting new features in trunk early on in a development cycle really helps, IMO, with making the next release happen sooner and easier.
tahoe-lafs modified the milestone from 1.9.0 to 1.10.0 2011-08-09 16:38:34 +00:00
Author

I opened #1550 to track drewp's new visualizer.

The remaining parts of this ticket are to add documentation and labels to the current visualizer. That seems like it should be in scope for v1.9.0 to me, so I'm moving this ticket back into 1.9.0 from 1.10.0 (but I'm not the Release Manager for v1.9.0).

See also #1169 which is about updating the accompanying text document source:docs/frontends/download-status.rst.

I opened #1550 to track drewp's new visualizer. The remaining parts of this ticket are to add documentation and labels to the current visualizer. That seems like it should be in scope for v1.9.0 to me, so I'm moving this ticket back into 1.9.0 from 1.10.0 (but I'm not the Release Manager for v1.9.0). See also #1169 which is about updating the accompanying text document source:docs/frontends/download-status.rst.
zooko modified the milestone from 1.10.0 to 1.9.0 2011-09-28 19:43:39 +00:00
zooko changed title from Brian's New Visualizer is insufficiently labelled/documented (plus layout problem) to New Visualizer is insufficiently labelled/documented (plus layout problem) 2011-09-28 19:43:39 +00:00

this is not making it into 1.9 . If anyone feels like adding docs, prove me wrong! :)

this is not making it into 1.9 . If anyone feels like adding docs, prove me wrong! :)
warner modified the milestone from 1.9.0 to 1.10.0 2011-10-28 04:47:43 +00:00

Attachment timeline.png (153940 bytes) added

timeline view on current trunk

**Attachment** timeline.png (153940 bytes) added timeline view on current trunk

I've just attached a screen-capture of the timeline view displayed by current trunk. It has seconds along the bottom, and labels on each section. No layout problems on Firefox or Chrome. All comments on this ticket (except for zooko's original description) are about drewp's work, so if this ticket is about my visualizer, then I'm going to kick this back to zooko with the question: is timeline.png sufficiently labeled for you?

I've just attached a screen-capture of the timeline view displayed by current trunk. It has seconds along the bottom, and labels on each section. No layout problems on Firefox or Chrome. All comments on this ticket (except for zooko's original description) are about drewp's work, so if this ticket is about my visualizer, then I'm going to kick this back to zooko with the question: is [timeline.png](/tahoe-lafs/trac-2024-07-25/attachments/000078ac-74b1-0c05-7ded-a921c08044cb) sufficiently labeled for you?
warner removed their assignment 2012-05-13 02:38:19 +00:00
zooko was assigned by warner 2012-05-13 02:38:19 +00:00
Author

timeline.png is broken, probably due to #1581. I'll try it out myself from trunk (again) and report back.

[timeline.png](/tahoe-lafs/trac-2024-07-25/attachments/000078ac-74b1-0c05-7ded-a921c08044cb) is broken, probably due to #1581. I'll try it out myself from trunk (again) and report back.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#1265
No description provided.