Improving the UX of Macrel's Webserver
As we try to move the Macrel preprint through the publishing process, one reviewer critique was likely caused by the reviewer using our webserver in the incorrect way. We support using either DNA contigs or peptides input, but it is technically possible to use it in a wrong way by feeding it peptides and telling it they're DNA (or the other way around).
The easy response would have been "this was user error. Please do not make mistakes." Instead, we looked at the user interface and asked if this was instead a user interface bug. This is what it used to look like:
Advantages:
It has a big text box where you input: this is pretty obvious what to do
We accept a file upload too
The Data Type field has a red star indicating it's mandatory. This is a pretty typical convention. Hopefully, many users will recognize it
It is still quite easy, however to make mistakes:
See how the user selected "Contigs (nucleotide)", but the sequences are clearly amino-acids. The phrasing is not so clear. Having two ways to execute the service (a textbox and an upload box) was also potentially confusing: if you ask me now what happens if you type in something and upload a file, the answer is that I don't know.
New Version
In the new version (currently online), we rejigged the process:
The user first has to explicitly select the mode and only then can they progress and see the textbox:
Now, the guidance is also explicit "Input DNA FASTA". More importantly, if they make a mistake, we added some checks:
Advantages:
More explicit choice for the user, so less room for careless mistakes. Also, the instruction text adapts to the previous choice as does the filler text.
Error checking on the fly
Simpler: only a big text box, no uploading of a FASTA file.
The last one can sound like "bad usability": the tendency in some usability circles to privilege first-time and casual users over power-users. Also, having to click on one button to get the textbox may similarly be better for first-time users, while ultimately annoying for power-users (although this is all client-side, so it's very fast).
However, I argue that, in this case, power-users are not our main concern: Power users should be using the command-line tool and that will enable them to overcome any limitations of the website. We also put in work into the usability of the command-line tool (which is equally important: just because it's a command line it doesn't mean you do not need to care about its usability).
PS on implementation: I wrote the code for the frontend in elm, which was incredibly pleasant to work with elm even though it was literally the first time I was using the language. It is just nice to use a real language instead of some hacky XSLT-lookalike of the kind that seems popular in the JS world. The result is very smooth, completely running client-side (except for a single API call to a service that wraps running macrel on the command line).