Open Nyco opened 5 years ago
Can you please fix the orientation of the images? it's not easy to see what's going on in your notes...
@jcbrand
Can you please fix the orientation of the images? it's not easy to see what's going on in your notes...
Absolutely not, I think about your health: that was completely intentional, in order to stretch your neck ;-) Nah, just joking, ok, I'm on it.
Here we go, all images rotated, sorry for the mess and the delay.
Thanks
Here is a possible UI:
Create Channel:
Note: members is a field working in "find as you type" mode, type "a", it suggest "albert" and "alice but not "bob", etc.
Create Channel, advanced:
Note: each radio need text explanations for the normal/regular user (non-technical), maybe the wording needs review (as we don't have to map perfectly the protocol with the UI/UX)
Join Channel:
Note: we propose a list of local MUC, the search field filters, for example here we have "Help", "Jobs", and "Tools", if I type "o" then only "Jobs" and "Tools" and shown, and "Help" is filtered out.
What do you think of this?
You're missing a nickname input for all these mockups :) I like the idea of inviting members and setting the avatar immediately upon room creation. I also like having advanced options, but collapsed by default. Some of the wording definitely needs improvement, but no big deal.
What does location
local
/remote
mean?
You're missing a nickname input for all these mockups :)
Ooooh, I'm like you, I miss those nicknames, as my habit is rock steady, I resist change. ;-)
Actually, while doing these observations and interviews first and then user tests with hand-drawn UX, people reacted to nicknames, saying there is no need for a nickname, as adding a nickname is confusing and disturbing, feeling some more disorder and cognitive overload, one more field to type in. Clearly, they just plainly want the feature removed, so the overall user experience is way simpler.
To reinforce this, a simple market exploration shows nicknames per MUCs are used in no leading IM (Interpersonal: WhatsApp, Telegram, Facebook Messenger / Team Chat: Slack). They all use per-account nicknames (, or "display names", meaning a unique nickname is used in all groupchats). Doing differently is unexpected.
As we have tested those screen, and users have validated them, I'd say let's KISS (Keep It Simple, Stupid). Per-account nicks or "display names" (which means same nick for all MUCs).
That said, we can definitely think of a way to satisfy the "power XMPP users" category, which represents a few hundred users (maybe thousands) in the world, that would allow them to user per-MUC nicknames like the protocol allows. For example, this can take the form of an advanced setting in the MUC, hidden by default, a user action being necessary to uncover that option.
Concretely, we have the JID, so we can default nicknames for all MUCs to the left part before the "@" sign, and we can offer a field in the user's profile to setup a different nickname.
Example:
I like the idea of inviting members and setting the avatar immediately upon room creation.
People have clearly preferred this.
I also like having advanced options, but collapsed by default.
That's less clear, but it is a good practice.
Some of the wording definitely needs improvement, but no big deal.
Absolutely, we'll research and test this as well.
Yes, the result of discussing with actual real users, this process is of a great value: we are not blind anymore, we clearly see and understand people's uses.
What does
location
local
/remote
mean?
Oh, sorry, I should have explained:
I'm ok with defaulting to using the per-account nick (Converse already does that) and then we hide the per-MUC nickname field under the advanced settings.
Concerning local and remote. This is very confusing and doesn't make logical sense either. There's nothing inherently local about the MUC domain of the XMPP server that hosts your account. It can be on the other side of the world.
Instead of having local and remote radio buttons (which also doesn't make sense, because power users won't type the full JID, then open the advanced settings just to click an additional radio button), we can rather just have an input field default host which has by default the MUC of the user's XMPP host. Users who aren't scared of JIDs can then also still type the entire JID in the input and be taken to the right MUC.
OK, makes sense.
Followup of: Major pain points of Converse after a small user test series #1580
The major pain point was: "create and join a channel".
Reminder (copy-paste of the above mentioned ticket):
We drew new screens with a pencil on a white paper:
We took influences from:
Create:
A![Converse user test join-create channel A](https://user-images.githubusercontent.com/25348/58537249-d0ffbb00-81f2-11e9-8f9a-3a0ebd5692f3.jpg)
B![Converse user test join-create channel B](https://user-images.githubusercontent.com/25348/58537286-dfe66d80-81f2-11e9-82d9-f3110cee974c.jpg)
C![Converse user test join-create channel C2](https://user-images.githubusercontent.com/25348/58537318-f2f93d80-81f2-11e9-84be-2d4a4b0e4b2e.jpg)
D
The red annotations were made after the user test.
Join:
E![Converse user test join-create channel E](https://user-images.githubusercontent.com/25348/58537429-2a67ea00-81f3-11e9-9b18-b538ab282602.jpg)
F![Converse user test join-create channel F](https://user-images.githubusercontent.com/25348/58537472-3bb0f680-81f3-11e9-8af6-1041b38451f1.jpg)
G![Converse user test join-create channel G2](https://user-images.githubusercontent.com/25348/58537488-466b8b80-81f3-11e9-978b-26bfe98c28ff.jpg)
We tested those with 6 users (almost the same as the previous user test).
Users have chosen one "join channel" screen and one "join channel" screen:
We took qualitative feedback, that we classified.
Based on that choice and the feedback, we very rapidly drafted and handwritten set of screens.
Create Channel:
Create Channel (advanced options):
Join Channel:
We will iterate on that and propose an UI and specifications.