Grants talk:IEG/Replay Edits

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search
IEG key blue.png

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:

  1. You will be contacted to sign a grant agreement and setup a monthly check-in schedule.
  2. Review the information for grantees.
  3. Use the new buttons on your original proposal to create your project pages.
  4. Start work on your project!

Questions? Contact us.


Aggregated feedback from the committee for Replay Edits[edit]

Scoring criteria (see the rubric for background) Score
1=weakest 5=strongest
Potential for impact
(A) The project fits with the Wikimedia movement's strategic priorities 3
(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:
  1. A better visualisation method for article-histories is a field ripe for experimentation.
  2. Appears to be an improved version of Wiki Blame with animation. It would quite interesting to visualize the process how articles are evolved.
  3. Could this tool be finetuned to help detect copyright violations? That would be helpful.
  4. Tool may be useful for patrolling for vandalism, other benefits remain undemonstrated.
  5. The measures of success and intended impact that the proposer has listed seem incorrect. Why should number of edits increase?
  6. Budget for UI design appears to be unrealistic.
  7. How it will get into the ecosystem of MediaWiki and incorporate with related tools such as Visual Editor is unclear.
  8. Would like to see the proposer demonstrate more familiarity with Wikimedia and MediaWiki.
  1. 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.
  2. 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.
  3. 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 .
  4. 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$ .
  5. 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.
  6. 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)
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)

Visualization[edit]

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)

  • 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 Paul 19:14, 12 February 2013 (UTC)
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)
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 Paul 14:06, 15 February 2013 (UTC)
Thank you for this mockup. It gives me a far clearer idea, and hopefully to others, too :) --whym (talk) 12:56, 16 February 2013 (UTC)

Deadline to propose is 15 February[edit]

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)

Server load[edit]

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)

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)
This should be workable in production if we trade off some correctness in the output generated for speed and efficiancy.--Jeph Paul 05:50, 14 February 2013 (UTC)

Hosting[edit]

Where will this tool live once development is complete, and how will users learn about it to access the tool? I think because you're planning to build a stand-alone tool that makes API calls, you aren't going to have an issue with the eligibility criteria related to engineering-focused projects, but it would be helpful if you can confirm on this point. Thanks! Siko (WMF) (talk) 21:49, 15 February 2013 (UTC)

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 Paul 12:26, 16 February 2013 (UTC)

Why is a grant needed?[edit]

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)

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 Paul 10:48, 18 February 2013 (UTC)
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)
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 Paul 09:17, 19 February 2013 (UTC)

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. Gryllida 23:45, 18 February 2013 (UTC)

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 Paul 09:17, 19 February 2013 (UTC)
Thanks for reading; I really hope your funding would work out well (if approved). --Gryllida 02:15, 22 February 2013 (UTC)

Who needs this?[edit]

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)

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.
I think it goes beyond being a fun tool , and will help improve engagement & the ease in editing. --122.172.50.1 19:31, 20 February 2013 (UTC)
"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)
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.1 16:13, 21 February 2013 (UTC)

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). -Gryllida 02:14, 22 February 2013 (UTC)

Visualization over time is perfectly to showcase to the media the development of Wikiarticles. 87.78.74.58 09:31, 5 March 2014 (UTC)

Article evolution playback tool idea[edit]

Congratulations! This project is similar to Article evolution playback tool idea or viceversa. You may want to stay in touch for better collaboration. Also, please consider open a bug report for tracking progress about this project and make it easy for others to follow. See how we are doing this at mw:Mentorship_programs/Possible_projects.--Qgil (talk) 22:11, 29 March 2013 (UTC)

We should surely work together on this , I have posted on Ainali's Talk Page regarding the same.

Other related work[edit]

There was a contest in 2005 to "automatically generate a slideshow of Wikipedia revision history." There must be lots of work in visualizing changes in word processing documents, both desktop and HTML (Google Docs, Zoho docs, etc.) S Page (WMF) (talk) 21:17, 18 April 2013 (UTC)

Thanks for sharing , Siko had mailed me the links :-) --Jeph paul (talk) 09:06, 23 April 2013 (UTC)

Features for the tool[edit]

Please add here the features you would like to see in the tool.--Jeph paul (talk) 03:50, 1 April 2013 (UTC) Please checkout the live demo: https://googledrive.com/host/0B1hJO1N6piYFTTVZdW1mU2c0S28/visualise.html

  • " 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. Gryllida 08:39, 20 August 2013 (UTC)
  • Pause/Forward/Backward & adding the metadata about the author/date time etc are in the works. --Jeph paul (talk) 18:42, 20 August 2013 (UTC)
  • Pause/Play button & a slider to control the speed of the animation have been added to the demo.--59.92.37.190 20:45, 8 September 2013 (UTC)
  • Is the replay speed slowed down in the script or is it slowed by the API queries? Gryllida 08:39, 20 August 2013 (UTC)
  • The replay speed has been slowed down as part of the animation , they are not slowed by the response from the API. --Jeph paul (talk) 18:42, 20 August 2013 (UTC)
  • 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. Gryllida 08:39, 20 August 2013 (UTC)
  • Will surely refractor the code. --Jeph paul (talk) 18:42, 20 August 2013 (UTC)
  • I think the tool keeps saying 'waiting for wikipedia.org ...' in the status bar if the page name field is empty. Gryllida 08:48, 20 August 2013 (UTC)
  • 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. Gryllida 08:48, 20 August 2013 (UTC)
  • I did not get your fifth point, could you elaborate it a bit more :-) --Jeph paul (talk) 18:42, 20 August 2013 (UTC)
  • 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. Gryllida 21:35, 21 August 2013 (UTC)
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)
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)
  • You may want to use the technology FirefoxOS uses, webl10n, to add multilingual interface support. Gryllida 08:48, 20 August 2013 (UTC)
  • 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)
  • +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)
  • 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)
  • 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)
  • 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)
  • An early prototype--Jeph paul (talk) 02:57, 15 October 2013 (UTC)
  • 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)
  • 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)
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)
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)
  • I feel the feedback is active; it could be useful to obtain a bug tracker to dispose of duplicates: there is currently none but it becomes harder to keep track, in my view. You can get one at Wikitech - Wikimedia labs (git, bugs (?), web hosting) or at http://devlabs.linuxassist.net/ (git, bugs, wiki), or simply use GitHub's issue tracker. Gryllida 11:02, 23 August 2013 (UTC)
  • total number of edits done to date.
  • which edit number & its date.
  • if this is the first, second etc of the total number of requested edits.
AshLin (talk) 06:41, 28 August 2013 (UTC)
  • 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)
I'll remove them from the visualisation, they are indeed quite misleading --Jeph paul (talk) 18:29, 11 September 2013 (UTC)

Is animation the best way?[edit]

I think the aims of this work are valuable. But I think it might be more effective to just show a number of diffs side-by-side.

Maybe I am biased because I have proposed that idea myself before. Check out wikipedia:en:User:Yaris678/DiffDeck.

If anyone wants to implement my idea. Please be my guest. (A mention as the source of the idea would be appreciated but that is all).

Yaris678 (talk) 14:44, 27 August 2013 (UTC)

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)
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. --Nemo 07:08, 16 December 2013 (UTC)

Filters?[edit]

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)

"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)

Integration[edit]

Are there plans to integrate the tool into wiki interface, either built-in into MediaWiki or as a gadget? Thanks. Smiley.svg Gryllida 20:18, 31 October 2013 (UTC)

The tool currently looks as show in the image (screenshot of the actual tool, but not yet released).
Visualisation Tool.png
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)
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.)
--Gryllida 09:52, 7 November 2013 (UTC)

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)

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)

Server Response Time[edit]

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)


Updated Mockups[edit]

Slider Mockup

I'm using this as a reference for the silders.--Jeph paul (talk) 03:52, 2 December 2013 (UTC)

Screenshot of the tool with new UI.png

--Jeph paul (talk) 03:06, 6 December 2013 (UTC)

UI redo

The tool with a new UI and a bunch of new features.--Jeph paul (talk) 19:02, 15 December 2013 (UTC)

Suggestions[edit]

Nice work! I have a few suggestions:

  • 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).

Helder 11:25, 16 December 2013 (UTC)

UX suggestions[edit]

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 | Talk 05:45, 17 December 2013 (UTC)

+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.
Congrats on getting this version live, Jeph! Siko (WMF) (talk) 19:39, 17 December 2013 (UTC)
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)


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:
Icon robot.svg EmausBot
Unisex user icon.svg Jeph paul
Icon anon.svg 212.106.179.88
or (more familiar and less colourful):
Icon robot.svg EmausBot
User icon 2.svg Jeph paul (standard Wikipedia user icon)
Gnome-stock person ktos.svg 212.106.179.88 (same style, also Gnome-stock person ip.svg or Gnome-stock person ip2.svg). --Atlasowa (talk) 12:29, 20 December 2013 (UTC)
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)
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)
  • 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
  • The colourcoding of users is very nice!
  • I really hope to have this as a gadget for german Wikipedia too! :-) --Atlasowa (talk) 15:17, 19 December 2013 (UTC)

UX Todo[edit]

Tool with features annotated
Issue Fix
Make speed control intuitive (1)
Looks cluttered (2)
Make revision link meaningful (2)
Play/Pause not intuitive (3)
Bars in zoomed in version clickable not intuitive (4)
Slider in bottom graph draggable, resizable, can be redrawn not intuitive (5)
Add Loading icon
Older edits can be added by dragging slider to rightmost corner not intuitive (6)
Homepage explaining the tool
Need of two graphs not intuitive
Identify bots/users
Explain features with tooltips
Add nice Dropdown for languages
Add indicate direction/time in bottom graph
Make the direction of the graph Left to right (latest - right , older -left)

--Jeph paul (talk) 19:46, 19 December 2013 (UTC)

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)

Simulating text input speed / single-edit session length[edit]

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)

Metal Umlaut edit visualisation, August 2013, Jeph paul

"simulating text input" - isn't that exactly what the replayer already does?

And trying to design this in a way that even works on mobile devices - is really awesome! --Atlasowa (talk) 13:04, 3 January 2014 (UTC)

OK, comparing this side by side i get what you mean. That's very slick! --Atlasowa (talk) 13:22, 3 January 2014 (UTC)

Show general information popup box while loading[edit]

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.

Compare "page information" for the russian article "Metal umlaut", this is available for all pages in all language editions! Then, add some guidance about using the replay tool (b), for example:

  • Replay the edits by clicking the play button Oxygen480-actions-media-playback-start.svg and pause by clicking on the pause button Oxygen480-actions-media-playback-pause.svg. You can choose a different starting point by clicking into the timeline at the bottom.

And while people read this short overview the replay tool can load things in the backround :-) --Atlasowa (talk) 10:40, 3 January 2014 (UTC)

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 Oxygen480-actions-media-playback-start.svg / Oxygen480-actions-media-playback-pause.svg

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)

New design changes![edit]

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 Human-go-next.svg 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 Loading Key.gif or the RefToolbar spinning throbber? RefToolbar spinning throbber.gif 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 ?
Yes! :-) --Atlasowa (talk) 16:24, 13 January 2014 (UTC)
  • (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.
I didn't find stats on article revisions, but we could probably ask at the english Village pump if someone knows. I assume the number of edits will follow the usual power-law, 27,101 edits to popular Michael_Jackson (despite page protections!) and 2 edits to small village Palle_Deltota. Bogus calculation: Your File:Metal_Umlaut_edit_visualisation.webm needed 45 sec for 20 edits (it's quite fast, this would be replaying 1,600 edits in 1 hour!) so replaying Michael_Jackson would take almost a day (~18 hours!) - i haven't the slightest doubt that there are fans that would actually do that ;-)) --Atlasowa (talk) 16:24, 13 January 2014 (UTC)
  • (12) Provide permalinks to replay specific article and/or specific revision.
I removed them on a suggestion that 'The tool shows the content in a revision, by give a link to it again'. We can bring it back.

I think "replay" will be a huge hit and immensely useful. I added a link to the replay project at Wikimedia Blog/Drafts/Humanizing Wikipedia (oh, this draft was already published. But replay will be relevant for humanizing :-) )

Its been added to [5]

Awesome work, Jeph paul! --Atlasowa (talk) 12:19, 7 January 2014 (UTC)

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?
- "mydiff": what happened since my edit? (MyDiff, user script)
- replay last 6 month
- replay last 20 edits
- jump into biggest modifications of the article (how to find them?)
- jumping around forth and back in the edit history
- wikiblame example: who put "foam" in "mattress"? (other wikiblame offsite) interlinking?
- 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 View-playback Gion simple.svg in black) for the tool? --Atlasowa (talk) 16:24, 13 January 2014 (UTC)

Getting started[edit]

The recent version at http://cosmiclattes.github.io/wikireplay/player.html doesn't appear to display any diffs, so I could not evaluate it in detail. Gryllida (talk) 03:20, 11 January 2014 (UTC)

Scratch that, forgot to click "Play". Gryllida (talk) 03:28, 11 January 2014 (UTC)

Seeing edit author[edit]

It appears that the edit author is only visible after clicking the relevant bar. Would on-hover effects be more intuitive? Gryllida (talk) 03:28, 11 January 2014 (UTC)

Web.archive.org-like interface[edit]

I might perhaps find it more intuitive if a time slider is at the top with article content at the bottom, like here at the Web Archived history of Wikipedia main page. Gryllida (talk) 03:28, 11 January 2014 (UTC)

WikiDashboard, PARC 2007
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)

Scope[edit]

Please make the tool available for all projects (this means Commons, Wikibooks, Wikisource, etc per wikipedia:WP:SISTER) in all languages as impact assessment would appear incomplete otherwise. Gryllida (talk) 03:22, 11 January 2014 (UTC)

Jeph paul? Ping? --Gryllida 17:05, 26 January 2014 (UTC)
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)
Added the language selection dropdowns back & added a suggestion list to the input box. Will add il8n soon.--Jeph paul (talk) 05:25, 3 February 2014 (UTC)
Added a hand rolled il8n support.--Jeph paul (talk) 15:05, 3 February 2014 (UTC)
Hi Gryllida,
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)
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. --Gryllida 08:45, 7 February 2014 (UTC)

New design (tweaks)[edit]

I really like this version!

  • At the bottom where it says Replay Edits could you add 'About'
  • Once I play an article, I didn't see how to go back to the search screen to try another
  • The graphs play right to left, but most video progress bars are left to right. Could this be flipped?

Great work! So encouraging to see you continuing to improve it :) Ocaasi (talk) 19:30, 11 January 2014 (UTC)

1-click userscript install with guided tour[edit]

Hey Jeph,

I think this might be of interest to you:

FindDPLA.

Try it out, we could build one for your tool, too!

Jake Ocaasi (talk) 13:11, 30 January 2014 (UTC)

No Visualization?[edit]

Why is there no pictire inside the article? I mean, this is about visualization, right? 87.78.28.119 08:32, 7 February 2014 (UTC)

Wishlist[edit]

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.

Shyamal (talk) 07:56, 16 February 2014 (UTC)

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)