Feeback from usability testing

judgej

A client is running some usability testing on Vanilla today, and I'll post any feedback I have here in case it is any use.

What I will post here comes from very non-technical readers who have not spent day-after-day staring at Vanilla like we do, and so should highlight a lot of usability issues in areas that we have simply got used to, but are not very obvious to other end users coming to a Vanilla forum for the first time.

judgej

First one: personal messages (they don't like the term "discussions" "conversations" at all):

When a new message comes in, it is not clear what they need to click on to mark it as read. They were clicking on the name in the message of the message list, and just kept ending up at the profile page of the sender.

They were able to read the message in the message list, but it never got marked as read, and so believed they had to reply to the message in order to flag it as read. They eventually worked out that you need to click on some empty space in the message area to read it (i.e. re-read what you have already read) in a new page.

I think the messages overview need "mark as read" links. At a minimum, rollover titles are needed to tell users what clicking will do (may be more an issue with the theme).

judgej

The forum being tested is a private forum, so only logged-in users can see it, and they must be authenticated through an external CMS using ProxyConnect.

Now, that does not by itself remove the ability for users to register on the forum. To do that I have set registration to "invite only" and then only allowed administrators to create invites, hoping that they will remember not to use this feature. I assume that is the way to handle it.

Now, the issue is that "my invites" and several other related links still appear in various admin menus. What would have been ideal would be an option to switch off the registration features completely, i.e. not to allow anyone to register on the Vanilla site through any of the Vanilla registration forms. ProxyConnect would bypass this anyway, so new users will always be created when they are authenticated externally.

tester13

Being UX designer your observations from practical testing look very interesting.

Term 'discussions' is very uncommon, and yes, most people are uncomfortable with it.
But changing this term is very hard in Vanilla.

Under personal messages you mean thread view? Or Inbox?
Inbox and, especially, notifications are broken in current version, so sometimes you have wrong indications.
But Inbox do not use term 'discussions'.

I also hope that as in proper usability testing all users have some scenery to follow and all actiona are precisely documented.

judgej

I think changing the text labels and terms should be pretty easy, as all the strings are translatable and so can be substituted by creating the relevant translation files. The URL is not so easy to change, but that's not really in the scope of this testing.

Under personal messages I mean the first page you come to when you click "inbox", whatever that page is called (the fact I don't know what it is called is a red flag, I guess).

It appears to list the first message, i.e. the "head" message for each discussion. Just going to this page ought to be enough to mark these messages, i.e. discussions, as "read" IMO, so long as there are not unread replies to be read.

Yes, the users are all working from a guide and set of instructions written by the client. There is more to this testing than Vanilla, since it covers a CMS too, but it is all being documented. I'm logging and prioritising the issues as they come in.

I'm using Vanilla 2.0.13 with a customised default theme.

tester13

Translating 'discussions' is easy. This was first thing that I did.
But it still appears in URLs, making confusion among users.

As for Inbox - I think that here we have some extra functionality that is really not equired. I mean separate conversations application. Why not making new discussion (thread) in special category called (##Conversations, or anything like that) and with restricted access. We already have all code for this, WYSIWYG plugins, etc.

judgej

Yeah, I guess there is some duplication of code and functionality there. In my case - however it is implemented - did need the conversations feature as it is something the client has specifically asked for.

tester13

@judgej
Also try to test email notifications.
As for me, using latest 2.0.17.8 they are still in text format with links also represented as text, so you copy link and past it in browser. Weird.

judgej

In the profile page of a user:

"Emma Smith changed his profile picture."

"His"? Now how do I change the gender of a user that is obviously not set up right? Oh, I can't - there appears no way to change this through the admin screens.

I am wondering whether this is a feature of ProxyConnect, since it makes no sense for users to be able to change their own account in Vanilla, when the details will just get overwritten from the CMS details next time they log in.

Now the issue here is that the CMS does not record the gender of these users, and so everyone defaults to "male".

IMO Vanilla needs a third option in gender: "Not specified" or "Mind your own business".

tester13

I believe that idea of
"Emma Smith changed his profile picture."
came from FaceBook. With some other not so good ideas :-)

judgej

2.0.13 sends *too many* emails, while 2.0.18 reportedly sends *too few*. Can't win really.

I have pulled some of the fixes from 2.0.18 into my 2.0.13, so reporting on email issues would probably not be useful. The fixes I've pulled are those that queue up the emails when making a post so that each user will only receive one.

I'm not getting email notifications for "mentions" on posting comments though, and that appears to be a bug (the code that does the mentions check is simply not in the execution path for comment posting).

I wish I could upgrade to 2.0.18 for a clean slate, but those category changes were just too wide-ranging and too unstable at this point in my project to roll out.

luc

I wish I could get 2.0.18

judgej

Or 2.0.17.8 - I have not had my second coffee yet.

judgej

It is the fact that gender is *mandatory* that makes it very difficult to work around.

luc

So you want:
"Emma change mind your own business profile picture"?

And indeed, the activity stuff is mainly inspired by facebook stuff IIRC.
To work around those kind of issues, maybe it can be changed to something not so gender specific for the ones that don't have any gender specified.
"Emma Smith: profile picture changed."

Now, it just needs to be implemented. The hardest part (because time needs to be found for that, not because it might be difficult).

judgej

Yeah, that would be how I would see it working. Whether it gets changed or not depends on how the project feels, I guess. There will always be time to do something if enough talented people want it done, or a client is specifying that it *must* be done and is willing to sponsor the changes. Otherwise, just on my whim? Nah ;-)

tester13

Current version of unstable branch is already 2.0.18 btw :-)

And if you think that notifications are outside of execution path you need to report this bug.

ottorobba

As far as nomenclature goes, what you can do is create a locale.php file inside the conf folder. That is what I did, to get closer to a more standard forum approach. I linked the locale.php file I'm using below. I also renamed the menus. You can see the end result here: http://www.mongbat.com/forums

http://www.mediafire.com/?9r2szenols3hypt

Linc

First one: personal messages (they don't like the term "discussions" at all)

You meant "conversations" right? I'd generally agree with the critique of how that app is laid out. The interface is simple enough, but the "click-to-read" is unintuitive because there's no cue.

tester13

@Lincoln

Any chance to integrate conversations to Vanilla itself?
As all we need is only access rights change (so only listed people will have access to perticular discussion).
Few forums that I know use similar approach with just modifications for normal threads handling.
But I like visual separation of conversations, as mixing them with threads(discussions) always have negative impact on usability.

Linc

@judgej To close registration, drop this in config.php:

$Configuration['Garden']['Registration']['Method'] = 'Closed';