Page MenuHomePhabricator

OOUI in HTMLForm on Special:Pages – evaluate collapsible main forms
Open, HighPublic

Description

In contrast to finding different solutions for every single, transformed Special:Page to OOUI, resolving one of the biggest point of critique, the vertical space needed, we should evaluate a central solution.
A collapsible form similar to RevisionSlider comes to mind.

Event Timeline

Volker_E created this task.Apr 10 2018, 3:54 AM
Restricted Application added a project: UI-Standardization. · View Herald TranscriptApr 10 2018, 3:54 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Volker_E added a comment.EditedApr 10 2018, 4:12 AM

From a discussion to clarify my take with @Prtksxna on the topic:

@Prtksxna: Might lead to more interactions than needed though

@Volker_E that's exactly the trade off
one click more
therefore it should be possible to add that functionality to OOUI Special:Pages as option, but not by default
also a cookie or some persistent setting could be of interest
maybe a volunteer never wants to see the form

@Prtksxna nods
@Prtksxna: Hidden forms is one alternative too, yes. Not one that I particularly like though (exactly because its hidden ☺ ) But an alternative to consider, certainly.

@Volker_E: let's be sure we're on the same page, with hidden I mean collapsed to, let's say the legend

not completely hidden

A collapsible form similar to RevisionSlider comes to mind.

Are you referring to the collapsible interface?

ClosedOpen

Sorry I am not a big RevSlider user so don't know all the elements so well.

@Prtksxna Yes, a collapsible element similar to this should be considered (with small adaptions, like title/legend being left aligned).

Volker_E added a comment.EditedMay 6 2018, 3:08 AM

We have had a discussion about field labels on top versus horizontal, among other places, at T117724 on related patch https://gerrit.wikimedia.org/r/#/c/366603/

@Prtksxna made a test case there with horizontal layout and max-width of the labels:
https://phabricator.wikimedia.org/F9952734
which shows the disadvantages of orientating and violating gestalt principle of proximity pretty clearly.

I'm convinced that above approach won't lead us anywhere, it will introduce just design debt and only maybe tame the repeated feedback of change on OOUI taking up too much space. For this reason above treatment on Special:Pages which include an instant result list below seem to better address vertical space concerns.

Horizontal scrolling in general seems less a usability issue than changing orientation from top-to-bottom and left-to-right.

Volker_E added a comment.EditedMay 6 2018, 3:42 AM

An ability to give an HTMLForm an optional 'collapsable' parameter with two options:

  • 'collapsed' or
  • 'expanded'.

'collapsed' results in:
It takes the first form legend and adds some CSS class(es) to it which result in a clickable appearance and add a down-facing caret at the end of line.
The current legend labelElement is turned into a clickable area with a treatment similar to a frameless ButtonElement.
.oo-ui-fieldsetLayout-group(s, forms to evaluate on this) will be hidden.
Including ARIA attributes (aria-controls & aria-expanded) at best similar to http://www.oaa-accessibility.org/example/20/

collapsed view:

We have different types of Special pages and not all need the same treatment. Pages which primarily show just one form (Upload, BookSources) are alright with form taking up vertical space. Then come the list or report special pages which might (AllPages, ActiveUsers) or might not (BrokenRedirects) have filtering capabilities. The ones with the filtering could surely use something like a collapsible form as you're suggesting.

It might be even better if in the collapsed state it could mention a little of what kind of filtering is being currently applied.

ExpandedCollapsed

While a collapsed form is surely a good first step, I worry if we're misjudging what is required here. Most eye tracking and proximity studies on forms have been on pages where the forms have been the main focus of the page, for example - a checkout process. Ours is more a case of filtering, where the resulting data is the main focus for the user. I don't know of any recent studies about this usecase, if someone knows any good ones I'd like to read.

The 'filter' UI patten often has multiple form elements stacked from left to right, something that might not be straightforward to do in OOUI and will require us to give attention to each page before converting it. It might be something that we want to look at.


Again, I think a collapsed form which maintains state is a good first step.

Volker_E triaged this task as High priority.Jun 1 2018, 2:06 PM
Volker_E moved this task from Backlog to Next-up on the OOUI board.Jun 4 2018, 7:46 PM

@alexhollender I see convergent potential here for our Quarterly goal and your ideas for selected mobile views…

Thanks for looping me in. My interest is special pages on mobile. As discussed here, many special pages are filterable/searchable lists. The thinking I've done so far has similarly focused around figuring out a way to collapse the filter/search fields, allowing the focus to start with the contents of the list. The designs that @Pginer-WMF worked on here T158923#3060814 have been helpful to me.

Change 490493 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] Collapse the form at the top of the history page

https://gerrit.wikimedia.org/r/490493

https://gerrit.wikimedia.org/r/490493 results in:



Collapsing this form would be useful for mobile.

Change 490493 abandoned by Jdlrobson:
Collapse the form at the top of the history page

Reason:
Preserved on https://phabricator.wikimedia.org/T216420

https://gerrit.wikimedia.org/r/490493

Jdlrobson moved this task from Inbox to Focus on the User-Jdlrobson board.

Change 490493 restored by Jdlrobson:
Collapse the form at the top of the history page

https://gerrit.wikimedia.org/r/490493

Jdlrobson moved this task from Focus to Blocked on the User-Jdlrobson board.Mar 28 2019, 12:26 AM
Volker_E moved this task from Next-up to Doing on the OOUI board.Apr 3 2019, 3:08 AM

From a conversation with @Jdforrester-WMF. We need to make sure that discoverability of the expand/collapse action is given.
He was adding that it, depending on the form, might be preferable to have certain elements visible by default and collapse just the more specialized.

Change 502620 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] History form can be collapsed

https://gerrit.wikimedia.org/r/502620

Volker this is done right?

Volker_E added a comment.EditedMay 9 2019, 4:02 PM

@Jdlrobson Just filed a follow-up subtask. Also the patch for Special:Contributions is still under review.

Volker_E removed a project: OOUI.May 9 2019, 4:05 PM

2c from a user perspective:

The History page had its filter form collapsed previously in a similar way. I think that change made things better for mobile, and narrow screens in general, but I fear that for desktop it made the form effectively non-existent. Hard to discover, especially considering a user might not know such functionality is available at all. (Failing to find vs failing to search). Consider the history action, and a user story to see the edits made in February 2018.

My expectation is that a majority of (new) users would start paging until their patience runs out. I'm not sure they'd identify with "Filter revisions" or a far-away generic "expand" button ("show" on enwiki). I didn't raise this as an issue at the time, because I think paging is an acceptable workaround, and the larger use case is relatively rare. Should probably be improved mid-to-long term to ensure curators can ensure the quality and relevancy of our content, but not urgent right now.

For Special:Contributions, though, this form is essential, and has no fallback workflow. I like the mockups from @alexhollender that provide relevant and action-oriented buttons and labels. E.g. "Search for a different user name", "Apply namespace, date, and metadata filters" etc. I think it's important to separate these two fro the user perspective as I'm not sure a typical user would consider everything in the form as a "search query" or "filter settings". The username field represents a higher-level concept, separate from filtering down what results to include.

Would that be worth including from the start when collapsing the contributions's form?