How can working with templates become easier? That's the question the Technical Wishes team at Wikimedia Deutschland will focus on for two years. This focus was set by the 2019 Technical Wishes Survey on German Wikipedia.
The team sets out to find solutions for different problems that people on the wikis encounter when they work with templates. Improving individual templates is not part of the project. Instead, it's about finding concepts that generally make it easier to work with templates.
Based on the research results, feedback on the prototypes, interviews with Wikipedians and further input from the communities, we started the first projects in September 2020.
<templatedata> supports a “paramOrder” where one can specify a preferred order in which a template’s parameters should appear in VisualEditor. Alternatively, the actual order of the parameters in the “params” section can be changed. This is now respected when there is no “paramOrder”. T216808
Significantly improved performance of the wikitext syntax highlighter. T270317
Significantly improved loading time of the template editor when editing large multi-part templates, e.g. tables where each table row is a template. Note that it might still take up to a minute in extreme situations, but is a lot faster on average. T296335
Improved keyboard navigation and screen reader support (e.g. utilizing ARIA standards) in the VisualEditor template dialog. T289653
VisualEditor works much better with templates that are supposed to be used with the “subst:” prefix.
The TemplateData API works better together with other API modules as “generators”. The responses from both API modules will be merged. Before the data from the generator was not visible. T274907
A few smaller improvements to the wikitext syntax highlighter to make it understand certain edge-cases better. Example: T277767
Fixed editor losing focus when switching syntax highlighting on/off. T298488
FileImporter now also supports syntax highlighting in the step where one can fixup the file description page before the actual import is started.
The interactive TemplateData editor now uses a proper user-friendly widget to manage aliases, instead of a comma-separated string. T285284
<templatedata> now validates “aliases” and “suggestedvalues”. Both need to be lists of strings. T297386
Made auto-detection of template parameters in the TemplateData API more reliable. Example (one of multiple): T290322
A TemplateData documentation table can be sorted by the parameter’s priority: required → suggested → optional → deprecated. This is now done numerically instead of alphabetically.
The TemplateData documentation table appears more clean with less non-essential bits, e.g. not sortable when there is nothing to sort.
Fixed the TemplateData editor accidentally adding empty “autovalue” fields. T295074
Over several months, an interdisciplinary team did intensive research into potential problems and improvement requests associated with templates, as seen from both a technical point of view and from that of a user. In the box below you can see a summary of that research:
Research
Over the past months, an interdisciplinary team has intensively researched which problems and improvement requests exist in the area of templates from both the user and the technical point of view. The results are based on the following:
Interviews with active members of Wikimedia projects on Wikimania, WikiCon as well as remote interviews. A total of 19 interviews were conducted with users from as many different backgrounds as possible: different working methods (e.g. Visual Editor / Source Code Editor), different areas of work (use of templates / writing of templates), new and experienced contributors, from different Wikis, different origins, and of different ages and gender.
Evaluation of all old surveys on "TechWishes" in the German Wikipedia and their equivalents on Meta
Evaluation of the discussion pages for this wish, the voting page, the pages of the template- and technical workshop, as well as the help pages for templates
Evaluation of the problems reported at the Tech on Tour
Viewing of several hundred, up to 15 years old, tickets on Phabricator about MediaWiki templates and related keywords
A workshop about templates at WikiCon 2019 to find out more about how to work with templates
Exchange with the Wikimedia Foundation about its past and potential activities regarding templates
The research has revealed numerous problems and suggestions for improvement. There are two large target groups: those who work on templates and those who use them. Problem areas were identified for both target groups:
People who work on templates have problems with:
People who use templates have problems with
the template syntax
insufficient developer tools
historically grown templates
Maintenance of existing templates
the overview and findability of templates
the documentation of templates
learning how to use templates
the handling of templates in the Visual Editor
the social values and norms that have formed around the use of templates.
Most of the problems and suggestions for improvement appeared several times and in different contexts during the research, which shows their great importance. The most frequently mentioned problems in these problem areas can be found here.
As always, feedback is welcome. For example, if you think that something has been overlooked during the research, or that other criteria should be considered for the next steps, please write to us on the discussion page.
Following this first phase, further research was done to determine the improvements that could be implemented. We examined a number of improvement ideas for their feasibility, effort, potential value and any possible disadvantages. The goal was to have improvements for both template users and for template creators & maintainers.
Based on that examination, we created basic prototypes to share and further discuss possible projects, which you can see in the following box:
Early prototypes
In the autumn of 2019, the team carried out comprehensive, interdisciplinary research in the subject area (see above); the result of this research is the list of problems in the subject area published here. Since then, research has been underway to determine which improvements could be implemented. To this end, numerous ideas for improvements were examined for their feasibility, effort, potential value and possible disadvantages.
Over the coming weeks, a series of simple prototypes (first draft designs) for possible projects will be published here regularly. Everyone is invited to evaluate and comment on them. For a balanced picture, feedback is sought from Wikimedians with different levels of experience, working methods and fields of activity. Based on this feedback, the Technical Wishes team will consider whether to implement the ideas, revise them again, or discard them in favor of others. Depending on the outcome of this prototyping phase, there may be another round of new ideas to provide feedback on later in the year.
Feedback on the prototypes is always welcome. However, timely feedback (within two weeks of posting) on prototypes can be used to feed directly into the development of the next prototypes.
In order to get an even deeper understanding of the issues users face, there will also be remote interviews and user tests with Wikimedians in parallel to the onwiki feedback rounds - we are still looking for volunteers! If you would like to volunteer, you can register here. Please enter the keyword "templates" in the comment field.
Important: Since we want to present new prototypes regularly in the coming weeks and we don't want to flood users' inboxes, we ask all interested people to watch this page.
Prototype 1: Featured Templates and Search Filters
This proposal consists of two parts: Search filters to find templates and the introduction of “featured templates”. The aim of this proposal is to address the frequently mentioned need for better "overview and findability of templates". This proposal should make it easier for Wikimedians to find the right template without searching through other articles for a suitable one to copy and paste.
Both the Visual Editor and the TemplateWizard in the Wikitext Editor currently have a simple input field with auto-completion to select the desired template. At the moment templates can only be easily added here if you know the exact name of the template you want to insert.
We plan to extend this to a search with filter options, so that it is easier to find the desired template. Through the filters, the search results can be narrowed by type of template (infobox, source, etc.) or by subject area (biographies, animals, etc.).
The second part of this proposal is the introduction of featured templates, following the example of featured articles, list and images. As with these, the criteria and processes of designating templates as ‘featurable’ are in the hands of the community. The featured templates would be shown more prominently in the search described above and suggested to users. The designation of featured templates could provide an incentive to improve existing templates instead of creating new alternatives.
The animation below shows a rough draft where you can see how these two features could work together. At the current stage the emphasis is not on the implementation details, but whether these ideas are worth pursuing further.
When the user clicks on "Insert template" in the Visual Editor a modal window opens. In this window, it is possible to search for featured templates filtered by category and type. A more detailed, larger version of this could be found on a new special page.
We are looking forward to any kind of feedback. Do you think these two suggestions are suitable to simplify the process of finding the right template and would this make your work easier? Should we follow up on these suggestions? If possible, please tell us if you consider yourself more of a template user or template creator and more of a newcomer or a power user.
Thank you for the valuable feedback on the two parts of the first prototype as well as the numerous other ideas, suggestions and comments. We won't pursue the idea of featured templates, but will continue looking into ideas related to findability. We will be sharing another prototype about the latter for additional feedback. We appreciate all the suggestions, many of which coincide with our research, which makes us confident that we will end up with projects that will take Wikipedia and its sister projects forward.
Back in March, the Technical Wishes team shared a first prototype: Featured Templates and Search Filters. It consisted of a search with filter options and the introduction of featured templates, similar to featured articles and images. We received a lot of feedback for that prototype. Thanks a lot for all your ideas, questions and comments.
After carefully reviewing the feedback and investigating several possible directions, the next prototype we would like to propose is a refined Template Finder as a standalone feature without Featured Templates. It builds upon the previous proposal but searches all templates on a wiki. Additionally, it has different types of filters and ways of exploring the results. Ideally, this specialized search would allow users to discover new templates to meet their specific needs and help experienced users who maintain templates to easily find the templates needing attention.
The video shows an example of how a search for a template might look like in the future.
This walkthrough video begins in Visual Editor, but we would be able to provide links to the Template Finder from the TemplateWizard in the source editor, Advanced Search, and potentially elsewhere. As a standalone page, there are many options for integration and the goal is to ensure that it would be accessible to anyone who might find it useful.
The video then shows a user completing a search and narrowing the selection of templates by using the available filters. For more detail on the possible features, see the individual proposals below.
Currently, the search for templates is unsatisfactory as it does not display all suitable templates to users (too narrow) while at the same time leading to only loosely related pages (too broad).
Here are some potential ways that search results could be improved. Please note that not all proposals would necessarily be implemented.
Remove documentation pages from search results
Order of words does not affect results, meaning that the search term could exist at any point within the template name, not just at the beginning
Look for search term in the template description, not just the template name
Templates are mostly created for specific fields of application. Filters could help to find the right template for the use case in mind.
Please note that the proposal includes some filters based on existing TemplateData (machine-readable metadata about individual templates) while some would require adding new fields. This content would not be added by the Technical Wishes team, but would be flexible and added on a per wiki basis by the Community based on their needs.
Intended Namespace:
There are several namespaces on Wikipedia such as article pages, discussion pages and project pages. As most templates only make sense in the context of a certain namespace, this would be added as a filter (Information would need to be added to TemplateData).
Template Type:
Wikis have different template types such as banners, citations or stubs. The exact template types differ from wiki to wiki. Every community would be empowered to set their own template type system in TemplateData and filter by this.
Category:
The goal with category filters would be to make existing categories more visible and explorable. This does not include changes to the category system itself or the way categories function. When filtering by category, only categories used by templates in the current search results would show up.
The displayed categories are then ordered based on which contain the most templates, so that they are ordered by relevance.
As there are many categories, users could also start typing to find the one they want.
Has/Missing TemplateData:
The search could allow filtering for templates that do or do not have TemplateData. This might be helpful to those maintaining templates, as well as users who are looking for a template that works easily within the visual editor.
Additionally, it would be possible to search using only filters without any search terms, for example to easily compare all templates in a category of a specific type.
The exact implementation and feasibility still needs more investigation, but ideally an example invocation (not an image) would be displayed. If no example invocation is available, the fallback plan would be to show a default/empty invocation. If a preview is missing or broken, it would display a button leading users to the TemplateData where it could be updated.
Note: The implementation would need significant investigation and discussion with the Community, but we believe that the benefits could also be significant.
Description:
The search results would display the description provided in TemplateData. As the examples show, most templates are currently missing the required information. There would be an info icon encouraging users to add descriptions to fill in the gaps.
Layout:
TemplateData already contains information on whether a template is inline or block formatted. This could easily be displayed. If useful, this could also be added as a filter. Please let us know if a filter for layout would be useful for you.
Number of Parameters:
The number of parameters is a nice indicator of both complexity and type of template. This would also not require additional TemplateData.
The quick view would show more detailed information without needing to open a new page. It would focus on information needed to:
properly use the template,
compare templates in detail, and
select the right template.
It would contain:
Name of the template
With a button to easily copy the name of the template for use in the visual editor’s TemplateDialog and the source editor’s TemplateWizard (the dialog windows for inserting templates).
Wikitext
A box showing the source code, with a button for easy copying of the snippet, would allow source code editors to easily use a template.
There is one more idea not included in the video: If users put the name of an article as the search term, all the templates used within the article would be displayed in the table below as search results.
We are looking forward to any kind of feedback either on the talk page or in the survey in this section. Please note that not all features will necessarily be implemented, so feedback is very useful in helping prioritize. You are welcome to leave comments on any aspect of the design, but here are a few questions as a starting point:
Do you think the Template Finder would simplify the process of finding the right template? How?
Which feature is most useful? Which feature adds the least value?
How do you see the Template Finder fitting into existing workflows?
The expansion of TemplateData would increase the amount of machine readable information about templates and greatly improve the usefulness of this feature but would require community effort as well. What do you think about this impact?
Since 2018, the Wikitext editor includes syntax highlighting. This feature displays the source code with different colors, backgrounds and text styling according to their category. This should help the reader to understand the code and to orientate themselves better in the source code. Syntax highlighting can be used in both the article namespace and the template namespace (and most others). So it can help both when editing and using templates. But in more complex situations - especially when working with nested templates and when editing complex templates - the current syntax highlighting reaches its limits.
In these prototypes, the aim is therefore to improve this function. We have five suggestions for this, which are roughly sketched below. As with all prototypes in this project, these are sketches of the ideas we want to hear your opinion about. Not all ideas will necessarily be implemented.
Prototype 2a: Active section highlighting and elimination of other background highlighting
Active section highlighting and elimination of other background highlighting
Currently, syntax highlighting colors the text background if the text is within a template or a so-called ParserFunction. When working on templates or editing pages with many nested templates, this can lead to almost all text being highlighted, thus creating confusion instead of clarity.
This suggestion is therefore to not color the background of these texts in general and instead only highlight the innermost function or template in which the cursor is currently located.
In the graphic, the cursor is located at the selected position within the 'if' function, so the entire area of this 'if' function is highlighted with a red background. This makes it easier to see what belongs together both as someone writing code and as someone looking to understand what another user has written.
The template syntax is known for its many curly brackets. Since templates, template variables and parser functions use different numbers of curly brackets, it can be difficult to identify which brackets belong together when developing templates or when using nested templates.
Many source code editors and IDEs outside of the Wikimedia projects have a "bracket matching" function for this problem: If the cursor is next to an opening bracket, the corresponding closing bracket is highlighted and vice versa.
Ideally, the functionality could also be extended so that not only the single associated bracket is highlighted, but all brackets belonging together are highlighted.
In the sketch, for example, the cursor next to a closing parenthesis and thus the four curly brackets that form the beginning and end of the 'if' function are highlighted.
Typing curly brackets varies in complexity depending on the keyboard. In order to be able to type faster and not forget closing brackets, another known function from development environments could be built in: if you type an opening brace, the closing brace is automatically inserted and the cursor is placed between the brackets.
For example, if you type {{{, you automatically get {{{|}}} and the cursor is in the middle of the brackets, so you can continue typing the name of the variable.
In implementation, there would be a way to toggle the function on and off.
Demonstration of how white space highlighting could help working with templates
Prototype 2d: Highlight whitespace that affects formatting
Depending on the context, spaces and line breaks in the wikitext may or may not affect the rendered page. Especially when editing templates, it is often difficult to see what effects whitespaces have. An extension of syntax highlighting could mark spaces and line breaks that affect formatting. For example ¶ for line breaks and · for spaces could be used, shown in subtle colors. In implementation, there would be a way to toggle the function on and off.
Prototype 2e: Update styling rules and color theme
Not all current colors are meeting accessibility standards, the two blues are not easily distinguishable, and when all colors combine it’s not always the easiest on the eyes. We completed a study on each of the colors, adjusting to meet contrast requirements for accessibility. The category colors would stay fundamentally the same - variables would stay orange and templates would stay purple - but small changes could improve the contrast, especially for people with color vision deficiencies. Colors would be adjusted for contrast and the background could be adjusted for optimum readability.
Current Colors
Improved colors, meeting accessibility criteria
Simplified, color-blind friendly scheme
Alternative color-blind mode: high contrast for people with visual impairment
We would like feedback from any users familiar with template syntax, whether you are comfortable writing it from scratch or if you only rarely use nested templates or edit templates. Please leave your feedback on the discussion page.
Would you find these changes helpful?
How would it impact your interactions with templates?
Which proposal are you most excited about?
Note: We appreciate all the comments received so far but also wanted to provide a way for quick responses and have added a quick survey to this section.
The proposal of introducing global templates – templates stored centrally, that can be used in all Wikimedia wikis – popped up many times in the research conducted by the team, as well as while creating and announcing prototypes. We see the big potential of this proposal, but after looking into it we came to the conclusion that we don’t have the resources for this kind of a project. The WMDE Technical Wishes team is a small team and bound to a two year timeframe per focus area to ensure that we can make improvements in more areas of Wikipedia – our assessment concluded that this project would need more staff resources and time than we have. Therefore, we unfortunately won’t be able to tackle it at this time for now.
Prototype 3: Improve working with templates in Visual Editor
When filling out a newly added template or editing an existing template in Visual Editor, a dialog window pops up to add, edit, or remove different fields. The following proposals concern this window and how to more easily fill in the fields. This is often laborious and confusing for both new and experienced editors. It is difficult to understand what information to fill in to the fields and how to format it correctly. Most of the proposals aim to provide better help, while also assisting in the correct formatting of fields. To find this screen, edit an article in Visual Editor and click on “Insert” > “Template.”
Note: The dialog in the images is expanded to show the interface changes, but the lengthened size is not part of the design proposal.
Prototype 3.1 - 3.6 - Improve working with templates in Visual Editor
Currently, the name of the template appears twice. In the proposal, the icon and title are changed to describe the section more clearly and guide you to the right place when you are looking for help. A rephrased sentence encourages you to visit the documentation page.
For added clarity, required parameters would be shown with a label instead of an asterisk. Tests have shown that asterisks do not universally mean “required” to users. Suggested and Optional parameters remain unlabeled.
When a specific parameter is in focus, the [[]] button would no longer be shown. The [[]] button rarely serves a useful purpose and is being eliminated to limit confusion and simplify the interface.
Currently, descriptions are hidden and only shown when the info “i” icon is clicked. Often these descriptions have critical information which helps you correctly fill out parameters and format them correctly. The proposed design removes the info icon and instead displays descriptions under the parameter name. When TemplateData is missing, then nothing is displayed (ex. Birth date). Currently, the info icon is visible but unclickable in these cases, which is very confusing.
People writing TemplateData could choose to group parameters. This would result in a visible grouping in Visual Editor, plus sub-parameters would not have labels in bold. This would for example be particularly useful for image related parameters.
Adds the possibility of specifying a list of values that are proposed for a parameter in TemplateData. In the template dialog in Visual Editor, they would be shown as a drop down menu from which you could select one or type in a different value. The field would have auto completion so that when you start typing, the proposed values are filtered.
Autocomplete would work for file names on Wikimedia Commons, in addition to the names of Wikipages and usernames. The current functionality would be expanded, so that if a parameter accepts these input types, then results would show once you start typing (see 7a). In addition, after a page is selected, it would be automatically formatted to become a wiki link (see 7b).
Prototype 3.8a - Add buttons to use existing Visual Editor media selector
3.8a Add buttons to use existing Visual Editor media selector
Buttons to add images or other files would be added to parameters of the corresponding type. You would no longer need to open Wikimedia Commons in a separate tab to search for an image. This would be particularly helpful for newcomers who might not know that they need to copy and paste a file name. When clicked, the buttons would open the existing Media selector for Visual Editor. Depending on which button is clicked, the corresponding tab in the Media selector would open.
Proposed above are many smaller changes to improve working with templates in Visual Editor. What do you think about them and which do you think are (most) useful?
Any type of feedback on the discussion page is appreciated. Additionally or alternatively you can fill out the quick survey in this section.
Based on the feedback we received on the foregoing, as well as all our previous investigations and discussions, we improved on the ideas and evaluated them as to
their impact (how beneficial are they?),
the effort required (how hard would they be to implement?), and
risks (are there negative side effects? might the project fail or be blocked by other teams?).
For those projects we deemed most valuable and doable for our team, we conducted further investigations, and developed more elaborate prototypes. The idea of a standalone Template finder, for instance, was dismissed; instead, ideas for better findability were integrated directly into the template editors. These high-fidelity prototypes were tested in usability tests with newcomers, casual editors, power users, template users and template creators & maintainers, to make sure our contributions would serve all types of users. We also made sure to have testers with diverse backgrounds (home wiki, including RTL wikis, age, gender, color blindness). The tests showed that some project ideas would create confusion or additional problems, or just wouldn’t help as much as we thought. Those ideas were dismissed or significantly revised. Other ideas generated a lot of excitement and were further improved by constructive feedback from the testers. Those are the ideas that will now be implemented.
Done
In development
Done Research of problem areas, presented on Meta and dewiki
