Page MenuHomePhabricator

Usability review to become an integral part of MW/extension development
Open, Needs TriagePublic

Description

I feel a void in our development work (development in the sense of coding new features in MediaWiki and its extensions) with regard to usability evaluation and best practices.

We don't have a #usability project on Phab but we do have Design and Design-Research, though I have not seen these used when interface changes occur. To the best of my knowledge we don't have a rigorous usability evaluation process either. The Wikimedia Usability Initiative seems to be something of the the past ( edits on their wiki practically stopped in 2015 ).

The purpose of this task is not to question whether we have the (human) resources; it is to signify that we need the processes to be set up and followed. For instance, we should regularly review all new visual interfaces that are being added to MW or its extensions, to ensure they comply with best practices of user interface design and usability.

Not sure what Tag to assign to this Task. Do we have a tag about "running shop"?

Event Timeline

If current workflows welcome improvements I'd recommend to discuss your impressions and ideas with the Design and/or Design Research team: See https://www.mediawiki.org/wiki/Wikimedia_Research/Design_Research for mailing list information (as I do not consider this task in itself 'actionable' currently).

I do not think some team should "regularly review all new visual interfaces that are being added to MW or its extensions" (not feasible given the number of available humans, if at all that should be on request).
With my bugwrangler hat on, from my personal experience, I've seen people throwing a #usability tag at any and every task in other task tracking systems ("it crashes so it is not usable!") which makes me very reluctant to introduce that.

@Huji: Does my last comment make sense? Discussing such a process and whether to implement it could probably happen in a task (though I personally think it's too broad) but if you want the attention of stakeholders who'd be involved I'd highly recommend actively reaching out to their venues.

Yes. I just emailed the design mailing list.

Andre is right in stressing that people have wildly divergent views of usability. For instance, for me anything that requires JavaScript is less usable than a pure HTML solution, yet some devs keep adding heavy JavaScript frills on top of MediaWiki special pages in the name of usability. So, it's important to pick objective criteria.

Conducting usability tests with small groups of 10-15 persons for each relevant audience is a reasonably effective system, but I don't think we have resources for such a commitment. Cfr. https://www.mediawiki.org/wiki/Talk:Wikimedia_Research/Usability_testing

This board for Contributors ux research. As mentioned, can't guarantee resources but it'll get on our radar.

There's also the Accessibility tag (which sometimes gets mis-used for usability issues).
A while ago, I made a list of all the related pages at https://www.mediawiki.org/wiki/Accessibility_and_usability_cleanup with the hopes that it will eventually lead to fewer pages overall (mergism), and better details within each page (updates and improvements). For now, it serves as an (incomplete) index. Cleaning it up is an epic task (if done right).

Who is the we? Please be more explicit about who should do it and for which code. We don't mandate anything for a volunteer developed extension not deployed to Wikimedia sites, except open license of course.

Aklapper changed the task status from Open to Stalled.Mar 20 2018, 9:08 AM

@Huji: Could you reply to the last comment please? Thanks!

@Nikerabbit good question. My focus is MediaWiki core and it's most commonly used extensions (such as AbuseFilter, CheckUser, CodeEditor, etc.) and most commonly used skins (such as Vector and Monobook), but I am happy to even start more restrictive and only thing about MediaWiki core. And "we" refers to the community of developers that work on these.

The point is not to mandate anything, but to agree that it is a value and actually spend time on it without the need for a mandate.

Imagine you are in charge of a city (like the mayor's office). You can focus on just making the city work better (improve public transport, etc.) but not give a whole lot of care to how it looks like, is it easy to navigate, are the public places aesthetically consistent, etc. That is kind of our status quo. You can say "well I don't see a reason to work on these unless there is a mandate by the state/province/county legislature"; that works, but is less than optimal. Or you can be like "I think how things look is as important as how they work and going forward for every major construction I will make sure to do my best to engage urban designers, etc." and that is what I am asking/wishing for here.

Best practices for extensions could use a usability section, but someone would have to figure out what exact advice to give.

As for review, I feel like you are talking about some kind of guerilla usability testing. That's not (just) process, that's a whole lot of human effort. It would certainly be great; I'm not sure if it is feasible.

@Tgr, correct, though perhaps we can start with an on-demand testing and start really small and grow from there only if we see that it is being effective and supported.

There are definitely ways to integrate best practices for good usability into how software, and extensions are built. I know little about coding, but a lot about how to best design software for humans to more easily interact with and use. I could advise, and perhaps collaborate (time permitting) with others if it would help.

Here is a description of how to do usability testing, for example. @dchen and @Capt_Swing and I created it to share.

Usability testing takes time and effort, though UX researchers are always striving for ways to make it less expensive, and a quicker and easier process. As a start to thinking about best practices without imposing a lot of process, here are some heuristics to look over and consider.

These These are good basics. Even though they are old, they still apply. There are more updated heuristics, and heuristics specifically for mobile development. Can share more if it is useful.