Congratulations! Your proposal has been selected for an Individual Engagement Grant.
The committee has recommended this proposal and WMF has approved funding for the full amount of your request, $500.
Comments regarding this decision: Very generous of you to donate your time for this project! We look forward to supporting your progress and seeing the user-feedback on this tool.
Next steps:
You will be contacted to sign a grant agreement and setup a monthly check-in schedule.
(B) The project has the potential to lead to significant online impact.
3
(C) The impact of the project can be sustained after the grant ends.
4
(D) The project has potential to be scaled or adapted for other languages or projects.
5
Ability to execute
(E) The project has demonstrated interest from a community it aims to serve.
2
(F) The project can be completed as scoped within 6 months with the requested funds.
4
(G) The budget is reasonable and an efficient use of funds.
4
(H) The individual(s) proposing the project have the required skills and experience needed to complete it.
3
Fostering innovation and learning
(I) The project has innovative potential to add new strategies and knowledge for solving important issues in the movement.
3
(J) The risk involved in the project's size and approach is appropriately balanced with its potential gain in terms of impact.
3
(K) The proposed measures of success are useful for evaluating whether or not the project was successful.
2
(L) The project supports or grows the diversity of the Wikimedia movement.
2
Comments from the committee:
A better visualisation method for article-histories is a field ripe for experimentation.
Appears to be an improved version of Wiki Blame with animation. It would quite interesting to visualize the process how articles are evolved.
Could this tool be finetuned to help detect copyright violations? That would be helpful.
Tool may be useful for patrolling for vandalism, other benefits remain undemonstrated.
The measures of success and intended impact that the proposer has listed seem incorrect. Why should number of edits increase?
Budget for UI design appears to be unrealistic.
How it will get into the ecosystem of MediaWiki and incorporate with related tools such as Visual Editor is unclear.
Would like to see the proposer demonstrate more familiarity with Wikimedia and MediaWiki.
Fighting copyright violation :This seems like an interesting feature to have in the tool.An edit could be googled and relevant data could be brought up , flagging the edit or otherwise.I'll add more details as I work on it.
Benefits beyond patrolling vandalism :It'll help in reviewing the edits made to an article faster in general , not just to catch acts of vandalism.When a big revision is being done to an article , we break up the edit into smaller edits and save them.The tool would make it easier to compare the smaller edits we make.
Incorrect Metrics :As mentioned in above , when large revisions are made to an article we break the edit into smaller edits , the time taken in comparing them will become lesser if the tool is used.Hence the time taken to make substantial edits will decrease . So I felt ,if the time taken to make the edits decrease , then indirectly there will be more edits (Is this a fair assumption ?). I guess the indirect effect will be hard to measure and attribute and I will accordingly change the measures of success .
Budget for UI/UX :Im budgeting 20$/hr for a UI/UX professional (Average Indian rate). I think it involves 20 to 25 hrs of work spread over 2 weeks.So a total of, 20 * 25 = 500$ . My initial ask was for 200$ , less than half of the new amount requested . I was hoping since the work was for wikipedia they would agree to a cut. After talking to Siko , I have decided to increase the grant request to 500$ .
Integration with Mediawiki ecosystem and Visual Editor :The tool will be a mediawiki gadget , it can be easily accessed by the users from their preferences/gadgets . It can also be rolled out to other wiki's after enabling it on the english wikipedia by asking the respective admins to add it to the list of gadgets.The visual editor and the tool are addressing different problems.Trevor from the Visual Editor team had the same view too.The fundamental idea of the tool is to visualise the edits made to an article , whereas the visual editor wants to make it eaiser to make edits to an article , they will co exist with each other as different tools in a toolbox.
Increasing familiarity with Wikimedia and MediaWiki :As the first step I have started using my global account Jeph Paul which has been dormant for a long time now ,I will start talking to people on the village pump and other venues possible. Jeph paul (talk) 12:28, 17 March 2013 (UTC)Reply
Thanks for the updates, Jeph. I think it is going to be very difficult to demonstrate success after 6 months with the measures of success you propose, because any additional edits made would indeed be pretty indirect as a result of the tool. However, it seems that the committee does feel that the tool would be of use to editors, possibly including vandal fighters. What about changing the measures instead to something like: 1) Gadget available on at least x # of language versions of Wikipedia (it could be just 1, if we don't feel confident there will be interest beyond English at first), and 2) Positive feedback from x # of users demonstrating the tool is useful (you set your own target of the numbers of users you're planning to engage with in the first 6 months). Does that seem reasonable? To me, that would demonstrate that after 6 months you've built something of use to members of the community, and this is the value I believe the committee is seeing in your idea. Siko (WMF) (talk) 19:05, 18 March 2013 (UTC)Reply
Latest comment: 11 years ago5 comments3 people in discussion
Hi. As far as I understood, the proposed tool will offer a visualized representation to what Wikiblame tool is offering right now. This is nice, but I am still not sure how the new tool will help to increase edits, as the tool is most likely to be used only when investigating vandalism? Thanks. --Haithams (talk) 19:38, 11 February 2013 (UTC)Reply
It will be visually much more than just searching through the edits.It will be more like a movie being played out , showing the edits as they change. Of course it will be useful to detect vandalism , more importantly it will let an editor view and go through a large number of edits in a very short time. In the current interface going through more than a few consecutive edits takes a lot of time.Going through 100 consecutive edits is going to be really difficult .I'm trying to address that with this tool.Also if someone wants to know how an article evolved this will be really useful.--Jeph Paul19:14, 12 February 2013 (UTC)Reply
Would it be possible to make some mock-up images of the visualization of the replay? Since the way it will present edits seems to be an important part of the proposal, it will be great if we can share the idea clearly by images. --whym (talk) 12:54, 13 February 2013 (UTC)Reply
A Mockup of the tool. This show an edit that happened on the wiki page 2013 Russian metero event .The tool has two buttons a forward and backward , the forward keeps adding the edits from the current edit & backward does the opposite . There is a slider which can be used to set the point from where to start adding/removing edits.The word being added , deleted or modified will be highlighted.Also the div/container will scroll to show the content being modified .--Jeph Paul14:06, 15 February 2013 (UTC)Reply
Latest comment: 11 years ago1 comment1 person in discussion
Hi there - just a reminder that the deadline to finalize proposals is 15 Feb 24:00 UTC. When you've completed your budget and other sections and are ready for final review, please update status in the wikimarkup of your page from DRAFT to PROPOSED. It is also ok to keep drafting this for a proposal in Round 2, if you won't be ready for Round 1 review by the end of this week. Thanks! Siko (WMF) (talk) 19:34, 12 February 2013 (UTC)Reply
Latest comment: 11 years ago2 comments2 people in discussion
Thank you for an interesting proposal! You mentioned the target user would be "Every user how wants to make an edit". This is great but, at the same time, it could be challenging from a computational point of view. It would serve a lot more people than an editor-only feature would. You mentioned that "the module does not burden the servers with excess load". Could you talk a little bit more about how it will avoid excess load? What will be computed in the client side and server side? Not everything needs to be specified at this early stage, but I think assessing feasibility to production implementations is important for this kind of proposals. --whym (talk) 13:19, 13 February 2013 (UTC)Reply
Initially when I got thinking , I wanted to get the wikitext of each edit and parse it locally completely in js, but after some reading I found that there is no library , that fully implements the grammar , hence there will always be some cases that are broken with this approach. I was prototyping the other extreme with the parsing for each edit being done on the server side using the mediawiki api , I guess this puts a lot of load on the server especially if a number of people start using it.
One possibility I'm thinking of is to parse wikitext of small length on the on the client side (assumption being it has no nesting etc) and parsing long wikitext edits on the server. (This may not guarantee 100% correct output , but will be accurate to a great extent)
Another idea I've had is to use emscripten and generate the mediawiki parsing module in js. (No idea if this is even possible)
The tool will be built in js , making api calls. It would be a standalone tool and maintained as a user script or a gadget.But ultimately I want it to be integrated into the edit page of a wiki page as part of the editor , only then will it be able to get maximum reach . Till then temporarily we can have a special page like ApiSandbox , where people can try it out.--Jeph Paul12:26, 16 February 2013 (UTC)Reply
Latest comment: 11 years ago7 comments3 people in discussion
Hi! You've noted that you plan to do the development work for this project pro-bono. As such, I'm wondering why a grant is needed. What is the $100 for, and what support do you believe a grant will provide that you cannot do as a volunteer now? Siko (WMF) (talk) 02:02, 18 February 2013 (UTC)Reply
Im a developer by profession and design/UI is not my forte . So to make a tool that will be used by a lot of people it is really important to get its UI/Ux right . For this I need a designer to work with me. I have spoken to a few people and they have agreed to help me out on this front , taking a big pay cut , hence the $100 figure. Besides ,the grant will give the tool a greater visibility during its development phase , makes me accountable and ensures its successful completion on time.--Jeph Paul10:48, 18 February 2013 (UTC)Reply
Thanks for these responses, Jeph. Could you please update your project plan to clarify the use of the budget that you've described here, and also make clear that you are planning to complete this as a script or gadget making API calls as described above. Although I understand you would like to take the project further with more integration in the future, it would be important to clarify in your plan at this point that that is outside of the scope of the grant period. Then, I'll be able to mark your proposal as ready for review. Siko (WMF) (talk) 20:46, 18 February 2013 (UTC)Reply
I have made the requested changes , added the clarification to the budget spend and made it clear that it will only be a standalone tool.--Jeph Paul09:17, 19 February 2013 (UTC)Reply
The tool would need to undergo the feedback and maintenance stages. They could take a long time, from a few weeks to a few months to get the tool polished for Wikimedia projects; I'm pretty confident that it would get thorough feedback and ideas for improvement. Are you confident that these tasks would fit into your budget? Thanks. Gryllida23:45, 18 February 2013 (UTC)Reply
I have bumped the budget to $200 , as a buffer in case the cost of a UI designer escalates , but I strongly believe this should be enough.--Jeph Paul09:17, 19 February 2013 (UTC)Reply
Latest comment: 10 years ago6 comments4 people in discussion
I am very puzzled by the notion that this tool would make editing easier or faster, or that it would increase the number of edits submitted. Do you review an article's revision history before deciding whether or not to save an edit? I certainly don't, and I can't understand why anyone would. The revision history and diff tools are useful for a number of things, but making substantive edits has never been one of them.
I also don't understand how this tool would improve the editing experience for the new or casual user. From what I've seen as an ambassador, the problem with the revision history is not that newbies can't figure out how to use it, it's that they don't even know it's there. They don't notice the tabs at the top of each page, and if they do, they've never explored what they are. The only reason that a novice would really need to be able to use the revision history is if they wanted to self-revert a mistake, and that doesn't require a tool like this.
In short, I can't figure out who would actually benefit from this tool. I don't mean to be harsh, but even if it worked perfectly, it seems like it would be fun gimmick without any real value. --Cryptic C62 (talk) 20:56, 19 February 2013 (UTC)Reply
There are two use cases where I think the tool would be very effective
To look at revisions happening to an article that is fast developing (in the news currently).It will have a large number of revisions and comparing them will be a painful task.
To know how an article has evolved over a period of time. This is very difficult to do with the current revision comparison interface.
The tool is a fundamentally different approach to showing the changes between two revisions.
A person who makes a reasonable number of edits on a page will compare the revisions a lot , the tool will surely help him .The tool will cut the time he needs to go through the changes .Hence my contention that it will make the task of editing faster.
The mockup of the tool has a simpler UI than the present revision comparison page , if a "newbie" user gets to the history section he will find the experience more intuitive and engaging. It will not directly bring more people to the history section , but since I believe the usability will be better eventually more people will end up using it , helping improve the discover-ability of the history tab in the long run.
"A person who makes a reasonable number of edits on a page will compare the revisions a lot" This sounds to me like giving a potato peeler to a blacksmith: a kind gesture, but utterly impractical, as it is based on an understanding of the blacksmith's behavior that is simply not accurate. --Cryptic C62 (talk) 21:21, 20 February 2013 (UTC)Reply
In the past , while editing articles I have felt the need for such a tool , I believe there are a number of people who would use such a tool if they had access to it .--122.172.50.116:13, 21 February 2013 (UTC)Reply
I can acknowledge that I often want to know "who added this word or category to an article" and end up manually navigating its history, showing diffs, clicking "Previous diff" a few tens of times - having an ajaxified and clear interface to visualize this would be a plus. Having such tool would also help Recent Changes Patrollers to double-check which edits to undo (one last one, a bunch of last ones made by an IP, or more). -Gryllida02:14, 22 February 2013 (UTC)Reply
" One thing that might be neat is have the slider overlayed on top of a 2D graph which shows article size plotted just as a filled line graph. Then you can easily "dial in" places where the article size shot up or down, and see what changes were made. I find if I'm looking at an article history, often I am scanning past all these little changes just looking for who is adding big chunks of prose " suggested by Silas Ropac on the (Village Pump).
Another cool feature would be to have a time scroll bar, so you can quickly scrub through the timeline and skip the boring edits or, better yet, scroll through them with your mouse wheel.
Would a pause button with subsequent information display be good to know who in particular added a certain phrase? I see the progress, but not its authors. I understand this may be a thing which you already planned. Gryllida08:39, 20 August 2013 (UTC)Reply
The source code has no comments inside. It could be easier to maintain if at least each function had a description of what it does, if not each block of code. Gryllida08:39, 20 August 2013 (UTC)Reply
Adding support for other projects — just one or two fields for user to input which — sounds like a good thing to think through at the beginning, just to make sure your code allows for such additional option without overheads. Gryllida08:48, 20 August 2013 (UTC)Reply
Other projects such as ar.wikibooks, fr.wikipedia, etc. User can either enter the 'fr.wikipedia.org' string and you check it, or you add two dropdowns (language + project) and the user selects them. Gryllida21:35, 21 August 2013 (UTC)Reply
Hi, since this looks especially interesting for teaching purposes, can you please add other languages as well - even just for a limited set of articles? Some Italian Wikipedians are very interested in this! --Elitre (talk) 10:46, 30 August 2013 (UTC)Reply
Added Dutch, Espanol, Francais, Italiano, Deutsch, Polski, Portugues, Svenska, Suomi, Catala, Winaray, Romana, Esperanto, Dansk, Slovenčina, Türkçe, Bahasa Melayu, Simple English. I haven't tested it much, but I think they should all work.--Jeph paul (talk) 14:30, 9 September 2013 (UTC)Reply
I love it. love it love it love it!! Please can you add the edit number to the page somewhere? It gets confusing to keep track of it. Maybe also if text is replaced, to animate the old text being backspaced before the new text is slotted in.--Coin945 (talk) 18:26, 20 August 2013 (UTC)Reply
+1 to the request for adding an edit number (=revision count, and potentially some other meta data like who made the edit) on the page, it would be helpful for playing back longer articles to know more about which revision we're seeing at any given time. Fun seeing this tool come to life, Jeph! Siko (WMF) (talk) 19:52, 21 August 2013 (UTC)Reply
Added revision metadata, author's name, date, minor, anonymous and link to the revision to the tool, it appears as a fixed box on the top of the page.--Jeph paul (talk) 18:04, 24 August 2013 (UTC)Reply
Great work Jeph! It'd also be neat to be able to start the animation from any point in the article history, for example, if I only want to see the most recent 50 edits. Cheers, Ocaasi (talk) 22:20, 21 August 2013 (UTC)Reply
The mockup shows a two level edit selector bar. The primary bar will show all the edits, the edits will be of equal width with their length varying as a measure of the size of the edit Eg If there are three thousand edits all of them will be shown with a width of 1px or so.
There is a slider whose width is adjustable which serves to select a subset of the edits.
The selected edits will be shown in a zoomed in view above the primary bar, here the edits will be bigger in width and easier to view, If the user selects the entire primary bar then the zoomed in version will look like the primary bar.
A handle bar in the zoomed in view, it can be used to select the starting point of the visualisation or to manually go through the changes edit by edit.
A mockup of the slider in the visualisation tool
A Slider showing the time between edits in the selection. The gap between the bars in the zoom in is proportional to the time between the edits, I'm not sure on how exactly to tell the user what the value is.(The slider show the edit history of George W Bush, you can see the vandal/ back and forth edits in the article)
As an experienced editor, it seems very weird to see a template grow i.e. a disambiguation template where the text gradually appears, since the editor is not actually writing that text. And it also makes the assumptions that people are editing from the beginning to the end, while in reality they might perhaps start adding sections and then fill them in. To solve both these, just skip the animation 'within' each diff. It would make the visualization more truthful. --Ainali (talk) 05:08, 23 August 2013 (UTC)Reply
Meaning to say , people add the sections & then add the content to each section before saving. Hence showing the animation from top to bottom in a diff might not be a true representation of the chronological order ?--Jeph paul (talk) 11:12, 24 August 2013 (UTC)Reply
Agree! It would be more accurate to show the entire change from any given revision fading in all at once, rather than typed 1 letter at a time chronologically (because all we know from a given diff is that everything added/removed in that edit happened, but not in which order). It would also take less time to see 1 revision if all changes from a given diff faded in at once, which seems nice when you're visualizing a page with hundreds of revisions :) Siko (WMF) (talk) 18:34, 26 August 2013 (UTC)Reply
If all the changes in a revision are faded out/made to appear at once , the changes that have happened in the part of the page that was not in the viewport/window cannot be seen , to see them the page will have to scroll to bring those parts into the view.So if all the changes are shown at once, the changes not currently in the screen will be missed. The template growing is really odd, I'll try to do something about it.--Jeph paul (talk) 19:59, 26 August 2013 (UTC)Reply
I encourage you to switch to Wikimedia's bug tracker (bugzilla.wikimedia.org), tool-building infrastructure (tools.wmflabs.org), and possibly our source control (mw:Gerrit). If you'd like to have lots of people use your service, you'll benefit from being in the same ecology as lots of other Wikimedia projects. Sharihareswara (WMF) (talk) 17:04, 26 August 2013 (UTC)Reply
Right now the buttons Edit and Edit beta is animated, which is really strange, I am pretty sure that is not what the user wrote :) Is there a way to just not show them at all? They do not add any value for the visualisation. --Ainali (talk) 05:11, 11 September 2013 (UTC)Reply
My attempt is an experiment in making it easier for user to understand the changes. Time will say what the best way to do it is, showing them side by side, an animation like the demo, the current interface or something none of us have yet thought of. I think it is important we explore all the different ways, someone should surely code up your idea too :-)--Jeph paul (talk) 20:08, 27 August 2013 (UTC)Reply
This approach however has a number of difficulties.[1][2] A really useful tool would just show (visual?) diffs one after the other in infinite scrolling. --Nemo07:08, 16 December 2013 (UTC)Reply
Latest comment: 11 years ago2 comments2 people in discussion
Would it be possible to apply filters such as "only bot edits" or "only template edits" or "only category edits". Thanks for your work on this - as a frequent editor, I would find it highly useful. Jane023 (talk) 09:53, 20 October 2013 (UTC)Reply
"only bot edits" is possible, I'm not sure about the other two. Skipping 'bot edits' in the playback would work, but playing back for example only bot edits may break the animation as, the normal scenario is probably like Bot---50 user edits---Bot. This will make the playback discontinuous. As part of the tool a slider has been built. Here the bot edits could be highlighted with a diff color etc. Would like to hear your ideas :-)--Jeph paul (talk) 03:13, 31 October 2013 (UTC)Reply
The tool currently looks as show in the image (screenshot of the actual tool, but not yet released). The original plan was to make it into a gadget and in the short term it will be. Would it be possible to put it on tool labs and provide a link to it on the history tab like the other external tools? --Jeph paul (talk) 19:21, 2 November 2013 (UTC)Reply
Good question. I would personally expect a gadget necessary for things that integrate themselves into interface. Would this one need, or make use of, integration with interface more than just "click this link to view the replayed edits"?
Having either of these two added would require community consencus on the target wiki.
(For more opinions, you may want to ask wikitech-l. Simply link them to this section.)
It appears a gadget format could be suitable, but design work may be required to fit the tool into a wiki content view container. It's currently occupying the whole web page. Gryllida (talk) 03:19, 11 January 2014 (UTC)Reply
Please try out the tool as a 'gadget' currently a userscript by pasting importScript( 'User:Jeph_paul/common.js' );importStylesheet( 'User:Jeph_Paul/common.css' ); into your custom.js on english wiki :-)--Jeph paul (talk) 16:39, 11 January 2014 (UTC)Reply
Latest comment: 11 years ago1 comment1 person in discussion
The initial plan was to retrieve the wikitext through the API and turn it into html completely on the client. But as it tuned out to be rather difficult due a variety of reasons, it was decided to fetch the parsed html of a revision of an article using the wikimedia API. The first prototype was working from the beginning of time of an article and each request took under 2s. Now that the tool shows the latest edit first (the image above) fetching a revision when the article has become big takes a lot of time, upwards of 10s. Pre fetching or making the user wait till a reasonable number of revisions have been fetched are the alternatives. Parallel requests are not encouraged. I'd love to hear ideas on how to get around this. The latest code is in github, wikireplay--Jeph paul (talk) 19:50, 2 November 2013 (UTC)Reply
In the main page, make the ENTER key trigger the "Load Edits" button;
If you swap the position of the username and the date inside of the controlsInfoContainer, the position of that text will not change as much as it does now while playing the history (because the dates have approximatelly the same width, but user names can vary a lot).
Latest comment: 10 years ago7 comments5 people in discussion
I like the general look of the new design. However, I think the main action (i.e. play) should be a little more prominent, including a bigger click target. Also, the play button should not be greyed out (except while it's loading). This made me think it was disabled.
I also wasn't sure how the selectable graph at the bottom related to the rest of the UI. I think it's the range of playback, but tooltips and possibly label would help (this goes for the rest of the UI too). Superm401 | Talk05:45, 17 December 2013 (UTC)Reply
+1 to all these. I like the new look, and appreciate the hard work that went into the functionality! But I found it pretty confusing to use at the start - seems like some labels and color would help, for calls to action
It isn't super clear what the difference between the 2 sliders are, or their relationship.
Took me forever to find the play button (it looks like a sideways collapse button, more than play arrow, to me, and it is so small and gray, it didn't call my attention...I waited a while thinking it would just autoplay before I started random clicking).
Then, while it was playing, I wanted to pause on an edit, wasn't sure exactly how to do that so I clicked on a diff in the bottommost slider (I now know I was supposed to use that tiny pause button). What I did indeed has paused me on one edit, and then I couldn't get it to play again after that (perhaps this is a loading issue, and the progress bar will help with that?)
Wondering what you decided to do with the language selector for articles? I liked having that feature in the prior version.
Hey Jeph, very slick design! Maybe even... a touch too slick. It really needs clear labels that tell the user what to do. What is each element, what does it do for the user, and how does the user interact with it.
On the landing page, I want to know what this tool is? Replay Edits: Watch Wikipedia Evolve.
Rather than "load edits", I would prefer something more aspirational or clear. 'Load edits' makes me think I'm seeing a list rather than an animation. Maybe an active verb form like "Watch Wikipedia Change".
Also, I'm not sure "Random" is so obvious. Do you mean "Random article?" How about something lighter like, "Surprise me".
On the main page, the good news is that the animation is terrific. It's smooth and polished. Excellent work.
Things that need some attention: The play button, the single most important piece of that UI is sandwiched between two very detail-heavy graphs. Play should be extremely obvious, since that's more or less the only thing users are there to do.
I'm pretty much expecting the animation to auto-play on page load, and was surprised I had to click a button at all.
I would like an easy and obvious way to pause the replay, I'm not sure if there is one, or what it is.
When I click the play button, I then see a larger flashing play arrow. Am I supposed to click that? I thought it was maybe a loading symbol but it had a play button. Loading icons are usually progress bars or spinning circles of some sort.
I'm also confused by the fact that there are two horizontal history graphs. How are they different? Could you get away with just one?
The link to the diff is very cool! But that number alone will not mean much to people, even though it's blue. Maybe label it, Link to Wikipedia, or something more clear.
I'd like a basic info/about page with some summary of the context that explains a few very key things: 1) What is Wikipedia; 2) What is a Wiki; 3) Why do pages have 'history'; 4) What is a 'diff'?; 5) How can people get involved?; 6) Who created this tool (Jeph, IEG), and why did you create it--what purpose does it serve, or goal achieve.
Lastly, is there a way to adjust the replay speed?
Overall, this is such a fun and neat tool with great functionality and teaching potential. I just hope the finishing touches make it as easy and clear to use as it is cool and well programmed. Cheers! Ocaasi (talk) 19:52, 17 December 2013 (UTC)Reply
Hi Jeph paul, this i really fantastic! Congratulations! I watched some random article histories and it's great. I was confused by the UI too, the suggestions above are spot on.
I would expect a big prominent play/pause button and more descriptions.
For example: "revision no. 123456" instead of just the number "123456" (with the link to the WP revision, awesome!).
This should be bigger and provide more info
I noticed a lot of bot edits. Since I read a lot of revision histories, i do recognize the bots, but new users and especially readers won't. There is a nice tool by User:Edsu, wikistream: http://wikistream.wmflabs.org and it uses little icons to show the type of editors (bot, registered user, IP). I don't know how he does it and if this is difficult, but this would be terrific next to the editors:
Would you be able to find greyed out and coloured versions of the icons above, they look really nice ,we could use them as buttons themselves.--Jeph paul (talk) 17:31, 22 December 2013 (UTC)Reply
Hi Jeph paul, let me see if i understand this correctly. You want to have greyed out user icons, so that you can give them different colours and assign each user a differently coloured icon? That's really clever! (Why didn't i think of that? :-) ) I'm sorry that this is beyond my design abilities. The first 3 icons above are Creative Commons CC0 and were created by User:Notafish / Delphine Ménard, maybe you can ask her for help. The other icons are also freely licensed (Gnome-stock or tango icons). I really like your colorcoding idea! I would recommend to stick with grey for the bots though. --Atlasowa (talk) 18:55, 29 December 2013 (UTC)Reply
The timeline was very unclear to me. How much time passed between the edits? This information is lost because it jumps so fast to the next edits and without a visible "bump". Often it is quite interesting at what date a change was made, how long there are no edits at all and then how there is a burst of edit activity in a short time. A tool that uses a sparkline for visualizing this is
One question regarding "Make revision link meaningful": Did you consider linking to the diff XY vs. linking to the revision number XYZ? Wikipedians would mostly prefer to look at the diff (IMHO), but that would mean looking at wikitext (which readers and newbies might find confusing?). Just wondering. --Atlasowa (talk) 19:30, 29 December 2013 (UTC)Reply
Simulating text input speed / single-edit session length
Latest comment: 10 years ago3 comments2 people in discussion
I love the latest improvements, and I agree with the above UX suggestions.
Something that the current version doesn't provide to the reader is a sense of time spent per revision: whether a user is fixing single typo or adding an entire block of text, the change happens instantaneously. I am wondering if simulating text input would produce a more realistic experience. User:EpochFail may have some relevant thoughts here based on data from edit sessions. DarTar (talk) 21:33, 19 December 2013 (UTC)Reply
Metal Umlaut edit visualisation, August 2013, Jeph paul
"simulating text input" - isn't that exactly what the replayer already does?
Latest comment: 10 years ago2 comments1 person in discussion
Regarding the need for more information in the replay tool, how about this: Currently, after clicking the load edits button (which is not the best name, "replay edits"? "show edit history"?) or random button (better "random article history"?) there is nothing happening at first. It would be great to get (a) some overview information about the article's edit history and (b) some short guidance about using the replay tool. For (a) there is the fabulous "page information" for any article in any language Wikipedia, i.e. "page information" for the english article "Metal umlaut", see section "Edit history":
Page creator 81.77.207.173 (talk)
Date of page creation 12:18, 15 April 2003
Latest editor 99.47.70.89 (talk)
Date of latest edit 19:12, 20 November 2013
Total number of edits 1,852
Total number of distinct authors 1,140
Recent number of edits (within past 30 days) 0
Recent number of distinct authors 0
You could easily turn this structured data into a short overview text:
The article Metal umlaut was created on 15 April 2003 by user 81.77.207.173. Since creation, the article was edited 1,852 times by 1,140 distinct users. In the past 30 days there were 0 edits by 0 distinct users. The latest edit was on 20 November 2013 by user 99.47.70.89.
Replay the edits by clicking the play button and pause by clicking on the pause button . You can choose a different starting point by clicking into the timeline at the bottom.
Oh, i just saw in the current version that you already have an overlay that slides down from the top of the page, perfect!
Replay edit history
The article Metal umlaut was created on 15 April 2003 by user 81.77.207.173.
Since creation, the article was edited 1,852 times by 1,140 distinct users.
In the past 30 days there were 0 edits by 0 distinct users.
The latest edit was on 20 November 2013 by user 99.47.70.89.
Replay and pause by clicking /
You can choose a different starting point by clicking into the timeline at the bottom.
Just add the info text and show it when starting the replayer. Leave it open for ~5 seconds for reading, then make it slide away to the top and automatically start the play button. :-) --Atlasowa (talk) 15:40, 3 January 2014 (UTC)Reply
Latest comment: 10 years ago16 comments3 people in discussion
Parul's new mockup
Wow, just saw the new changes, very nice! Some comments:
(1) The "random" button has disappeared. This looks very clean, but i actually liked the "random" idea. It would be nice to click a "random" button that fills in a random article name in the input field, which you can than replay by clicking the "show history" button. And if you don't want this random article, but another random article - just click "random" again for another article name. BTW, the blue "show history" button doesn't look like a button.
(2) The new 4 small graphics/pics look really nice and inviting!
"Enter article name" (the graphic actually looks different than the current design, different button placement)
"Place the peg on the edit to play"
"Click Play"
"Enjoy viewing edits!"
At first sight, i thought the pics were alternative options (to click on), not a step-by-step flow explanation. You might want to add little arrows between the pics/steps to make this clear.
(3) There is now a small link at the bottom "Replay Edits", very good. Maybe add "info: " to the link to Replay Edits (but this is a matter of personal preference i guess?).
(4) When i click the blue "show history" button, the screen slides away to the top, but when i touch the top slider it is gone/disappeared. Instead i get the input field with my chosen article name and a blue "load edits" button (now it's "load edits" and not "show history"?) See also my section above, #Show general information popup box while loading.
Would the user want to see the entire page again ? Showing the entire page seems like a better user experience.
(5) I tried to replay "matress", which is a redirect to "mattress". The replay output was confusing: 1 edit in 2005, nothing to see, "#redirect" code not shown. Maybe redirect the replay too? Or if i would see the edit comment (redirect) by user RedBLACKandBURN, that would help too.
We need to do this for sure. Currently if the article does not exist the tool does not give an indication or any article suggestions either. We'll have to add all the three (redirection, suggestions, non existent title).
(6) Right now, the play button is still not very prominent: no colour, a small black triangle (in the graphic explanation it's orange?), very small click field.
(7) When i click the play button: How about a spinning wheel or the RefToolbar spinning throbber? The appearing/disappearing play icon is confusing when you have a delay and nothing happens.
The play/pause icons were supposed to give the user an indication (Eg, when the user mover the slider in the overview at the bottom the playback is paused.) It's not giving the user the right message, many people tried clicking them even though they were supposed to be only notifications. We'll try to come up with a better way.
(8) The timeline goes from right to left, which is really weird! (2013) ....... (2007) Actually, both timelines do. That is not intuitive (imo?).
This is something we are figuring out too. Would flipping it (2007) ..... (2013) be a better idea ?
(9) "Place the peg on the edit to play" Right now, you actually have to choose/mark a timewindow on the timeline at the bottom...? Which is then shown in the other smaller timeline... where you can actually click "on the edit to play". Is this the definitive design or still under construction?
T:hat's what we have come up with as yet, If you have an alternative we'll implement it & try it out.
Feature requests:
(10) edit comments are really valuable additional information, "typo", "changed categories", "putting the last section further up", "added refs" etc. Readers don't even know what "M" means (minor edit).
(11) Provide a "shortcut" play button to only "replay last 6 months" and/or "replay last 20 revisions". I think these will be popular use cases. Do we have a guess how long it takes to actually replay an article with 2000 revisions: hours, days, weeks? What is the average/ mean number of article revisions?
This is interesting. In fact even in the overview we are currently loading 500 edits at a time. Is 500 even necessary ? Would just 100 suffice ? Can we have button for years (2009,2007,2006 etc expand and show the edits on clicking the button instead of loading them by dragging the slider)
I don't think we can estimate how long it would take to play 'x' edits across articles. (Some maybe small , some large)But we could try doing them on an article by article basis.
I don't yet have a number for the average number of edits per article. We should spend time on this & then optimise the UI for that number if possible (The way the edits are loaded in the overview graph, the number of edits being loaded each time). We should probably look at the mean number of edits per article in articles with a minimum number of views/edits etc, to discard articles with 2 or 3 lines/ few edits over the years.
1,2,3,6,10 Are valid and don't need a comment :-) Shall we make a questionnaire with q's about the UI of the tool & send it to people ?I haven't done it before. I guess it'll help with publicity & we could ask specific q's at the same time too.
Hi Jeph paul, I think a questionnaire is a good idea. I think formulating specific questions about the user experience is very useful by itself, because it makes one think about specific options and solutions. We should also ask how people would like to use the tool ("likely use cases"). For example:
- "look at what i did!": a replay-permalink of "my Wikipedia edit" to share on talk pages or via twitter etc?
- show me 1 examplary edit history in less than 4 minutes. Just to see how writing Wikipedia works in general. (example article: short, not so many revisions, not too many templates, with refs, ...?)
Brainstormin' :-))
BTW, I like the "replay edit" logo (shouldn't this be "replay editS"), why not take this play button design (similar to in black) for the tool? --Atlasowa (talk) 16:24, 13 January 2014 (UTC)Reply
I think the Internet archive is a good example. I don't care so much about top vs. bottom, but the general timeline design is good: clear and space-economical. That's what i like at the wikidashboard design too (see on the right). --Atlasowa (talk) 16:24, 13 January 2014 (UTC)Reply
Sorry about not replying earlier, I'm working on adding the language selection back. I'm also working on making the search for articles friendlier on the homepage & changes to the slider. I'll add a dropdown for sister projects after I'm done with these changes.--Jeph paul (talk) 17:40, 28 January 2014 (UTC)Reply
Should we be adding support for sister projects ?Commoms for example does not have a lot of textual content changing, whereas in the case of wikibooks the changes are across different pages. Wont it be of very limited use in the sister projects ?--Jeph paul (talk) 19:01, 3 February 2014 (UTC)Reply
Jeph paulOn Commons it would be tricky but I think it would be rather intuitive and useful on them all anyway, such as to see copy-editing or reviewing progress. --Gryllida08:45, 7 February 2014 (UTC)Reply
Latest comment: 10 years ago2 comments2 people in discussion
Great meeting you yesterday Jeph. The new version looks a lot more attractive than the older one I saw. Adding some of the things that came to mind.
Allowing single stepping when you hit the pause button.
Showing links to the diff between the version being played and the previous version
Nice to have - kind of like a bruteforce (ie not binary search) blame tool - allow for tracking the presence of absence of a text that is entered - in the corner of the box as a little glow indicator when text is is present.
Left-older and right-newer is I believe easier than the opposite or stack-like models that geeks are familiar with.
I second Shyamal's suggestions. I believe this tool has immense potential for us DYK contributors to view the progress of the article as well as for reviewing the article. I was wondering, maybe you could incorporate a few features of en:WP:DYKCHECK, such as word count et al? ----Rsrikanth05 (talk) 17:08, 16 February 2014 (UTC)Reply
[ I am writing a second time. Last 1 time I brought this up it was ignored. ]
Please put one timeline across the entire width of the page, not two (the time range to replay may be specified by two "pegs" in that). Look how the wayback machine does this:
Please put the timeline from left to right, not from right to left. This is confusing to two people who tried to use this tool. Again take a look at how the wayback machine does this:
The tool appears to be slow. When I click a page revision, it takes around 5 seconds to load. Is that intentional, or would you like to consider hosting the tool on Labs and querying a database replica?
Occasionally I'd like to know who contributed to a specific section, but the tool keeps scrolling off to the current edit position. I'd like to suggest window split, so that I can see current edits in the top part and a position of choice at the bottom.
Latest comment: 10 years ago1 comment1 person in discussion
Dear Jeph Paul, This is related to the past request to use a single time line instead of two, and to see window split. I would like to be able to click the time line and see a single revision so that I can narrow down the time range required to a more narrow range, and only start replaying then. --Gryllida00:04, 1 October 2014 (UTC)Reply
Latest comment: 9 years ago6 comments5 people in discussion
Add support for replaying edits at sister projects in other languages.
It is on the to do list, once the timeline issue's are fixed I'll get to this.
Please put one timeline across the entire width of the page.
Originally it was made that way so to show the time gap between two edits, the wayback machine style of representation may not be very useful here as the edit activity on most articles is very sporadic. Also it takes up a lot of the screen. But we should revisit the tool's design and look for a better solution.
Please put the timeline from left to right, not from right to left.
This is one change everyone wants and is on the top of my todo.
The tool appears to be slow
It happens because the html version is generated from the wiki on the fly and for long pages it takes a while, sometimes upwards of 9s. I don't know if getting a db replica will help, I havn't put much thought to this.
Ha, glad to hear from you, Jeph paul :-) (Sorry for being very late with responding) I saw your Wikimania presentation, very nice! "timeline from left to right... This is one change everyone wants and is on the top of my todo." That is really good, can you give me a ping if anything is changed? I'd love to use it! :-)) --Atlasowa (talk) 22:02, 10 November 2014 (UTC)Reply
Hi Jeph paul, I request that you add languages and sister wiki support to this software immediately, and that it is linked on the history tab of every article.
Siko, it is your responsibility to ensure that the project reaches completion. This project has not reached it and I believe that you should issue another grant to achieve the intended impact.
Hi Gryllida. While I can't speak for Siko (or Marti Johnson, the new IEG grant officer), I can say that as far as I know this project was completed according to the terms of the original grant, and all requirements have been fulfilled. If Jeph would like to apply for another IEG to continue to develop the tool along the lines you propose, he is absolutely welcome to do so: the fact that people like you find ReplayEdits useful and would like to see it made more broadly applicable and available is a strong argument for supporting its ongoing development with Wikimedia funds. Whether and when Jeph decides to apply for additional funds is his decision to make. Fortunately, Jeph has made the ReplayEdits codebase available online under an open license, so even if he doesn't want to continue developing the tool right now, someone else can. Cheers, Jmorgan (WMF) (talk) 17:43, 21 May 2015 (UTC)Reply
Yes, as you can see on the original proposal, the grant we made was for 6 months to develop a tool with a primary engagement target of English Wikipedia. It's great that you're still finding it to be useful and would like to see it developed for more projects and made more widely available! However, Jeph has indeed fulfilled the terms of his original grant. If he or anyone else would like to apply for another grant to develop the tool further in the future, I'm sure we'd be happy to consider that. Cheers, Siko (WMF) (talk) 17:13, 26 May 2015 (UTC)Reply
Latest comment: 9 years ago1 comment1 person in discussion
I just dropped by after seeing the results - it is VERY VERY WELL DONE! I tried it out on several browsers. Well tested out too I believe. Shyamal (talk) 05:43, 12 March 2015 (UTC)Reply
Latest comment: 9 years ago2 comments2 people in discussion
This project was featured on the front page of Hacker News on September 19, 2015 at https://news.ycombinator.com/item?id=10243645. The overall response was positive, but a point made multiple times by different commenters was that the timeline's current right-to-left implementation is unintuitive for users of English Wikipedia -- this product's intended audience. Left-to-right chronological ordering is a nearly universal convention in timelines for that audience.
Yes, people really like this visualization tool! :-) And almost all comment on the confusing right-to-left direction ;-) @Emw, have you tried the Replay Edits user script in your english Special:MyPage/common.js:
"We then shortly present two tools we recently developed and published in this regard in Section 3: Contropedia and whoVIS; and we introduce whoCOLOR, a userscript for highlighting provenance and controversity of words in Wikipedia articles. Further we briefly describe the above mentioned older legacy tools and one Wikipedia community solution called “Wikireplay”, which we believe could also provide a useful approach to our goal. (...)
Wikireplay (or “re Edit”, http://cosmiclattes.github.io/wikireplay/player.html , by Wikipedia user Jeph Paul) is a community-built web application that allows the user to select a Wikipedia article and a starting revision. It then displays the look of the HTML view of the article at the given time and sequentially visualizes all single additions and deletions that took place in a video-like animation."
Gryllida 20:18, 31 October 2013 (UTC)
EmausBot
Jeph paul
212.106.179.88
Jeph paul (standard Wikipedia user icon)
212.106.179.88 (same style, also 
or 
). --Atlasowa (talk) 12:29, 20 December 2013 (UTC)
and pause by clicking on the pause button 
. You can choose a different starting point by clicking into the timeline at the bottom.
between the pics/steps to make this clear.
or the RefToolbar spinning throbber? 
The appearing/disappearing play icon is confusing when you have a delay and nothing happens.
in black) for the tool? --Atlasowa (talk) 16:24, 13 January 2014 (UTC)
![[4]](http://wiki.splunk.com/File:Sparkline-Demo-Screenshot.png){kind=link}
