User:Jesse Groppi/GSOC 2010

Identity
Name: Jesse Groppi

Email: [mailto:jagroppi@gmail.com email]

Project title: Edit Forms

Contact/working info
Timezone: CST (GMT/UTC -6) prior to project, during project I could be in GMT/UTC

Typical working hours: Any

IRC or IM networks/handle(s): IRC: DuTempete; Skype: jesse.groppi; Google Wave: jagroppi AT googlewave DOT com; MSN: jagroppi AT gmail DOT com

Abstract
Wikimedia projects have been around for nearly ten years, now. There are millions of pages on thousands of subjects written in thousands of differing styles. This is an intimidating concept for editors and readers alike.

Over the years, editors and administrators have agreed upon certain styles for similar types of content to be written in. The method, however, has been imperfect. It is absolutely normal to find pages that don't fit their designated style, and most new editors begin editing without knowing there are guidelines at all.

My project is designed to benefit the content needing to be created and edited in a similar format many times over. In the editor, templates will be used to produce sets of fields at the beginning, the end, or in lieu of the edit box entirely. Entire namespaces can be set to always display a certain template, and individual templates can be categorised in order to be made available via drop-down menus.

This extension (or core mod) would help ensure that format guidelines are followed by making it easier to do, as well as enabling new editors to be informed from the very beginning. Most importantly, this project would improve usability for both editors and readers.

Templates
First, I should state that I'm aware of some planned changes to templates within the usability initiative. Any changes I would like to make are either identical or in line with the initiative's plans. While I'm working on the template code, I'd like to maintain communications with the folks working on the initiative.

The changes I have in mind start with adding metadata. Templates will have types and parameters will have input types. Parameters will also be able to contain lists of possible values for use in drop down menus.

Error handling will include the ability to coincide with templates that have not been updated with the new syntax. The metadata will have default values such as inline template types, which aren't affected by the new code, and text field entry for parameter input types.

Editing interface
If the page being edited is not a member of a namespace that has been predetermined to always require certain templates, the editing process will begin with the user being asked if a boilerplate (takes over the editor), or prepended template is required. If the user selects none, or the prepended template option, there will be another option to choose an appended template between the main editing box and the summary field. These questions would be asked and answered with text and input fields inline on the editing page, with dialogue boxes, or a combination of the two (combination probably being the best).

Only templates on a "whitelist", that are found in already existing pages, will automatically be shown as input fields. This whitelist would include templates such as infoboxes and navigation aids. Pages that already exist may or may not be parsed as using boilerplates (This depends on how practical the solution turns out to be). If they were, the name of the "boilerplate" would have to be designated, and the editing page reloaded. It may also be necessary to turn all traditional boilerplates (pages without traditional template syntax that are created with in mind) into regular templates, in the template namespace, with template syntax. This shouldn't affect usability since the raw wiki syntax would not be seen (usability being the reason real templates aren't used as page starters, as far as I know).



Creating a new article
While Betty is trying to decide what brush she should use on her dog, she notices that many of the articles in Wikipedia make reference to the brush, but there is no description of it. She decides to create a new page for "Slicker brush". She types it into the search box and clicks on the red link. Rather than allowing her to immediately edit a blank page, a dialogue box pops up over the window. It asks her to select from a list of page templates (which are used and written just like infobox's preload templates), so she reads through them and finds one called "dog equipment" and selects it. She clicks on "Start editing" and the mod parses the page template she selected, automatically selecting the proper templates for the bottom and top of the page and filling the edit box with the body of the template. Alternatively, she could have chosen to click on "Edit a blank page" and manually chosen which templates she wanted for the bottom and top, and the edit box would have been blank.

Editing an existing page
Editing individual sections does absolutely nothing to the edit window, however, say John wanted to add a new revival to the list of productions of Man of La Mancha. Because some of that information goes into the infobox as well as the body of the article, he clicks on the edit tab. The mod parses the page and picks up on an infobox, but no navigation banner (Wikipedia doesn't really use these) or article management boxes. John sees the mod has selected Infobox Musical from the drop down menu, laid out the paramters with text fields that already contain values that were entered previously. He clicks on the Productions field and adds a link to the current production to the end of what is already there. John ignores the banner navigation and article management options and clicks on the edit box. He scrolls down to the Productions section to add more detailed information. The navigation template section at the bottom of the page already shows the templates for Tony Award winners and he has no other template to add, so he previews the page and then saves it.

About you
Hello! My name is Jesse, and I'm an adult student from Chicago, Illinois, in the United States. Programming and web design have been hobbies of mine since I was, shall we say, much younger. I am mostly self taught, though I have taken a couple classes in order to meet the requirements of a teaching endorsement in computer education. I am, in fact, a student of education; my joint bachelor's degree in English and drama should be completed in 2012, but my ultimate goal is to receive my Post Graduate Certificate of Education, also from the University of the West of England, in 2013.

People often look at me incredulously when I say I'm a writer that is also interested in programming and mathematics. However, I find them to be rather similar to each other. All three require a strong grasp of logic, thinking creatively and outside the "box", and the ability to convey meaning to others. That said, I'll admit that programming scratches a mental itch that I can't satisfy elsewhere. I enjoy it immensely, and get much gratification from working with the open source and free knowledge communities.

Tasklist/Deliverables
This section outlines the step-by-step tasks involved in my project. Points in bold are deliverable products.

Absolute basics

 * 1) get familiar with the specific files, classes, and methods involved in the project
 * 2) * Draw up a flowchart of the template code
 * 3) * Draw up a flowchart of the editing code (will probably need to be super-simplified)
 * 4) flowcharts for expected changes/hacks to existing code
 * 5) * template code
 * 6) * editing code
 * 7) final mock-up of interface layout
 * 8) plain language or "pseudo" code
 * 9) * template pseudo-code
 * 10) * editing pseudo-code
 * 11) * interface pseudo-code
 * 12) finalise list of system messages
 * 13) request several translations of system messages for localisation testing
 * 14) add items to Special:AllMessages
 * 15) write template changes
 * 16) test template changes
 * 17) write interface changes
 * 18) test interface changes
 * 19) write editing changes
 * 20) test editing changes
 * 21) test overall mod/extension

Niceties in order of priority

 * 1) Skinning
 * 2) * Monobook
 * 3) * Vector
 * 4) Translations
 * 5) Favourite templates
 * 6) * preferences that bring up commonly used templates to the top of the menus

Project schedule
I've made a Google Calendar that best explains how I would like the flow of work to go.

Participation
I tend to work best in a very structured environment. If you look at the Google calendar I linked above, you can see that is exactly what I've created for myself. I plan to start work and information gathering as soon as I receive my acceptance notice, and I've created a very probable work schedule that is, of course, not set in stone.

I am also a stickler for constant communication, both for accountability and teamwork purposes. I do consider my mentor, myself, and the MediaWiki community a team; if this project is not for them, it's hardly worth the effort I plan to put into it! On the calendar, you can see I intend to have a meeting with my mentor immediately, so that we can get to know each other and discuss anything that needs clarification before I begin work. Once that is concluded, I've allotted the next week for meetings with interested WMF projects and WikiEducator.org. I want them to be able to provide input at all stages of the project. I also intend to post daily updates on my progress. There are also mandatory weekly meetings with my mentor, with optional on-call meetings on a second day (The days and times I picked are only for example).

My goals for communication and participation are to make it easy for the community and mentor to follow along while also minimising their time commitment to the project.

Past open source experience
I have no direct experience contributing to open source software, however I have been working with the MediaWiki platform since 2007, when I began editing WoWWiki.com. I haven't made many contributions to WMF projects, but more recently I've become involved with WikiEducator.org, the founder of which is a member of the WMF Advisory Board, and I've contributed to several Wikia projects.

Better related, I've started my own MediaWiki site, from which I learned PHP and gained a familiarity with the internal code. I designed the skin, and hope to package it for use by other community members as soon as I iron out all the kinks.

Any other info
Some requests for these features:
 * Extension_requests
 * Extension_requests