docs: add first draft of usability test script

[olizilla]

I'm not sure this is a great usability test yet, but it's been productive to think about what the app should make easy vs possible, and just thinking through how you might test for that has uncovered a few significant UX issues like #815

The doc

WIP on #746

License: MIT
Signed-off-by: Oli Evans [email protected]

[olizilla]

@meiqimichelle it's a usabiltity test script! Cribbed from https://github.com/18F/myusa-ux/edit/master/research/usability/sprint22_research-plan.md

I'm keen to get your thoughts / corrections on this. Perhaps we should try it out?

[olizilla]

The rendered preview is here https://github.com/ipfs-shipyard/ipfs-webui/blob/d3efcd3c272cec299d820faba70be9e489ffb686/docs/usability/ipfs-webui-useabilty-test.md

[lidel]

"Files"? Do we mean MFS or all objects in IPFS repo?
It would be much easier if we had better language to talk about those things.
MFS is a really bad acronym and even worse full name (civilians just shut down).

Digression:
Any thoughts on UX change to use "IPFS Drive" instead of "MFS" (ipfs/specs#174 (comment)) across the stack, docs etc? It is a so much better name.

[meiqimichelle]

We could at least test that language in the app, if it appears there. Does it appear in the app? It would be great to see first if that makes more sense to people before changing everything across all our docs. (I'm sure it will be clearer than MFS, but I wonder if through testing we'd come up with something even better!)

Would 'IPFS Drive' replace.....repository? No, that's not quite it. Hmm. Do you think we're at a place where we can talk at Team Week about how lots of our concepts/terms fit together? ie, to a Normal Human, what ipfs add means, what ipfs get means, how that relates to, say, an IPFS Drive.....??? It would be great to start to align on an illustration or metaphor for all this that the team could use since often when you change one word, you find out later that it doesn't make sense once other terms are changed. Might be asking too much at this stage of development tho :)

[olizilla]

@lidel I used files here as I don't think that user will typically know there is a difference between "things in the MFS/Drive" and "things in the repo". I think the name "Drive" is better than "MFS", and I think better still would be for all files in your repo to be in you MFS and we just refer to them as "your files".

@meiqimichelle Strong yes from me about making time in team week to figure this out! We have to find a story and a set of terms that work. Not having it slowing us down.

The biggest ones that are causing me trouble today are

• Files in repo vs Files in MFS / Drive. Right now, the list of files in your MFS are a subset of all the files in your repo. We could lobby for that to not be the case in the future, but in the mean time we have to deal with it.

• Upgrade "pinning" to co-hosting. We need to start pushing for apis that let us build apps that let people co-host content and set a duration (1week, 1month, until i need space, forever, kind of thing.) The concept of pinning doesn't seem to work for everyone, and it's an all or nothing thing; If I pin it, it's forever until I unpin it. If I don't pin it, I share it anyway until my repo is full, at which point it may get deleted.

[lidel]

It would be interesting to ask people (1) to describe how long data uploaded via webui or share.ipfs.io will be available [on public gateway], and (2) why they think what they think.

[meiqimichelle]

These are really good areas of understanding that we need to dive into! Yays.

I really like your suggested question (1) @lidel ! We should find a different way of getting at (2) tho -- humans aren't generally very good at accurately describing why they do something or know something because they'll naturally try to give you an answer that makes them look smart, or gives you the answer they think you want, because they want to seem likable. Human nature n such. So we shall have to be sneaky.

In any case tho....hmmmmmm........as a first step, I like the idea of adding a version of @lidel 's question to the test script. After they send the link to the interviewer, could ask something like:

• How long do you think that picture will still be available/at that address/at that link?
• If they answer so that it seems like they understand about the close-the-computer-its-unavailable thing, could ask How would you make sure that picture is always available?
• Can anyone find that photo, or just me?

You can likely improve on those questions, but that's a start -- what do you think?

For bigger questions of understanding in general, it might be good to decide what the Mission of the App is (you might know this already, and I just don't know the latest!). Is it meant to be someone's first toe-dip into IPFS-land? Or...? Having this target in mind will help understand what sort of research we need to understand potential misconceptions, or even at the start, what the app should be helping folks understand. ie, I could see a different sort of module or illustration that we should develop, or metric, if one of the key communication points we want to convey is that IPFS is not a backup service (something around time, perhaps, and how that interacts with IPFS). And if we want to convey that 'uploads' are technically available to anyone on the network, I could see some different ways of illustrating that, too.

But maybe those shouldn't be main 'talking points' for the app in the first place. But! It could be really cool to make the app the place people go to understand how IPFS works, soooooo.....hmmmmm... 🤔

[olizilla]

I'm leaning towards Web UI is for new users and should help people learn about the concepts.

For the fancy technical people we can improve the docs around using the command line and the api, and encourage the community to build out the dashboards they need. More pressing is that you can't currently use webui to do sys-admin work on a remote machine, so it's of limited use for someone running ipfs as a service on a remote machine.

It's prime use-case right now is being a UI for people who are excited about IPFS and want to run it on their machine, but aren't comfortable with the command line. The UI we build for it will appear in the Desktop app which is even more clearly aimed at non-command line folks, and will bring the benefits of auto-updating and starting your ipfs node automagically when you start your computer.

[meiqimichelle]

This is great @olizilla and I'm excited this is happening! I am sure we will learn alot a lot.

Ok, let's see -- how to make it even better 💃

Does your test script (which I quite like!) cover all the things you want to make easy (the list at the top)? It seems like you've focused on a sub-set of the problem space in lines 3 - 22, which isn't a bad thing, but! I think you've got two or three documents all rolled together into this one that each deserve fuller exploration.

You might consider:

• Pulling out the kinda intro section from lines 3 to 22, and the Questions/musings section at the bottom, into a background doc, and/or use a version of that as the README to the usability folder. It can become something the sets up your problem space for user research and usability testing priorities in general.
• Then, you're free to really focus on the specific features you're testing in this round in this doc. You could scope the intro into the parts of lines 3 to 22 that you think the questions you're asking will inform. This doc becomes a very practical guide to this specific test that you can come back to months from now when you need to remember wth you were trying to do in these specific weeks of testing. Because, memory.

I think the musings you brought up are important, and we should explore those more, and in the meantime you can separate and 🚢 the first, scoped usability test. IMHO I would scope the doc, and then do what you said -- try it out, and see how it goes!

[olizilla]

Thank you @meiqimichelle @lidel, that's super helpful. I've split out the background section to a README and tweaked the questions. I'm gonna merge this PR now, but please do take another look when you have a moment.

Let's do some tests! Who should we ask? It'd be interesting if all three of us did at least one interview so we can compare notes.

[lidel]

What if we change this to (or add it as a separate item):

• Add two files/pictures and share then with a friend

This could produce more data, for example: Are people sending one by one and sending two links, or do they notice that multiple files could be selected and shared together? Are our GUIs communicating the fact multiple files can be bundled and shared together?

We could ask follow-up questions about content-addressing and the meaning of root CID (wrapping directory) etc. (I suspect having more than one file make it easier to reason about wrapping directory and related concepts)