This document is a work in progress. Comments are appreciated but this is not a final draft.
This document describes the design of the Contact us landing page for the developing Wikipedia Mobile site.
After discussion with OTRS folks and the Legal and Community Advocacy team, there were some new requirements that have come to light:
- include referring page in all emails
- can we reduce the number of blank emails?
- does it make sense to put comments onto a wiki page automatically?
It was decided that the answer to the last question is no, due to spam appearing on the page, which violates a principle of wiki content.
Several ideas could help with the large number of blank emails that are submitted. Here are a few:
- Add wording to the top of the email body, such as, "Type your comment below. If you have no comment, please go back or tap Cancel."
- Create a few blank lines below the text above and above the referring page and user agent
The current mobile view of the Contact us page is difficult to navigate.
- Ongoing effort to implement a UI step between the current interface and Glaucus/Athena
- To make interaction simple, smooth and intuitive.
- To outline a simple contact form
- To discuss and solidify useful features and their behavior
- To keep the bare minimum of feedback types and actions
- To capture some information automatically, such as platform, browser/app and device
- Also to capture the referring page and possibly other info that is easily accessible
- To direct comments to the appropriate destination, such as a wiki page, email alias or OTRS email address, as detailed below
- Another important use of this form is to act as the main conduit of feedback from Android Market and the Apple App Store, to the degree possible
- This page must be compatible with feature phones, not just smart phones - or a separate version will be delivered to feature phones
- (Here is an imagined minimal interface to go along with this feedback page.)
This interaction begins when Contact us is selected from the footer of any page.
Search box remains at the top, footer remains at the bottom. The text boxes and buttons should match the style selected for the header.
Only Cateogries should appear first. Then other fields appear depending on the action chosen below.
- The contact form includes
- Comment category menu (categories TBD)
- Technical problem goes to email@example.com
- General - goes to info-XX@wikimedia.org (where XX refers to language code)
- Article feedback - regarding me or a company I represent - goes to firstname.lastname@example.org in English, or info-XX@wikimedia.org where XX is one of the language codes listed below, or EN if none of those languages provides a match
- Article feedback - factual error - reveals a link:  in the language versions listed below, and if the language does not correspond to one of these pages, to this email address: info-XX@wikimedia.org, where XX is one of the language codes listed below, or EN if none of those languages provides a match
- Article feedback - another problem - goes to info-XXemail@example.com in English, or info-XX@wikimedia.org where XX is one of the language codes listed below, or EN if none of those languages provides a match
- Larger box with Type your comment here in very light gray
- Box with Your email address in very light gray, see notes below
- Send button
- The email addresses must be generated automatically from the following list of languages, based on the language setting of the current article view, and if the language is not available, use the English version:
- info-af General information in Afrikaans/Afrikaans
- info-ar General information in Arabic/العربية
- info-ca General information in Catalan/català
- info-cs General information in Czech/česky
- info-da General information in Danish/dansk
- info-de General information in German/Deutsch
- info-el General information in Greek/Ελληνικά
- info-en General information in English or languages not covered by other queues, includes emails moved from the Board's queue. See alsoOTRS/info-en mission
- info-es General information in Spanish/español/castellano
- info-et General information in Estonian/eesti keeles
- info-fa General information in Persian/فارسی
- info-fi General information in Finnish/suomen kieli
- info-fr General information in French/français
- info-he General information in Hebrew/עברית
- info-hi General information in Hindi/हिन्दी
- info-hr General information in Croatian/hrvatski jezik
- info-hu General information in Hungarian/magyar
- info-it General information in Italian/Italiano
- info-ja General information in Japanese/日本語 (にほんご)
- info-ko General information in Korean/한국어
- info-ml General information in Malayalam/മലയാളം
- info-nds General information in Low Saxon/Plattdüütsch/Nedersaksisch
- info-nl General information in Dutch/Nederlands
- info-no General information in Norwegian/norsk
- info-pl General information in Polish/polski
- info-pl-ban Information for blocked users in Polish/Informacje dla zablokowanych użytkowników - w języku polskim
- info-pt General information in Portuguese/Português
- info-ro General information in Romanian/română
- info-ru General information in Russian/Русский
- info-sk General information in Slovak/slovenčina
- info-sr General information in Serbian/српски језик
- info-sv General information in Swedish/Svenska
- info-tr General information in Turkish/Türkçe
- info-vi General information in Vietnamese/Tiếng Việt
- info-zh General information in Chinese/中文邮件
- The sender's email address must be the reply-to address in the messages that are generated from this form.
- Email address of the user could be pre-populated if the user is logged in and the email address is in his or her profile. If the email address is not in the user's profile, show an option to have it saved, which is checked by default.
- If the user enters an email address, validate that it has an @ sign and a properly formed domain. If not, show the error message: "The address you entered is not valid, please try again."
- The Factual error page currently exists in a limited number of languages, and the URL shown should correspond to the language setting of the current article view - the available pages are listed below. If there is no page in that language, an email address should be used that goes to the corresponding language version of that email.
- The Factual error link can be shown by itself, so when "Article feedback - fatal error is selected, " only the link appears and the button says "Go" instead of "Submit." On smartphones, this could be implemented so as to re-direct the user in 5 seconds, with text above the link appearing, as follows: "You will be re-directed to the following page in 5 seconds."
- Send button only becomes visible when it can be used. It can be used when the user has entered an email address and some characters in the comment box.
- All text boxes will have a symbol to clear.
- Email and comment fields should not clear by clicking away.
- After selecting a category, the category button should reflect that category.
- The larger comment box should have an in-box gesture scroll to allow longer messages.
After sending a comment
The user device and platform information should be automatically included with comments that are forwarded to WMF.
Send is selected and the comment is forwarded. The page returns to the original feedback landing and the screen now says, Thank you! Your comment has been sent. (Is that proper grammar?)