I am considering to make an animated infographic based on SVG, Javascript and CSS technologies of a timeline. I have lots of experience in programming but not so much in using these technologies to animate something (means that you could possibly tell me that I should approach the problem in a different way).

With Inkscape, I can generate a large SVG image (large in the horizontal dimension and also relatively large in file size, unless I avoid embedding the pixel graphics). The SVG contains lots of boxes for events (SVG groups) which I would like to enlarge when clicked such that the details may be seen. I think, I could produce a working animation that shows the whole SVG and allows to enlarge all the boxes separately.

However, since the timeline is so long, it is necessary to zoom it such that only a part of it is visible at a time. There would need to be some buttons that allow the user to shift to the left or to the right to display earlier or later events. But still, whenever the user clicks one of the events it should be enlarged.

Here is the concept in pictures (the smaller large box is supposed to be the screen or the visible part of the graphic):

enter image description here

I am wondering if that is a feasible approach (how would I approach the combination of the two functions?). A different option would be to generate a separate SVG, or whatever, for each of the events and to position them in a different way on the screen.

Since I will need to repeat this many times for different or updated timelines, I will need to do most of it programmatically, working on the source text files. However, If such a single timeline can be created with some tool, from whose output I can learn how to do it, I am open to suggestions. In this case, I would need to know how.

Also, it would of course be very useful to have a working example, if there exists something comparable out there.

  • What type of content are each of the smaller elements that enlarge when clicked? That is a big determinant in what approach you should use Commented Jan 28, 2016 at 14:28
  • They are grouped svg elements that can be paths, text and pixel graphics. The pixel graphics may be embedded or external. Since they are what makes the whole file a bit large the latter approach is in principle favorable. Should the pixel graphics cause problems, it is also thinkable to include them only in the 'enlarged' box if possible.
    – highsciguy
    Commented Jan 28, 2016 at 15:17

1 Answer 1


Is it feasible?

Yes. Just as you have thought about it, it is definitely possible to do it like that. A better question is "Are there better ways to do this?" in which case I would answer probably.

The only time that I would use SVG for this is if most all of the elements that you want to zoom in on are originally SVG (such as icons) you're trying to exemplify of something like that. You can animate SVG's viewbox to do the horizontal scrolling and do some custom zooming function to zoom into particular elements (perhaps saving the viewbox before zooming so you can go back to it).

If there's much text, photos, or really anything much except what is usually an SVG, I would opt not to use this approach.

If you do use this approach, make sure to optimize your SVG(s) by following some rules and using some tools.

Instead, the approach I would use would be to create a regular web page that scrolls horizontally. Then, I would use HTML elements for the smaller parts. Part of the reason behind this is that content that is zoomed out (small) is not readable. But if you instead use content preview in that "un-zoomed" view, you can then, instead of "zooming" (unless it was an image or something static like that), you can open the full content (or perhaps even a new page).

What I mean by that is to use transitions like Google's material design recommendations. These sorts of animations can be created with relative ease (by a person who knows what they're doing) with JavaScript but Polymer has some built in if you want to use a framework for it.

You can add some buttons to scroll horizontally, but if you use this approach I recommend that you don't disable the usual way people scroll. It is important to indicate that the page scrolls horizontally though because users aren't used to this type of movement.

Using this approach, you can handle all sorts of contents and still do the same type of zoom that you are talking about for SVGs and similar types.

Some positives of this approach is are:

  • It uses the browser's default navigation (paired with some more custom transitions and zooming) and layout: Native scrolling is always less buggy than custom scrolling. Not hard coding positions (like in SVG) allows the content to position with less effort.
  • It saves file size: An SVG of this scale can be pretty massive. This affects not only load time, but also performance and makes users pay more to access your content.
  • It allows more freedom of content: Instead of being restricted to only SVG-like content, it would allows this same format to be used more generally.
  • It's likely more modular: which allows easier reuse in the future or on other pages.
  • It's easier to edit: Instead of going into Illustrator every time something needs to be changed, you can just add to the HTML.
  • Thanks! I am investigating these options. Since I am not familiar with Polymer I have asked a follow-up question at stackoverflow.com/questions/35067882/… .
    – highsciguy
    Commented Feb 1, 2016 at 11:33
  • @highsciguy If an answer satisfies your question, you can click the arrow to the left of the answer to mark it as correct Commented Feb 1, 2016 at 12:52
  • I won't forget to do it!
    – highsciguy
    Commented Feb 1, 2016 at 12:56
  • @highsciguy I hope you didn't forget :) Commented Feb 12, 2016 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.