User:Blackjack48~mediawikiwiki/GSOC proposal for watchlist improvements

Contact/working info

Name: Aaron Pramana
Email (preferred mode of contact): aaron XatX sociotopia XdotX com
IRC or IM networks/handle(s): IRC: blackjack48, AIM: javaron Timezone: Pacific Daylight Time (UTC−07:00)
Typical working hours: I usually respond to messages 4:00pm - 9:00pm PDT on weekdays, however over the summer (late May-August) I should be available throughout the day (9:00am - 9:00pm).
Mentor: Alex Emsenhuber

Project summary

My goal for this project is to redesign the watchlist to improve the workflow for current and potential power-users. For many wiki editors, the watchlist is one of the most important features that the MediaWiki software has to offer. The watchlist can encourage casual Wiki users to take ownership of a specific niche on the Wiki. Many top ranked websites, from e-commerce sites like eBay to media sites like YouTube, have comparable features that help users track pages that interest them, encouraging them to return and ultimately increasing the amount of time they spend on the site. The watchlist should continue to evolve so that the MediaWiki software remains a premier tool for the collaborative exchange of knowledge. This project is designed to be an amalgamation of several smaller feature improvements which will make the watchlist more useful.

About me

I am passionate about coding and have the stamina needed to interpret and debug code for hours. I’m motivated by my passion for problem solving and creating tools that make the web more awesome. I started designing websites with HTML and writing simple scripts in PHP when I was 12, and quickly grew fanatical about web programming. I now know standards compliant XHTML/CSS, Javascript, Java, Python, and MySQL Databases. My involvement with Wikipedia began in middle school, when I authored over 300 edits. For me, Wikipedia demonstrated the power of collaborative wiki software, which I began using for personal projects.

One of the most appealing elements of pursuing this project will be seeing the end product of my work used to further improve the most visited reference website on the internet. This project is important to me because I enjoy watching wiki pages develop as edits are made over time. However, the editing process is largely invisible to casual users. I want to streamline it and make it more enjoyable for all wiki users by making it easy to track topics that interest them.

Deliverables

Required

1. Grouping - The watchlist table will have a new column that stores a group id. Newly added titles (and existing titles on existing wikis) will be given a group id value of 0 initially in a user’s watchlist. A new table (wiki_watchlist_groups) will store the group id, group name, user id, and public availability (see below) for each group. Watchlists are accessed via Special:Watchlist/{username}/{group name} (and Special:Watchlist or Special:Watchlist/{username} for titles in group 0.)
2. New UI for the watchlist page - Currently, the “View/edit watchlist” page isn't as useful as it could be, only allowing users to remove titles from their watchlist. This page could be expanded with additional functionality, but will initially be redesigned for grouping.

• Adding: A text field, which takes the name of the new group from the user, will be added at the top of the watchlist page. Adding a new group submits an AJAX request to the server, stores the group name and the user id in wiki_watchlist_groups, and dynamically adds a new fieldset group to the page.
• Populating: The user can then drag and drop titles from other groups into the new group. The jQuery UI sortable plugin will be used as the basis for drag-and-drop group population. Once a user is finished populating groups, they can submit their changes, changing the group id of the title(s) in their watchlist to the corresponding id in the desired group.
• Renaming a group creates a text field in the legend element of the fieldset, taking the user’s desired new name for the group and passing it via AJAX for validation and updating the database.
• Deleting a group prompts the user for confirmation and sends a request to remove the group and change the group ids of the titles belonging to that group to 0.
• All actions (adding/populating/renaming/removing) will give the user confirmation on the same page via AJAX.

See a partially functional example of the interface here: http://www.sociotopia.com/wiki/wikiwatchlist.html
3. Modify the raw watchlist page so that groups can be denoted. One possibility is to use wiki formatting. For example:
==Group name==
Title of article
Other title of article
Etc…
4. Public groups - Allows groups to be shared publicly, depending on user-specified permissions. Watchlists will be referenced by the URL format: Special:Watchlist/{username}/{group name}

Optional, if time allows:

5. "Groups of groups" - used to organize groups once grouping is implemented and tested.
6. Inline group adding - upon clicking "watch" (or the star) on the article page, the user will be prompted to choose a group (if they have multiple) to add the title to.
7. Category-based watchlist groups - when adding a category to your watchlist, a new watchlist group will be created containing all of the titles belonging to the category. Essentially, this group will mirror any changes made to the category by referencing the category id number.
8. Modify token-based watchlist RSS feeds to work with grouping.

Optional, long term

9. Replace the “watched changes” page with a box on the right side of the “view/edit” page displaying recent changes (see example linked above.) This box would continue to use the RecentChangesLines API and would retain the format of the existing watched changes page. However, this new box would have better simplified filters and sorting options than the current RecentChanges page does. It could use infinite scrolling (like the Facebook minifeed) to preserve the compact nature of the new page. This approach to displaying recent changes is useful because it creates a single, central page for watchlist use and modification.

Project schedule

April 23 – May 20 (Community Bonding Period): Solicit further feedback on my proposal. Familiarize myself with the documentation for the associated Special pages and database tables. Continue learning the development/Git merging process. Begin planning the new functions needed for SpecialEditWatchlist and create an outline of all affected classes and functions.

May 21 – June 3: Write the Model-side (database) functions needed for grouping (adding/populating/renaming/removing) and changing group permissions.

June 4 – 17: Edit the View-side (user interface) code for grouping. This includes rewriting HTML forms, adding jQuery effects, and setting up new “action” calls to the Watchlist controller via AJAX.

June 18 – July 1: Make groups publicly accessible by editing SpecialWatchlist for directory-style group display and adding options in forms for toggling watchlists between public and private.

July 2 – 8 (Week prior to the evaluation due date): Debugging, testing, and merging code. Solicit feedback from the MW development community. Assess progress and identify additional areas for improvement. Finish planning subgroups and inline group adding.

July 9 – 22: Implement subgroups by modifying SpecialWatchlist forms and views, again using the new directory-style URL format.

July 23 – August 5: Implement inline group adding, modifying the ajax-triggered box displaying "addedwatchtext" to prompt the user to choose one of their groups from a dropdown menu in that box.

August 6 – 12: Tidy up and consolidate duplicative functions. Search for unresolved dependencies and fix outstanding errors. Finalize code, debug, and merge with trunk.

August 13 – 20: Obtain Community feedback on changes made during the second half of the project. Plan next steps for features not yet implemented.

Participation

I will work on a live web server where I can test my output and provide my mentor and other wiki developers access to preview my changes and give feedback. I will set up a blog where I will post weekly (or more frequent, as needed) updates on the status of my project. I will reach out to the IRC channel and the Wikitech mailing list for input.

My work style is very straightforward. I make liberal use of inline commenting in my code (which can be scaled back in the final product, if necessary). When I participated in the Google Code-in contest, I worked on a feature for a day and checked in with my mentor at the end of every day as needed to address issues as they arose. I have no other major commitments this summer, so I will be able to devote my complete and undivided attention to completing this project. I plan on working on this project and being involved in other MediaWiki development, even after GSOC is over.

Past experience

I have a thorough knowledge of standards compliant XHTML/CSS, Javascript, Java, Python, and MySQL Databases. I have frequently used Subversion to manage group projects in the past and I am learning Git.

• Patched bugs for MediaWiki: [1], [2]
• Web and technology editor for TheLowell.org, a student news website - maintaining a Joomla CMS, developing modules/plugins for it, and managing a tech lab for the publication. (2008-12)
• Teaching Assistant for Academic Talent Development Program at UC Berkeley - Java Programming Class (2011)
• Google Code-in - Google's SOC for high school students (2010-11 & 2011-12)which involved coding and documentation tasks. (2010, 2011)
• Google Highly Open Participation Contest - the initial iteration of Google's SOC for high school students (2007-08) which involved coding and documentation tasks. (Joomla, Moodle)