[guardian-dev] Improving the UI/UX of ChatSecure

Chris Ballinger chrisballinger at gmail.com
Thu Jan 9 14:40:43 EST 2014


One of the issues we have to manage on iOS is that we are unable to run the
app in the background, which complicates asynchronous push messaging quite
a bit. We have been working on a
solution<https://github.com/ChatSecure/ChatSecure-Push-Server>that
allows people to use their existing IM accounts and networks by acting
as a layer on top, but it would only work with clients aware of this
functionality (e.g. ChatSecure <-->ChatSecure). The only other solution
will be to run a server that acts as a man-in-the-middle thin XMPP client
that forwards all messages to the actual client, but I think that
"solution" has far too many flaws from a security perspective.


On Thu, Jan 9, 2014 at 8:51 AM, Liron Tocker <lirontocker at gmail.com> wrote:

> Apologies, my previous mail was sent from a different account and I'm not
> certain it made it to the list. In case it did not, here it is again:
>
> -----------
>
> Most popular messaging systems at this point are moving away, if they
> haven't already, from displaying presence and I'd probably see ChatSecure
> moving in the same direction. That said, it'll be _really_ tricky from an
> interaction point of view, because OTR can only be initiated when both
> parties are "online" - and both parties are _aware_ of the fact that
> they're both online and connected to the system, in order to avoid
> confusion or frustration. We'd basically be leaving the user guessing, or
> end up sending messages like "are you available?". One way to solve this is
> to force OTR on all chats by default - I'd be interested to hear if you've
> considered this in the past. I can imagine how this would simplify things a
> lot for the user, since you'd only need to set up and verify a person once
> (not sure if this is a terrible idea, security wise - this means that if
> one party is unavailable or not connected to the service, an encrypted
> message will be to be held in some kind of limbo state until the other
> party connects).
>
> I'd love to do a hangout next week, that sounds like a great idea! I'd say
> everyone's invited who wants to listen in or has something they'd like to
> contribute (within reason, of course). I haven't started doing any sketches
> yet so now is a great time for me to get feedback from you guys and drink
> it all in :)
>
> I'm available after 19:30 on weekdays and 10:00-20:00 on weekends (GMT
> +1), my Hangouts ID is this google account, please feel free to add me. If
> you prefer to use Jitsi, please let me know and I'll set it up (I have an
> Ostel account).
>
> ---------
>
> And to Natanael:
>
> Thanks for the feedback - I think that's a very relevant use case.
> Ultimately, I think we need to try and figure out which is our largest and
> core use case(s) for ChatSecure is and try to make decisions regarding
> usability and functionality around that.
>
>
> On Thu, Jan 9, 2014 at 4:46 PM, William Gray <wgray at zetetic.net> wrote:
>
>> Hi Liron, Nathan,
>>
>> I love this kind of design work, though I'm still fairly new to it, so
>> it's really interesting to see you guys hash some of it out here on the
>> list. For instance, Nathan's discussion below about the different between
>> texting and chat, and how to handle that.
>>
>> Nathan I think you're dead on about dropping status altogether (e.g. you
>> are "online" when you are using the app). Seems to me like that paradigm of
>> as-fast-as-you-want-to-go makes the difference between text and chat
>> orientation for an app smaller. Both parties can chat in real-time, or they
>> can respond to messages later, and come back later for missed messages. And
>> people already use Messages and WhatsApp like that I imagine, as both text
>> and chat.
>>
>> Messages for OS X is an interesting little duck in that it supports
>> status and is basically an all-around IM client like Adium, and yet I get
>> to ignore status in that app completely when it comes to "iMessages" (which
>> is what I use it for mostly), and I usually don't even have it running. I
>> get an OS X notification when say my girlfriend messages me, I click it and
>> the app pulls up, we chat a bit, then I quit the app when I'm done. I get
>> some messages while I'm away, they're not missed, they're stored as
>> notifications just like on iOS. I think these newer hybrid chat/text apps
>> excel by keeping an always-on perspective with good support for missed
>> messages and notifications.
>>
>> Anyway, I'd really love to sit in on y'all's next design hangout if you
>> end up having one, but only to be a fly-on-the-wall. I think it'd be really
>> personally valuable to me to see how some of the sausage is getting made
>> and how you guys work around obstacles towards your goals. And ChatSecure
>> is really keen, so I'd love to get a sneak-peek at what's in the works :)
>> No worries if not!
>>
>> Cheers,
>> Billy
>>
>> On Jan 8, 2014, at 10:06 AM, Nathan of Guardian <
>> nathan at guardianproject.info> wrote:
>>
>>  On 01/06/2014 04:02 PM, Liron Tocker wrote:
>>
>> I’ve only been using ChatSecure for about a week so I’ve got some catching up to do, but perhaps my perspective as a new user might be valuable as well.
>>
>>  Yes, for sure. It is difficult to clear your head and see with new eyes,
>> when you are thick in the fog of code.
>>
>> Telegram are essentially following the same basic design patterns that most modern instant messaging systems use. The decision if ChatSecure should do the same boils down to the goal of the project and what it’s ultimately trying to accomplish. As far as I see it, If we want to introduce new users to encrypted messaging it’d be a good idea to create an interface with a minimal learning curve - which means: A) adhering to the UX a user would expect from an instant messenger and B) introducing unfamiliar interactions (such as verifying an OTR session) in a way which users can easily learn and keep in mind (sorry for this being totally vague, I can’t be more concrete before hacking at wireframes for a while).
>>
>>  Do you think there is a difference between a Mobile Messaging app
>> ("texting") and an Instant Messaging app ("chat")? When we began work on
>> Gibberbot/ChatSecure, they were quite different things. Until recenlty,
>> Google had two apps Messaging and Hangouts/Talk, now those have merged.
>>
>> I think there is a subtle difference between "I want to send a one off
>> text message" vs "i want to start a chat with someone I know is online".
>>
>> Also, another point to consider is that we expose the online/offline/away
>> status of users, while many of these new-style messaging apps completely
>> hide presence as an aspect. Sometimes, I feel like we should completely
>> hide it as well... just focus on whether the message was delivered or not,
>> and don't display any other on/offline connection or presence information.
>> However, then I get back to the core question - is "chat" different than
>> "messaging"?
>>
>> We also have the issue of having multiple accounts and identities, which
>> is an important one. Most of the messaging apps out there only allow one
>> identity, tied to your phone number or some other public identity. A key
>> differentiator of ChatSecure is the ability to have multiple identities
>> that you can easily switch between.
>>
>>  I think what I’d like to do would be to talk one-on-one with the iOS and Android devs to get a better understanding of what thoughts and ideas they have regarding the interface - I’d also like to hear your thoughts regarding the reasoning of some of the design decisions you’ve made. I’d then go ahead and start working on some paper sketches so I can form some more concrete ideas regarding specific improvement of user flows and layouts. I’d make sure to send you guys frequent updates - I’m a fan of releasing early and often :)
>>
>>  There are some nice online design sites where you can build interactive
>> mobile wireframes. Proto.io ( http://proto.io/) for example. We are also
>> happy with pictures of paper drawings.
>>
>> As for design decisions, I think we have already started down that road,
>> but I can also share some of the directions we want to go. In short, I do
>> want to move towards a more people and message centric system, where we do
>> a better job hiding all of the plumbing of accounts, buddy lists, etc, and
>> just focus on connecting to another person in a secure manner.
>>
>> We also have some exciting stuffing coming down the road in terms of data
>> sharing... moving beyond just photo and voice messaging, and supporting
>> more social apps features... so again, the tasks become "I want to securely
>> share a set of photos with these friends" instead of "i want to chat with
>> this person and attach a photo".
>>
>>  If you guys are okay with group voice chats, that’d be a great way for me to get feedback as well.
>>
>>  We use Google Hangouts for that mostly, at least for non-sensitive,
>> public discussions. We can also use our Ostel.co service with Jitsi to
>> do an encrypted conference call. Either way... maybe next week?
>>
>> +n
>>  _______________________________________________
>> Guardian-dev mailing list
>>
>> Post: Guardian-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>
>> To Unsubscribe
>>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>        Or visit:
>> https://lists.mayfirst.org/mailman/options/guardian-dev/wgray%40zetetic.net
>>
>> You are subscribed as: wgray at zetetic.net
>>
>>
>>
>> _______________________________________________
>> Guardian-dev mailing list
>>
>> Post: Guardian-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>
>> To Unsubscribe
>>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>         Or visit:
>> https://lists.mayfirst.org/mailman/options/guardian-dev/lirontocker%40gmail.com
>>
>> You are subscribed as: lirontocker at gmail.com
>>
>>
>
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit:
> https://lists.mayfirst.org/mailman/options/guardian-dev/chrisballinger%40gmail.com
>
> You are subscribed as: chrisballinger at gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20140109/4740ad4b/attachment-0001.html>


More information about the Guardian-dev mailing list