Improve message coloring

[generalmanager]

The colored messages are supposed to convey to the user the difference between push messages and SMS.

But the green color has confused myself, @sagischwarz, @phenx-de and literally everybody I have told to install the app.

@phenx-de and myself have had a rather extensive discussion about the whole shebang in #908.

What we came up with:

• Use orange instead of green
  • Green is widely used to indicate security aka encryption (green traffic light -> you're safe / good to go) and people are used very to it.
  • Green is already used to indicate encryption / TS users in the contact list
  • It also collides with several ideas in Improve usability / look of contacts list #741 and Add trust level indicator to conversation screen #910 to indicate trust
  • Orange is the only color left in the Android color scheme, apart from purple: https://developer.android.com/design/style/color.html
  • It doesn't have such a direct association as green and red have
• Use toned down colors to indicate the most likely transport for messages that aren't sent yet (pending messages more accurately conveyed to user #796)
  • Provides information about the most likely transport
  • Indicates that the message hasn't been send yet
• We should use color strips on a light grey message body. Either on the speakers' side or on top of the messages
  • A whole window of completely colored messages looks very playful/cartoonish
  • It improves the contrast of the gray message-delivered text and icons below the message, making it easier to read
  • Scale down the importance of the transport information to a reasonable level
• Color both the messages of sender and receiver
  • While roaming and in some countries people have to pay (a lot) for incoming texts, so knowing if it's an SMS or not is important.
  • The current implementation is inconsistent from a UX perspective.

This is what @phenx-de came up with:

Blue message sides for data and orange message sides for SMS:
____

Those are two of my own mockup sets, one with white and one with grey backgrounds.
The first one doesn't have the nice new send icons because I couldn't be bothered to put them in after I made the mockups.

Colorset 1: Blue message headers for data, grey background:

Colorset 1: Orange message headers for SMS, grey background:

Colorset 2: Blue message headers for data, white background:

Colorset 2: Orange message headers for SMS, white background, encryption:

Colorset 2: Orange message headers for SMS, white background, no encryption:

Please tell us what you think ;-)

I did a quick count for several different preferences.

If I misunderstood anybody, just tell me and I'll change your vote. If you have an opinion to one of those topics and aren't listed, just answer in the thread.

The first two are about the shape of the messages only, the colors are to be discussed apart from the way we use them.

• New style messages with colored bands (colors to be discussed) on top or on the side:
  @Lindworm, @phenx-de, @noschinl, @Anaron, @monreal, @tinloaf @maulwuff
• Old style messages but with toned down colors:
  @virtualritz, @0xACE, @L3st3r
• Message color should indicate encryption
  @virtualritz, @Lindworm, @mcginty
• Message color should indicate transport method
  @Anaron, @Cimbali, @0xACE, @L3st3r, @backspace
• Colors should stay the same (blue and green)
  @Anaron, @monreal, @sagischwarz, @0xACE, @L3st3r
• Colors should change
  @Lindworm, @phenx-de, @maulwuff

Everybody seems to like the toned down colors for sending, so at least we have one thing in common ;-)

[Anaron]

Green has been commonly associated with SMS for years now. We can thank Apple for that because that's what they used for SMS. It wasn't until the release of iMesssage that they added blue for data-based messages. Although it may make sense for you and I to see green as secure, it wouldn't make sense for the average user.

I think the TextSecure developers should stick to green for SMS but switch the blue colour for secure data-based messages to orange. Blue only indicates that it's data-based so another colour to indicate security is nice. Red and purple are not suitable so that leaves orange.

EDIT: LIke so:

[generalmanager]

@Anaron
Well the fist thing several friends and even my mom associated the green color with was that the message is encrypted. Some specifically asked why the old messages (before we both switched to V2) were not encrypted, while the new ones weren't.

We should get as many opinions about this as possible, but I personally think the first association with green is security and it would be bad for the user experience if it symbolizes something different.
We should also consider that it's not that bad if a user doesn't immediately recognize the difference between SMS and data but it's a lot worse if they can't differentiate between secure and insecure communication.

About the third color for encryption:
First that would mean you would have an own color for encrypted data but none for encrypted SMS - that's not good.
We've been discussing different options to signal trust and encryption in quiet some detail in #910, #741 and #766.

The one thing we are basically on the same page about is that we should not overuse colors, especially not to convey two different meanings at the same time (data+encryption).

[Anaron]

@Lindworm Would your friends and mother have made the same association with an iPhone running iOS 7? Apple set the "green for SMS" standard once the iPhone became popular. And that's a device marketed towards the average non-tech savvy consumer (like your mother). In the image below, the left is iMessage (blue chat bubbles) and the right is regular SMS.

I agree that green should be used for encryption because it makes sense but the issue is that it wouldn't make sense with the average consumer. Apple kinda messed things up by popularizing the colour green for SMS. For now, we're left with orange. And it makes sense when green is the colour most people think of when it comes to SMS. If anything, options for different colour schemes should be implemented.

Also, I thought data=encrypted so there's no point in differentiating the two. There's no way they can encrypt outgoing SMS. The only encryption for that is for locally-stored SMS and that's to keep it safe from someone that manages to copy it from your phone so it can be viewed externally.

[generalmanager]

There's no way they can encrypt outgoing SMS.

This is wrong - TextSecure has been sending encrypted SMS for years now. The one thing it couldn't do was data.
Afaik there is no unencrypted data, but there is definitely encrypted SMS.

[Anaron]

@Lindworm Are you sure? I'm finding it hard to believe that they can encrypt regular SMS to non-TextSecure users. How can other users decrypt such messages? It doesn't make any sense. I know that messages between TextSecure users are encrypted via SMS (old way) and data (new way). Perhaps you misunderstood what I was trying to say. I should have been a little more specific earlier.

[generalmanager]

@Anaron No, the SMS to non TextSecure users are of course not encrypted, but the SMS between TextSecure users are.

I'm not sure how you would want to signal the difference between secure and insecure SMS though. ;-)

[Anaron]

@Lindworm Okay. What about green for unencrypted SMS, orange for encrypted SMS, and blue for encrypted push messages? Green obviously wouldn't have the padlock icon and orange/blue would. It's great because blue is already associated with data thanks to Apple's iMessage service. And orange wouldn't clash with the other colours like purple and red.

[generalmanager]

I don't think we should use colors to indicate the message encryption at all. It's simply too confusing.
We have the send icon and the top bar lock icon to do that.
Please read the discussion in #766 too.

What do you think about the partial coloring instead of the full message body?

[noschinl]

I like the partial coloring; it definitely improves readability. A colored line at the top as in @Lindworm's suggestion looks cleaner to me as the one on the right in @phenx-de's mockup (mostly because the latter over-emphasizes the speech-bubble in my opinion).

As for the coloring, I think it is important to note that we are discussing an Android app, not one for iOS. Green has this 'everything is alright' connotation, so using it for SMS seems counter-intuitive.

[eikowagenknecht]

@Lindworm Thank you very much for putting our discussion from the other issue to this one in so much detail. I have nothing to add to your first post 👍

@noschinl I'm glad that you mention the iOS vs. Android difference here. The two systems use distinct visual styles, so I see no need to copy what iMessage does. It seems that the meaning "green = SMS" is not common sense yet for most of the users, especially those from the Android world, as indicated by @Lindworm and also consistent with my experience from non-tech-savvy friends.

The single most confusing point for most of them was: "Why are some messages encrypted (meaning green) and some are not (meaning blue)". And also: "Why is there still a lock symbol on non-encrypted messages (meaning blue again)". So they totally got confused.

I can understand the argument that this has been the default coloring in TextSecure for some years now (has it? I'm a fairly new user), but since the rollout to the masses only started recently with the release of version 2, I don't think it's too late to change colors to something more sensible.

[virtualritz]

@phenx-de I had the same misconception about encryption vs non-encryption (green/blue) when I used TS for the 1st time now.
And I do 'speak' two dozen computer languages, write software for a living and studied HCI/UX at uni. :) So this needs addressing, imho.

My suggestion would be to have one message bubble color meaning encrypted and one color meaning unencrypted.

This makes the lock icon at the bottom of each message obsolete. Instead, it can be replaced with an icon indicating transport channel. That means we need an icon to represent SMS and one to represent push.

I like @Lindworm 's suggestion of using a different shade while the message is traveling. In the light theme this should be a lighter shade of the color, in the dark team a darker.

[virtualritz]

I would still keep the message bubbles of the sender a uniform color (instead of using the bar). It can just be a light shade of the color we end up choosing. I agree that the current colors, green and blue, are too saturated and prominent, also impacting text contrast on the sender's messages negatively. A lighter shade of the color (or darker in the dark theme) can alleviate this.

On that note: in the dark theme, the text is always white on dark gray or blue/green bg message bubbles.
That is good.
In the light theme, however, the text of the recipient's messages is black on gray but the text of the sender's messages is white on color! This is bad. It requires the visual system of the user to switch every other message, when using the default, light theme.
When you use printed docs (black text on white paper) alongside a screen, it is suggested that the screen uses a matching text/bg coloring, precisely for that reason. It is straining for the eyes when you have to invert every time you look at the book or the screen.

For the same reason, in the light theme, the messages should use a light shade of the color, so black text can be used, too, for the sender's messages.

[generalmanager]

@phenx-de
You're welcome!

I can understand the argument that this has been the default coloring in TextSecure for some years now (has it? I'm a fairly new user)

Nope, it was basically black on white:

[Anaron]

@Lindworm I don't think so. It's only 3 colours, 2 of which are easily recognizable as regular SMS (green) and data (blue). Both the send icon and padlock icon can complement the colours. To totally avoid confusion, it can say something like "Now via SMS" under the message. The same thing is done in Hangouts. With that said, I'm not the average user and this app should be designed for the average user. The less confusing it is, the better. I like @virtualritz's one colour for encrypted and non-encrypted messages idea.

What do you think about the partial coloring instead of the full message body?

I think it's great. I really like the horizontal partial colouring. I think it looks much better than the vertical one. However, I imagine it would look worse with the dark theme. For that reason, I think it's better that we stick with a solid colour for the chat bubble rather than a partial one. The lighter shade indicating that the message is still being sent is a very good idea.

@noschinl

As for the coloring, I think it is important to note that we are discussing an Android app, not one for iOS. Green has this 'everything is alright' connotation, so using it for SMS seems counter-intuitive.

Actually, we're discussing what's currently an Android app. Open Whisper Systems have plans to release an iOS version of TextSecure called "Whisper". They're also going to rename TextSecure on Android with the same name. You can read about it on their blog here. It's important to keep that in mind when discussing changes to the UI. The more consistent the apps are across platforms, the better it is for brand image.

@virtualritz I think you're onto something with the colours. It's better to have black text in a coloured chat bubble just like Kik Messenger. It offers consistency and it's aesthetically-pleasing.

[monreal]

I really really like style of message bubbles from "Colorset 2" above (thin color stripe at top, white bubble). In "Colorset 1" there is not enough contrast between the bubble background and text colors IMHO.

However I do not like the use of orange. Like it or not, Ale seems to have set a standard here. Surely not for the Android platform but keep in mind that TS will be available for iOS really soon and I would fully expect it to be consistent a) with the Android client and b) with the Ale app.

[sagischwarz]

Just a very personal view on one of the colors in the discussion: For me, orange (and yellow) are warning colors, like: "Look, something could go wrong, it has not yet reached 'red', but you have to have a look at it!". I wonder if it is like this for others.

[generalmanager]

@virtualritz

My suggestion would be to have one message bubble color meaning encrypted and one color meaning unencrypted.

I thought about that and really liked the idea at first (you know how much I like the state of encryption to be clear ;-). I agree that it's usually more important to to communicate to the user if his conversations are private than if he has to pay a few cents for each message. But the state of encryption is generally not going to change during the conversation, while the transport does change dynamically and may do so several times a day.

If we do it, I'd propose to use red and green for encrypted and unencrypted messages respectively, for the reasons we already discussed.

In an encrypted conversation the green color will probably positively reinforce the user, to use encryption whenever possible.
The question is, if the red will do the opposite for people chatting unencrypted.
In the short term this kind of nagging will certainly make users try to get it to green by convincing friends and family to switch to TS. But most users will have only a few TS contacts. If they use TS as their main SMS app, like I do, they will have many more unencrypted conversation full of glaring red "stop signs". That may discourage people more than a little red lock on the send icon ;-).

But I guess we can't solve all problems at once. For now, I think the color should indicate transport, because it's the property which changes more frequently.

I like @Lindworm 's suggestion of using a different shade while the message is traveling. In the light theme this should be a lighter shade of the color, in the dark team a darker.

I agree, but for now I'm mainly working on the light theme. When we have a working color set and iconography there, it should'nt be too hard to invert the interface.

I would still keep the message bubbles of the sender a uniform color (instead of using the bar)

I guess that's personal preference. I tried it, but didn't like it too much. It still seemed too playful and toy-like to me. We may consider choosing one for the default and making a seperate theme for the other option.

In the light theme however, the text of the reciepient's messages is black on gray but the text of the sender's messages is white on color. This is bad.

Absolutely. That's why I like the nearly white messages in the mockups above so much. It's really tiring with the current theme.

@Anaron
Why do you think it would look worse on the dark theme? I think it looks even better:

That's because I don't have to change the colors of the bars. The sent messages always have a strong color, that doesn't get in the way because it's just a small strip.

I personally dislike the current dark theme, mainly because it uses dark blue bubbles on black.

If we use fully colored but toned down bubbles it will always look bad in the dark theme because it's hard to distinguish dark blue from black. Really dark red would probably look even worse.

The dark theme was actually not much work. I basically just swapped the colors used for text and background, while the color strips and grey notification icons and text stay the same.

@sagischwarz: when used in together with green and red, I feel the same about orange. But when it's used with blue, as phenx-de and I suggested, it doesn't come off as a warning to me.

[Cimbali]

My personal take on this is to have the colour represent the channel, and the padlocks the encryption.

That being said, I agree with @sagischwarz on orange being a bad choice. A little bit of warning connotation, but especially it's blue's complementary colour and that just doesn't mix well. I mean, even if the colours are only applied to a part of the message, having blue and orange messages next to each other - which could happen - is just plain ugly. Take a look at @Anaron 's screenshot if you're not convinced.

[Anaron]

@Lindworm My goodness, you're right. What I imagined was much different than that screenshot.

[generalmanager]

@Cimbali

I don't think it's that bad. @Anaron's screenshot is veeeery colorful ;)

@Lindworm My goodness, you're right. What I imagined was much different than that screenshot.

Thanks!

[eikowagenknecht]

@Lindworm: I very much like the dark theme as shown in your new image as well. Looks very clean and crisp to me.

Allthough I am still not quite happy with green as the color for SMS, but there seem to be some valid points for green, so I'd like to collect them here.

Reasons to use green instead of yellow/orange:

• Apple uses it, like it or not. TextSecure will be available on iOS in the near future and since it will be run next to iMessage it makes sense to use the same coloring scheme. For consistency across platforms the Android version should use the same colors as the iOS version.
• Orange and blue don't look good next to each other (see screenshot from @Anaron). It might be less disturbing with the bars at top of the bubble, but still green and blue fit together better.
• Orange is seen as "warning" by some people as well. So that just might give the confusion another new turn: People now might consider the messages unencrypted even when they really are encrypted. That's slightly better (no leaking of private information when the user considers it to be safe), but still not perfect.

While the main reason to use yellow/orange would be:

• Avoid confusion, so that people don't think messages are encrypted when they in fact are not.

Regardless of the final decision, there really is a need to explain the colors to new users to avoid confusion one way or the other, for a discussion how this could be accomplished, see #908.

[generalmanager]

@phenx-de

Apple uses it, like it or not. TextSecure will be available on iOS in the near future and since it will be run next to iMessage it makes sense to use the same coloring scheme. For consistency across platforms the Android version should use the same colors as the iOS version.

Point taken, I'm not a fan but I agree that it should be consistent across platforms.
But I still think it's better to "surprise" Apple users with a new SMS color, than to have lots of people think green means it's encrypted (when in fact it may not be). These people will then be shocked/unpleaseantly surprised, that they can't seem to communicate encrypted at home (where there is wifi).

Orange and blue don't look good next to each other (see screenshot from @Anaron).

Did you see the two examples with orange and blue messages in one screen I just posted? I don't mind them at all.

Orange is seen as "warning" by some people as well.

That usually happens in the context of green and read, which then makes up a traffic light.

[Cimbali]

If we go for the top (or side) colour strip we can literally use any colour. Why not a darkish blue for push and some light blue or even turquoise (yeah, compromising between blue and green here) for the text messages ? That way you'd have a light/dark contrast as well.

That would give something like this : http://46.19.37.204/playwithcolours.html#push=#009AD9&text=#5ee5c6 (if there is an authentication request just cancel it you'll be fine)
Code is here : http://jsfiddle.net/5pHb5/2/

I just think we should experiment a bit before selecting any colour :)
(e.g. to illustrate my point from earlier, this still looks bad : http://46.19.37.204/playwithcolours.html#push=#009AD9&text=#f34800)

[0xACE]

Don't change the message boxes. One could easily argue that orange messages are broken...

Do not use colours to indicate encryption. The padlock does it. If you believe the padlock is too small, experiment with having it as a big faded background of the message (something tells me this isn't a good solution, clutter). Or even just increase the contrast of the message sub-text.

Having that small bar instead of a full coloured box will make it more difficult to find your message, say that the screen is cluttered with long texts, the full coloured message box will be much less confusing than the coloured bars. Do not apply these bars, it would make it more difficult to identify who's who. The bars makes it more difficult for the user to find their messages, do not implement this. You need a clear indication of who's message it is. Good luck finding that small bar in sunlight.

Arguing what colour means what will probably be difficult, all cultures may not consider the colours to mean the same...

I agree that the app doesn't make it clear what the colours mean, but neither does any of your suggestions of just changing it to another colour. Icons or text is the more appropriate way to make sure users understand.

Leave the full coloured green and blue message boxes as they are. The encryption is indicated by the padlock. Messages without padlocks are implicitly unencrypted. Implicit vs Clutter is another discussion... Maybe give a greater contrast to the sub-text of the text messages is a better idea.

OT: in group chats are participants given different coloured message boxes?

Red can mean error,danger, superb job, extra important
Orange can mean deceit, distrust, almost
Green can mean good, success, money
Blue can mean health, softness, understanding
Purple can mean royalty, nobility

My point is colours are confusing, keep the blue and green as they are.

Regarding the colour consistency with the other mentioned issues. You're going to further complicate the setup. The app was intended to make encryption easy. A novice user seeing orange encrypted message while others have green ones will make the user believe it can't trust this program without some magical procedures. Don't make it more complicated, you will cause distrust with novice users and eventually scare them off...

[virtualritz]

To consider: WhatsApp, too, uses slightly green colored sender message bubbles.

But: FB messenger uses blue, Kakao Talk (de facto standard in South Korea, has >100 million users, mainly in South East Asia) uses yellow!
Both FB messenger and KakaoTalk do so for obvious branding reasons.

And a big chunk of the users of these apps are indeed on iOS.

I guess the bottom line is that it is not so important to copy iMessage when it comes to message coloring.
What we can take from this is that all these apps use one consistent color, throughout the app, for message bubbles of the sender and a different one for the bubbles of the receiver. However, all these apps also do not have an emphasis on encryption. That is, the use case of clearly communicating the encryption status of a message does not apply to them.

So what we need, if we like the to make the transition for users of other messaging apps easy, is a single default color for the sender's message bubbles. For the common case. Then we have the specific case, which is unencrypted SMS.

Here are the cases with resp. suggestions:

• Encrypted (push) (default color)
• Encrypted (SMS) (default color, SMS transport indicator icon)
• Unencrypted (SMS) (other color, SMS transport indicator icon)

Again, I think key is consistency, not copying what app X or Y uses for a color but how the majority of widely adopted messaging apps use color in message bubbles.

From that pov it does not matter what color we use for the sender's bubbles. All that does matter is that the use of color is consistent and doesn't cause confusion. Currently it does cause confusion as many new users think that blue translates to unencrypted. This needs a solution.

P.S.:
This is OT, but ...
When you think about modern messaging apps, we need to think about customization/theming. Because people spend so much time in these apps, they like to customize them. I predict that people will ask for this being added to TS/Whisper, in the very near future and I also predict that this will be key to the success to TS/Whisper particularly in the Asian countries, specifically South Korea and Japan. This means being able to possibly customize:

• background wallpaper/color
• sender message bubble wallpaper/color
• receiver(s) message bubble wallpaper/color
• text color(s)
• message icons/emoticons/emoji

KakaoTalk is a prime example of this.
I just though to mention this makes sense as it gives a good context on the importance of message bubble coloring in app like TS/Whisper. ;)

[generalmanager]

@virtualritz
I fully support everything you just wrote. If we really do use only two colors, I think green for encrypted and red for unencrypted are the most intuitive choices.
And we can just take the SMS icon from the Android Icon Pack to use in the message bubbles.

I also just uploaded some examples for signaling trust with badges and the "horizontal colored strip" skin in #910.

[0xACE]

@Lindworm: virtualritz said that there should only be one colours rather than two. Don't have the colour indicating encryption, it's only going to confuse users.

Only thing I have to add regarding virtualritz post: be careful with what icons you add, don't clutter the screen if it's not necessary. A text/SMS app that has an icon indicating that it was sent as SMS may not be the best idea, however it's probably less confusing than colours.

It's worth mentioning:

User A Scenario (Exclusively uses SMS)

• The SMS icon is unnecessary as all texts are sent by SMS.

User B Scenario (Exclusively uses Data network)

• The dataplan icon is unnecessary as all texts are sent by data.

User C Scenario (Mixes between SMS/Data network)

• Now has icons on all Text messages. Doesn't each rendered icon require more resources?

virtualritz's plan only had icons for SMS, interpret the scenarios as you like. If you decide to add a icon the problem will be how do you determine which icon to show? Do you show the SMS icon because it may cost? Which is not universally true. Atm TextSecure isn't used by the majority, you will possibly have this icon on most messages.

[jeremymasters]

@virtualritz Maybe I don't have enough time to site down and enumerate all the answers to your ex post facto list.

[virtualritz]

@jeremymasters: Please understand that answering you takes time too. If you don’t want do the ‘homework’ you will have a hard time getting through with your proposals.

Having an idea is great but you will need to go through the process of convincing people that it is a good one. If you want them to implement it at least.

Even if you implement it yourself – getting a pull request accepted by the project maintainers will likely require you to go to the same process that I outlined above with them.

I hope that doesn’t discourage you from contributing further. The more you show people that you have really thought about a proposal, the more weight it will have for them when they consider it (and the less likely it will be that it will be flatly rejected).

[PulsarFX]

To sum up the current status once again:

• Colors for background: done. filled background
  • color for unencrypted message: open. (green/grey or green/blue for encrypted/unencrypted)
• Send button: nearly done.
  • open lock: black or a toned down red?
• SMS/MMS/DATA icon: in progress.
  • DATA: no icon
  • SMS/MMS: waiting for @virtualritz.

[agrajaghh]

Long discussion for nothing? ;)
Does someone knows how the status is for the message colors? Are there other issues adressing these? Will they stay blue and green for sms/data or will they change to colors for unencrypted/encrypted?

[generalmanager]

@mcginty made good points in #945 (comment) but unfortunately nothing about the actual colors yet.

I think whatever we do with them should/has to be released either before or at the same time with the iOS release, because it has to be consistent between platforms.
And the iOS version will not be able to send SMS, because Apple doesn't allow apps to access this function.

If we stick with the current scheme, iPhone users will only ever send blue messages. If we change the colors to indicate encryption, we can use the same full color scheme on both platforms.

[oiceberg]

As you know, there are only three possibilities:

PUSH encrypted.
SMS encrypted.
SMS unencrypted.

The closed or open lock informs about the encrypted or unencrypted status of a sent message. To inform the transmission channel, there are other possibilities besides the color scheme, as has been said in some places here. But in fact, it is important to have consistency between the Android and iOS platforms, well as between the messages sent and received.

[nysatrok]

I think we should keep in mind that the visualization for incoming and outgoing messages should be consistent. In the case of incoming messages it is important to distinguish between verified and unverified keys. In #1172 there is a discussion focused on that fact.

[generalmanager]

@nysatrok This isn't something that should be done on a message level but for a whole conversation. That's why we are discussing this in #910.
Even in group messages a per message identifier doesn't make sense because if one is not verified, the whole conversation can leak in case of a MITM attack.

[mcginty]

The long discussion isn't for nothing :). It's been hanging around in my head, but we've been very heads-down on more explicit necessary feature work and fixing broken things. I think to a certain extent, updating color and visual security indicators in the Android app might be best done when roughly coordinated with the TS-iOS release in order to limit unnecessary change and maintain as unified a look as possible cross-platform.

I have a couple more ideas for visuals that I want to experiment with but haven't had the time just yet.

[agrajaghh]

@mcginty I think its a good idea of coordinating it with the iOS release. But if the colors should be changed, it has to be done at the same time or a bit before I think. The iOS release will push the android version aswell, and we shouldn't confuse the new users right away with changed colors.

[ei8fdb]

Hi there,

I came across this thread after a discussion on twitter about the same topic. I am still reading through all the messages here.

I am speaking as a European Textsecure user and a user centred designer who is privacy sensitive, the most importance piece of information I want to know is if my message is encrypted or not.

The discussion above about the design patterns to follow, if iOS’s model of green for SMS and blue for iMessage was a good model to follow. My opinion would be Android is different than iOS. There are a few ways to handle this.

• if there are no plans to bring TextSecure to iOS, then TextSecure should follow Android design guidelines because it’s an Android application. No-brainer. I can’t think of any valid user centred design reasons why you would have iOS design patterns in an Android application.
• if there are plans to bring TextSecure to iOS then maybe you might want to take into account making TextSecure look the same on both. The reason is this will assist users when they switch from one to the other. Because, some will. It’s a given.
• or possibly keep the Android UI close to the Android guidelines and develop an iOS version close to iOS guidelines

That decision will ideally be informed by user research, talking to users, and measuring iOS user requests for an iOS version.

It would be farking wonderful if a TextSecure client could be developed to private iOS users with private SMS and push messages.

Is there a need to communicate what transport is used for the message? In terms of communicating if the message is sent over SMS or over PUSH, there needs to be a decision if it is a characteristic users WANT to know. Asking users is a good way. :)

Get a simple survey together and ask TextSecure users to fill it out. Provide it in anonymous form. I’d happily help put it together.

Speaking as a user living in Europe where I have unlimited (almost) SMS’s, I don’t mind if it is sent over SMS or PUSH. However, if I am a user in the US and SMS costs a lot, and I have a data plan, then maybe I want to know.

Possibly more important is: if sending a PUSH message is provably more secure than sending an encrypted SMS, then maybe I need to know how it was sent.

-How to represent transport in the UI-

Colour:
From a user centred design point of view, it is not ideal. There are a number of reasons:

• It is not accessible to people who are colour blind. Red/Green colour blindness affects approx 10% of all men. As a result, they will not see this.
• In itself colour does not convey any meaning. The first time user will have no idea what it means. There is a need for the user to retain recognition – does blue mean PUSH or does green mean PUSH? I don’t remember. I do not agree that there is a higher cognitive load associated with colour. More a higher recognition need. I’m happy to be proven wrong with some real research. :)

A Textsecure user on Twitter mentioned she also found it unhelpful "Can that (the use of colour) be changed? Not only it doesnt help, it hinders us ADHD ppl."

Possible solution:
Inform the user first time of install to what the colours mean. Like those “silk screen” walk-throughs. Just a thought.

Text:
Using words like “SMS” “PUSH”, etc have some issues…

• Translation (if they are to be translated)
• People with dyslexia. I do not know if there is any research focusing on the minimum/maximum number of characters people with dyslexia can have issues with. I have asked some other HCI friends who know more about it.
• There could be issues with cultural understanding – is “PUSH” English jargon? I know what it means, but does a non-technical user from understand?

Possible solution:

Text may be a good option, but the char count would need to be short – something like “SMS” “PUSH”, “DATA”.

Icons

1. Lots of icons are not good. Ever.
2. Icons are the lazy approach. :)

Possible solution
Icons should be used sparingly. Maybe TextSecure tries to send the message via the most secure transport possible, then:

• If it succeeds, only display that it the message is secure.
• If that fails, then fall back to SMS, and show both using icons a) the message was sent by SMS and b) that is was sent insecurely.

Possible ways to get a better decision:
It would be good to get feedback from first time users as to their understanding of the colours.

Get some new users and ask them what they think the colours mean. Don’t tell them what it means, let them figure it out, or not, themselves.

I'd like to do some user testing with some users to see. Anyone want to help?
Bernard

[mcginty]

@bernardATdiymut TextSecure-iOS is well underway, so this is the case. Roughly speaking and not surprisingly, the goal is to style the Android and iOS equivalents to carry the same information in a way that adheres to the design guidelines of the platform.

Agreed that color is a bad indicator on its own, but it can be a good second assistant. I'm confused about how ADHD plays a part in color choices. When we end up making color/indicator changes we can definitely include a note explaining the interface on first open, I think that's a good idea.

You can find a discussion of what to replace "push" with at #1139, feel free to join that conversation too :).

I disagree in the general sense that icons are lazy. We should be selective, but in this case both the encryption status and transport are important enough pieces of information to warrant a visual indicator of some kind per message. At the moment, I'm leaning the Hangouts route of a small SMS indicator both in the text input and in a message:

I'm interested in user testing as well, and we have a couple channels to help make that happen. If you have any specific suggestions, we can come up with specific tests to run and get that on its way.

[deutrino]

Based on my poking around in UX tickets for the messaging view, I've sort of done a meta-review of these tickets today, and wanted to add my $.02 here.

• In a comment I made on Unable to send non-encrypted SMS to previous TextSecure user #845, a ticket about being unable to manually fall back to unencrypted SMS with a (presumably former) TextSecure user, I made a proposal which included the idea of enhancing the difference in the existing UI between encrypted and unencrypted messages under certain conditions where the user should be alert, e.g. when a former TextSecure contact suddenly reverts to unencrypted SMS.
• In Rename 'push' to something non-technical #1139 people don't like using the word "PUSH" to indicate message transport. I agree, and believe a reverse-color "SMS" rectangle icon should be displayed in all sent/received messages, and possibly in the send-message textarea as well. Data transport display is also discussed in improve 'send encrypted' icon #766 (should this be in message bubbles, in the send icon, does anyone care, what about color-blind people, here are 50 takes on how the send icon could look, etc :)) and SMS fallback behaviour when other directory users are offline #678 (seems to favor a more explicit approach maybe in the text entry area?). I think data is the default transport; wherever an icon is needed, I suggest a cloud ( "☁" ), but I suggest not using this for historical messages or in the send-message textarea, as data is considered the default.
• In [UX] Confirmation / return receipt UI should show more useful state than it currently does #2095 I argue in a brand new ticket ;) for adding more state display to the return receipt icon: currently it is "receipt confirmed" or "lack of receipt confirmed." I lay out two cases:
  1. In the case that quite old data/SMS messages, and/or all SMS messages will not be confirmed, I propose, in every message in scroll history, having the icon be in one of three states.
     • awaiting receipt (clock on envelope, lower intensity, suggested timeout 1 hour)
     • receipt confirmed (checkbox on envelope, full intensity)
     • receipt timed out (question mark on envelope, full intensity)
  2. In the case that a receiving party will make all available attempt to confirm messages (even over SMS), I propose the icon in three very similar states, but all messages in history will be updated if they are ever confirmed before they "scroll away."
     • awaiting receipt (clock on envelope, lower intensity, suggested timeout 1 hour)
     • receipt confirmed (checkbox on envelope, full intensity)
     • receipt unconfirmed (question mark or interrobang on envelope, full intensity)

I'd like to synthesize my thoughts on all of these since I've spent the better part of a day digging through them and their myriad dupes and sprouts and branches. :)

Message transport and delivery display

• 👍 to displaying transport in all previously sent messages using a reverse-color "SMS" icon (since SMS is less secure and people may pay for it) but no data icon (for which, wherever it is needed, I suggest a cloud, "☁") as data is the presumed default.
• 👍 to displaying transport in the text entry area opposite the send icon using a reverse-color "SMS" icon (since SMS is less secure and people may pay for it) whenever SMS is the forced or presumed first-try option, but no data icon ("☁") as data is the presumed default. ("Hangouts"-like UX.)
• 👎 to displaying data transport using the color of the send icon!!
• 👍 to either of my above suggestions to show a bit more state in the receipt confirmation icon ([UX] Confirmation / return receipt UI should show more useful state than it currently does #2095)

Message security display

• 👍 to displaying encryption in all previously sent messages, either as a closed lock (encrypted) or a red lock like this but with the hasp rotated away (unencrypted)
• 👍 to displaying encryption status as a similar black "encrypted" lock or red "unencrypted" open lock very prominently in the send icon
• Regarding my comments in Unable to send non-encrypted SMS to previous TextSecure user #845, I advocate enhancing the display of secure versus insecure messages in the style of the message bubbles themselves. People have argued whether message bubble color (the current case) or a vertical or horizontal color edge stripe should indicate data transport or encryption status. I don't think any of these should be used and would prefer icons. (Yes, "iconistan" defended below.) However, I really dislike the green-for-SMS, blue-for-data convention. I was confused by it for days and I'm so deep in tech I'm practically drowning in it. My primary concern is message security. Thus, I think:
  • display of historical messages' security should be enhanced beyond just the lock icons. If background is light and icons/text are dark, I would like to see a thin dark stroke of the message bubble for secure messages, and a thin greyed/muted, diagonal-dashed "warning" type stroke for insecure messages. The muting is to avoid making the user's eyes bleed when talking to their many insecure SMS contacts, but to train them for a less muted use of the visual style in potential security compromise situations, such as...
  • display of insecure messages received under unexpected fallback from (apparently former) TextSecure contacts (e.g. the Degraded Contact Proposal in Unable to send non-encrypted SMS to previous TextSecure user #845) should have a thick warning-colored/non-muted, diagonal-dashed "warning" type stroke for insecure messages.

Pulling it together

I can probably be arsed to make some mockups if folks are interested in what I'm saying. Right now, it's tired and I'm 1am. ;)

In every historical message, I want:

• Mandatory security icon
• Mandatory return-receipt status icon
• Optional transport icon, if SMS was used.

In the text entry area, I want:

• Mandatory and highly prominent security icon in a non-color-changing send icon
• Optional transport icon opposite the send icon if SMS will be used.

Yes, I understand this could mean ::gasp:: up to three icons in every historical message. I'd be happy with that, because I believe each one would be easily understood by users, and far easier to differentiate than colors which follow few conventions other than stoplight colors. It's also good for color-blind folks. And, you can assimilate it in a glance.

If number of icons on the screen/scroll buffer is for some reason a problem, use a single graphical element to display the various states. Security has up to 3 states (insecure, secure, and secure-trusted). Return-receipt has up to 3 states (awaiting receipt, receipt confirmed, receipt unconfirmed). Data transport has 2 states (SMS or not present). Thus you need 3 * 3 * 2 = 18 total combinations which could be something like a PNG or SVG displayed as a single element on each historical message.

[wp9015362]

Hello,

as already mentioned in:

#2774

I think the message bubble colors should not be used to indicate what messaging channel (Data/SMS) is being used or if the message is encrypted or not or if the message has arrived or not.

I think those things should instead be indicated via icons.

So, it would be nice if you would use icons as indicators instead of the message bubble colors.

Regards

[moxie0]

@wp9015362 Please don't open an issue, link it to another issue, and then immediately repeat yourself in the issue you're linking to. Just linking to it is enough. We're very busy, please respect our time by keeping the amount of email we receive to a minimum.

[McLoo]

@moxie0 fixed with 2.21.0?!

[moxie0]

Why not!