Well, you might not understand the text but the sense:
This is what you can create with JavaScript: http://www.mrbbc.org/files/de/cloudlevels.htm
Simply imagine the graphic above at this place: http://de.wikipedia.org/wiki/Wolke#Internationales_System
Should we include such JavaScript features and graphics and animations into MediaWiki ?
Unlike Flash or SVG this solution should work for most visitors. This state of JavaScript is directly supported from all current browsers since above 4 years or more. - SVG isn't far enough yet. You can view static vector graphics, but animations AFAIK only with special plugins.
---
My technical recommendation would be to implement an additional parameter for links that is filled into the onmouseover- and onmouseout attribute of the created HTML elements, i.e. the <a> and <area> tags, see http://www.mediawiki.org/wiki/Extension:ImageMap
Further you should include a JS file with standard functions that could be used for interactive graphics. And last but not least you may have to add some HTML elements and CSS formatting into every Wiki page.
---
* TOOLTIPS
There should be several kinds of tooltips. First the most simple one only containing text, second text and graphic like mine, and third only a graphic, maybe without this tooltip border stuff.
Let us name them e.g. tt1, tt2 and tt3 or better ttt(ext), ttt(ext_and)i(mage) and tti(mage), maybe also ttit when the image should be on the left side... So in the JS file you've get functions named tttshow(content), tttishow(content, image) and so on, further of course ttthide(), tttihide() or simply (and more safe) tthide() which hides all tooltip boxes.
- Or maybe the only one (or both) when you make a flexible tooltip, where you change the whole parameters of the inner table. (the second tooltip box might be the one that only contains an image and therefore needs not to be changed except of the shown image)
The size of the images should be further fixed - e.g. 120x90, which might be adapted for ridiculuted displays by using maybe CSS. On the other hand... someone who can afford a 12 inch display with 1680 by 1050 pixels should also have enough money for a magnifying glass...
---
A Wiki link with tooltip will for example look like this:
[[Cirrus||Tooltip:Cirrus (Ci), auch: Federwolke#Image:Cirrus_over_Warsaw%2C_June_26%2C_2005.jpg]]
(I assume the third column of a Wiki link is not yet used; an empty column will be ignored, i.e. if the link would be written out, the content of the first column will be used instead)
- You might also put such scripts into the description column, but then you can't put a tooltip above the text of a link (although this might not be sensible anyway).
The HTML generator can be intelligent enough to determine which tooltip function is to be called, i.e. what to fill in the onmouseover and onmouseout attributes...
I made my first hypertext experiences with ST Guide; there you could not only define full articles (called node) but also small descriptions (called p(opup)node), that popped up in a small box when you clicked them. Maybe you might define in a Wikipedia article also small explanations for the respective term that are then inserted as a tooltip above any link in other articles linking to that term...
I.e. for example when you move your mouse cursor above the word "atavism" a tooltip pops up e.g. with the text "evolutional throwback to older forms". So you won't have to click the link when you only need to know what a term means to understand the statement. - Just a suggestion. I know that this increases the server load (everytime when the Wiki syntaxis is translated into HTML).
---
* ANIMATIONS
That's too much for me now. I think of course you may make something like with the ImageMap extension: http://www.mediawiki.org/wiki/Extension:ImageMap
where you write down in principle a list of movable pictures their positions and movement...
There are only two types of animations to support: silhouette animations and slide shows. For videos the only sensible way is a video file format like MPEG. But maybe you might also draw lines and simple geometric forms inside this animations...
First draft:
<animation> Image:Foo.jpg|640px|picture of a foo #0 show 1 0 0 Image:bar.png|32px hide 2 0 0 Image:bar2.png|32px #1 2 move 1 32 0 desc A bar goes its way... pause 60 desc wait </animation>
First line is the main picture/background and description of the animation.
#0 introduces the base animation frame. Maybe there you've got to specify all used images
show/hide are specifing movable images; "1" and "2" are for adressing, "0 0" are their initial coordinates in pixel relatively to the background image.
#1 is the second animation frame that appears when you run the animation
the second number is the time in deciseconds that all images moved inside this frame will need to reach their destination coordinates
move moves an image; the first number/letter etc. addresses the image, the following numbers are destination coordinates where the image will move linearly...
desc displays a text in the description block of an animation; a single desc in the line will clear the description block, it does not reset simply with the next frame. Along with desc you might also play a wave file that "reads" the same text.
pause waits for the next frame n deciseconds, wait stops the "animation" until the user hits the mouse button or a key.
END OF LINE
So you want to mess even more the parser, isn't? Those clouds are very nice. I think instead of asking the parser to do the whole job and inserting JS, it would better be added by a JS (will only show to JS browsers anyway). It is even possible now... fulling the Monobook.js of almost-unused code. What about doing a MediaWiki:articlejs/<PAGENAME> include (if exists) for each article?
Platonides schrieb:
So you want to mess even more the parser, isn't? Those clouds are very nice. I think instead of asking the parser to do the whole job and inserting JS, it would better be added by a JS (will only show to JS browsers anyway). It is even possible now... fulling the Monobook.js of almost-unused code. What about doing a MediaWiki:articlejs/<PAGENAME> include (if exists) for each article?
Well my graphic makes most sense if it's inside the article; silhouette animations on the other hand might be better in a popup-window when you click its "thumbnail" graphic. Especially when the animation is simply much larger than a usual picture.
But again on the other hand you might also make such interactive graphics nearly as broad as the article text, i.e. they are placed in the middle and dividing the text. The disadvantage of them is that they fairly increase the size of the HTML code.
Of course it would be also somehow nice if you might be able to store interactive graphics as one file in the Wikimedia Commons as if they were Flash animations; on the other hand in most cases you will have to localize them, therefore you'd get a new file for each language Wikipedia is available which is not very sensible-like, because in many cases an interactive graphic would be used only once from a single article...
wikitech-l@lists.wikimedia.org