Community Wishlist Survey 2020/Wikiversity/Simple structured input forms

Simple structured input forms

  • Problem: Information is often far better input via a form rather than editing wikimarkup (like this page). Especially when either A) the same fields will be repeatedly required or B) when new users are involved. New users are often put off my wikimarkup, even when templates and preloaded text is used (example). This leads to projects and affiliates often using google forms in stead then copy-pasting the information to wiki (example). Currently a small number of outstanding issues remain on the Pageforms Extension that could address this by making an in-house, general-purpose form tool with structured inputs.
  • Who would benefit:
Example use case in wikiversity: It'd be great to be able to use this peer review submission form rather than the current system (peer reviews are submitted via this google form, which deposits them to a google spreadsheet like this, where they're manually copied to the relevant article talkpage, and noted down on this tracking table, and maybe at some point will have their metadata added to Wikidata). Similarly useful for submitting articles in stead of this google form.
  • Proposed solution: A way of having structured forms to create and edit specific wiki pages that always have the same layout/format. Particularly useful capabilities listed below with submitting peer reviewer comments as the worked example:
  1. Free text box for content to be added to page section or inside template (e.g. the content of a peer review, or a faculty webpage)
  2. Dropdown list or autocompleted textbox of predefined options to pick from:
    1. Populated/autocompleted from wikidata like when typing into wikidata field (e.g. to pick affiliation from wikidata-listed organisations)
    2. Populated/autocompleted from category (e.g. to specify which article is being reviewed)
    3. Hardcoded list (e.g. whether to have identity open or embargoed)
    4. Tickbox that when clicked will add set text (e.g. declaration of no competing interests)
  3. Ability upload of a file (e.g. pdf of peer reviewer comments/annotations)
  4. Distinguish between required and optional fields
  5. Ability to show additional fields based on what has previously been picked (e.g. if user states that they wish have their identity embargoed, box appears to ask them to provide description of credentials, or makes the credentials box required rather than optional)
  6. Ability to pre-fill some of those fields using info in the URL (e.g. when link is sent via email to potential peer reviewer for specific article)
  7. Submission button to convert those chosen options into the required wikitext and save to the specified page (e.g. the peer review page).
  8. Option to edit which fields are displayed depending on whether the submitting user is listed in a template, or on wikidata as either the submitting author
  1. Add text to page (e.g. the content of a peer review)
  2. Create new page (e.g. when the first per review is submitted, create the talkpage)
  3. Replace text in a specific page section or template
  4. Update wikidata item (e.g. add {{{}}})
  5. Add file to commons or locally
  6. Create new wikidata item (e.g. if reviewer provides ORCID, but wikidata item for them doesn't yet exist)
  7. Add information to the user's hidden information (e.g. if they had not previously added an email address to their account, allow them to do so via the form, but eventually other info such as committed identity)
Although it'd be useful to have as many of these functions as possible, I've tried to order them from most necessary to most optional.
  • More comments: Using more structured input has already been useful for (e.g. the commons upload wizard). A general solution for use in other contexts would be hugely useful. Possibly broader solution via Page_Forms: T149869. See also bot request for related wikidata tasks.
  • Phabricator tickets:
  • Proposer: T.Shafee(Evo﹠Evo)talk 04:04, 2 November 2019 (UTC)


  • No argument that this would be very useful. The phab ticket selection suggests that the main blocker on this is some outstanding security issues in the Page Forms extension (Page Forms on Phab, and the Extension page). Is this the case, or are there other major issues? HLHJ (talk) 22:22, 3 November 2019 (UTC)
  • Strong support. Better form input would help newer editors enter consistent information as well as being able to analyse the resulting structured data. This would be a big win across the board. — Bryandamon (talk) 22:07, 6 November 2019 (UTC)
  • T.Shafee(Evo﹠Evo), thank you for submitting this proposal! We have one request: Can you provide more information on the problem? Right now, we mostly see information on the proposed solution, which we may or may not be able to implement. However, if you flesh out the problem a bit more (in the "Problem" section), we can have a better sense of the potential options to solve the issue. Thanks! --IFried (WMF) (talk) 04:51, 11 November 2019 (UTC)
    @IFried (WMF): Thanks. I've now expanded on it a little from a user point of view. Sadly I don't have enough knowledge to comment on the technical side of T149869. T.Shafee(Evo﹠Evo)talk 05:17, 11 November 2019 (UTC)
    @Evolution and evolvability: Thanks for the update! Your changes helped clarify the problem. --IFried (WMF) (talk) 05:27, 11 November 2019 (UTC)

Unfortunately, this extension would require much more work to be deployable on WMF than it's assumed. We can't dedicate this amount of time to it because we will have other projects to work on next year. Regardless, thank you for participating in our survey! MaxSem (WMF) (talk) 00:58, 19 November 2019 (UTC)

@MaxSem (WMF): Is there scope for a stripped down version to be implemented that don't include the abilities that cause security issues? The main elements that would be the most useful are:
  • Saving text to a page
  • Updating a wikidata item
  • Creation of a new page
  • Upload of a file
via any kind of structured form that can have e.g.:
  • Dropdown lists populated from wikidata or categories
  • Dropdown lists populated from set of options
  • Presentation of additional options based on those previously entered
  • Free text field
T.Shafee(Evo﹠Evo)talk 02:20, 19 November 2019 (UTC)
T.Shafee(Evo﹠Evo), hello! We have discussed this as a team, and we think that this wish can be unarchived, if it has some changes. First, the wish should be rewritten to not imply that it will include deploying Page Forms. Second, we propose a change of title to something like 'provide a form to create new articles for wiki journal structures.' If these changes are made, the wish will be more flexible and manageable for us. Please make these changes before tomorrow at 18:00 UTC (which is when voting begins). Thank you! --IFried (WMF) (talk) 21:25, 19 November 2019 (UTC)
Ok, I'll edit up this page and move to a different tile to focus on the specific use case and requested capabilities rather than the extension itself. I'll add a link to this oldid so that people can see the earlier version if they wish. T.Shafee(Evo﹠Evo)talk 04:56, 20 November 2019 (UTC)
Initial submission titled "Extension:Page forms on WMF servers", see this oldid. T.Shafee(Evo﹠Evo)talk 01:51, 21 November 2019 (UTC)
  • Just to be clear, this proposal is about installing the Cargo extension on Wikiversity, right? (As opposed to SemanticMediaWiki, which has been rejected already.) Or is it about making PageForms work without Cargo and with a different kind of "backend"? Nemo 09:13, 22 November 2019 (UTC)

I've updated the application to focus on specific capability set rather than any particular tool to achieve those capabilities. T.Shafee(Evo﹠Evo)talk 01:51, 21 November 2019 (UTC)


  •   Support Libcub (talk) 08:48, 22 November 2019 (UTC)
  •   Support Lionel Scheepmans Contact French native speaker, sorry for my dysorthography 11:03, 22 November 2019 (UTC)
  •   Support To enable PageForms on Wikiversity, it will need to be improved to meet WMF code standards. Doing that will be hard work, but if accomplished, then it would be much easier to enable it on other wikis, which would help enormously to increase the amount and quality of contributions, since new users are much more familiar with forms than with wikitext. So enabling PageForms would benefit not just Wikiversity, but the Wikimedia movement generally. Sophivorus (talk) 13:52, 22 November 2019 (UTC)
  •   Support Scott Thomson (Faendalimas) talk 15:20, 22 November 2019 (UTC)
  •   Support OhanaUnitedTalk page 16:20, 22 November 2019 (UTC)
  •   Support MavropaliasG (talk) 05:54, 23 November 2019 (UTC)
  •   Support Steven Fruitsmaak (Reply) 02:17, 25 November 2019 (UTC)
  •   Support - this is long overdue and should be rolled out across all projects. Wikitext is essentially a markup language, looking far too much like a programming language (remember Wordstar markup before Word came alone, anyone?) and many years past its sell-by date. New users should be able to add a cited fact as a single entity, so that it is immediately obvious that the source and its attributes (author, date, ...) are part of the claim, which could naturally be thought of as "author A makes claim C on date D in journal J ..." rather than the current bald "C" [is unconditionally true (not)]. It would be transformative to do things properly. Chiswick Chap (talk) 09:36, 25 November 2019 (UTC)
  •   Support Liuxinyu970226 (talk) 15:40, 25 November 2019 (UTC)
  •   Support 17:02, 25 November 2019 (UTC)
  •   Support Smvital (talk) 06:10, 25 November 2019 (UTC)
  •   Strong support Better form input would help newer editors enter consistent information as well as being able to analyse the resulting structured data. This would be a big win across the board. — Bryandamon (talk) 00:26, 26 November 2019 (UTC)
  •   Support Josephine W. (talk) 23:28, 27 November 2019 (UTC)
  •   Support AirSThib (Flight attendant · Flights) 11:11, 30 November 2019 (UTC)
  •   Support Novak Watchmen (talk) 17:38, 2 December 2019 (UTC)