Timeline

[admin]

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

[Yestin]

OK, I get it. But I'm curious what do you think about zooming in general? Let's say we have got a data source with 200 years and we are interested in studying one of them (using e.g. month interval). From what I understand "intelligent unit selector" would set "years" unit, because other units would cause a "mess". How can we investigate this year in a comfortable way (i.e. not using a magnifying glass )? I'm thinking about a combination of mouse scroll zooming (or some another mechanism) with changing units using a combo box you propose (of course there is a problem with "hiding" bricks, I think that if we zoom too much we should cut intervals to fit the visible interval). So, what's your opinion?

If we use only "unit selection", the problem what @Cezary raised did exist. But in my point of view, I think "zooming in general" is not that necessary. If we have the need of exploring one month from 200 years, we can using the filter to filtering the data of that year, then set the unit to "month". (BTW, I ignored the importance of architecture. I will pay some attention on it. So that we can implement the "zooming in general" as a plugin.)

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.

It's my fault not noticing the expandability of the timeline. I didn't think of the feature @Seb said, but I think it's very necessary. I will spend more time on the expandability.

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.

I don't know whether I understand what @Seb said correctly. After capturing the OpenGL window, the image should first be encoded(compressed), we can save the images using a cache file. Then we can use ffmpeg to converting images to videos. I found the difference of this solution and mine is the video processing toolkit(JMF VS ffmpeg, If we use JMF, we have to implement the video generation by ourselves. If we use ffmpeg, we only need to provide a proper UI. Right?). I looked throught ffmpeg, users must have a complied ffmpeg if they want the video generation feature, mustn't they?

Finally, please answer to the questions raised by jbilcke on this thread while drafting your solution.

Timeline player:
First of all, the potential added-value of our timeline player is that it is developed on Gephi, so it can do many processing work on what users see at a time.
The speed is controlled by unit and a speed controller. For example, if current unit is year, we paly the graph from one year to the next year with a fixed time interval (maybe 1 second). Then we can using the speed controller to change the speed (in fact the changing is time interval, maybe from 0.1second to 5 seconds).
What should be animated is decided by what users select on the timeline panel by selecting the min and max value of time, ie, from 2001 to 2009. We may animate the selected time from year to year, or month to month, which depends on the current unit.

Zoomable Viewframe:
I want not to implement the wheeling on controlling the timeline, because I still think using both the brick of slider and mouse wheeling to control the scope of the time will cause confusion. But I will try to optimize the architecture of the timeline module, so that other developers can implement such feature easily.

Precise Timeline
I prefer to use "unit selection" and "snap to grid" to help user give precise time/number.

Well, we could offer different "setters" for different time formats. But you are generally right about the importance of this feature. I think that cases in which user set intervals like "15 hours 4 minutes 34 seconds 80 milliseconds" are rather seldom But sometimes one would like to set, let's say, 1 hour 30 minutes. What do you think about painting a major unit (the selected one) and a minor unit, e.g. hour as the major unit and minute as the minor unit etc. I think that in such case "snapin to grid" and "unit selection" would be really sufficient (assuming we can zoom, I think it's important). By the way - I think we should be able to go to milliseconds in the unit selection.

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.

BTW, I will update my draft application asap, many of the documents will be changed.

[cezar_1]

Zoomable Viewframe:
I want not to implement the wheeling on controlling the timeline, because I still think using both the brick of slider and mouse wheeling to control the scope of the time will cause confusion. But I will try to optimize the architecture of the timeline module, so that other developers can implement such feature easily.

Well, maybe you're right I'm not an ergonomics expert, so I'm not sure this redundancy (zoom + filters) is really necessary. But if you can leave the code open for extensions it would be really fine.

[mbastian]

Yeah, I think the zoomable timeline makes the UI too complicated. Maybe it can be added later and disable by default thought.

Moreover I think users are more interested by insights in dynamic data, and therefore having charts within the timeline seems a higher priority.

Intervals defined in the data are also important, and should be somehow visible in the interface, for instance with a veritcal bar. They could also be used to add stickyness while moving the slider. If my intervals bounds are 2000, 2001, 2002....2011, I probably want to filter according to those and have for example 2000-2005.

[Yestin]

Now I have a big picture about the timeline player, and most of them are shown in the new draft application.
The keywords are : architecture(expandability,barchart,linechart or other dashboard), animation(time interval, speed control), unit/graduation(tooltip, unit selection, graduation drawing), movie generation.

Just as Seb said, "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. ". But if we want such feature to be implemented, that problem always exists.
I don't know ffmpeg very well. I still have no idea on whether to use JMF or ffmpeg. Can you give me some suggestions?

[admin]

This is how I use mencoder (not ffmpeg, sorry) to record Gephi videos:

http://forum.gephi.org/viewtopic.php?f=6&t=3

[Yestin]

I see what you did this. First record the screen and then compress/codec the video.

I think I understand what you said, what I need to do is capturing all the opengl window of each timestamp, and then a ui is provided to generate video (by a third party software or by our own tool). The importance is separating capturing images and video generating into two separate tasks.

In fact, comparing with timeline module itself, movie creation is not that important. If we need record the playing of the graph, we can use video recording software just as you said .

[cezar_1]

As far as I know some people would like to generate movies from GEXF files. Maybe it's not so important in comparison with other features, but it's good to think about possibilities of such a feature.

[admin]

Movie creation is really expected from our users, so it is important. My trick is for advanced users, but we need that everybody can create their own video.

[mbastian]

I see what you did this. First record the screen and then compress/codec the video.

I think I understand what you said, what I need to do is capturing all the opengl window of each timestamp, and then a ui is provided to generate video (by a third party software or by our own tool). The importance is separating capturing images and video generating into two separate tasks.

It would be better to compress while recording, as uncompressed video takes enormous amount of disk-space.