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

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 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. I also took pride in being the only student in my middle school to author over 300 Wikipedia edits. I’m motivated by my passion for problem solving and creating tools that make the web more awesome.

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.

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, and user id for each group. 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. 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…
 * 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.

Optional, if time allows/after the GSOC coding period:
4. 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. 5. Reduction of special pages - This proposal would not create additional Special pages to accomplish grouping. In fact, because of the aforementioned consolidation of the watched changes page, Special:EditWatchlist would be merged into Special:Watchlist, reducing the number of Special pages.

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 10: Write the Model-side (database) functions needed for grouping (adding/populating/renaming/removing).

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

June 25 – July 1: Debugging, testing, and merging code.

July 2 – 8 (Week prior to the evaluation due date): Solicit feedback from the MW development community. Assess progress and identify additional areas for improvement. Finish planning the merge of SpecialEditWatchlist with SpecialWatchlist.

July 9 – 22: Make changes to RecentChangesLine, such as inserting line breaks to make the line less wide or hiding the username and comments portion requiring the user to mouseover for those elements. This will allow me to fit the list into the new narrower box on the same page as SpecialEditWatchlist.

July 23 – August 5: Port the sorting and filtering features from SpecialWatchlist. Implement AJAX pagination or infinite scrolling. Avoiding page loads is important because the user may be in the middle of group modification when checking the recent changes.

August 6 – 12: Tidy up and consolidate unneeded functions. Possibly rename the new SpecialEditWatchlist to SpecialWatchlist for simplicity’s sake. Search for unresolved dependencies of the old SpecialWatchlist. Finalize code, debug, and merge with trunk.

August 13 – 20: Obtain Community feedback on changes made during the second half of the project. Plan steps for future expansion/improvement.

Participation
We don't just want to know what you plan to accomplish; we want to know how. Briefly describe your work style: how you plan to communicate progress, where you plan to publish your source code while you're working, how and where you plan to ask for help. (We will tend to favor applicants that demonstrate a clear vision for what it means to be an active participant in our development community.) 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.
 * 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.
 * Google Highly Open Participation Contest - the initial iteration of Google's SOC for high school students (2007-08) which involved coding and documentation tasks.