Page MenuHomePhabricator

Design review for help contents sample pages
Open, Needs TriagePublic

Description

I'm working on help contents, which implies to have a new design for help pages. This work needs a design review to spot possible blockers or obvious mistakes.

Pages to review are

Event Timeline

Trizek-WMF updated the task description. (Show Details)Jan 21 2020, 5:53 PM
RHo added a comment.Jan 27 2020, 2:55 AM

hi @Trizek-WMF - here's some review notes for the sample pages, hope it helps!

A. Overall feedback
  • “Wikipedia Help contents” link colour in orange looks like an alert/error and also not in keeping with the standard style guide. Suggest to keep the existing color as the bolded and slightly larger font-size in the breadcrumb is sufficient.
  • Breadcrumb wrapping display bug on Desktop and Mobile

  • Placement of the “Search in Help” field and button makes it slightly ambiguous whether the user will only be searching the contents of the specific help content on the page, or whether it is searching across all help pages. A suggestion is to move its that it is hierarchically on the same level or over the help page title. Potentially the search in help makes more sense as a secondary side panel/column on the RHS of the page; where users may also be shown other related or top help page links.
  • Consistency in terminology and grammar details such as capitilisation
    • eg1., Inconsistency in naming - the “Add contents to an article” contents page has the breadcrumb “Edit an article”, and it is unclear whether the “Format text” list item refers to Copy editing. Generally we should aim have the same names for help as the item for which the help is being provided.
    • eg2., I would *not* capitalise “Article” and “Citation” in the middle of a sentence.
  • Maybe the contents/overview page does not require a H2 if it is only intended to list the links to different edit types. This is especially not desirable on mobile where the contents list is hidden in the default collapsed section.
  • The “Why” section is essentially repeating the same sentence as the ‘intro’ text in the box at the top without providing more information. We should avoid this repetition as much as possible.
  • Users should be informed succinctly what the “why” is without having to navigate to another page from the help.
  • Minor quibble - suggest we keep consistent language for “Learn more” or “Read more” everywhere. Not such a fan of “Know more” more as it may promise more than what is being delivered
  • Can we be slightly more explanatory with the “Caution” text again without requiring users to click to another page?
  • Let’s remove the lightbulb icon being used for “Note”.
  • There is, in my opinion, too many “Notes” being added in the how too subsections in a slightly confusing layout (sometimes above, sometimes within, sometimes after the step-by-step instructions),
  • The five different how-tos for Desktop/Mobile VE/Wikitext/New Wikitext editors is too overwhelming and the terminology likely unclear for the majority of newcomers visiting help.
    • suggest removing the “new wikitext” mode for starters
    • let’s rename with Desktop/Mobile in the tab label first, following be the editor type slightly more clearly labelled as such, for example change “Visual (desktop)” to “Desktop - Visual edit” , and “Wikitext (mobile)” to “Mobile (source edit)”
    • Adding screenshots for each of the tabs would be a fast and easy way to distinguish the different how-tos
  • Suggest removing the first step of each how-to on clicking “edit”, or else at least rewriting to be more generic, since the label may be different depending on availability or previous choices from a user. For example, a user may not have “Edit source” as an option available until after selecting “Edit”
  • Add steps at the end of the how-tos with general guides on previewing and saving their edit.
B. Mobile-specific
  • Search in help text field and button is unexpectedly center-aligned on mobile and causing display issues

  • since tabs are not available to split up for the different editor and platforms for mobile, can these be separated into subsections instead? It’s quite confusing too for the mobile-VE and source sections to be last
C. Desktop-specific
  • “Wikipedia Help contents” breadcrumb should be vertically center aligned with “Search in Help” elements if they are to remain in the same location
  • Minor visual bug - Search in help text field and button is not aligned to RHS divider line of inset box

hi @Trizek-WMF - here's some review notes for the sample pages, hope it helps!

Thank you very much! I've tried to change everything, except for some elements I have questions about - see below.

A. Overall feedback

“Wikipedia Help contents” link colour in orange looks like an alert/error and also not in keeping with the standard style guide. Suggest to keep the existing color as the bolded and slightly larger font-size in the breadcrumb is sufficient.

How can we differentiate an Help pages from a regular help page then?

  • Placement of the “Search in Help” field and button makes it slightly ambiguous whether the user will only be searching the contents of the specific help content on the page, or whether it is searching across all help pages.

A suggestion is to move its that it is hierarchically on the same level or over the help page title.

Which title? The h1 one that is on every page, or the one I've added in the box at the top? The latter exists because some communities may use subpages like I did on my examples.

Potentially the search in help makes more sense as a secondary side panel/column on the RHS of the page; where users may also be shown other related or top help page links.

You mean have the entire grey box being on the right? This has already been done on some wikis, but they often use the box to add thousand of links there. I'm afraid of a possible similar effect there.

  • Consistency in terminology and grammar details such as capitilisation
    • eg1., Inconsistency in naming - the “Add contents to an article” contents page has the breadcrumb “Edit an article”, and it is unclear whether the “Format text” list item refers to Copy editing. Generally we should aim have the same names for help as the item for which the help is being provided.
    • eg2., I would *not* capitalise “Article” and “Citation” in the middle of a sentence.

What's the way to emphasis an important piece of vocabulary people have to know about, and may need to re-use later?

  • Maybe the contents/overview page does not require a H2 if it is only intended to list the links to different edit types. This is especially not desirable on mobile where the contents list is hidden in the default collapsed section.

How can we have sections to structure the page, then?

  • Users should be informed succinctly what the “why” is without having to navigate to another page from the help.

This conflicts me: Wikipedia has pages about recommandations and rules, and Help pages are supposed to clearly explain how to apply these rules. You mean that I should expand this section, but, if I want to follow a best practice, I will have to add a link to the main page.

  • Can we be slightly more explanatory with the “Caution” text again without requiring users to click to another page?
  • Let’s remove the lightbulb icon being used for “Note”.
  • There is, in my opinion, too many “Notes” being added in the how too subsections in a slightly confusing layout (sometimes above, sometimes within, sometimes after the step-by-step instructions),
  • Adding screenshots for each of the tabs would be a fast and easy way to distinguish the different how-tos

Even if we will have to make a screenshot for every language?

  • Suggest removing the first step of each how-to on clicking “edit”, or else at least rewriting to be more generic, since the label may be different depending on availability or previous choices from a user. For example, a user may not have “Edit source” as an option available until after selecting “Edit”

Not sure to get it, can you clarify?

B. Mobile-specific
  • Search in help text field and button is unexpectedly center-aligned on mobile and causing display issues

This box should be properly coded. I'm just prototyping here. :)

  • since tabs are not available to split up for the different editor and platforms for mobile, can these be separated into subsections instead? It’s quite confusing too for the mobile-VE and source sections to be last

We have two solutions there:

  • make the tabs working
  • have a way to have h3 sections title being collapsible on mobile

Hey Benoît,
You asked me to take a look and after reading what Rita already covered, I don't have much to add.
But here you go:

  • in the breadcrumbs it should say Edit a page
  • currently see this on the Add a citation page
  • I agree that the Why section can be shorter. Right now you have repetitive sentences, as well. Actually as a newbie myself, I am not so sure what I would look for on https://www.mediawiki.org/wiki/Help:Contents -- the page you link to via Read more about sources, maybe that text can also be more descriptive, so then I can judge for myself right away if there is optional/mandatory information behind the link.
  • Generally I like the tabs (looks much better than what I am used to seeing), but it takes a second to scan all the options here.
    • my suggestions after "How to" write a short sentence of what the section is about, e.g. "Here are the different tools to add a citation on desktop and mobile"
    • and make two boxes with tabs, one for desktop and one for mobile.
RHo added a comment.Feb 8 2020, 12:30 AM

Hi @Trizek-WMF - apologies for the delayed reply to your questions. Answers as much as possible inline.

==== A. Overall feedback
“Wikipedia Help contents” link colour in orange looks like an alert/error and also not in keeping with the standard style guide. Suggest to keep the existing color as the bolded and slightly larger font-size in the breadcrumb is sufficient.

How can we differentiate an Help pages from a regular help page then?

– The clearest way imho would be naming it something specific and distinct, like "Suggested edit help" or "Newcomer help". Introducing a different colour and/or other difference in font-styling is unlikely to make users perceive "Wikipedia Help contents" from other "Help contents".

  • Placement of the “Search in Help” field and button makes it slightly ambiguous whether the user will only be searching the contents of the specific help content on the page, or whether it is searching across all help pages.

A suggestion is to move its that it is hierarchically on the same level or over the help page title.

Which title? The h1 one that is on every page, or the one I've added in the box at the top? The latter exists because some communities may use subpages like I did on my examples.

– I was suggesting placing hierarchically on the same level or over the h1, if it is meant to search all sub-pages of the Wikipedia help. If however it is meant to search only within this specific help page, then maybe it's a matter of renaming it to something like "Find in page"??

...

  • Consistency in terminology and grammar details such as capitilisation
    • eg1., Inconsistency in naming - the “Add contents to an article” contents page has the breadcrumb “Edit an article”, and it is unclear whether the “Format text” list item refers to Copy editing. Generally we should aim have the same names for help as the item for which the help is being provided.
    • eg2., I would *not* capitalise “Article” and “Citation” in the middle of a sentence.

What's the way to emphasis an important piece of vocabulary people have to know about, and may need to re-use later?

– Bolding text is probably the most i18n-friendly way (since many languages do not have italics or capital letters)
– You may also want to consider linking to a relevant article when it may be beneficial to explain terminology further. Ideally if link previews are in place on these help pages users could hover to get more context about the term without leaving the page.

  • Maybe the contents/overview page does not require a H2 if it is only intended to list the links to different edit types. This is especially not desirable on mobile where the contents list is hidden in the default collapsed section.

How can we have sections to structure the page, then?

– I meant to not have H2s on the contents page only, the different sub-pages as a list seemed OK

...

  • Adding screenshots for each of the tabs would be a fast and easy way to distinguish the different how-tos

Even if we will have to make a screenshot for every language?

– In an ideal world each wiki would be responsible for adding and maintain their specific language screenshots.

  • Suggest removing the first step of each how-to on clicking “edit”, or else at least rewriting to be more generic, since the label may be different depending on availability or previous choices from a user. For example, a user may not have “Edit source” as an option available until after selecting “Edit”

Not sure to get it, can you clarify?

– What I mean is that different wikis and different users may get different "Edit" links labels and behaviour, so including this first step will potentially be confusing. For example, say I am reading the instructions on the Desktop (source edit) tab. The first step says On an Article page, click "Edit source". However, say I happen to try this on enwiki not logged in. There is no "Edit source" link for me to click on, only "Edit", so already this introduces a bit of doubt and confusion.

====B. Mobile-specific
...

  • since tabs are not available to split up for the different editor and platforms for mobile, can these be separated into subsections instead? It’s quite confusing too for the mobile-VE and source sections to be last

We have two solutions there:

  • make the tabs working
  • have a way to have h3 sections title being collapsible on mobile

Agree. Probably having h3 sections being collapsible will be preferable since tabs with long labels will not look great on mobile

RHo added a comment.Mar 18 2020, 5:46 PM

hi @Trizek-WMF - let me know if you would like another round of design review, or else feel free to close. Thanks!

hi @Trizek-WMF - let me know if you would like another round of design review, or else feel free to close. Thanks!

It awaits Marshall's revision of the existing sample pages I've created.

Urbanecm edited subscribers, added: Urbanecm_WMF; removed: Urbanecm.Aug 22 2020, 6:51 PM