Here’s some initial design ideas for a location-aware chat app that, as far as I am aware, has significant new features over and above existing mobile chat apps (iMessage, WhatsApp, BBM etc.) and existing location-based functionality in apps (FourSquare, Facebook check-ins, Google Places).
The inspiration for this idea came, more or less, from the Nintendo DS “Pictochat”application. PictoChat allows up to 16 users to link their DS consoles over a peer-to-peer WiFi connection, and share doodled messages with each other in real time. Between a couple of DS-using friends, PictoChat is an interesting gimmick, but I first encountered it coming into its own at an anime (Japanese animation) convention called MinamiCon. Here, the concentration of DS users was so high that multiple 16-person PictoChat rooms came into existence, full of people chatting away with other convention-goers.
This was in 2005, before the now ever-present smartphone really came into its own. What about today? Achieving a critical density of DS users to make PictoChat useful is no longer an issue – a critical density of smartphone users exists at every event and every non-event in the Western world. What if we reimagined PictoChat for the smartphone?
There is one big change to the PictoChat concept that we need to make to have a viable idea – and one big addition.
- Text, not pictures. The DS’ stylus and resistive touchscreen were ideal for doodles, but not so much for text – though a keyboard was available. Modern smartphones have thumb-friendly capacitative screens, and anyone who’s tried to give textual clues in DrawSomething will tell you that writing text PictoChat-style is a non-starter. This new app needs to be text-based, with optional picture and video sharing, much like MMS.
- Catching up. The idea of “catching up” provided the app’s working title, and forms a secondary mode for the app. As well as real-time chat between people in close proximity, the app also attempts to solve the problem of “how do I keep in touch with people I did [activity x] with?”. Say, for example, that you are at a concert. Over the course of the event the app detects 20 people in your vicinity. You could chat with them live (though hopefully you paid to watch the band not stare at your phone…), but the app remembers who was there so you can also chat to them afterwards.
There are a number of technical issues that the app would have to address.
- Privacy. It must be easy for users to indicate that they don’t want to be interrupted by messages, and that they don’t want people to detect your presence and “catch up” with you later.
- Identification. Integration with Facebook would be desirable to allow users to find their friends on the service. However, the app is providing a semi-public mapping of people to locations, so CatchUp users should not be identifiable to people who are not their friends. Foursquare has struck a reasonable balance here.
- Connection technology. PictoChat used device-to-device WiFi. This is not ideal for CatchUp as it would prevent users from using their WiFi for other things. A low-power Bluetooth connection is a possibility which would also enforce the “chats must be local” idea. However, if we are going to enable “catch up” chats later, we need a server-side chat backend anyway, so it may be best to route everything through the server and determine user proximity for local chat groups on the server.
- Integration to other services. Integration with the Facebook, FourSquare or Google Places API could give users the ability to “check in” and use the chat facility together, increasing uptake. Integration with services like Last.fm could incorporate knowledge of event times and places, meaning that the “catch up” chats can have sensible names like “Justin Bieber Concert, Wembley Stadium, 1/1/2012” rather than “with 312 users at Wembley Stadium, 1/1/2012”.
Last.fm’s Events List
- Blocking. It must be easy for users to block and report abusive users, prevent them from finding out where the reporter is in future, etc.
I have produced a couple of user interface mockups for the potential design:
CatchUp Main Menu
The main menu of CatchUp presents a simple list of chat opportunities, in reverse chronological order.
At the top is the “Chat now” area. Pressing there takes you to the live chat for your location, as determined and managed by the CatchUp server. The tile shows where CatchUp thinks you are, and how many people you will be placed in a chat room with.
Below this is a list of all your “catch up” opportunities. If configured to do so, CatchUp monitors your location in the background. If you stay in a location with enough people for long enough (possibly without having to explicitly open a chat), a “catch up” for that event will be placed in the list. The user can press one of these to be taken to a chat room for everyone who was there. Users can remove the Catch Up from the app (and thus prevent being chatted with by other event attendees) with a swipe.
Settings will have fine-grained privacy options, for example to prevent the user appearing in others’ Catch Ups without explicit permission, to mark certain locations that Catch Up will automatically deactivate itself in, and so on.
CatchUp Chat Interface
Chatting in CatchUp is a simple affair. As locations may have many people chatting, iPhone-style bubbles are replaced with a more basic appearance – though images and videos can still be embedded.
No application is without its flaws. Here are some that CatchUp would have to address:
- User Critical Mass. Any social app is only as good as the number of people using it, particularly if the main use case is live chatting. Facebook integration could help a lot here, as could venue sponsorship such as posters with instructions / QR codes to download the app.
- Balancing default privacy options. Many (most?) users will never change their privacy options. The default must be restrictive enough that the app does not raise Facebook/Buzz-style security concerns, but permissive enough that Catch Ups are still useful.
- Web interface? Can Catch Up do without a web interface and run mobile-only like Instagram? Or would a web-based interface be useful so that post-event Catch Ups can be done with a proper keyboard?
- Permanence. Catch Up needs to strike a balance between permanence (everything is kept forever – but UI becomes more complex and permissions more fine-grained) and impermanence (Catch Ups expire and are deleted – but we may need to allow users to get their data out).
Aside from “CatchUp”, a number of other names have been suggested:
- Ketchup (a pun on Catch Up)
- ReCollect (based on the idea that you can “collect” people at events then chat to them later)
What’s next for CatchUp is largely down to you.
I am a UX guy and a Java/Python/PHP developer with zero experience of mobile app development – I can do a mean usability study, but I can’t make this app myself in a sensible amount of time.
If you want to help make this app, get in touch. I can’t do it without help.
If you want this app to exist but can’t help, share this post! Eventually it’ll get to someone with the time, skill and inclination to help out.
And if you have any comments whatsoever, keep on scrolling. I’d love to hear any thoughts or (constructive) criticisms you may have!
Interesting idea, although it could be tricky to generate the events - users would have to allow location data/etc for it to be effective. Would offer a hand but my app development is sadly limited to (very dodgy) Objective-C, and glancing-at-the-Android-tutorials-then-giving-up-due-to-the-emulator...
Yep - the app could allow an "enter your location" box if the user doesn't choose to enable location, but the idea was centred around having location available.
That said, how about introducing "not there" chat members as second-class citizens in chat? That way, anyone could see what was being talked about in real time at a certain event, but users that are actually there can optionally restrict their view of the chat to only include people who are also there.
Really nice idea! You could have events also generated by the users.
Say someone turned up to a gig and they open the app. They're greeted by a local area map showing the locations of nearby chats that they're close enough to join (say a 0.5 mile radius?). If they don't see an applicable chat, they can begin a new one. Others then turn up later and join the already created one. Really cool!
Something totally aside. How do you stop someone from taking this wonderful idea and with much greater resources just developing it behind your back? The reason I ask is I had an idea for an app myself (albeit hardly as innovative as this!), and I want to pitch it to the company in question (a local high street chain) without them just saying, "no thank you", then making it behind my back without my input.
That's a pretty good idea -- weirdnesses in the geographical clustering algorithm, bad address-to-location mapping for events or high error on user location could all cause users to be placed outside the main chat room for an event, so a map and the ability to name events yourself on the fly would be very useful there.
As for how to prevent that, in this specific case I don't -- I'd like the app to exist, but if some other group nicks the idea and builds it themselves I don't really care.
In the general case, most businesses produce and sign Non-Disclosure Agreements (NDAs) to cover that eventuality. The company with the idea would produce an NDA and get the other company to sign it before they discuss the idea in any detail. I'm not sure whether this would come across as too cocky if you're an individual trying to get a high street chain to sign up. There's a StackExchange site called <a 0="" href="http://answers.onstartups.com/" rel="nofollow noopener">http://answers.onstartups.com/</a>" rel="nofollow">OnStartups</a>, your question may have been answered there (it's roughly on-topic) or if not, it can't hurt to ask. If you do go ahead with an NDA, it's almost certainly worth getting a solicitor to draft it with you to ensure it's legally binding.
I'd be up for assisting. What about Chattr?
I'm gonna have a go at some ideas, but these are only to help you. :-)
Damn, it already exists :-(