Last modified: 2012-12-21 18:01:17 UTC
Hello, It is discussed to have Extension:WikiTimeLine activated in en.wikipedia, and there has been no objection. Nevertheless, no action is made in that regard. http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_32#Discussion_about_activating_WikiTimeLine_extension_on_Wikipedia The timelines provided by this extension is "interactive," and can present multiple unrelated articles in a single graph. Such presentation is not achievable through any other model. Because the timelines is created client-side, this extension can be used on heavy traffic wiki with no drawback. Live example and more information can be seen here: http://www.chaosreligion.com/wtl/index.php5?title=WikiTimeLine I am in both en.wikipedia and fa.wikipedia, but mostly active in fa.wikipedia. I am particularly requesting this extension for fa.wikipedia, but, of course, it is very useful for other wikipedia's as well. Thank you in advance for your consideration, Greetings, Fakhredin.
A few things. We need a version in our SVN... And it needs review. As it's GPL, there's no issues in this regards. That site is running version 1.12 of MediaWiki, which is rather old. Does the software run on >= 1.17?
(In reply to comment #1) > A few things. > > We need a version in our SVN... And it needs review. As it's GPL, there's no > issues in this regards. > > That site is running version 1.12 of MediaWiki, which is rather old. Does the > software run on >= 1.17? I am not the creator of this extension, but, if I understand corrently, it says in the follwoing page that it runs on 1.5 or higher: http://www.mediawiki.org/wiki/Extension:WikiTimeLine
You're going to have to get in contact with the original author, and find out if he (or someone else) can do some testing and tidying up. From a quick browse through, it's using $_GET, $_SESSION directly, the messages are done in the wrong way. It doesn't follow our coding guidelines, has '?>' at the end of each file, uses old/deprecated setup methods And that's without me reviewing the JS
I will try to contact the author, and come back to you as soon as possible. Thanks a lot for your swift replies.
Questions: * What exactly does it do? The descriptions are vague and the demos are confusing. * Is there a non-JS/non-interactive display available for print output, etc? This should be considered an absolute requirement for proposed Wikipedia use. * What's the overlap with existing EasyTimeline extension in data formatting, display, etc? Should they be merged? * How is data to be put into the timeline created and managed? * UI seems to have some serious issues, such as displaying a timeline view offscreen at the top of the page instead of near the actual invocation. This'll need work. * Navigation seems a bit confusing; mostly I seem to accidentally scroll way too far and get lost in -40,000 BC. :) Probably needs some overhauling on ensuring that you don't wander away from the data.
(In reply to comment #5) > Questions: > > * What exactly does it do? The descriptions are vague and the demos are > confusing. Each syntax contains one event, and appears as a link (it is a single line and very easy to write). By clicking on it, a timeline appears in the graph at the top of the page. The graph is in JS, and it remains on the screen even when you navigate to a completely different article. This is essential, because you can add another event timeline to the same graph. For example, you put an event from American history from one article side by side an event from French history that is described in a different article. Similarly, you can add events from science, politics, art,... fields in a single graph and study their relation in time. > > * Is there a non-JS/non-interactive display available for print output, etc? > This should be considered an absolute requirement for proposed Wikipedia use. As explained above, the whole concept is to have an interactive display, and users can create the graphs they need based on the subject they study. It will allow users to produce limitless timelines according to their need. This would not be possible in a non-JS/non-interactive display. > > * What's the overlap with existing EasyTimeline extension in data formatting, > display, etc? Should they be merged? There are at least two major differences. WikiTimeline output is (1) dynamic and (2) interactive while EasyTimeline is static and non-interactive. EasyTimeline serves well in producing nice overview and at the same time presenting details of a particular event, or series of events. It is, however, not suitable in studying multiple (relatively) unrelated events. Furthermore, it can be modified only by editing the syntax, but WikiTimeline the users can easily combine several syntaxes and creat unique displays as needed. In short, EasyTimeline and WikiTimeline have different purposes, and will be used in different circumstances. > > * How is data to be put into the timeline created and managed? For each event a syntax (one single line containing begin and end date/time) will be written that creates a link. The links will be placed in the corresponding article. The users can combine as much syntaxes as they want from different articles and create their own interactive graph. > > * UI seems to have some serious issues, such as displaying a timeline view > offscreen at the top of the page instead of near the actual invocation. This'll > need work. > > * Navigation seems a bit confusing; mostly I seem to accidentally scroll way > too far and get lost in -40,000 BC. :) Probably needs some overhauling on > ensuring that you don't wander away from the data. The author may be able to assist us with these issues. I have sent him an email. I hope he checks his email regularly and sends me a reply soon.
> For each event a syntax (one single line containing begin and end date/time) > will be written that creates a link. The links will be placed in the > corresponding article. The users can combine as much syntaxes as they want from > different articles and create their own interactive graph. Hmm, that's a kind of interesting idea but there's some serious usability issues with the display and the concept is still a bit unclear. A single-purpose extension here for creating those event 'links' seems very awkward and hard to maintain, in addition to simply being very confusing for users (clicking on a link bumps the page around vertically with no explanation if you're not at the top of the page, and if you are at the top of the page the view still is pretty unclear). Being able to extract general date information so you can put *any temporal event* into an interactive timeline, rather than just some handful that have been manually annotated specifically for it, would make it much more valuable and interesting. If something like that can be done, I'd probably recommend building a timeline tool like this as a JavaScript gadget, as that'll be much easier to deploy for opt-in usage. To make this something we'd really be excited about you'd also probably need ways to save and share the built timelines; while looking at one just for fun by yourself might be occasionally useful, saving one for yourself for your ongoing research, or saving one into an article where it can be seen as a whole, would be far more useful and allows building on each others' work.
Hello! I'm the author of the mediawiki extension WikiTimeLine and was contacted by FakhredinBlog concerning this suggestion. I'm hereby giving you my full support for the integration of WikiTimeLine into en.wikipedia (or any other wikimedia branch/language). This means I will answer all your questions as good as possible, I will test it on the newest MediaWiki software and will incorporate suggestions for improvement. I will also tidy up the code (as well as write better documentation for easier review) and test it with all the newest browsers. Putting the software on svn should be no problem, if there are any other requirements please let me know, I'll be happy to fulfill them. All this will all in all take a little bit of time for me (depending on how much exactly is to do), since I'm a fulltime programmer and will need to do all this in my spare-time. But if there is interest in using this extension on any wikimedia branch I'll focus my "programming in free-time" on WikiTimeLine. As I can see, some of the questions have already been answered perfectly by FakhredinBlog! I'm going to germany in half an hour and will be gone for four days, but I'm returning on sunday and will report back next week! Greetings, Markus
It is good to have you here, Markus. Like Brion, I think the most important issues with the extension at its current stage are with regard to usability. However, incorporating the extension in Wikimedia wikis will be much easier if the code is cleaned up and standardized in accordance to MediaWiki's coding style. In order to make your extension "testable" on Wikipedia's (by installing it on test.wikipedia, for example), I think it's a good way to start with polishing the code and ensuring it works with the most current version of MediaWiki and most current versions of all common browsers.
(In reply to comment #8) > all your questions as good as possible, I will test it on the newest MediaWiki > software and will incorporate suggestions for improvement. I will also tidy up > the code (as well as write better documentation for easier review) and test it > with all the newest browsers. Putting the software on svn should be no problem, > if there are any other requirements please let me know, I'll be happy to > fulfill them. > [..] Hi. Here's some links that might be useful to you: http://www.mediawiki.org/wiki/Commit_access and http://www.mediawiki.org/wiki/Manual:Coding_conventions Cheers.
Hi! First I'll answer some questions raised and comment some of the posts. At the end of my post I'll make a proposal for date-information-standard, that is still in development by me, to be used by wikipedia in the future. This standard may solve many many problems and be more in the spirit of wikipedia, as it will be very simple to use/implement and the information would be useable by anyone and any program that wishes it to use. (In reply to comment #10) > Hi. Here's some links that might be useful to you: > http://www.mediawiki.org/wiki/Commit_access and > http://www.mediawiki.org/wiki/Manual:Coding_conventions > > Cheers. Thank's for the links! I'm currently cleaning up the code according to the standards, I hope of being able to put out a 1.0.1 version some time soon (will probably take a few weeks) with the code newly formatted and adapted to the current standards and wiki-interface as well as tested with the newest wikipedia versions and browsers. I will inform everybody here with a new post as soon as this is done. (In reply to comment #3) > From a quick browse through, it's using $_GET, $_SESSION directly, the messages > are done in the wrong way. It doesn't follow our coding guidelines, has '?>' at > the end of each file, uses old/deprecated setup methods > > And that's without me reviewing the JS As said above, I am currently adapting the code to the newest standards (if there's a not-direct way of accessing $_GET and $_SESSION directly I change the code to use the alternative). In contrast to the PHP Code, the JavaScript code is very complex, but also very good documented. I have already, by now, changed the code to only use one globaly assigned variable (in the 1.0 version it uses multiple). So since that's done, there shouldn't be much to do in the JavaScript code I think. It's pretty good tested with many browsers and I'm sure the new browsers will be able to work with it as good as the older ones did, but I'm of corse testing it anyway. (In reply to comment #5) > * Navigation seems a bit confusing; mostly I seem to accidentally scroll way > too far and get lost in -40,000 BC. :) Probably needs some overhauling on > ensuring that you don't wander away from the data. There's a little link between the two timelines that reads "show all", it ensures that the timeline zooms in to the first beginning and last ending event. So that all events are shown on the timeline as big as possible. It ensures that, if you have wandered off or zoomed in too much or lost yourself any other way, you can always click on "show all" and you're kind of 'on the start again'. (In reply to comment #7) > A single-purpose extension here for creating those event 'links' seems very > awkward and hard to maintain, in addition to simply being very confusing for > users (clicking on a link bumps the page around vertically with no explanation > if you're not at the top of the page, and if you are at the top of the page the > view still is pretty unclear). In version 1.0.1 the timeline will be displayed at the bottom of the page, so it shouldn't jump around vertically. And now to the date-information-standard, which I think is something that comes pretty close to what Brion already wrote... (In reply to comment #7) > Being able to extract general date information so you can put *any temporal > event* into an interactive timeline, rather than just some handful that have > been manually annotated specifically for it, would make it much more valuable > and interesting. > > If something like that can be done, I'd probably recommend building a timeline > tool like this as a JavaScript gadget, as that'll be much easier to deploy for > opt-in usage. > > To make this something we'd really be excited about you'd also probably need > ways to save and share the built timelines; while looking at one just for fun > by yourself might be occasionally useful, saving one for yourself for your > ongoing research, or saving one into an article where it can be seen as a > whole, would be far more useful and allows building on each others' work. ... It would be called "Open Date Standard" (I already own the domain opendatestandard.org) and, as the name says, would be an open standard. Meaning that per definition, there is no fee or charge coming along with it's use and the definition must be freely accessible. Also, it will be useable with every program wished and will not affect the programs license (you can use the standard in a commercial program, a private or an open source, it doesn't matter). I'm currently also in the development of the license which I'm specially writing for this standard. The purpose of this standard would be 1) to define per XSD how the date would be displayed in XML and 2) to define per XSD how any calender can be defined in XML and with informatin regarding its conversion of any date in this calender to a date in another calender. To put it simple, the possible outcome would be this: 1) Any website, program, database or whatsoever (in this example we'll take one Wikipedia article) will send the date information along with its html (just like rss). One date entry may consinst for example of: Description (America), From (1776 given in gregorian calender), Till (today) and is for example sent in a seperate file as xml information. 2) Any program, for example a FireFox-Extension, may recieve and read this xml data and because of the standard, is a) able to interpret the data and b) able to convert it in a date of another calender (like hebrew or arab) 3) The program may display or save the information in any calender and any form it likes. This ensures a) easy and free access to simple information b) programs now know how to interpretate this information in different ways c) programs can use this information in any way they want. By the way, by using the date information in the infoboxes and building an xml file for every article out of it we already have thousands of date-information ready for this. A little example? A teacher accesses the article of Napoleon on Wikipedia and saves the life-data with an FireFox-Extension in a file. He does the same with the start and end-dates of the frensh revolution and the founding dates of america. He goes into his class the next day and loads the data into some fancy program that can display those dates in a pretty way and shows the timeline of those events to his pupils... and hopefully they all make "wow" and have it a little bit easier (and with more fun) to learn history than we did ;) So... the standard would of course be totaly independend of wikipedia, and its coming anyway... but I think it would be very usefull to wikipedia! What do you think? greetings, Markus
re: date standardization. Don't such things already exist - [[w:ISO 8601]] for an unambiguous way of writing dates - Microformats (or Microdata/whatever fad it is today) for embedding dates in html, or if really set on a pure xml format - rdf.
(In reply to comment #12) > re: date standardization. > > Don't such things already exist - [[w:ISO 8601]] for an unambiguous way of > writing dates - Microformats (or Microdata/whatever fad it is today) for > embedding dates in html, or if really set on a pure xml format - rdf. All that is defined by these standards is a possible way of writing down date information. ISO for example doesn't tell the software anything about the calendar in use or even that it's a date at all, even if that's a logical thing for human eyes. Microformats like hCalendar are very limited in it's possibilities and use html. The thing about the "Open Date Standard" is, that it will be able to describe any calender with microseconds being the only universal unit. If there is a calender out there that doesn't have days, or it's days are of different length (imagine a calendar for Mars with a 25 hour day), than it still wouldn't be a problem. The "Open Date Standard" doesn't only define how to write down a date and tell the software which kind of calendar to use, the most important thing about it will be the ability to define calendars in xml and the posibility to convert a date from one calendar to another, simply by reading in the xml definition of the two calendars. So, as a user, you don't have to think about different calendars any more. Even as a programmer of a "Open Date Standard" library you don't have to think about the definitions. As long as you implement the standard correctly, the XML definition of calendars will cover the complex part of calendar convertion, date displaying and date reading. Hell, it shouldn't even be a problem of implementing the mayan calendar... as long as it's done before 21 December 2012 of course ;) greetings Markus
Markus: https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment might be helpful to see what's needed for deployment and how to approach it.
