Hello design!
*TL;DR* Help pages are just like encyclopedic pages on Wikipedia, but they have not the same goal: when you need an information to contribute, you need it quick.
Since January, French Wikipedia community[6] has begun an important project: redesigning Help namespace. With this project, we want to create a specific design for help pages, with defined blocks to organize key points, big and readable titles, more friendly TOC, etc. The result is visible on two mockups[1][2] and a live demo[3].
This new design is quite ready, and we planned to deploy it on our common.css a few weeks ago in order to run some tests with new users. But some users has some rationale concerns about the deployment itself: we planed to create a new design by adding new CSS to the common.css file. This involves an important risk of conflict if there is an important skin update in the future.
For us, next steps are: 1/ validate the choices we made for this new interface, 2/ create a separate skin (with an extension? An other solution?). We need you to help us on these two points.
*Long version* On French Wikipedia - and I assume this is the same on other projects - help pages are just a an out-of-date mix of technical information without any organization. They are not easy to read! We also often have barbaric changes on Help namespace, by people who believe they are writing an article.
With this design project, we plan to create more friendly help pages. We are working on two points: * the *content* (text, images) is rewritten in order to be shorter, more precise, and focused on what newbies ask all the time. We have separated basics from advances and expert knowledge. We are busting all not up-to-date information, pure technical stuff or jargon on basic help pages, encyclopedic style, etc. We are making a clear separation between technologies, with wikitext on one side and VE on the other[4]. * the *design* in order to have a presentation which is clear, more readable and efficient, and of course, user friendly to update.
A page with the new design is now is divided into 4 big parts : * header * toc * contents * bottom We also have generic elements.
First, the *header* presents (a lot of) information about the page: * a description which indicates the purpose of the page * a difficulty level (basics, advances, expert) in order to avoid surprises when a newbie reads the page * information about user status (when an account is needed, or autopatrolled status for example) * information about the concerned product (wikitext or VE) * links to relative contents, parent contents, etc. We have made a classification for help pages, based on action verbs (insert, create, discuss...). All this is included in one template. This is the only important template on an help page.
The *TOC* is reduces to h2 and h3 titles, others are not displayed. By this, it is easier to read the TOC. When we modify an help page, we need to be more concise or create a specific page in order to detail a long point which requests h4 or h5 titles. The TOC displays h2 titles as a main title (bolder) and h3 as sub element (inline elements). By this, we emphasize key points and reduce the need of scrolling on the whole TOC when searching information.
*Content* is composed of blocks, delimited by gray blocks. A block starts with a h2 title and stops when an other h2 title starts, with a visible white delimitation. The rule is now one information = one block (where I add a reference, how I add a reference, etc.).
h3 titles are sub elements in their parent block. There are separated from the other elements by an horizontal gray line. An important padding makes the text column narrower, and easier to read.
We are also working on best practices: add a tl;dr on the first section (called "à retenir" - not fo forget), short text on h3 sections, and more.
When wikitext and VE are available to edit, we add on the *bottom* page a list of useful links: how to insert a link, a template, an image, etc. We also put generic informations about editing (no copyvios, reliable sources). We can imagine to have a form who takes feedback from readers (who says Article Feedback Tool?).
In order to reduce efforts when reading the pages we have change some *generic elements*. The page has a max-width at 1,000 pixels. Text font has been enlarged by 0.1 em and titles redesigned to be like titles used on Flow (and quite more visible).
Concerning colors, we have used the MediaWiki UI palette[5], especially the orange - which is a symbolic color for work in progress or constructions - and gray, already used on other products (Flow, MediaViewer).
All these changes are inspired by other help pages on other big websites (Google docs, GMail, Facebook, Twitter, YouTube...): every time, content pages design and help pages design are different. You know you are on a place where you can have some help and some information. But not on Wikipedia.
*And now?* Now this project is stopped, for the design part at least. We (the community) have some questions about the next steps. * Is there an official way to validate the choices we made for this new interface? We can run a test, but we don't have tools (or skills) for this. * in order to deploy this new design, we can create an extension. We have volunteers for this, with strong skills (some of them are already volunteers developers for MediaWiki). But is it the best way? Is there other ideas or solutions?
We need you to help us on these two points. We will also be happy to have any feedback or advice about our project. :)
On behalf of the Projet:Aide et Accueil[6], Benoît / Trizek
[1] https://commons.wikimedia.org/wiki/File:Aide_Ins%C3%A9rer_une_r%C3%A9f%C3%A9... [2] https://commons.wikimedia.org/wiki/File:Aide_Homonymie_fr.wikip%C3%A9dia.png [3] On French Wikipedia, go to your preferences https://fr.wikipedia.org/wiki/Spécial:Préférences, *Gadgets* tab, and activate *MiseEnPageEspaceAide* gadget. Then go to Aide:Sommaire https://fr.wikipedia.org/wiki/Aide:Sommaire and browse help pages. [4] Example of page making the distinction between VE and wikitext, with a link to reach each technology : https://fr.wikipedia.org/w/index.php?title=Aide:Ins%C3%A9rer_une_r%C3%A9f%C3... [5] https://commons.wikimedia.org/wiki/File:Mwuipalette.png [6] https://fr.wikipedia.org/wiki/Projet:Aide_et_accueil
Hi Benoit,
One relatively simple way to test your changes is to come up with a short list of help-seeking tasks ("find out how to create a sortable wiki table", "find out where to ask a question about citing sources"), and then have two groups of users try to complete those tasks--one group will use the old interface, the other will use the new interface.
Have someone who was involved in the design project sit next to those users (or have the users share their screen over Google hangout), and watch as the users try to complete the tasks. Take notes, ask questions. If you find that users are able to complete tasks more quickly (or at least more often) with redesigned page, you're probably on the right track. If you find that certain aspects of the redesign (the wording of a heading, for example) seem confusing to a number of your test users, or if your users have a hard time completing the tasks, you should consider revising your design.
The above is a basic usability test protocol, and can be conducted by pretty much anyone. There are good online how-to resources available through Google.
Peter Coombe (now of WMF Fundraising) conducted a help-page-redesign project in 2012 on the English Wikipedia. He performed usability tests for that project as well. Not sure if you've seen his work, but here are some related resources: https://en.wikipedia.org/wiki/Wikipedia:Help_Project/Community_fellowship
Hope that helps, Jonathan
On Sun, May 10, 2015 at 9:34 AM, Benoît Evellin <benoit.evellin@wikimedia.fr
wrote:
Hello design!
*TL;DR* Help pages are just like encyclopedic pages on Wikipedia, but they have not the same goal: when you need an information to contribute, you need it quick.
Since January, French Wikipedia community[6] has begun an important project: redesigning Help namespace. With this project, we want to create a specific design for help pages, with defined blocks to organize key points, big and readable titles, more friendly TOC, etc. The result is visible on two mockups[1][2] and a live demo[3].
This new design is quite ready, and we planned to deploy it on our common.css a few weeks ago in order to run some tests with new users. But some users has some rationale concerns about the deployment itself: we planed to create a new design by adding new CSS to the common.css file. This involves an important risk of conflict if there is an important skin update in the future.
For us, next steps are: 1/ validate the choices we made for this new interface, 2/ create a separate skin (with an extension? An other solution?). We need you to help us on these two points.
*Long version* On French Wikipedia - and I assume this is the same on other projects - help pages are just a an out-of-date mix of technical information without any organization. They are not easy to read! We also often have barbaric changes on Help namespace, by people who believe they are writing an article.
With this design project, we plan to create more friendly help pages. We are working on two points:
- the *content* (text, images) is rewritten in order to be shorter, more
precise, and focused on what newbies ask all the time. We have separated basics from advances and expert knowledge. We are busting all not up-to-date information, pure technical stuff or jargon on basic help pages, encyclopedic style, etc. We are making a clear separation between technologies, with wikitext on one side and VE on the other[4].
- the *design* in order to have a presentation which is clear, more
readable and efficient, and of course, user friendly to update.
A page with the new design is now is divided into 4 big parts :
- header
- toc
- contents
- bottom
We also have generic elements.
First, the *header* presents (a lot of) information about the page:
- a description which indicates the purpose of the page
- a difficulty level (basics, advances, expert) in order to avoid
surprises when a newbie reads the page
- information about user status (when an account is needed, or
autopatrolled status for example)
- information about the concerned product (wikitext or VE)
- links to relative contents, parent contents, etc. We have made a
classification for help pages, based on action verbs (insert, create, discuss...). All this is included in one template. This is the only important template on an help page.
The *TOC* is reduces to h2 and h3 titles, others are not displayed. By this, it is easier to read the TOC. When we modify an help page, we need to be more concise or create a specific page in order to detail a long point which requests h4 or h5 titles. The TOC displays h2 titles as a main title (bolder) and h3 as sub element (inline elements). By this, we emphasize key points and reduce the need of scrolling on the whole TOC when searching information.
*Content* is composed of blocks, delimited by gray blocks. A block starts with a h2 title and stops when an other h2 title starts, with a visible white delimitation. The rule is now one information = one block (where I add a reference, how I add a reference, etc.).
h3 titles are sub elements in their parent block. There are separated from the other elements by an horizontal gray line. An important padding makes the text column narrower, and easier to read.
We are also working on best practices: add a tl;dr on the first section (called "à retenir" - not fo forget), short text on h3 sections, and more.
When wikitext and VE are available to edit, we add on the *bottom* page a list of useful links: how to insert a link, a template, an image, etc. We also put generic informations about editing (no copyvios, reliable sources). We can imagine to have a form who takes feedback from readers (who says Article Feedback Tool?).
In order to reduce efforts when reading the pages we have change some *generic elements*. The page has a max-width at 1,000 pixels. Text font has been enlarged by 0.1 em and titles redesigned to be like titles used on Flow (and quite more visible).
Concerning colors, we have used the MediaWiki UI palette[5], especially the orange - which is a symbolic color for work in progress or constructions - and gray, already used on other products (Flow, MediaViewer).
All these changes are inspired by other help pages on other big websites (Google docs, GMail, Facebook, Twitter, YouTube...): every time, content pages design and help pages design are different. You know you are on a place where you can have some help and some information. But not on Wikipedia.
*And now?* Now this project is stopped, for the design part at least. We (the community) have some questions about the next steps.
- Is there an official way to validate the choices we made for this new
interface? We can run a test, but we don't have tools (or skills) for this.
- in order to deploy this new design, we can create an extension. We have
volunteers for this, with strong skills (some of them are already volunteers developers for MediaWiki). But is it the best way? Is there other ideas or solutions?
We need you to help us on these two points. We will also be happy to have any feedback or advice about our project. :)
On behalf of the Projet:Aide et Accueil[6], Benoît / Trizek
[1] https://commons.wikimedia.org/wiki/File:Aide_Ins%C3%A9rer_une_r%C3%A9f%C3%A9... [2] https://commons.wikimedia.org/wiki/File:Aide_Homonymie_fr.wikip%C3%A9dia.png [3] On French Wikipedia, go to your preferences https://fr.wikipedia.org/wiki/Spécial:Préférences, *Gadgets* tab, and activate *MiseEnPageEspaceAide* gadget. Then go to Aide:Sommaire https://fr.wikipedia.org/wiki/Aide:Sommaire and browse help pages. [4] Example of page making the distinction between VE and wikitext, with a link to reach each technology : https://fr.wikipedia.org/w/index.php?title=Aide:Ins%C3%A9rer_une_r%C3%A9f%C3... [5] https://commons.wikimedia.org/wiki/File:Mwuipalette.png [6] https://fr.wikipedia.org/wiki/Projet:Aide_et_accueil
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Mon, May 11, 2015 at 9:08 PM, Jonathan Morgan jmorgan@wikimedia.org wrote:
The above is a basic usability test protocol, and can be conducted by pretty much anyone. There are good online how-to resources available through Google.
A three part article on how to conduct user testing: https://medium.com/cluster-ideas/how-to-run-live-user-testing-sessions-fef63...
If you don't want to conduct the tests yourself, and have some budget for this, you can also try tools like: https://lookback.io/ http://www.usertesting.com/
Abbey (+cc), might be able to give you some pointers too.
—prtksxna
Hi Benoit, this is very interesting! I really like the standardised headers with difficulty-levels, and the key-point-reminder/TL;DR/à retenir section. :-)
A few quick notes: * I suggest reducing the indent for list-items (from 5em to 2em?) otherwise it leads to problems at smaller (~1024) screen widths, e.g. https://i.imgur.com/sJgq799.png or https://i.imgur.com/pkwbvLA.png * I suggest reducing the margin at top and left, too, for the same reason.
Note to self: the CSS used by the gadget-ized version is here: https://fr.wikipedia.org/wiki/MediaWiki:Gadget-MiseEnPageEspaceAide.css
Sorry I can't help with the technical-implementation question.
Hello
Thank you Jonathan, Prateek and Nick! I'll forward your ideas and suggestions to the team.
Concerning the implementation, the question is still open. :)
Best, Benoît Hi Benoit, this is very interesting! I really like the standardised headers with difficulty-levels, and the key-point-reminder/TL;DR/à retenir section. :-)
A few quick notes: * I suggest reducing the indent for list-items (from 5em to 2em?) otherwise it leads to problems at smaller (~1024) screen widths, e.g. https://i.imgur.com/sJgq799.png or https://i.imgur.com/pkwbvLA.png * I suggest reducing the margin at top and left, too, for the same reason.
Note to self: the CSS used by the gadget-ized version is here: https://fr.wikipedia.org/wiki/MediaWiki:Gadget-MiseEnPageEspaceAide.css
Sorry I can't help with the technical-implementation question.
_______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Sun, May 10, 2015 at 9:34 AM, Benoît Evellin <benoit.evellin@wikimedia.fr
wrote:
... This new design is quite ready, and we planned to deploy it on our common.css a few weeks ago in order to run some tests with new users. But some users has some rationale concerns about the deployment itself: we planed to create a new design by adding new CSS to the common.css file.
It looks like this would change the appearance of every page in the Aide namespace, I can see why people might be nervous. Maybe there's a way to have CSS rules that only activate on some pages in the Aide: namespace.
This involves an important risk of conflict if there is an important skin update in the future.
That's always the case. Someone has to update software.
For us, next steps are: 1/ validate the choices we made for this new interface, 2/ create a separate skin (with an extension? An other solution?).
Why do you need a separate skin? If these commons.css rules that only apply to the Aide: namespace do the right thing, then I'm not sure what the benefit of a custom skin is. I don't know how a custom skin can make only minor tweaks to an existing skin like Vector.
If you do decide to make a custom skin, you will need to develop it and get it reviewed and approved for deployment on the WMF cluster, and I think you will also need to get either https://www.mediawiki.org/wiki/Extension:SkinPerPage or https://www.mediawiki.org/wiki/Extension:SkinPerNamespace reviewed and approved for deployment to configure which pages or namespaces get this skin. (I have some interest in getting one of these extensions deployed on mediawiki.org for the Living style guide and/or a developer hub so they can use a different skin like Blueprint.)
- in order to deploy this new design, we can create an extension.
Do you mean in addition to the new skin, or just an extension that can be smart about loading the CSS for the special look?
We have volunteers for this, with strong skills (some of them are already volunteers developers for MediaWiki). But is it the best way? Is there other ideas or solutions?
It depends what you need. Many skin experts don't participate on the design mailing list; you could ask on wikitech-l with a better description of what you're trying to do.
Cheers,