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 #741 and #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 (#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 ;-)

[liliakai]

Hey guys. I am all for using color to indicate encryption state, but I also see the value in preserving the existing associations of sms=green and push=blue, and going with a less-is-more approach to iconography or metadata text. I'd like to get your feedback on the following proposal, which combines some old ideas with some new ones.

Take a look at http://jsfiddle.net/8mQg7/6/embedded/result/.

With this design I had a few goals in mind,

• transport is indicated by color and the existing green/blue color convention is preserved
• blue is the color of security
• avoid being overly colorful
• think outside the bubble.

Additionally, I align with the philosophy that the user should not feel alarmed or punished for having unencrypted chats, since this is the normal mode of operation for many. Rather, the encrypted user should feel like that they are having an enhanced experience.

To that end, an encrypted conversation takes place on a sky blue background (In dark theme: midnight blue, though i suppose in android you'd just use different opacities?) I hope "getting" the blue color will feel rewarding to those who start encrypting their chats without being too demanding of attention. Plaintext conversations remain largely unchanged, on the existing neutral gray background. There's nothing wrong with plaintext. It's just "plain jane".

The use of the background color allows us to continue applying color to individual bubbles to indicate transport. It also visually underscores the fact that a conversation may take place across multiple transports, within a single encrypted context. Finally, it frees us from having to have a repetitive lock icon on every bubble.

Another new idea you'll notice is the 'Secure Session' header bar with a lock icon.

• Replaces the existing key-exchange visualization.
• Provides a visual break to help transition the eye from gray to blue.
• Educates the user on the meaning of the background color when it first appears,

For transport, I've diverged from the fully colored bubbles, which were a little too loud, and top-stripes which were still a bit distracting from the text, to just a touch of color on the bottom edge. In the existing UI, white bubbles have this bottom border detail in gray, making them more bubbly looking. My colored border doesn't give quite the same 3Dness, so I'd actually prefer if it had a bit of a gradient or maybe slightly less luminous shades of green and blue. (To Do...)

As mentioned above, SMS continues to be represented by green. Think money. Push messages continue to be represented by blue. Note that this is consistent with the rule that blue connotes security since push messages are always encrypted.

Feel free to tweak via js fiddle or sassmesiter (recommended) http://sassmeister.com/gist/9341048 http://jsfiddle.net/8mQg7/6/

[generalmanager]

@liliakai First: thanks for adding to this discussion and putting your work into this.

But I see a lot of problems in the design, that we have already discussed in this thread and because of those we have eliminated a lot of ideas.

• One color can not represent two things, this leads to huge confusion all around!
• The secure color has to be green! The problem that a lot of people think, green messages are encrypted and blue ones insecure, was one of the main reasons we started this thread. Green lights are just one of the many reasons why the color is strongly associated with security.
• The bars on the bottom fix the "scrolling out" problem, but now they are ground-heavy and really distract from the text, because everybody first looks at the bottom of the bubble and has to switch back to the top left to start reading the text.
• The whole messages should be distinctively unicolored, to make searching through large amounts of messages easy and the sender recognizable at first glance.

As mentioned above, SMS continues to be represented by green. Think money.

There are 7.2 billion people in this world, of which only the 4% US-Americans have any kind of association between green and money. And even with them the security association is probably a lot stronger, not to speak about the other 6.9 billion people.

Another new idea you'll notice is the 'Secure Session' header bar with a lock icon.

I think that's a good way to visualize the idea of a "secure session", but for the reasons mentioned above I wouldn't color the background blue.

I'll make a mockup of the consensus that seems to have been reached before.

[generalmanager]

I made two mockups, both conform with the summaries of the consensus we have reached (list copied from @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 for the "other color" we have the suggestions of blue and a second shade of grey. It was suggested that we replace the word IM with data message and the word push in the message bubbles with data, I however forgot to include both changes. The upper bubble is also missing the "DATA" text. But I think the concept should become clear:

Grey unencrypted / green encrypted:

__

Blue unencrypted / green encrypted:

__

The color of the meta information in the grey example would of course have to be changed for better contrast.

[ArthurusDent]

Generally speaking I think messaging colours should not indicate security.

1. It is incompatible with customization. Something the discussion has somehow dropped.
2. If we implement a traffic light system to indicate the security of a contact, we are free to use whichever colours we choose. If somebody only has the one red dot, it's quite obvious that the conversation is insecure. Lock-symbols could be added if we wanted to emphasise this even more. There is one thing with the traffic light systems that needs to be considered, though. If colours don't indicate security, messages shouldn't be green as default because this could introduce some confusion with the three green dots. A two dot yellow contact would also get green bubbles and this doesn't seem right. The traffic light system seems far more intuitive and if we implement it, we should probably use different colours (i.e. no green) in the default settings for the bubbles.

[agrajaghh]

@lindworm I like this! I did another version with the light gray always for the received messages (more consistent). I also added the DATA and SMS:

Grey unencrypted / green encrypted:

.

Blue unencrypted / green encrypted: .

[generalmanager]

@agrajaghh looks great! You are right, the one where the grey shades are swapped looks much better. It's important to have the incoming messages (which you actually read) with the higher contrast between text and background.

[hunleyd]

I was asked to 'move' my comment from #908 to here. So here it is: https://github.com/WhisperSystems/TextSecure/issues/908#issuecomment-36672286

fwiw, in looking at this thread, I much prefer set 2 from https://github.com/WhisperSystems/TextSecure/issues/945#issuecomment-36710815 as I personally can't stand coloring the entire bubble.

[Anaron]

@liliakai I agree wholeheartedly. I always felt that green should be the colour for SMS, especially because Apple made that colour synonymous with text messaging. That way, the UI will be consistent regardless of the OS (Android & iOS). I really like the coloured stripe on the bottom of the chat bubble. That's normally a grey colour so it's good that you're making use of something that's already there. The use of the background to show whether the session is encrypted or not is perfect. It allows you to set other colours to further differentiate the kind of encryption (e.g. SMS or push).

[Wikinaut]

Additional argument why green is the colour for secure:

you already use green (the very small green bar at the left side) in the list of contacts (when you select the recipient) for contacts where a key is locally available.

[Wikinaut]

if you say above that blue stands for secure, then you must also change green=> blue in the list of contacts.

[Wikinaut]

Why has nobody proposed to make the bar colour (list of secure contacts), background colour (messages) and font sizes (message text) user-configurable ?

[eikowagenknecht]

I think someone did in fact already mention to make everything user configurable. But the first step will have to be a good default value since most users won't change it.

[ArthurusDent]

I already said this over in #910 and in this issue a few posts before this one: I don't think that the colour of a message bubble should indicate encryption because once somebody implements customization of colours, the colour that represents security becomes arbitrary. People will have to configure two colours and remember which one means encryption and which one doesn't. There is the possibility of forgetting which means which or even mixing them up. I would like to remind everybody that the lock symbol on every encrypted message already indicates encryption. So the concept of colours of message bubbles indicating encryption already is redundant. The problem I see with the locks in message bubbles right now is that they are tiny and don't get bigger if you increase text size. Not very friendly for people who are visually impaired. But of course you still have that lock button at the top of your screen so you can still check.

We certainly don't even have to use two different colours for transportation because "SMS" and "Push" could also be written next to the lock or the time so everybody sees which means of transportation was used. People who have SMS included in their plan probably don't care if TS sends them and people who don't want TS to send SMS probably have disabled SMS or will be asked. I don't think this option already is in TS, but it has been discussed and some form of it will be in future TS so people might care less about the distinction between SMS and Push and therefore there is less need for different colours.

There is a second problem I have with the recent UI discussions. We have three spots in TS that are closely related to each other and therefore should get a visual style that is consistend: contact list, messaging history, messaging window. Either I haven't found the issue yet, or there are indeed no mockups of a new design of the contact list that is coherent with the designs of the new message window and the new messaging history.

[agrajaghh]

I think we don't have to worry about customization. The majority of the users will never change these colors. And the users who change the colors know what they do. Its our job to create a good default UI...

Regarding the contact list and other parts of TS, you are right. There should be one concept for all of them...

[PulsarFX]

anyone able to code this down? @generalmanager/lindworm?

[mreppen]

@agrajaghh

The majority of the users will never change these colors.

What is this claim based on? I can only speak for myself, but all non-technical users whom I have shown the app have at some point asked about some sort of customization.

[tinloaf]

@maulwuff Code what down? I see no consensus here so far?

[PulsarFX]

We have summed up what most people have agreed on some days ago. This discussion will go on like this forever.

[agrajaghh]

I think we need a decision made by @mcginty or @moxie0 ...

[mcginty]

@virtualritz your comments should be turned into a manifesto for UX, loved it.

@lindworm, @agrajaghh, and @generalmanager really appreciate you guys taking the time to make all these mockups and iterate so quickly on all the proposals here. We've been so busy since launch that this really helps productivity.

Here's where I am at with this discussion:

Colors

I prefer solid, and I still honestly prefer the darker color for outgoing and white for incoming scheme to be honest. While I understand the arguments made for lighter background colors, they're just not pleasing to look at for me.

Since we've exhausted all proposals for non-solid chat backgrounds, perhaps we should at least limit this to what type of solid background is preferable. All the effort on trying different combinations were not wasted - it was great to see if it was feasible - I just don't see it resulting in a more usable conversation.

Iconography

Send button

This seems to be one of the more settled topics. We need a send icon that has a more easily understandable upright lock which indicates the security of the message-to-be-sent. It shall also indicate, probably through color, the expected color of the message bubble once it's sent (remember, this is not promised, just a guess).

Message bubbles

I think if there's anything we should be redundant on, it's security indicators. Not excessively, but enough to inspire confidence and be obvious for those with various vision types. We should not get rid of the lock icon in my opinion, even if we end up using color as an indicator for that as well.

Adding a "DATA" or "SMS" or "MMS" to the metadata at the bottom seems to add a lot of clutter and is distracting to me. Maybe another icon is a cleaner solution, but I think with improved control over how and when TextSecure will send SMS/MMS (https://github.com/WhisperSystems/TextSecure/pull/984) this issue becomes less important since the reassurance is not as necessary.

[ArthurusDent]

I've just written a longer post about using Threema's traffic light system which would make us a bit more free when it comes to colours and symbols, while making the security system easier to understand. I don't know where this discussion should take place so here is the link to my comment: https://github.com/WhisperSystems/TextSecure/issues/910#issuecomment-37585407

[generalmanager]

@mcginty We really needed one of the project leaders to take a stance and make a decision, thanks for doing it so comprehensively.

If I understand you correctly you prefer @agrajaghh's latest mockup (it's also my favorite) with a few modifications: https://github.com/WhisperSystems/TextSecure/issues/945#issuecomment-37169657

• Either the current colors or at least more saturated / higher opacity than in the mockup
• I didn't see your stance on the debate if unencrypted outgoing messages should be grey or blue. (green/grey or green/blue for encrypted/unencrypted)
• The send button and locks basically as in the linked mockup (?). Do you want the open lock to be black or a toned down red?
• We should find good icons instead of the SMS/MMS/DATA text

If that's correct, I can send you the originals as vector files and in addition in the resolutions you need. Just tell me where to put the stuff and you'll have it.

If you don't have the time to do this, I might be able to create a pull request in the next one or two weeks, but I'd have to set the whole compilation environment up first. And my Android theming/coding experience is nonexistant, so I'd just change the color values in the source files I find, compile until it looks like intended in the VM. Regarding the icons: I currently have no idea where they are inserted. So the code would probably look really messy, because I'd just copy what I find for the other icons and go with it. Honestly I think you'd probably have more work cleaning up my mess than if I just sent you the icons and color values.

Let me know what you prefer.

[PulsarFX]

as "DATA" or "SMS" or "MMS" with an icon: Let's us the icons, the user is already used to: For SMS/MMS: For DATA: But I think, the arrows don't fit so much in an already sent message. Also, it doesn't fit, when sent via WiFi. But what about the icon of the app itself? TS stands for secure messages, so why don't just use it. Feels like a backronym to use it inside the app itself.

This leads me to a different approach with less icons:

• SMS is not the core functionality of TS. Therefore it will mark SMS messages with the sms-icon and/or Padlock (depends)
• PUSH only shows a Padlock.
• done.

[eikowagenknecht]

@generalmanager If you or @mcginty don't have time, I might be able to do this next week. I already had a look at the relevant part of the code for one of my former pull requests.

The exact details are still a bit unclear though (like you mentioned in your post) and I think we need a final decision before the implementation begins.

[generalmanager]

@maulwuff I like the data and sms icons are fine, but I don't like using the TS icon - that's just too confusing. Only using the SMS symbol might actually be the best solution, because it's only important to convey the information "this is beeing sent via SMS, you have to pay for it".

This might be a little inconsistent from a UX perspective (@virtualritz ?) but the better visibility (icon/no icon vs icon 1/icon 2) is worth it in my opinion.

@phenx-de That'd be great - I'm sure your pull request would look a lot better (codewise) than the mess I'd produce.

And I agree - the implemention should only begin, after the details are clear.

[virtualritz]

@maulwurf

SMS icon

I suggest to use a speech bubble that has ‘SMS’ written in it. This leaves no room for misinterpretation. A smiley face does. If in doubt, do a google image search for “SMS icon”. The same argument about learned UX concepts that I made numerous times throughout this thread applies.

On a side note, I also do not feel like smiling when sending SMS as it costs me money if the SMS is sent to someone with certain other providers, here in Europe. :P

Data Do we really need an icon here? This is the common case. Does it need emphasis through an icon?

Lock Let’s use the default Android lock icon. This follows Android HCI guidelines/best practices.

I have started doing vector graphics of all the icons we need (incl. the send icon) to resolve these but haven’t gotten to work on them in the last 10 days as I simply didn’t have enough spare time.

I will push them to a new repo. soon. People can then fork or branch this to add their own suggestions. I think we should try to convert all icons to vector graphics as a start.

I'm using Inkscape, all designs are snapped to a pixel grid that follows Android icon size guidelines.

I am new to Android dev. but I guess there may already be build tools in the NDK that turn SVGs into PNGs as part of an ant build?

I reckon we will maybe need two to three versions of each icon, hinted (snapped to) different pixel grids, so people with older phones, that do not have high PPI screens, will have sharp icons and people with very high res phones (current and next gen.) will see extra detail.

[generalmanager]

@virtualritz I agree with everything you said. I already have vector graphics of all the icons I used in my mockups. They are currently in the Adobe Indesign format, but afaik Inkscape can open those. There is also an Illustrator export script included in the Android Icon pack which resizes every layer and exports the icons in different sizes. The different dpi settings are explained here: https://developer.android.com/design/style/iconography.html

[merkste]

@mcginty @generalmanager @virtualritz Thanks a lot for your comprehensive comments!

Unfortunately, I am still not convinced that an icon would do better to indicate the channel. Especially, how do we intuitively distinguish between SMS and MMS? (Sending MMS makes me smile even less.) However, a speech bubble with the word SMS/MMS seems to be a sound compromise. And I like the idea not to show anything for DATA.

As a side note: Sending SMS is a core functionality of TS for me and most of my contacts. In fact, the argument that TS replaces their SMS app and offers instant benefits when texting with other TS users convinced them. Not too many people want to ditch their messenger in favor for TS, simply because they do not want to loose their contact list.

[agrajaghh]

Just displaying a sms bubble and not showing anything for data is a good idea I think. I just edited a mockup and put a little sms bubble in it:

The image has a width of 480px, and the SMS is already hard to read. There are smaller screens like that, no? So I don't know if this solution is feasible with the current icon size...

[virtualritz]

@agrajaghh: You made it hard.

Use the default Android speech bubble icon (the one with the smiley). This icon is a rectangular speech bubble with rounded corners, not an oval one.

This is a deliberate choice for UX reasons, not design. Specifically they choose that to have more space inside so the smiley face can become larger and is better to read on devices with little PPI or small screens. This is good design because it considers the constraints of the underlying use case.

The same approach applies to writing ‘SMS’ in there.

Chose a font with a letter width so that the width/height ratio of the word ‘SMS’ typeset at a generous letter spacing (needed for legibility at small sizes) matches the width/height ratio of the rectangular speech bubble.

I bet the letters will be 50% larger at least.

Last but not least: I would consider keeping the icon single color. I.e. instead of white make the text ‘SMS’ transparent so the bg color shows through.

If the contrast is not high enough to read the icon clearly, the whole contrast of the time stamp/lock icon/SMS icon should be adjusted until it is legible.

Aka: separate the problem of lacking contrast on the icon(s) vs their bg from the design of the icon(s). They’re separate issues and should be dealt with separately.

[agrajaghh]

@virtualritz You are right: its already better to read! I'm using Thamoa now. What font would you recommend?

Dont look at the send icon, its the wrong one..

[virtualritz]

Tahoma runs too wide. You also need more spacing between the letters so they don’t become a visual soup at this small size.

Unfortunately the Droid/Handset Sans Condensed is a commercial font from Ascender. But we’re only talking two letters here anyway. I'd try something like Open Sans Condensed Light 300.

https://www.google.com/fonts/specimen/Open+Sans+Condensed

In most fonts ‘M’ will be wider than ‘S’. For this reason, the text ‘MMS’ width/height ratio should match the bubble’s at the minimum letter spacing that is acceptable without hampering legibility. Space the ‘SMS’ text a bit larger to compensate for the width loss. This will look good and make the more common case (‘SMS’) even better legible. Aka: design the MMS case icon first, it is the more important case to determine the acceptable font and the required letter spacing. After that, do the SMS case with more increased spacing.

[agrajaghh]

Okay here with Open Sans Condensed Light and bigger letter spacing for SMS. But the width/height ratio is different from the bubble, but I dont think thats a problem...

[PulsarFX]

Wow, I can't read "SMS" on my Galaxy Nexus. Maybe we can leave out the "arrow" (dunno how to call it) at the bottom of the gray bubble? I think it's duplicated to the one at the right of the message bubble. Without it, I'd call it a badge (to stay with twitter bootstrap slang). Now you can make the badge and the font size bigger.

Another idea: take the padlock, turn it by 90°, enlarge the "body" and write SMS into it. Now we only have to but one symbol next to the time. Don't know if this still looks any good.

[virtualritz]

The font needs to be hinted to be legible at low PPI. That is precisely why I said we need a deliberate version of the icons for low PPI/res devices.

Hinting means that the font outline must be snapped to the pixel grid @ the resolution the icon will be rendered at on the target device. This is work that just needs to be done but not needed for us to see if the mockup can work.

[virtualritz]

-1 for the padlock w. SMS idea. This will be hard to understand/confusing and won't safe/bring back any screen space real estate we really need. The status line with the time stamp is there no matter what.

[agrajaghh]

You cant read it because its too small or not well scaled? I have no problem reading it on my N4. But for smaller screens its too small I think...

Combining the padlock and the SMS/MMS sounds like a good Idea beacuse we would save one icon, but it just looks terible:

Some other points against it:

• Not consistent with the other padlocks (received message, the big padlock in the bar on top)
• displaying the lying padlock open would be looking really weird...

[PulsarFX]

Ok, I already thought that it would look terrible. What about the badge idea anyway? There are still 2 of those bubble-anchors close next to each other.

edit: I mean a bootstrap style label, not badge. example: http://getbootstrap.com/2.3.2/components.html#labels-badges

[generalmanager]

Whatever we do with the sms/mms icons, I am strongly against the padlock + text idea. It combines features that should be kept separate and it's not like it's going to get us any more screen space.

@maulwuff I think if we do this, it should be easily recognizable as a message bubble, otherwise there is no point in making an icon, if we just scale down the text we used before and put it in a tiny grey box. It lowers visibility and doesn't help at all with recognizability (which is an icon's sole purpose).

[virtualritz]

I will work on this icon this weekend and make a properly hinted version. It will be legible at low PPI, I promise. :)

[PulsarFX]

@ legibility: I trust you that it's readable if it is not scaled down by the phones browser. ;) @ icon: I see no real difference between an icon with this little arrow, and an icon without that little arrow: It's still a little gray box with "SMS" rendered to a jpg or png. For both can be said: this is an icon - at least for me. The reason, I'd like to skip the arrow on the icon-bubble is, that it sits inside another bubble. That's "Blubberei" ;)

[merkste]

@virtualritz Could you please make a variant that is not filled but simply text with a speech bubble outline? Just to see how this would look like.

Well, if we remove the SMS/MMS bubble's arrow, we end up with a trivial icon: just the text at a smaller font with some border or background. That might be worse than text only.

[jeremymasters]

What about a lock that is locked or unlocked along with one letter symbolizing sms/mms/data? So: unencrypted sms = open lock with "S" beside it. encrypted sms = closed lock with "S" beside it. same for mms as above. data, while always encrypted, would be nice to see the closed lock still. encrypted data = closed lock with "D" beside it. You could even put the letter inside the lock part maybe...maybe.

[virtualritz]

@jeremymasters Please do this when suggesting UX changes/improvements:

Ask yourself these questions for the use case at hand:

1. What does the user want to do/what information needs to be conveyed to the user?
2. How is this done at the moment?
3. Read all posts in the resp. ticket carefully, they may cover your topic already.

Communicate this here:

4. Does this need improvement? Why? Resp. could this be improved? Should it?
5. Propose changes.
6. Make clear why the change/feature you are proposing really is a usability improvement.

You did 5. But 4. & 6. are absent from your post.

Specifically: why merge two icons which are standardized into one that isn't? How is a single letter obvious to mean 'SMS' or 'MMS'?

As for closed lock/open lock icon: this was already discussed.

[agrajaghh]

It's not intuitive, the user doesn't know what 'S', 'D', or 'M' means. Perhaps he think 'S' stands for secure...

[generalmanager]

I fully agree with @virtualritz and @agrajaghh. We get a lot of proposals that have already been discarded for various reasons, many of which have all been discussed in great detail.

The single letters are simply not intuitive. It works after the user understands it, but many will never read the help and will just uninstall TS if they sent more SMS/MMS than they intended to.

[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?