Closed generalmanager closed 9 years ago
virtualritz
commented
10 years ago As for stripes. Ask yourself why no other messaging app uses stripes to color message bubbles?
We're talking some companies who have some of the best UX/HCI experts in this industry, that money can buy, working for them. You think these people didn't have this idea? I tell you, you're mistaken. ;)
monreal
commented
10 years ago @virtualritz what you say is that open source should not even try to innovate and just copy big companies because what they do is right as they they pay a lot of "experts".
The striped bubbles @lindworm came up with look great and everyone but you seems to like them a lot.
midi
commented
10 years ago i like @virtualritz's ideas. color for encrypted/un-encrypted and a more control/feedback, for when textsecure wants to send sms and the ability to disable sms, for textsecure contacts (int'l sms, roaming, recipient has only internet, no mobile network...) , as already suggested in other issues.
bungabunga
commented
10 years ago my 50 cents:
-don't use colors for marking encryption/non-encryption. the padlock says more than any color. it just can't confuse anyone, while colors could.
-colors red and orange are (as someone said already) warning/alarming colors. they are also more disturbing to the eye then green and blue.
-two different colors (with light editions for non-sent msg) are the most that a conversation can bear. more colors would only add confusion and would also be a bit disturbing to the eye.
-that leaves us with green and blue for sms/mms and data.
geileszeuch
commented
10 years ago +1 for what bungabunga said. The pad lock under the message already indicates encryption state so there's no need to introduce more colors. We have to keep it simple and more colors will only confuse.
merkste
commented
10 years ago Just my 2 cents.
eikowagenknecht
commented
10 years ago @merkste You posted the same post twice, maybe you want to remove one.
Besides that, I very much support everything you just wrote. My first suggestion (way back in the other issue) was to use words like SMS / MMS / Push for the transport as well, because I don't think it's that important and doesn't justify the "straight-in-your-face-coloring".
The focus of this app is secure communication and colors are the most obvious thing to notice first, so it would make sende to use them to signal the encryption status. In fact, like mentioned many times before, but this can't be stressed enough: This is exactly what users expect who haven't used this app before! And being intuitive to new users is key for fast adoption I think.
I like the idea of neutral for unencrypted to not punish users for writing with people that don't use the app yet. The open padlock should be enough as a reminder that it's currently not safe.
I would go with bright green for the encrypted message. The questionmark next to the avatar and in the action bar should be enough to remind the user that it is not verified yet who they are talking with. But neutral as well feels wrong for me, since it's already pretty secure and the color should indicate that.
Dark green for verified is perfect.
generalmanager
commented
10 years ago @virtualritz I see your point, but I see it like @monreal. In design (other than in math) there are some basic rules that should never be broken, but the implementation details can be done in many different ways and I don't see any drawbacks of the stripes, apart from personal preferences.
I am also going to create a mockup with the stripe and the message bubble in the same color, but at low opacity. Maybe it'll look horrible, maybe we can use it as a compromise.
@bungabunga
don't use colors for marking encryption/non-encryption. the padlock says more than any color. it just can't confuse anyone, while colors could.
Some colors carry emotions all by itself for basically everybody (eg, green=secure, orange=watch out, red=stop/warning), when used in a specific context. Others may carry information, IF the user has become conditioned to them (eg green=sms, blue= data for iMessage users)
The first group is inherently larger than the second and always will be.
two different colors (with light editions for non-sent msg) are the most that a conversation can bear. more colors would only add confusion and would also be a bit disturbing to an eye.
@virtualritz doesn't propose additional colors for the encryption, but replace the meaning of the only two colors to convey the use of encryptio instead of transfer mode.
@merkste To 1: full ack
To 2: I don't think we should convey the trust level with colors, but instead with badges as proposed by @virtualritz in #910. There you can also see several examples how that could look.
I think two colors + shades of the same colors to indicate "sending..." is all we should use.
Yellow for the message itself also seems counterintuitive to me, because now you see a warning color for encrypted but not for unencrypted messages - that's really confusing.
To 3: I'm working on a version with stripes + slightly colored message body. My first impression is rather positive.
Full-on colored borders are confusing, because the colors distract the eyes from the message. The colors should lead the eyes to the message text, but not distract from it. With the top border or borders on the left for example, our usual reading style "top to bottom, left to right" is supported and the eye is lead to the text and then focuses on the text. With complete borders there ist no "escape" for the eye and you get distracted from the message.
To 4: That could work, see above at the dark blue/black theme for example.
@phenx-de
My first suggestion (way back in the other issue) was to use words like SMS / MMS / Push for the transport as well, because I don't think it's that important and doesn't justify the "straight-in-your-face-coloring".
I think we are on to something, will try with text and icon. But it may not work with short messages in small bubbles.
The focus of this app is secure communication and colors are the most obvious thing to notice first, so it would make sende to use them to signal the encryption status. In fact, like mentioned many times before, but this can't be stressed enough: This is exactly what users expect who haven't used this app before! And being intuitive to new users is key for fast adoption I think.
Absolutely!
I like the idea of neutral for unencrypted to not punish users for writing with people that don't use the app yet. The open padlock should be enough as a reminder that it's currently not safe.
Me too. We don't want to punish, we just want to be sure the user knows if he can expect privacy.
I would go with bright green for the encrypted message. The questionmark next to the avatar and in the action bar should be enough to remind the user that it is not verified yet who they are talking with. But neutral as well feels wrong for me, since it's already pretty secure and the color should indicate that. Dark green for verified is perfect.
I think this could work, but I'm still not really convinced that we should indicate trust with colors at all.
merkste
commented
10 years ago @phenx-de et al: Sorry for the double posts, I was in a train and had a pretty unstable connection.
@phenx-de and @lindworm:
| my pretty funny message text | my pretty funny message text | |
|---|---|---|
| sending SMS [lock] | > | 10:35 SMS [lock] |
I'd be happy if someone with more PS talent than me would post an image illustrating my points above.
Btw, I like the improvements on the paper dart and padlock very much. The clamp to the right makes it crystal clear that the padlock is open.
generalmanager
commented
10 years ago @merkste
Actually all my friends I've convinced so far, expected the colors to symbol encryption.
All of my friends too!
Restricting ourself to a single color in two tones (light and dark green) might improve accessibility for the colorblind tremendously.
good point!
Maybe we can indicate the sending status of a message be prepending the channel with the word 'sending'
I like the idea, but have one concern: This would blow up the message bubble for short messages like "ok" tremendously, which would then make it look like the additional information is more important than the context.
virtualritz
commented
10 years ago I love the look of the stripes, from a design perspective. But I think they are a bad idea from the UX perspective for all the reasons that were given by others in this ticket already. I also do not see the "innovation" in a message bubble with a stripe. Again, from a design perspective it is an obvious variant. You could put a colored dot, use a 45 deg badge overlaying an edge of the bubble or use a faint pattern with the resp. color in the bg. But the fact remains they're just obvious variations of the same. Namely "coloring the bubble". This has nothing to do with improving UX.
If it doesn't improve UX, you have to ask yourself: why do it? And: does it degrade UX. Horizontal bars: yes (can't be seen when the bubble is partly visible and at the top of the screen). Vertical bars: yes (harder to spot/see than a fully colored bubble).
HCI (human computer interfaces) are subject of scientific study. Being a designer does not make you an HCI expert (and vice versa). This is a very common misconception.
TLDR;
What some people here do not get is that good usability decisions are not made based on "I like this", "it looks nice", we have 10 participants in this debate vote for A and 5 for B so it will be A. If you do an A/B test with 10k users, and 7k like B better, then you can make a point about B despite all conclusions from before pointing to A. Lacking such data, as we do here, we're down to logic & reasoning.
Good usability is done by people who have lots of experience analyzing a use case and devising an interface considering all constraints. In this debate I often see people making points from their pov. This is useless (pun intended). ;) Forget what you like and try to solely think: Who is the average user? What do they want to do? Will this help them do it or make it harder?
You do not copy other apps because you don't want to innovate. You copy them because messaging apps are not new. There is only so much you can do in terms of innovative UX without punching average users in the face, who have learned certain UX paradigms that all other apps use, to convey certain concepts.
When you do something new, you must never force people to learn something new if you can use a paradigm that is used in another app, which matches your target audience but has several orders of magnitude more users. E.g. WhatsApp, KakaoTalk or FB messenger. This is a design principle for startups that want to attack an existing market.
Do you know why Gimp is hated by Photoshop users? Because everything I learned in PS, menu naming, filter naming, keyboard shortcuts, UI element positions, is different. For no reason other than to be different. There is zero innovation in this.
merkste
commented
10 years ago @lindworm
I like the idea, but have one concern: This would blow up the message bubble for short messages like "ok" tremendously, which would then make it look like the additional information is more important than the context.
So how about using an ellipsis (if the message body is too short)?
| Ok | Ok | |
|---|---|---|
| ... Push [] | > | 11:04 Push [] |
@virtualritz: I absolutely agree that the goal must be perfect usability instead of a fancy/new design. But the main question remains: How do we get empirical evidence supporting the design choices? Its not obvious that, e.g., a full colored bubble is the best compromise. For instance, I belong to the group of people (of unkown size) that get confused and distracted by too many and too vivid colors in message threads.
generalmanager
commented
10 years ago @virtualritz
If it doesn't improve UX, you have to ask yourself: why do it? And: does it degrade UX. Horizontal bars: yes (can't be seen when the bubble is partly visible and at the top of the screen). Vertical bars: yes (harder to spot/see than a fully colored bubble).
Alright, what if the body is slightly colored and has one of the bars? That'd eliminate the problems you mentioned and wouldn't look like a simple rip-off of other messengers. I don't want to change things just to make TS look different, if it negatively affects UX but if there are two shades of the same color that shouldn't cause any confusion. It also means the message background color can be lighter than if we only had the fully colored messages, further improving contrast between message background and text.
Also: What do you think about grey/white (neutral) for unencrypted and green for encrypted, as @merkste proposed?
@merkste Take a look at my examples above, all of them do that, exept for the transport text ;-)
bungabunga
commented
10 years ago very well written, Moritz Moeller!
0xACE
commented
10 years ago Sorry I couldn't respond earlier.
@phenx-de:
Why is the transport the message was sent with of such an importance to you?
It's not that important to me. I intend to use the app even if it gets this change, though I still may not agree with it.
If that happens once in a while in extreme lightning situations or in horizontal mode... then what?
obscuring/making it harder to see the information doesn't sound like a sound like a good solution. Sure you can ignore the extreme lightning situation/partly concealed screen even tough some parts of the world have sunny weather conditions all year. The rendered examples that I've seen seems to be on phones with greater resolution or at least big screen surfaces. Imagine how it is for someone with a small cellphone screen, imagine them walking and reading the screen. Small things are hard to see.
And the stripes are way more colorful than the unicolored bubbles could ever be, if we want them to have good contrast with the icons and dates.
Sure not having text over over the coloured area introduces the possibility for greater scale of saturation. However it's still possible to create more contrast for the dates/icons or even the text if need be.
The thing with the full coloured box is that you can identify it from long range, it's clear and obvious. Think about it, everyone doesn't have the same phone as you, some have these super small screens. People have broken cellphone screens. That small stripe is introducing more potential problems than it is solving, you're making a detail harder to see. Another note worth mentioning is that you are OKing this on while sitting perfectly still with a proper screen, imagine people walking, it will be harder to identify these things. How does these stripes work in the worst case scenario vs full coloured boxes? Don't play with the interface because you think the stripes look cute, see that it is functional too. A 4 year old could shake my screen violently and I would be able to identify [from distance] if my message is the last message in the conversation when the message box is unicoloured, doubt I could do that with the stripes.
Imagine if road signs wouldn't have coloured backgrounds and instead just have a stripe above the sign, it would increase the difficulty. Re-routed roads today (at least in my country) seem to have a bright orange/red background to indicate that there is some kind of maintenance and that you should read these signs instead, stripes would make it more difficult. Say we introduce error messages; you could put up a red message to indicate some kind of or error, it would stick out more than a red stripe (of course there are alternatives).
If you still argue that the date/icons are hard to see, have you experimented with having them shown beneath the message box? (just a proposal)
Overall the whole stripe idea only makes the coloured messages harder to utilize.
@lindworm
Alright, what if the body is slightly colored and has one of the bars?
Don't flood the user with information. The additional details you are adding are considered confusing. The information will be redundant, even if the proposal is better than the first one.
The thing regarding flooding user with details could be applied to the push for different coloured Contacts depending on how you verified them, I'd say you're complicating things for NOVICE users, it is off putting and scary to them. It'd be better off having it exclusively/explicitly show that you verified a contact manually and never show any indication of it in the other cases. Be careful with what you add to the screen. It is considered bad to flood the user with details.
I could probably start referring to user interface guidelines in the future instead of trying to argue, but I believe that the guidelines aren't always correct. In this case I don't see the appeal of the stripes at all.
liliakai
commented
10 years ago Hi everybody. Long time reader, first time poster here. First off, I gotta say that I've been blown away by this debate. Thank you all for your time and energy, your ideas, and your mockups! It has been amazing to see the community come together with such passion for improving the TextSecure UX.
Secondly, @virtualritz, I'm glad you brought up A/B testing. LET'S DO SOME. We've all got our own opinions but we're only so many people, and we may not be fully representative of the general population. We should get users to look at lots of variants and answer questions like "Which messages are secure?", "Which were sent via SMS and which were sent via PUSH?", "Is this a trusted contact?", etc...
I've been building out some of the style ideas you all have come up with over at sassmeister, trying to make it easy to experiment by swapping them in and out. Take it for a spin: http://sassmeister.com/gist/9341048. My hope is that these styles could eventually be used on a browser-extension or desktop client, but in the meantime I think it wouldn't be too hard to use them to whip up a lightweight testing framework.
The revolution will be A/B tested. -- Aaron Swartz
generalmanager
commented
10 years ago A new day a new mockup... I focused on signaling encrypted messages with green and nonencrypted ones with grey.
I used three differend message styles "toned down color", "light body and colored horizontal strip", "toned down colored body with colored horizontal strip."
Set 1: fully colored messages
__
Set 2: light grey messages, colored horizontal strip
__
Set 3: lightly colored messag body with colored horizontal strip
__
Also note that I indicated the transport both with text in the message bubbles as well as in the input box.
There's also the little grey badge with the green checkmark on top to indicate a verified contact as I proposed in #910. We can of course use any badge, I just didn't want to make several versions of everything.
For outgoing ones I could have removed it. But I guess you can imagine what a missing lock looks like ;-)
Personally I prefer the last combination. What do you think?
generalmanager
commented
10 years ago Both colored this time. I pretty much botched the other messages together, as you can see at the text not really black and in addition there are some cases where the locks of the contact are wrong. But we'll probably omit those, so it's no big deal.
Set 1: fully colored messages, right one is the same as above
__
Set 2: light grey messages, colored horizontal strip
__
Set 3: lightly colored messag body with colored horizontal strip
__
Note that the two grey striped ones are the same, because they were basically identical (only the sending...bubble was a little darker in one).
I prefer the last two ones and against my first feeling, I don't think that it's too much to color both.
sagischwarz
commented
10 years ago I'm not an UX expert and I admit that my argumentation might be quite subjective, but anyway: I think of locks as an indicator for security as far more intuitive. Why not just use a lock symbol and color it green if it's closed for encrypted messages and gray or red if it's opened and the messages are unencrypted? Because it is hard to see in some situations? Coloring the whole message will very prominently transport that information (if you have learned what the colors mean), but it also slams it right 'in your face' all the time. I think there is a reason why we print our books on white paper most of the time: it is far more relaxing for the eye having the black/white contrast. Also, I think coloring the lock icon relates the color directly to the security context, whereas using a colored bar at the top (or anywhere else) of the message has no intuitive relation to the lock icon or the encryption. Color should support other indicators, like the lock or the transport indicator, not replace them (also thinking of the colorblind people; that said, also the transport should be indicated by a (colored) symbol or text for the same reasons).
merkste
commented
10 years ago @lindworm: Thanks for the new mockups! Its good to actually see what we are talking about. =] As far as I can see, you've integrated ideas from discussions on the send icon #766 and the trust indicator #910.
But the most important point is that the message coloring, the verification indicator #910 and the send button #766 are consistent.
agrajaghh
commented
10 years ago I agree with sagischwarz, symbols are intuitive, everybody gets what an open or closed lock means. Please don't omit these. Colors are not intuitive, you have to teach the user what the colors means (and telling them, that encrypted messages are green one time at the first app start is definitly not enough).
All messages green (like in your set 1 or 3) is confusing I think, its hard to tell which messages are sent, and which are received. I really think there is a good reason why the big messengers (facebook, whatsapp, etc) use different colors for sent and received messages...
I really like the "Send an encrypted IM" and "Send an unencrypted SMS" in the textinput field, and the "PUSH" and "SMS" in the "Not Sent!" messages, this is intuitive!
merkste
commented
10 years ago Btw, I'd change the text from 'send an encrypted IM' to 'send an encrypted message'. I doubt that everybody knows what IM stands for.
@agrajaghh
I agree with sagischwarz, symbols are intuitive, everybody gets what an open or closed lock means. Please don't omit these.
I totally agree. The lock symbol can't be mistaken.
Colors are not intuitive, you have to teach the user what the colors means ...
True. An important question in this thread is what the colors should stand for. Should they tell the channel (SMS, ...), the trust level or encryption? What do you think?
virtualritz
commented
10 years ago I am all for fully colored messages. As they are now. Which means: only from the sender. No other messaging app colors the messages of the receiver! For a reason. @lindworm: please try to understand this reason before you throw away the UX scheme it led to.
The coloring in messaging apps originally (and this still applies to most apps) is a UX scheme to make it instantly obvious which messages belong to the sender (color) and which belonged to the receiver(s) (absence of color). We can not break this scheme; it has become a de facto standard among messaging apps.
Even if we add another layer of information. TS already does this, by using distinct colors for push & SMS (or encrypted/unentcrypted). But it only ever applies them to the sender's messages.
I repeat. Please try to understand a UX scheme 1st, before you break it!
Horizontal color bars: please, no! For these reasons:
All the stuff I just wrote feels like repeating myself. Please re-read my previous reply about making changes for the sake of change/design/cuteness/cool looks rather than fox UX reasons.
The new mock-ups from make it seem like I wrote all this stuff in vain.
@liliakai re. A/B testing. That would be great! But I fear that TS currently doesn't have the dev resources to tackle this. There are so many issues where plain polishing is needed before true feature requests, such as this ticket here, will be addressed. I wish I had some spare time myself that I could contribute to this.
agrajaghh
commented
10 years ago I totally agree with virtualritz, sent and received messages should not have the same color. Especially with long messages, its otherwise really hard to distinguish...
eikowagenknecht
commented
10 years ago @virtualritz Thank you for so patiently repeating yourself.
I guess the basic misunderstanding here is the "design versus UX experience" topic.
While from a design perspective (being more of a designer that a UX guy) I still really like the bars as shown in my mockups in the first post and in @lindworm's numerous mockups, you got me convinced that it might not be good from a UX point of view.
So I agree with you now on those points:
For pictures, I like the style in @lindworm 's set no. 1 here: https://github.com/WhisperSystems/TextSecure/issues/945#issuecomment-36705307 (regarding the actual message area, top bar and text input / paper plane are discussed in other issues)
Off topic, but since you seem very experienced with HCI/UX and I would like to know more about this topic: Can you point me to any good books / resources to start with?
bungabunga
commented
10 years ago @phenx-de: if the colors show encryption status instead of transport, then the receiver's uncoloured bubbles suggest that their messages are unencrypted. which again leads to confusion. (that's not the same as with transport, because only sender's transport info is really important)
so, i agree with @virtualritz, things are good the way they are now.
eikowagenknecht
commented
10 years ago @bungabunga : I think you misunderstood @virtualritz , he does not think things are good the way they are now, see for example his post here for a well written explanation: https://github.com/WhisperSystems/TextSecure/issues/945#issuecomment-36509731
generalmanager
commented
10 years ago @merkste
@lindworm: Thanks for the new mockups! Its good to actually see what we are talking about. =]
You're welcome!
As far as I can see, you've integrated ideas from discussions on the send icon #766 and the trust indicator #910.
Yes, I wanted to see how everything can work together. I didn't safe all possible combinations as .jpgs tough. If you want to see a particular combination, just tell me.
And I like the small text telling the channel (PUSH/SMS/MMS). It is easy to understand and not too prominent to distract from the message itself.
Yes, me too.
Is there a particular reason why you omit a) the padlock on the messages being sent and b) the channel indicator on sent messages?
a) I somehow thought, that there may be cases where the encryption status would be unclear. But that's obviously nonsense. The thing is that the color already indicates encryption, so using the locks is not necessary anymore. b) Should have done that!
Just to avoid a misunderstanding here since we discussed several variants: The green color means 'verified contact', correct? (How) Would you color encrypted messages to unverified contacts? Light green?
For this mockup I did not use color to indicate trust. @virtualritz made some very good points about why that is a bad idea and I agree. The trust information is supposed to be conveyed by the smell grey/green checkmark icon in the top bar next to the lock.
Maybe others might be confused by this but after I've seen the mockups, I think letting input's default text telling the transport is indeed a good idea and makes it clear what will happen. Actually, I would go with a non-colored send button then.
I really like the default input texts too! Subtle and a reminder of the meaning (which was explained on first use). We should keep in mind that the send button indicates if the next message will be encrypted, while the message colors indicate if these specific messages have been sent encrypted. Most of the time it's the same but if the other accidentally or purposely ends the secure session you need to have an indicator if what you are typing will be encrypted.
But the most important point is that the message coloring, the verification indicator #910 and the send button #766 are consistent.
I agree!
I'm blown away by all the comments and will answer them all, but I don't want to make too many of these incredibly long posts where nobody can find anything again. So I'll make another post for the comments after @merkste's
bungabunga
commented
10 years ago @phenx-de: you're right, thanks. but despite this my first remark is still valid: colors showing encryption status only lead to confusion.
i have nothing against one and only sender's color as @virtualritz proposed although two colors don't bother me at all (i got used).
virtualritz
commented
10 years ago @phenx-de understood me correct.
To repeat: I do think color should communicate transport encryption. I do think blue and green are good colors. So this is not a big change from how TS looks at the moment, but a pretty sever change in how a concept is expressed (mainly color vs currently icon and vice versa).
Green for encrypted, blue for unencrypted. If we limit ourselves to the default color palette for Android for now (https://developer.android.com/design/style/color.html), then we do not have too many choices. On that note: please read the last sentence of the 1st paragraph carefully. It repeats a point I made about color blind users which we must consider.
I think green for encrypted is pretty much a given. For unencrypted there are blue, purple and yellow.
I would not suggest to use red or orange for unencrypted because these colors have confusing associations and because it would mean color vision impaired people can't possibly distinguish the two message types any more (assuming the other color was green).
To make things obvious and ensure we do not ever penalize or endanger color vision impaired users, I suggest keeping the lock icon on the message bubble still, if it is encrypted, and adding an unlock icon if it isn't.
But these icons would be a darker (light theme) or lighter (dark theme) shade of the message bubble color itself to enforce the meaning of color equals encryption status more. It would also mean they convey the message without standing out as much as they do now. This coloring approach is already successfully used for the timestamp (or status messages as delivery failure etc) displayed at the left of the lock icon, at the message bubble bottom, in the current TS version. There is enough space at the bottom line of each message to display the abbreviated timestamp, the transport layer (SMS or push) and the encryption status (locked/unlocked). These can all have the lighter/darker color shade of the actual message bubble's bg.
merkste
commented
10 years ago @lindworm: Although the padlock is not needed anymore, I'd not omit it since it somehow explains the colors and can be understood by colorblind people as well. Regarding trust, I see your and @virtualritz point. Convinced.
@virtualritz: How about the following variant of your proposal:
Where I'd choose grey or maybe blue for the second color since they are relatively neutral.
Edit:
Green for encrypted, blue for unencrypted.
Ok, you've been faster. =)
But these icons would be a darker (light theme) or lighter (dark theme) shade of the message bubble color itself to enforce the meaning of color equals encryption status more.
Good point!
bungabunga
commented
10 years ago @virtualritz: while i agree totally with you about sender (coloured) and receiver (uncoloured) logic, i find marking encryption status with colors problematic. as i said before: if the colors show encryption status instead of transport method, then the receiver's uncoloured bubbles suggest that their messages are unencrypted. which again leads to confusion. (that's not the same as with transport method, because only sender's transport method really matters)
so it's more a question of: a. having only one sender's color (no confusion at all) or b. having two sender's colors for different transport methods (slightly more confusing)
agrajaghh
commented
10 years ago @merkste
- Encrypted (push) (green + closed padlock + 'PUSH')
- Encrypted (SMS/MMS) (green + closed padlock + 'SMS' or 'MMS')
- Unencrypted (SMS/MMS) (other color + open padlock + 'SMS' or 'MMS')
Where I'd choose grey or maybe blue for the second color since they are relatively neutral.
I think, thats the best solution!
Regarding the transport method vs encryption: I think the transport method of past messages doesn't matter that much to the users. They are already sent... Its much more important how the next message will be sent. So they can know if they have to pay or not (sending SMS to another country is quite expensive...)
Natanji
commented
10 years ago Just want to throw in that recipient's transport method does matter for some people, and we might want to add at lwast an option that colors received messages as well, or at least lightly tints them in the transport color.
Some people pay for each incoming SMS/MMS, especially when roaming in a foreign country. A recipient of such a costly message might want to notice this, e.g. to tell the sender to switch to push messages instead.
I also disagree that it becomes in any way hard to tell who the messages belonged to. The user can see this by checking if the bubble is aligned with the left or the right side of the screen; AND the user surely k ows which messages she sent herself, no?
On 5. März 2014 14:10:46 MEZ, bungabunga notifications@github.com wrote:
@virtualritz: while i agree totally with you about sender (coloured) and receiver (uncoloured) logic, i find marking transport encryption with colors problematic. as i said before: if the colors show encryption status instead of transport method, then the receiver's uncoloured bubbles suggest that their messages are unencrypted. which again leads to confusion. (that's not the same as with transport method, because only sender's transport method really matters)
so it's more a question of: a. having only one sender's color (no confusion at all) or b. having two sender's colors for different transport methods (slightly more confusing)
Reply to this email directly or view it on GitHub: https://github.com/WhisperSystems/TextSecure/issues/945#issuecomment-36740189
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
generalmanager
commented
10 years ago @agrajaghh
I agree with sagischwarz, symbols are intuitive, everybody gets what an open or closed lock means. Please don't omit these. Colors are not intuitive, you have to teach the user what the colors means (and telling them, that encrypted messages are green one time at the first app start is definitly not enough).
Yeah I think the lock doesn't take away too much space and a reminder what the colors mean is always nice. We also use the locks everywhere else, so omitting them, because we also use color might lead to confusion.
All messages green (like in your set 1 or 3) is confusing I think, its hard to tell which messages are sent, and which are received. I really think there is a good reason why the big messengers (facebook, whatsapp, etc) use different colors for sent and received messages...
Indeed, I think it's not that bad if you are just chatting, but when you are searching your history for something, that's really straining.
@merkste
Btw, I'd change the text from 'send an encrypted IM' to 'send an encrypted message'. I doubt that everybody knows what IM stands for.
I wanted something that was short and had a clear distinction from SMS. Message could very well mean SMS for many people, but we should get more opinions in on this one. English is also not my native tongue, so the distinction in everyday use may be clear to a native speaker.
@merkste
An important question in this thread is what the colors should stand for. Should they tell the channel (SMS, ...), the trust level or encryption? What do you think?
First I preferred it to indicate transport, but absolutely everybody I showed the app intuitively thought the green messages were encrypted, not SMS. That's why I'm now convinced that we should indicate encryption with the colors.
@virtualritz' 1st post
I am all for fully colored messages. As they are now. Which means: only from the sender. No other messaging app colors the messages of the receiver! For a reason. @lindworm: please try to understand this reason before you throw away the UX scheme it led to.
I am not trying to throw away anything ;-) You are right, it's confusing if you search for old messages and scroll through many messages quickly and it's also too much colored space. I really botched the fully colored ones, because I wanted to actually see it, before kicking it to the curb. But I didn't want to put a lot of effort into it, when it would probably not look great anyway. My "I prefer this or that" comments were only meant to apply for the examples in each post.
Horizontal color bars: please, no! For these reasons [...] All the stuff I just wrote feels like repeating myself. Please re-read my previous reply about making changes for the sake of change/design/cuteness/cool looks rather than fox UX reasons. The new mock-ups from make it seem like I wrote all this stuff in vain.
I'm so sorry man, you sound frustrated. I didn't do the mockups with the bars with spiteful intent, actively ignoring your posts at all. I read every one of them carefully. All the points you make are valid. I just wanted to see the bars in action next to the other possibilities, before killing them off for UX reasons. Something about seeing them one last time I guess ;-) I still think they might be used as an alternative theme (the dark version does look nice...), but not the default one.
@phenx-de I wholehearteldly agree with everything you wrote. I'm doing webdesign myself and in the beginning it was hard to accept @virtualritz's points for the "uglier" (not as interesting looking) solution, but his arguments are valid and we should not confuse the user with fancy designs.
@bungabunga
if the colors show encryption status instead of transport, then the receiver's uncoloured bubbles suggest that their messages are unencrypted. which again leads to confusion. (that's not the same as with transport, because only sender's transport info is really important
This is a collision in meaning (unencrypted messages grey and received messages grey), but I feel like the locks make it rather clear that they all were in fact encrypted. I also want to know if somebodies message comes via sms when I'm roaming (not uncommon in Europe with many people living near the borders and commuting to another country). It also gives an idea if your own push messages will be received quickly or only after the other is connencted to the internet again.
@virtualritz 2nd post
To repeat: I do think color should communicate transport encryption. I do think blue and green are good colors. Green for encrypted, blue for unencrypted.
Alright, I didn't catch that. I only saw the proposal for grey/green and instantly liked it.
I think green for encrypted is pretty much a given. For unencrypted there are blue, purple and yellow.
I agree on the green. But why do you think a light grey is no alternative? Because of the collision with the other messages? We could use two shades of grey to make that distinction clear.
I would not suggest to use red or orange for unencrypted because these colors have confusing associations and because it would mean color vision impaired people can't possibly distinguish the two message types any more (assuming the other color was green).
Yes, orange and red are too "in your face" and the color impaired people would have a hard time too. No reason to punish people with a disability or people who just want to write SMS.
I am also all for the locks in the message bubbles - should have thought about vision impaired people more.
There is enough space at the bottom line of each message to display the abbreviated timestamp, the transport layer (SMS or push) and the encryption status (locked/unlocked). These can all have the lighter/darker color shade of the actual message bubble's bg.
I agree, not sure about the lighter shade of the bubble color instead of a shade of grey, but that's minor stuff. What's your take on indicating transport with text in the messages instead of icons?
@merkste
Although the padlock is not needed anymore, I'd not omit it since it somehow explains the colors and can be understood by colorblind people as well.
As I wrote before, I'm convinced of that too now for exactly those reasons.
Encrypted (push) (green + padlock + 'PUSH') Encrypted (SMS/MMS) (green + padlock + 'SMS' or 'MMS') Unencrypted (SMS/MMS) (other color + open padlock + 'SMS' or 'MMS') Where I'd choose grey or maybe blue for the second color since they are relatively neutral.
I like it! just not yet sure if we should use grey (collides with incoming messages, may need two shades) or blue (no collisions, but confusion abound for all current TS users, because we change the meaning, but no new colors actually show that we changed something. We'd have to very carefully make everybody aware who already learned blue==data, green==sms).
Natanji
commented
10 years ago Just want to throw in that recipient's transport method does matter for some people, and we might want to add an option that colors received messages as well.
Some people pay for incoming SMS/MMS,1
On 5. März 2014 14:10:46 MEZ, bungabunga notifications@github.com wrote:
@virtualritz: while i agree totally with you about sender (coloured) and receiver (uncoloured) logic, i find marking transport encryption with colors problematic. as i said before: if the colors show encryption status instead of transport method, then the receiver's uncoloured bubbles suggest that their messages are unencrypted. which again leads to confusion. (that's not the same as with transport method, because only sender's transport method really matters)
so it's more a question of: a. having only one sender's color (no confusion at all) or b. having two sender's colors for different transport methods (slightly more confusing)
Reply to this email directly or view it on GitHub: https://github.com/WhisperSystems/TextSecure/issues/945#issuecomment-36740189
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
agrajaghh
commented
10 years ago Ah, I didn't know you have to pay in some countries for incoming SMS. I'm living in germany and never had to pay for incoming sms while roaming in europe. And I think thats regulated in the whole EU. Where do you have to pay for incoming SMS?
OT: Its a rip-off, you cant control who is sending you sms. You can choose not to answer an incoming call, thats why I accept roaming costs for that.
eikowagenknecht
commented
10 years ago @agrajaghh The way I understand it, it's mostly US and Canadian providers who do this. And even without roaming!
(i.e. http://www.ask.com/answers/462131/does-at&t-charge-for-incoming-sms-messages or http://www.iphoneincanada.ca/carriers/rogers/rogers-to-charge-for-incoming-text-messages/)
And yes, it's a total rip-off.
0xACE
commented
10 years ago Please drop the stripes, they've been slammed so hard that they are currently considered to be zombies.
virtualritz and I have previously in this thread stated why it's bad, virtualritz even repeated himself.
We haven't even covered EVERY flaw with the stripes, there are more problems with it than we have listed. I can't even determine the length of a message with the stripes, this is something I didn't mention earlier and there are more things to say. I think my example regarding a 4 year old shaking the phone reveals a issue with the stripes, the example points out that a user can extract information from the screen in severly limited situations, the current method relays this information without big side-effects.
Don't colour the receiver's messages with the same colour, you might as well hide who's who and just leave it as a long text document with messages in them, you could decode that information in reasonable speed vs sharing the same color scheme, the text document method has the benefit of not having the eyes jump around to look for the message box tip.
Don't even add that stripe to coloured messages, it's redundant overflow of information thrown at the user.
It feels like the idea has been shutdown, please try to see what's wrong with the idea. When I get ideas, I tend to shift side and try to have strong hatred towards my idea, to see what flaws it has. In this case I can't defend the stripes in realistic situation.
Don't blend the colours into the background too hard, you're obscuring "free" information.
People could misunderstand the word "PUSH" they could interpret it that the message failed and that you should push it to try to re-send it.
I believe the messages are fine today as they are. Overflow of information is considered to be malicious.
If you add the SMS/MMS/PUSH information why not add:
There is a lot of useless information you could put up there. Please keep it minimal.
I'd probably be able to live with the SMS/MMS/PUSH information, just consider the possibility that you're bloating the message boxes severly. Overflow of information is considered to be malicious. Information has to be interpreted, if you put stuff up there, the user will need more time to decode/understand/find what it's looking for, it gets complicated very quickly.
I'd like to [re-]mention that I still believe the message boxes are fine as it is now, using colours to indicate encryption is redundant as the padlock does this. You could argue against this, your case as it is now will not be much stronger than mine or if at all as far as I can tell. I'd say it's fine as it is now.
(sorry I wrote this message earlier but couldn't put it up, so here it comes later on... most of it has been resolved it seems like. I just disagree with colour coding depending on encryption)
Natanji
commented
10 years ago @0xACE, I think you are using very hyperbolic arguments there. People have explained in great detail why they feel that users should be able to tell the message transport, most notably for cost control. Your reply feels like you just ignore that, and do not propose any solution of your own. We obviously have no legitimate use case for Spongbob quotes, but we do have one for cost control. It would be easier to take you seriously if you didn't use such absurd examples to underline your opinion, while ignoring what others have written. Please reconsider your stance.
On 5. März 2014 15:56:39 MEZ, 0xACE notifications@github.com wrote:
Please drop the stripes, they've been slammed so hard that they are currently considered to be zombies.
virtualritz and I have previously in this thread stated why it's bad, virtualritz even repeated himself.
We haven't even covered EVERY flaw with the stripes, there are more problems with it than we have listed. I can't even determine the length of a message with the stripes, this is something I didn't mention earlier and there are more things to say. I think my example regarding a 4 year old shaking the phone reveals a issue with the stripes, the example points out that a user can extract information from the screen in severly limited situations, the current method relays this information without big side-effects.
Don't colour the receiver's messages with the same colour, you might as well hide who's who and just leave it as a long text document with messages in them, you could decode that information in reasonable speed vs sharing the same color scheme, the text document method has the benefit of not having the eyes jump around to look for the message box tip.
Don't even add that stripe to coloured messages, it's redundant overflow of information thrown at the user.
It feels like the idea has been shutdown, please try to see what's wrong with the idea. When I get ideas, I tend to shift side and try to have strong hatred towards my idea, to see what flaws it has. In this case I can't defend the stripes in realistic situation.
Don't blend the colours into the background too hard, you're obscuring "free" information.
People could misunderstand the word "PUSH" they could interpret it that the message failed and that you should push it to try to re-send it.
I believe the messages are fine today as they are. Overflow of information is considered to be malicious.
If you add the SMS/MMS/PUSH information why not add:
- How many characters there are in that message
- How long it took to send the information
- Which route the PUSH message took
- How many bytes were saved by compression
- How fast was the message transfered in Bytes/sec
- A SpongeBob SquarePants quote.
- etc...
There is a lot of useless information you could put up there. Please keep it minimal.
I'd probably be able to live with the SMS/MMS/PUSH information, just consider the possibility that you're bloating the message boxes severly. Overflow of information is considered to be malicious. Information has to be interpreted, if you put stuff up there, the user will need more time to decode/understand/find what it's looking for, it gets complicated very quickly.
I'd like to [re-]mention that I still believe the message boxes are fine as it is now, using colours to indicate encryption is redundant as the padlock does this. You could argue against this, your case as it is now will not be much stronger than mine or if at all as far as I can tell. I'd say it's fine as it is now.
(sorry I wrote this message earlier but couldn't put it up, so here it comes later on... most of it has been resolved it seems like. I just disagree with colour coding depending on encryption)
Reply to this email directly or view it on GitHub: https://github.com/WhisperSystems/TextSecure/issues/945#issuecomment-36749761
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
L3st3r
commented
10 years ago You have convinced me that we should use the colour green for encryption and then stating the transport channel via text or symbols. But I agree with @0xACE about the problems with the word "PUSH". Maybe we could use symbols instead in the message bubbles? For SMS/MMS we could show a symbol for a mobile phone and for PUSH maybe a symbol of the globe, which could be a realistic looking globe or an abstract one like this for example:
http://www.clker.com/cliparts/3/6/d/8/12201595301606109066biodegradable%20symbol.svg.hi.png
I also like the idea of @merkste:
Encrypted (push) (green + closed padlock + 'PUSH') Encrypted (SMS/MMS) (green + closed padlock + 'SMS' or 'MMS') Unencrypted (SMS/MMS) (other color + open padlock + 'SMS' or 'MMS')
As a second colour for unencrypted SMS/MMS I would use a darker shade of grey as @lindworm suggested.
merkste
commented
10 years ago I am not yet convinced that more icons make things clearer. But how about DATA instead of PUSH?
On 5. März 2014 17:51:10 MEZ, L3st3r notifications@github.com wrote:
You have convinced me that we should use the colour green for encryption and then stating the transport channel via text or symbols. But I agree with @0xACE about the problems with the word "PUSH". Maybe we could use symbols instead in the message bubbles? For SMS/MMS we could show a symbol for a mobile phone and for PUSH maybe a symbol of the globe, which could be a realistic looking globe or an abstract one like this for example:
http://www.clker.com/cliparts/3/6/d/8/12201595301606109066biodegradable%20symbol.svg.hi.png
I also like the idea of @merkste:
Encrypted (push) (green + closed padlock + 'PUSH') Encrypted (SMS/MMS) (green + closed padlock + 'SMS' or 'MMS') Unencrypted (SMS/MMS) (other color + open padlock + 'SMS' or 'MMS')
As a second colour for unencrypted SMS/MMS I would use a darker shade of grey as @lindworm suggested.
Reply to this email directly or view it on GitHub: https://github.com/WhisperSystems/TextSecure/issues/945#issuecomment-36764513
generalmanager
commented
10 years ago @merkste I also prefer DATA instead of PUSH, you probably have to explain every icon at least once, but with text it will be clear right away.
The icons in the message window are also not very big - that may be ok for a very simple shape like a lock, but the skeleton of the world could cause problems even for people with slightly bad eyesight.
PulsarFX
commented
10 years ago So, to sum up what we have until now:
regarding PUSH or DATA: maybe just pick up the wording from the settings dialog to make it easeier to recognize?
as for the transport type inside the input box: you can't tell for sure that a message will be send either way or the other. If data connection is lost and sms fallback is enabled, it will be sent as sms.
generalmanager
commented
10 years ago @maulwuff could you add the option of two different shades of grey for the unencrypted ones to your summary?
as for the transport type inside the input box: you can't tell for sure that a message will be send either way or the other. If data connection is lost and sms fallback is enabled, it will be sent as sms.
@mcginty said it should be possible to predict that rather well - TS could just check if the device has wifi or mobile data activated. If so, one ping/request to the GCM server could verify that it's actually working.
merkste
commented
10 years ago Or maybe even simpler: ping and timeout?
On 5. März 2014 19:04:09 MEZ, lindworm notifications@github.com wrote:
@maulwuff could you add the option of two different shades of grey for the unencrypted ones to your summary?
as for the transport type inside the input box: you can't tell for sure that a message will be send either way or the other. If data connection is lost and sms fallback is enabled, it will be sent as sms.
@mcginty said that it should be possible to predict that rather well - TS could just check if the device has wifi or mobile data activated. If so, one ping/request to the GCM server could verify that it's actually working.
Reply to this email directly or view it on GitHub: https://github.com/WhisperSystems/TextSecure/issues/945#issuecomment-36772987
0xACE
commented
10 years ago ==============BEGIN discussion with Natanji================ @Natanji
I think you are using very hyperbolic arguments there.
I got a feeling that would end up biting me in the ass... The thing is, I was trying to prove a point that you can put details there easily, but they don't always fit. Every piece of information you add is potentially like you're building another Where's Waldo puzzle, it's a bad user experience to add unncessary details. I was listing easy examples so that you would shoot them down before you let me introduce them, you only explicitly reacted towards SpongeBob though while in reality each listed subject is equally disturbing.
People have explained in great detail why they feel that users should be able to tell the message transport, most notably for cost control.
I agree, that's why I believe the current system works fine. Just afraid that these discussions will lead to people adding more details, further bloating the screen with details.
Your reply feels like you just ignore that, and do not propose any solution of your own.
Nope. I didn't ignore things, I just pointed out errors and tried to provide reasons to why it's bad. I'm contributing without necessarily providing direct details. I'm playing devil's advocate, no one else seems to doing it, it causes discussions and extracts details/corrections/flaws. I'm contributing. I'll provide my own suggestions when I've spent enough time getting an idea+optimized it+interested in it. Had no one questioned the stripes, they could've very well been implemented.
We obviously have no legitimate use case for Spongbob quotes, but we do have one for cost control
I agree. SpongeBob quotes along with the other listed examples don't belong there in this case imho.
It would be easier to take you seriously if you didn't use such absurd examples to underline your opinion,
The absurd comments made it obvious of how things can go wrong, I could probably make my point without it but the things I said were easier to put in text.
while ignoring what others have written. Please reconsider your stance.
I've tried my best to catch everything people write, I'm sorry if I missed something, it was never my intention, not even sure of what I missed. I'm reading these issues on the bus/gym/between classes/lunch, I try to get a good understanding before I answer, I'm trying my best, I still stand by my opinion. Regarding the stripes, I have strong belief that it's going to be a very bad idea to implement it, and I'll stand by that any day of the week. I still believe some users would like to have the stripes there but for the wrong reasons. virtualritz pointed out that people want custom themes, there are these people who use bright yellow background and white text with some weird typeface, someone integrating SpongeBob SquarePants into the background doesn't seem far off to me.
I never have the intention to insult anyone, don't misinterpret.
I believe in dark pattern designs as much as the good ones I'm flexible with that, in this case I believe that good ones fit better for the target audience.
==============END discussion with Natanji================
I also prefer DATA instead of PUSH
Yes, DATA would lead to less misunderstanding, at least to my understanding. Thought I'd consider using DATA/MMS/SMS as last resort, it requires more details to decode for the user.
@lindworm:
@mcginty said that it should be possible to predict that rather well - TS could just check if the device has wifi or mobile data activated. If so, one ping/request to the GCM server could verify that it's actually working.
I haven't fully understood the PUSH/DATA system yet. What happens if the receiver can't accept the message atm?
Regarding colour choices: Are you saying we should colour messages according to encryption along with a padlock icon and add a SMS/MMS/DATA indicator?
generalmanager
commented
10 years ago @0xACE
Yes, DATA would lead to less misunderstanding, at least to my understanding. Thought I'd consider using DATA/MMS/SMS as last resort, it requires more details to decode for the user.
I think we have come to the understanding that the message colors will indicate the encryption status. Thus, we need a new way to communicate the transport, because a second color for each message has also been ruled out. So we are left with either icons or text. And I think that text is easier to understand without explanation and also better to see at first glance because of the strict size restrictions we have to work with.
Regarding colour choices: Are you saying we should colour messages according to encryption along with a padlock icon and add a SMS/MMS/DATA indicator?
Yes, I feel like that's the consensus most of us have reached.
I haven't fully understood the PUSH/DATA system yet. What happens if the receiver can't accept the message atm? There's been much discussion about that and also workarounds here: #678 There are other tickets, most of them linked in #678 and some discussion on the mailing list.
The current situation is this: TS can't know if the receiver is offline at send time. Which means, that when the recipient isn't online, he will receive the message after he comes back online, maybe several hours later. All this time TS doesn't know if the message reached the recipient, so we can't do an SMS fallback in this case. But there are proposals of a solution, where TS automatically sends a delivery notification (!="message read") and if the sender doesn't get a response within x seconds an SMS will be sent, either automatically or after the sender confirms it.
0xACE
commented
10 years ago @lindworm
I think we have come to the understanding that the message colors will indicate the encryption status. Thus, we need a new way to communicate the transport, because a second color for each message has also been ruled out. [...] So we are left with either icons or text. And I think that text is easier to understand without explanation and also better to see at first glance because of the strict size restrictions we have to work with. Yes, I feel like that's the consensus most of us have reached.
Alright seems fair enough. I'd say text will let the user know better than icons because afaik I don't know of icons that describe SMS/MMS/DATA. I've seen a nice SMS icon in TS, if you enable SMS delivery report, you will see a small indicator for a delivered SMS but the meaning of that icon can also be confusing. If you find icons it would be nice if you propose them, but for now the SMS/MMS/DATA gets my vote.
TS can't know if the receiver is offline at send time. Which means, that when the recipient isn't online, he will receive the message after he comes back online, maybe several hours later. [...] All this time TS doesn't know if the message reached the recipient, so we can't do an SMS fallback in this case. But there are proposals of a solution, where TS automatically sends a delivery notification (!="message read") and if the sender doesn't get a response within x seconds an SMS will be sent, either automatically or after the sender confirms it.
Yeah, I feel like the delivery notification is very important, as you could potentially delay a message for hours, I feel like this should be a critical issue requiring immediate attention/high priority...
TL;DR:
Wikinaut
commented
10 years ago Is anyone already working on such a patch already? It should be done with some priority, in my view.
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:
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.
Everybody seems to like the toned down colors for sending, so at least we have one thing in common ;-)