Proposal talk:Visualization methods

Cool

Very cool proposal.... -- Philippe 05:59, 4 August 2009 (UTC)

Excellent proposal. I agree that better visualization tools and interactivity are important for all our projects. the wub "?!" 10:49, 6 August 2009 (UTC)

Agree too. 212.98.136.42 12:46, 14 August 2009 (UTC)

I agree with the interactivity thing, like Microsoft's Encarta. Wikipedia will be much greater. Rainbowofknowledge 16:08, 14 August 2009 (UTC)

I support this idea, too. But consider another thing. Most of the people (on this planet)who rely on free knowledge such as Wikipedia won't always have a fast PC. Unintentionally, a more professional design could lead to the exclusion of those who cannot afford a fast PC or fast Internet service that can show all animations and an interactive graphic interface. Despite that I would I believe also that most of the media should be compatible with open source players so that nobody is forced to get a non-free or restricted player by Java, Adobe, Microsoft Google, etc.

--Trickymaster 00:41, 25 August 2009 (UTC)

Th key is SVG, probably. Our own Brion Vibber is giving a talk at SVG open that will touch on this very area. Globbet 22:52, 14 August 2009 (UTC)

I'm a bit worried about filesizes too. I think this is something the community really needs to discuss. We used to have a limit on page sizes, perhaps we need a policy to dictate filesizes too. --Bodnotbod 19:52, 18 August 2009 (UTC)

Glad to see somebody has submitted this. I'm the author of some widely used graphical templates on en (see w:en:Template:Location map, w:en:Template:Climate chart, w:en:Template:Bar box). Those show that you can achieve a lot with just CSS, but you soon run into its limits, plus the produced composite "images" aren't really images, so there's no way to save them and e.g. include them in a word processor document. What we need is templates that produce real images based on supplied parameters.

One way to do this for the general case is inline SVG. Another, possibly better, is inline Cairo. We could also use HTML canvas. In any case, we should use a well-known standard, and adapt it just enough to suit our needs, i.e. sanitize out any javascript and external images, allow internal images to be included in composites).

My Plotters extension can allow admins to install javascript applications in a way similar to the Gadgets extension. The applications can be used by end-users in wikitext, and can do generic canvas drawing, and/or graphing/plotting javascript libraries. Users should be able to test new javascript applications via their own javascript pages. The visalizations can fall back to tabled data if javascript isn't enabled.
--Ryan lane 20:31, 22 September 2009 (UTC)

Also, we should be thinking about other ways of presenting information, which may need their own extensions. One thing that springs to mind is GraphViz. 89.142.193.104 13:26, 17 August 2009 (UTC)

Seems these templates and this kind of reasoning is related to Proposal:Markup for Maps, and since this discussion's proposal is already on that proposals reference list, I think I'll add some comments here and there. Interactive graphics would probably be doable if SVG and ecmascript are perused, although only for the most modern browsers. I'm inclined to make a category for visualization proposals, or something like this in order to centralize discussions as pertaining to graphical and graphico-dynamical new presentation forms on mediawiki/wikipedia. Rursus 08:53, 20 August 2009 (UTC)

89's template links added to references of Proposal:Markup for Maps. Rursus 08:56, 20 August 2009 (UTC)

Wow, I agree. Reading through loads of text to learn something is boring compared to actually visually and intuitively grasping the concept. Mbrar.web 09:49, 20 August 2009 (UTC)

Interactive dynamic visualization

I like the proposal, although I hope that as it gets realized, editors will not grab it as a toy to "beautify" articles, which I fear may be mostly distracting, but use it wisely for those situations where visualization actually aids in comprehension. Current Wikipedia examples of (in my opinion) useful animations are commons:File:Territories of Dynasties in China.gif and commons:File:Archimedes-screw one-screw-threads with-ball 3D-view animated small.gif.

I'd like to stress the potential importance of dynamic visualization that can be interactively controlled. As an example, perhaps not entirely convincing in its execution, but indicative of the potential, look at this Prius driving simulator. Such visualizations should never come in the place of text, but support what is already explained, as well as is possible in words, in the article text.

The proposer notes the need of the reader being able to control starting an animation (and, if I may add, stopping it as well). Personally I'd further often like to slow down the animation to see more clearly what's going on. Something I'd like to be able to see is a dynamic political map of, for example, Europe, with a user-controllable slider for the date (which however can also be set into automatic motion) and an ability to zoom in on geographic areas (and zoom out again).  --Lambiam 11:14, 20 August 2009 (UTC)

We are going to use it as a toy to "beautify" articles, or not do any articles at all. I'm in it just for the fun, the only thing that restricts me is the effort involved. Think of the beauty and wellformedness as a kind of "fun", and "fun" won't seem so terribly dangerous to you maybe... (?) Rursus 14:53, 20 August 2009 (UTC)

Are you trying to say that even when animations or other visualizations do not help to make the content of an article more accessible, but are on the contrary more distracting than anything else, "we" are nevertheless going to put them in, just for "fun"? Maybe "we" should also enable <blink>BLINK</blink>, just for fun.  --Lambiam 09:07, 21 August 2009 (UTC)

Don't be a Luddite. As with any new toy, there will be initial enthusiastic over-exuberance which will engender a backlash from killjoys and then it will settle down to the normal stable running skirmish, with good work being done. Globbet 23:09, 27 October 2009 (UTC)

Synchronoptic display of historical data

I'd like to suggest that special attention is given to historical data and its display. In particular, I'd be very interested in seeing something akin to HyperHistory. A synchronoptic view allows to see historic data (events, life lines, etc.) in their historical relationship to other data. This could work very similar to GoogleEarth, i.e. information is refined as the user 'zooms in' on a given time period, instead of merely using imagemaps to cross-link events.

(FWIW, I've started to work on such a tool a long time ago, but couldn't publish it as the data was transcribed from a book I bought. Using Free Information from Wikipedia for this seems like a natural evolution of the idea !) -- StefanSeefeld

Animated SVG files and SMIL

I think animated SVG files like those in Commons:Category:Animated_SVG may be a promising model for more many types of interactive visualization methods. Unfortunately, the two most popular browsers -- Internet Explorer and Firefox -- don't natively support SMIL, the markup language describing these animated SVG files (the latest versions of Opera, Chrome and Safari do). These files have a relatively low 'bit-to-information' ratio, which was cited as a concern for animations in the Proposal. SMIL-based animations are also interactive: consider the movable blocks of a diagram of the Trajan Column in the file here: Commons:File:Trajans-Column-lower-animated.svg. (I downloaded the latest version of Opera just so I could take a good look at these animations.) For these types of animations, it may be best to present the SVG file in the article itself. Currently, SVG files are rendered as PNGs in the mainspace, which would strip files of their intended animation capabilities. Emw2012 21:44, 26 August 2009 (UTC)

As the author of that animation, I'd like to note that the solution used is far from satisfactory. The boxes slide out and back in on a fixed timeline, not leaving the time someone might want to have to look at it. With SMIL, there is no solution to slide out the blocks with one click and move them back with a second click.

Interactivity doesn't work well without scripting capabilities. For SVG, this would mean JavaScript, which currently can not be uploaded for security reasons. This seems to me to be a problem that needs to be tackled for any technology. As soon as you start to use Web technologies interactively, you open doors for exploits and attacks. Just a thought. --Hk kng 21:33, 4 October 2009 (UTC)

Yes, interactive SVG (and complicated non-interactive SVG) needs JavaScript, but I see no fundamental reason why JavaScript animated SVG files might not be contained, or vetted at upload, to ensure they do not present a security risk. Globbet 22:56, 27 October 2009 (UTC)

iPaper for Wikipedia

My suggestion is an application that is similar to the iPaper Viewer application to verify official public papers. Not only that. We could also use the same applet to show

• scanned fossils such as the former missing link Ida (You can zoom them without the requirement of loading the whole high-res image)
• old photographs or maps (for the same reason as above)
• very old writings such as the site of the Codex Sinaiticus, the oldest Bible in the world.

It would be very useful and give Wikipedia a more professional look And motivate others to do research by themselves. In addition to that, we could stop worrying about the resolution as there would not be the need to load the whole high-res image, but instead just zoom in to specific points. --Trickymaster 00:13, 29 August 2009 (UTC)

A warning about iPaper iPaper in specific is a closed format, much like apple AAC files (mp4) or Microsoft word files (wks, doc, etc) the only applications which can use it are those which are licensed to use it. I imagine it is possible for wikipedia to develop its own open file format or its own document interface, though this would increase load time and server load for every page and make accessing pages using old web browsers/handheld computers difficult.

When it comes to technical proposals is important that we have a sense of who might be able to do such a thing and how we might approach them. Any proposal is much more powerful if you can find a developer who can and would make it happen. --68.32.26.209 07:33, 1 October 2009 (UTC)

It just has to be similar to iPaper. I will begin to search for an open alternative as the one that was used for Codex Sinaiticus. We could also use it to show or references if the reference is not under copyright. --Trickymaster 05:28, 14 October 2009 (UTC)

Impact?

Some proposals will have massive impact on end-users, including non-editors. Some will have minimal impact. What will be the impact of this proposal on our end-users? -- Philippe 00:18, 3 September 2009 (UTC)

SmoothGallery

The SmoothGallery extension (full disclosure: it's my extension), can do slideshow galleries as described in the proposal. It also falls back to regular galleries, or a single image if javascript is disabled or unavailable.
--Ryan lane 20:33, 22 September 2009 (UTC)

Green Links

To put the ideas within reach, software would be needed. There is already the Jmol applet, used in [http://proteopedia.org the Proteopedia Wiki]. The green links there are the best invention since sliced bread.

But, as Jmol is specialized to chemistry, something more general, like for VRML is needed. Don't forget the green links.

Finally, even with movies and animation, which is already here, ... green links could be enabled to show specific parts of the movie. --85.177.90.26 14:17, 25 September 2009 (UTC)

Image from a plate

How to put into article a certain figure from a large plate? Is there useful to put a plate into Commons and view only some figures from the plate in articles? Or is more useful to crop all figures from the plate solely? Is more useful to show figures in the context or separatedly? --- Is there possible to show only a part of the image marked "as a note" with http://commons.wikimedia.org/wiki/Help:Gadget-ImageAnnotator in the article? --Snek01 23:46, 28 September 2009 (UTC)