Jump to content

User:Tinaj1234/MassMessage

From mediawiki.org

MassMessage page input list improvements

[edit]
Public Url
https://www.mediawiki.org/wiki/User:Tinaj1234/MassMessage
Bugzilla report
https://bugzilla.wikimedia.org/show_bug.cgi?id=62601
Announcement
http://lists.wikimedia.org/pipermail/wikitech-l/2014-March/075265.html

Name and contact information

[edit]
Name
Tina Johnson
Email
tinajohnson.1234@gmail.com
Timezone
Kolkata, UTC+5:30
Typical working hours
5pm to 2am or 9am to 9pm
IRC Nick
tinaj1234 on Freenode ( Channels: #mediawiki, #wikimedia-dev, #wikimedia-tech )
Other contact details
Talk Page
User: Tinaj1234

Project summary

[edit]

MassMessage is an extension used to send a message to a list of users. The parserfunction used for wikitext is #target. To create a list of target pages using #target, each page has to be added in this format:
{{#target: Page name | [optional wiki domain] }}
After the list is created, the page list is added through the MassMessage user interface.

Current Scenario

As of now, if a user has to send a mass message he has to create a page list with the above said format. That is, for each recipient wikitext has to be added in the page list (see image below). This is not at all user friendly.

What the project would accomplish

If we were to use a more lightweight format like JSON (JavaScript Object Notation) for serialization, both frontend and backend can be revolutionized. Using JSON, we could store the information in a more structured way. The JSON structure will look like: 

[
    {
        "page": "User talk:Tinaj1234",
        "wiki": "www.mediawiki.org"
    }
]


Current page list

A ContentHandler for the same will have to be provided, one which extends from ContentHandler class and TextContentHandler class. With this, each page is assigned a content format. This project would implement:

  • A user friendly interface - An 'Add page' button which would open up a JS dialogue box where the user adds the individual pages to which he wants to send the message and then saves it using ajax.The user can add three kinds of pagesː
    • A page list which has wikitext content - Here we make use of #target and all other related functions
    • A page list which has JSON content - JSON ContentHandler is used
    • A page which is not a list - If a number of individual pages which has neither of the above formats are added by user, a JSON page list will be created. But if just one page is added by user, a dilemma arises whether a list should be created or not. This is when the question "So I add a single page now, but what if tomorrow I have the idea that I need to add another page?" comes into context. On discussions with my mentor, we both agreed that creating a JSON list right away would be better. Again, what if the user want to add or remove a page to an already existing list? We plan to implement this functionality as well.
  • In order to have backward compatibility, we will use a function to identify if the page content format is wikitext or JSON. If the format is JSON, then its ContentHandler will be used. Or else if the content is wikitext, #target comes into play.
Possible mentors

Deliverables

[edit]
Prototype of final JS dialogue box
Prototype of primary JS dialogue box

What is expected:

The MassMessage UI will be completely altered for the better. An 'Add page' button would be implemented which would open up a JS dialgue box. User can add pages to be added and when 'Add' button is clicked, a html page is displayed with the list of all pages added by user. From this list, the user can delete any page if required. When 'Send message' button is clicked the message will be sent to the pages in the list and will be followed by a JS dialogue box. Here the user will be provided the following options:

  1. Save as new list
  2. Update an existing list(s)
  3. Keep the existing list(s) intact

I'm assuming that the last said would be the most challenging part of the project as there are can be a number of test cases. Few test cases are:

  1. An individual page added - A JSON page created at the backend and at the frontend the user is prompted for a name for the list (see image).
  2. Wikitext page lists alone - We stick with the #target parser function.
  3. JSON page lists alone - User has the option to either merge the lists or just keep them separate.
  4. JSON page list(s) + individual page(s) - When all the target pages are listed, user may trash out any recipient as per his requirement. After this he can either create a new list or merge the new list with other existing lists.
  5. Wikitext page list(s) and individual page(s) - Discussions are still pending. The best option will be creating a new JSON page but then again backward compatibility is to be considered.

* Microtasks

Project schedule

[edit]
Tasks to be completed Timeline
Write ContentHandler.php, Content.php for JSON 04/03/14 - 20/03/14
Create JS frontend 20/03/14 - 10/04/14
Test the working of JSON ContentHandlers 20/04/14 - 30/04/14
Create a basic layout for different combinations of pages (different test cases mentioned above) 30/04/14 - 15/05/14
Focus mainly on adding/deleting/merging to an existing JSON page list 15/05/14 - 30/05/14
Focus on combinations of wikitext page lists and individual pages (test case #5) 30/05/14 - 20/06/14
Mid Term Evaluation 20/06/14 - 23/06/14
Test the frontend functionalities (listing of recipients, deletion of recipients, etc ) 23/06/14 - 15/07/14
Test the Adding/Deleting of recipients, check for duplicates when lists merged 15/07/14 - 30/07/14
Documentation, Check for coding standards(conventions, variable names etc), Clean-ups 30/07/14 - 10/08/14
Final Report Submission 20/08/2014

About you

[edit]

I'm a 20 year old second year Computer Science Engineering undergraduate at Amrita Vishwa Vidyapeetham, Kollam. I'm a proud member of FOSS club in my college, which explains my interest in Open Source contributions. Also, this club is why and how I started contributing to Mediawiki. To get done with my first bug wasn't easy. Struggled to understand the code, even the instructions from IRC. But eventually when the patch was merged and when I got to see the trivial change that I made, it was pure joy. And that's what I love about contributing to Open Source. I get to make a difference, or even better voice my opinion on how something should be done.

When the project is finished, not just page input list will be improved but many more will be accomplished. As you go deeper into the idea being implemented, you can see how the extension itself is upgraded to a better version. Mediawiki is how I got started with bug fixing. The community has always been so kind with instant replies on IRC's and their keen interest in solving issues however trivial they may be. So when I thought of doing a GSoC project with Mediawiki, it just felt right.

Participation

[edit]

Being part of the FOSS Club enables me to be connected with the Open Source Community around after my college hours. I try to blog regularly on new knowledge learnt. My blog will be the regular source of all progress during the coding phase. I actively respond to emails and am active at the wikimedia IRC channels, where I actively communicate with the community. All the source code written will be pushed to github repositories MassMessage. Test results will be put up on subpages of MassMessage or even a thread can be started so that developers can share their ideas and views.

Past open source experience

[edit]
Retrieved from "https://www.mediawiki.org/w/index.php?title=User:Tinaj1234/MassMessage&oldid=4296003"