Re: Timeline
Posted: 05 Apr 2011 14:53
Hi,
I think you go to the right direction. Some advices and ideas:
Don't be too specific. You should avoid a specific UI for dates (calendar) as it can make the UI more complex without brining a real help for users. Most of them work with a series of snapshots, so the time is just an integer! It should remain simple for them. Also some may want only to work with approximation, but in research we don't. So let users input precise units if they want.
The first prototype of the timeline displayed bar charts inside to visualize bursts of changes on the network (i.e. # new nodes). Have a look at this document (in French) slides 10 and 11. The new design should allow to develop this feature in the future.
Screen capture is disk-space consuming and generate a heavy access on the hard-drive disk. Video encoding is CPU consuming, and can easily block other applications. Hence the video should be encoded after having captured the OpenGL window. We then can only implement a front-end to ffmpeg or the VP8 encoder to control the encoding speed vs quality.
Finally, please answer to the questions raised by jbilcke on this thread while drafting your solution. On the player for example, "what should be animated ? the lower interval ? the upper ? both ? how could we change this, while keeping it simple ? three button ? another way ?"
Cheers,
Seb
I think you go to the right direction. Some advices and ideas:
Don't be too specific. You should avoid a specific UI for dates (calendar) as it can make the UI more complex without brining a real help for users. Most of them work with a series of snapshots, so the time is just an integer! It should remain simple for them. Also some may want only to work with approximation, but in research we don't. So let users input precise units if they want.
The first prototype of the timeline displayed bar charts inside to visualize bursts of changes on the network (i.e. # new nodes). Have a look at this document (in French) slides 10 and 11. The new design should allow to develop this feature in the future.
Screen capture is disk-space consuming and generate a heavy access on the hard-drive disk. Video encoding is CPU consuming, and can easily block other applications. Hence the video should be encoded after having captured the OpenGL window. We then can only implement a front-end to ffmpeg or the VP8 encoder to control the encoding speed vs quality.
Finally, please answer to the questions raised by jbilcke on this thread while drafting your solution. On the player for example, "what should be animated ? the lower interval ? the upper ? both ? how could we change this, while keeping it simple ? three button ? another way ?"
Cheers,
Seb