Sprints/2019 January Brussels/Pad

From XMPP WIKI
Jump to navigation Jump to search
# UX Sprint

```
              .-"""-.
             '       \
            |,.  ,-.  |
            |()L( ()| |
            |,'  `".| |
            |.___.',| `
           .j `--"' `  `.
          / '        '   \
         / /          `   `.
        / /            `    .
       / /              l   |
      . ,               |   |
      ,"`.             .|   |
   _.'   ``.          | `..-'l
  |       `.`,        |      `.
  |         `.    __.j         )
  |__        |--""___|      ,-'
     `"--...,+""""   `._,.-' 
```

## TODO

- Extend https://wiki.xmpp.org/web/Usability/Glossary

### Daniel’s list
* What to name things?
   * Common Jabber vocabulary for Groups, 'Jabber ID', bookmarks, "muc members / participants"
   * Persons; (preference of roster name, pep name, local sync name (address book).
   * Persons in MUC (order of preference of room nick, roster name, pep name, …)
     * order of people in member list admins first?, alphabetical? (see affiliations)
   * Groups / Chats (preference of description, subject, local part, name, bookmark name, auto generated name)
 * do not get muc name from identity name but from disco form fields because identity name is set to localpart on some servers
 * Do we want to replace a referenced nick with the local version?
 * Adhoc, Impromptu group chat; come up with a cool default settings like members only, non-anon, allow pm?, allow subject change, allow invite. What to expose
Behavioral changes in impromptu mucs (send chat states, display read markers, e2ee by default, prefer 1:1 instead of PM when contacting a participant) and how to recogonize and impromptu chat (isMemberOnly && isNonAnon)
* Afflitations
   * Do we need an owner. Should in a three person chat someone be the 'owner' 
   * Administrators might make sense. But maybe we want to show owner and admin as the same.
   * Maybe it makes sense to make everyone owner and then call owner the admin

* Do we need different profiles?
   * Private, non-anon
   * Public
   * Annoucements. w/o presence broadcast, moderated
   * should those profiles be locked afterwards


* Do we want to keep bookmarks or just use it as a sync mechanism?
  * open/close conversations when bookmark created / autojoin flag removed?
  * do we also leave when bookmark is removed? Does that work? this basically means no join without bookmark. 'remove bookmark' (w/o leave) can not be an action anymores
 

## Naming things?!

* Jabber ID? JID? XMPP address?
	* "Jabber" trademark
  * "JID" widely used but might be a more technical term
  * "something address" is clear to people
  * "XMPP" is usually hard to remember, "Jabber" is more friendly to the ear
  * Jabber is the community, XMPP is the protocol
  * What about calling it "Conversations ID", or "Converse ID", or "Movim ID", all at the same time. Might be confusing for users when they use multiple clients but most don't.
  * Some other protocols use "username" (with a hint for the default domain)
  
Consensus: "XMPP Address"? (until another user-friendly term for "XMPP" can be found/agreed upon)


## Results / Consensus


### XMPP Address / Jabber ID
 - XMPP Address input: Always use one field. Never split into localpart and domain part. If possible do autocomplete on the server part in drop down

  
### Group chats / channels:
 - Private group chat (or groupchat)
   - members only
   - Jid visibility: all
   - MAM: yes
   - not listed (non public)
   - peristence
   - users can invite. default off. (does this need to be configurable?)
   - subject editability: owner only (probably make it configurable?)
   - disallow pm
 - Public channel
   - public / everyone can join
   - MAM: yes
   - listed: yes
   - persistent
   - JID: visibility anonymous
   - subject editability: admins only (probably make it configurable)
 - Possibility to omit the words 'private' and 'public' later down the UI flow and just talk about 'groupchat' and 'channel' (for example when constrained on screen estate)
 
  - recognize on members only AND visible JIDs AND not listed, everything else is a public channel. but a client should maybe warn before entering a public channel that makes your jid public. Those three 'detection properties' are immutable for private group chats
  
  - private group chats use randomized, auto generated JID (always on the server’s own muc host)
  - public channels always ask for bare jid on create (auto suggest of know muc hosts)
    - UI suggestion. ask for name first. Then normalize to local part of JID. But let user change the JID if they want to


Group chats and channels should be clearly distinguished visually.

|                  | Groupchat | Channel | Immutable for groupchats |
|:-----------------|:---------:|:-------:|:------------------------:|
| Members-only     | Yes       | No      | X                        |
| Reveal JIDs      | Yes       | No      | X                        |
| Publicly listed  | No        | Yes     | X                        |
| Persistent       | Yes       | Yes     |                          |
| MAM enabled      | Yes       | Yes     |                          |
| Subject editable | No        | No      |                          |
| PMs              | No        | Yes     | X                        |


### Terminology

People in the group chat / channel: Participants   	


| Affiliations | In groupchats | In channels |
|:-------------|:-------------:|:-----------:|
| none         | N/A **        | Guest       |
| member       | -             | -           |
| admin        | *Admin* (\*)  | Admin       |
| owner        | Owner         | Owner       |

Roles should not be used anymore.

(\*) A group chat will display an existing admin as such but it will not encourage/allow someone to be promoted to admin. UI options in group chats only allow a member to become an owner but not admin. So admins are discouraged by the UI but will be displayed as such if the end up being one for some reason.

clients MAY create an 'advanced view' that displays roles as well.

** Everybody is a member in groupchats


### Suggested order of what to call an individual
message: roster name, (address book), user nickname, localpart
groupchat message: roster name, (address book), user nickname, resource (mentions refer to resource. if you do proper references you can live replace it with the 'nice' name)
channel message: resource
roster: roster name, user nickname, bare JID
profile: roster name, user nickname, bare JID

Avatar display should follow the same order

### Bookmarks
Unbookmarking a bookmark doesn’t do magic leave on any devices
when receiving set/unset autojoin will join/leave on all devices
leave/join will unset/set the autojoin flag (exposed as a choice to the user)
clients should offer global sync-opt-out (Don’t adhere to autojoin)
clients should store the list of groupchats open, unrelated to the autojoined bookmarks

Summary: clients store the list of open chats (groupchats or not) and restore it on next start; on receiving a bookmark with a new autojoin from PEP, add the room to that list and open it; on receiving one without an autojoin, remove it from that list and close it; on joining a room add an autojoin bookmark; on leaving a room ask whether to leave it globally (then remove the autojoin from the bookmark), or to leave it locally (then remove the bookmark).

## Places to update/remove

https://wiki.xmpp.org/web/Usability/Glossary
https://wiki.xmpp.org/web/Easy_Group_Chats