Improve usability / look of contacts list

[CaneAtGit]

I would love to see some improvements in the contacts lists, especially when starting a new conversation with another of my phonebook contacts.

1. Make the small green bar on the left way more apparent. It should be used at least like a traffic light: Show me, if the contact uses TextSecure or not, if he is registered to Push-Service and if I manually verified his key.
2. Add the usual pictures of my contacts to this list.
3. Merge several numbers of the same contact to one entry, even if he registered separately with each number
4. Give some advanced filtering methods like "show only contacts in stage X (see listpoint 1)
5. Group contacts by firstname/lastname and even by filter (listpoint 4)

Some people told me especially the determination right out of the contacts (bevor the first message was send!) whether TextSecure sends SMS or PUSH is absolutely crucial.

I would love to see those improvements! Keep the great work up :).

[mcginty]

Very much agree, redoing the contact selection is on the list of UX needs. To be honest, the current one was thrown together at the last minute with the sole intention of making an actually decent one in an upcoming release.

Thanks for opening the issue! Will update here with progress. I'm also looking forward to making a smooth contact selection experience :).

[rmoore]

As to point 1, I would like to second differentiating between people whose keys have been manually verified, and those who are simply based on TOFU.

[merkste]

Actually, Threema does this pretty intuitive.

[generalmanager]

Hell yes - especially the first issue is really important. I never noticed the green bar until I read about it in some blog post. This should either work like the suggested traffic light or we could just add a checkmark in the middle of the green. Then we also have the three modes "doesn't support encryption", "encrypted but not manually verified" and "identity manually checked" @merkste Threema has it a little bit different, as they don't force the identity to be verified via telephone number and they don't support unencrypted communication, which we need for SMS. So we'll have 4 cases to worry about when TS implements the usage of emails or random strings as handles. But that shouldn't be too hard - we could just make the green bar yellow.

[jedie]

+1 the green bar is too small. Proposal: Make the bar bigger and add a separator between TextSecure contacts and the other contacts.

And sometimes the number display under the name is wrong. Seems that's just the first number and not the number used in TextSecure. e.g: first number a local phone number and second number is the mobile number used in TextSecure... I see the fist local phone number under the name. That's confusing.

Also confusing, related to this: Create a new chat and select one phone entry: You will get a list of all numbers from the contact. But there are duplicated numbers: Seems that TextSecure used not only the "real" contact numbers: It used also numbers from other app connections like Telegram, WhatsApp (if installed and connected)

[tinloaf]

Also, it would be great to see the trust level in the conversation screen. Perhaps you could color the lock accordingly?

[generalmanager]

@tinloaf Good idea, it would however collide with the changes I proposed in #766. If you have any specific ideas, we'd be happy to have another voice over there.

[tinloaf]

@lindworm I was talking about the lock in the header bar, sorry. The one you can use to end your session or verify your chat partner...

[jedie]

If there are profile pictures (see #706) then the contact list can display them. Maybe a green/grey bar and a contact grouping (secure contacts first, than other) can help to differentiate...

[generalmanager]

@tinloaf that sounds great, I talked about the header icon in my last response in #766 too, because it currently has the same signaling issues as the send icon. But we should really have this discussion over at #766, as we are talking about the message window there ;-) We just have to get the UX consistent across the board. It's confusing to have the color schemes/lock signals mean different things in the contact list and in the message window. Therefore I waive my earlier proposal. I now think this would be best for the contacts list:

• Keep TS contacts on top of the list.
• Remove the green bar we have now. Instead, all the TextSecure users get a big yellow or black lock in front of their names/contact pictures (#706).
• All the verified TS users get their lock color changed to green.
• Everybody else gets a big open, red lock (as I described in #766 )

This makes the distinction clear enough, that we don't necessarily need a horizontal divider between the TS and non-TS contacts. It should also encourage people to get as many of their contacts to use TS and verify the keys (I know it's not as important as in other apps, because of our sexy protocol. But it can't hurt.) But the most important thing is: it's clear right from the moment you pick a contact which level of privacy you can expect.

[jedie]

@lindworm +1 Great idea with yellow/green lock and red open look ! But IMHO somewhere must exist a explaining text about what's the three lock icons are about. Maybe touch the lock icon?

[generalmanager]

@jedie: yes we need a usable help 2 clicks away at max, but I think it shouldn't be after clicking on the lock symbol, but after clicking on the settings icon (three vertical dots). The help should also explain the blue/green coloring of the messages , the send icon etc. We should open a seperate issue about that.

I'm open to discuss everything, but especially the coloring of the normal TS users' lock symbol. We may want to use black instead of yellow for their lock to signal what moxie said about TS: "privacy is normal". And a black lock is a secure lock. However this would break the well known and widely used traffic light analogy. And the green lock would be seen as highly optional by most people (as it technically is, because the keys are already verified). Personally I prefer the traffic light symbolism, as it adds a playful incentive to get all the way to the best security.

[virtualritz]

As for trust level (manually verified key), please also see #910. If a trust level icon gets overlaid on the avatar, this should be reflected in the avatar display in the contacts list ofc.

[virtualritz]

I also like to re-iterate the danger of color use for trust level. What about color vision impaired users? E.g. people with red green color blindness. Color can be used to emphasize a concept but it should never be the only way in which the concept is expressed.

[rmoore]

@lindworm How well would a black lock work with the Dark color scheme? The verification-level colors should be the same across both themes to avoid any confusion, no?

[generalmanager]

@virtualritz Bringing color blind people up is a valid point, but we can not make design choices for a small minority, if those will negatively impact the usability for the huge majority. If you argue like that, we also shouldn't use the green/blue color scheme to indicate the transport channel, because there aren't just red/green color blind people. I think we should instead consider adding a third theme in addition to the light and dark ones, with high contrasts and/or different shapes. This is supposedly a positive example: http://wearecolorblind.com/example/ichat/

@rmoore The dark theme already inverts the black/dark grey icons to white/light grey ones. I think that would be a valid choice for the dark theme. Ideally the colors to indicate privacy would be exactly the same, but as the black/white exchange is used everywhere and people are not going to change between color themes all the time, that shouldn't cause too much confusion.

[virtualritz]

@lindworm: the huge majority has learned the icon e.g. Skype uses for this (http://goo.gl/mYzOJh). Other options are combining FB's friend icon (which most people will know too) with a checkmark (http://goo.gl/rTrMeo). Why force users to learn a new concept?

Using an icon overlaid on the avatar we kill two birds with one stone: an icon overlay does not disadvantage color vision impaired users and it is a concept that a lot of new TS users will already know from other apps.

Ideally the colors to indicate privacy would be exactly the same

You talk about colors indicating privacy but this is exactly what I meant with the danger of mixing two kinds of information (encryption status and trust level) into one icon.

Colors, in your suggestion do, not indicate privacy! The lock does. Either it is closed or open. That are the two stages of privacy you get.

The other concept is trust level. That says nothing about privacy.

E.g. even if you do not fully trust the other party and haven't verified them, you can be sure that a 3rd party can not listen in, when the lock is closed. If this important distinction is already causing confusion in this thread because a single icon is used for both, I wonder how good it will do using this idea in the actual app.

[virtualritz]

@lindworm: I think we also need to consider that the majority of new users will likely not use manual verification. I think this is a given. If anyone thinks different about this, I'm curious to hear why.

As such the majority users will only ever see a yellow closed or red open lock with your suggestion. A yellow closed lock would always make me doubt the security of the connection more than just the b/w closed lock we have now. Wouldn't it make you? But this doubt would be ill-founded as the trust level says zero about the security of the connection. Messages are either send encrypted or they aren't, regardless of how well I know the other party.

Even when users understand the fact that they need to manually verify each other 1st to make the lock go green, will they also understand that it hasn't made their message channel any least bit more secure? Or that it was just as secure before, when the lock was still yellow?

This is just another reason I think using colors on the lock icon and mixing security and trust level into one icon is a bad idea from a usability pov. They are prone to create more confusion/doubt for the users than they will help them understand what is going on.

Related: http://www.sitepoint.com/cant-rely-color/

[Kiwii]

@virtualritz

But this doubt would be ill-founded as the trust level says zero about the security of the connection.

I'm not sure if there's already another system in place to prevent a man-in-the-middle attack but in case not: With unverified keys a third party (e.g. a network operator) can create individual connections to both parties of the chat and forward their messages to each other so they won't notice someone's eavesdropping on them unless they manually compare each other's keys.

[generalmanager]

@virtualritz and @Kiwii TextSecure is not based on public/private keys, which need manual verification to be secure against man in the middle attacks. TS uses a modified Diffie-Hellman key exchange, the possibility of comparing the keys is just an added bonus. I wrote out my thoughts about that rather extensively in #910, let's please discuss this over there so we don't flood the other tickets.

[virtualritz]

@lindworm I know how TS works. That is precisely why I said that planting possible doubts about the security level of the connection with an unverified contact, by using color, is ill-advised. The connection is just as secure when the contact wasn't verified.

[tinloaf]

Secure, yes. Only that you don't know whom you are securely talking to. ;)

[generalmanager]

Hey guys, I just made up some differend colored locks for the light skin. The matching send icons will be posted in #766

• Set 1: black (encrypted) and red (unencrypted)

• Set 2: green (trusted), black (encrypted) and red (unencrypted)

• Set 3: green (trusted), orange (encrypted) and red (unencrypted)

Tell me what you think ;-)

[virtualritz]

See my reply with images in #910, please.

[mcginty]

just put up https://github.com/WhisperSystems/TextSecure/pull/1205 for first steps at improving contact selection, feel free to test and give feedback

[mcginty]

Going to close this issue since the contact selection activity was redone in #1205, and we should break up individual requests into their own issues for better tracking. Thanks!