766591 - [tracker] Events Manager UX

Status: NEW

(Participation Infrastructure :: Events Manager, defect)

Description

[Bram Pitoyo [:bram]]

This is a bug to track the progress of events manager’s UX design. Screenshots will be posted and discussions will ensue.

Comment 1

[Bram Pitoyo [:bram]]

Attachment: Event view - viewing as individual, not joined

Design note:
* Attendees list is put in another page, reducing the number of items on the page, making the whole thing simpler to skim through and quicker to load.
* The url structure for the attendees list could be something like /event-id/attendees, and for the editing interface, it can be /event-id/edit. Semantically meaningful URL increases user’s trust.
* The behavior for the “Invite Mozillians” box will be detailed later

The question to answer:
Do we want to give every Mozillian the ability to invite others, or do we want to limit this capability to event creators?

Comment 2

[Bram Pitoyo [:bram]]

Attachment: Event view - viewing as individual, joined

Exactly the same as the “not joined” view, except the button is now at a selected state.

Comment 3

[Bram Pitoyo [:bram]]

Attachment: Event view - viewing as organizer

When viewing as an organizer, a button to edit the event will appear on the side of the “join” button. The join button is automatically pressed, and display the text “you’re the organizer” or “you’re the creator”.

The question to answer:
Should the organizer/creator be able to unjoin the event s/he created? It would create a very complicated situation regarding who can edit an event if no one “owns” it.

Comment 4

[Bram Pitoyo [:bram]]

Attachment: Create view - Step 1: add info

The page is logically organized into three sections:
* What: event title, description and topics/groups
** The topics/groups bit will require some explanation. Tags can’t be useful in browser/search if its use isn’t regulated
* Where: venue, country, province/state and city
** The more we can organize this bit, the easier it will be to tie location data into each event
* When: start/end date/time
** The order of fields is start date, start time, end time, end date
** Reason #1: this is the way that we say things. For example, “This meetup will happen on Monday at 4pm to 6pm”
** Reason #2: we can deduce some (not all) end date based on the end time. For example, if you specify a start time of 10am, and an end time of any value below 10am, we know that the event will probably last for more than a day. So we can automatically move the end date forward to guess this. If your start time is 10am, and your end time is 4pm, the end date will be set to the same day. This is not true in all cases, but it’s true in most.

The question to answer:
* 24 vs. 12-hour system. Do we say 16:00 or 4 pm?
* What minute increment is helpful without being too granular and annoying to fill in? I’m thinking that 15-minute increment is good.

Comment 5

[Bram Pitoyo [:bram]]

Attachment: Create view - Step 2: review info

SUMO’s paper prototype research found that user likes to review materials that are going to be posted publicly, so I put a review step.

Design notes:
* User has two places to click the “edit” button:
** Below this page, to the left of “create event”
** On the event page, to the right of “you’re the organizer!”
* The edit interface looks and behaves exactly the same as attachment 634958 [details] (Step 1: add info), except the page title is called “Edit event”
** The difference is, the edit interface will not have a review step

The question to answer:
Can we use the “Invite” field on the bottom of attachment 634952 [details] (event view: organizer) instead of a separate invite step? This will simplify event creation.

Maybe after user clicks on “Create event”, we can go to the event view and go to the “Invite” field anchor, so the user gets a nudge to invite others?

Comment 6

[Bram Pitoyo [:bram]]

Attachment: Event view - invite box behavior

Design note:
* This field appear on the very bottom of the event view (attachment 634952 [details]), not as a separate page

Behavior of invite box:
* When user types a string of text, the system will try matching it to the existing database of Mozillians
* When system identifies name listed in Mozillians, it will produce a list. User can click or tap on any of the name on the list, or use the arrow key followed by “return”, to add the name inside the invite box. The system will give valid names some sort of a visual indicator.
* If user cannot find any match, he will either continue with typing an email address (if real name is part of the email) or erase the string and start typing again
* If the system cannot identify a name, then it will do a check to see if the string is a valid email (ie. cannot contain a space, an ‘@’ symbol, a .com/.org/.edu suffix, etc.)
* When a valid email string is identified and the user hits “return”, the system will add the email into the box. Visual indicator is optional, but I labeled it blue.

What happens after you click on the “Invite” button:
The page will refresh, giving the user an indicator of the invite sent, invite that was already sent, and Mozillians who are already in the attendees list.

The questions to answer:
* Are the mechanisms under invite complicated enough that we need to put it in its own page?
* Do we allow multiple resending of invites, or just once per email, per event?

Comment 7

[Bram Pitoyo [:bram]]

Attachment: Event view - view and manage attendees as organizer

Note that the word “manage”, as well as capability to delete attendees, will only be present if a user is the event’s creator/organizer.

Comment 8

[Bram Pitoyo [:bram]]

Attachment: Event view - view and manage attendees as viewer

If user is a viewer, the edit capability is gone, and the wording on the page changes to just say “view”.

Comment 9

[Bram Pitoyo [:bram]]

Attachment: List view

The default list view with no search keyword entered. Entry is sorted by date.

Comment 10

[Bram Pitoyo [:bram]]

Attachment: List view - search by keyword

Comment 11

[Bram Pitoyo [:bram]]

Attachment: List view - search by location

Both city and venue will make for valid locations. Both are considered metadata. If a user picks one of the autocomplete options, the system will list events with the corresponding metadata rather than treat the string as wildcard characters.

Comment 12

[Bram Pitoyo [:bram]]

Attachment: List view - search by date and time

Date and time may also be considered metadata, but months are only autocompleted when user enters the strings sequentially.

Open question:
Date and time searches will always relate to a place. That is, I cannot think of a user story where he would want to list events that begin at 11 am or 17 April, if he does not know the place. In fact, place is often more important than time.

1) Should we disallow date and time searches until a user picks a city?
2) Should we disallow date and time searches altogether? The thinking is, a listing page of all event in one city will not contain very many entries, and it will be easy for the user to sort out without using further filters like date or time.

Comment 13

[Bram Pitoyo [:bram]]

Attachment: List view - non-registered, unvouched, vouched and organizer

This shows the difference of event listing and editing between users who are not registered, unvouched, vouched, and event organizers who are vouched.

Comment 14

[Bram Pitoyo [:bram]]

Attachment: User flows

This is identical to the previous version that Aakash had made, with the differentiation between anonymous, unvouched and vouched users made clear in the “Sign up for an event” part.

The question to answer:
Do we allow anonymous/non-registered users “join” an event?

Comment 15

[Aakash Desai [:aakashd]]

(In reply to Bram Pitoyo [:bram] from comment #14)

> The question to answer:
> Do we allow anonymous/non-registered users “join” an event?


Yes, but only after they've been verified with BrowserId. There should be a suggestion for users to opt-in and use Mozillians.org too.

Comment 16

[Bram Pitoyo [:bram]]

(In reply to Aakash Desai [:aakashd] from comment #15)
> > Do we allow anonymous/non-registered users “join” an event?
> 
> Yes, but only after they've been verified with BrowserId. There should be a
> suggestion for users to opt-in and use Mozillians.org too.

Then we’ll just set it so that

The transactional nature of the IDs between events manager and mozillians could be very messy to sort out because it has a lot of UX implications for various user states.

It will be a lot less messy if we can prompt user with a “[Register with Mozillians.org] to join an event” message.

Or, when a user clicks on “Register”, he is automatically taken to the first registration step for Mozillians.org, but after he’s done with Mozillians, he will be taken back to Events Manager.

This way, Events Manager can rely on what Mozillians already have, rather than have its own Edit Profile and registration system.

I don’t know if this is harder or easier to implement, though, so it merits a discussion.