This is a rough draft post. Will update in a bit, but wanted to get this out asap…
Today we’re putting Wejit into public beta. What’s a Wejit? A Wejit is a widget you can put on your Android phone’s home screen. Pictures go in there. Whose pictures? Someone you know. A friend, your SO, family members, etc. The person who’s sharing with you can post pictures that show up on your home screen. Your boyfriend sending pics from the office, your kids sending pics of the grandkids, etc.
There’s also a “public share” feature, but we’re getting ahead of ourselves here.
A few weeks back we ran into a little downtime between projects, so we wanted to build something in house that was:
1) Android specific
2) Fairly limited in scope (not THAT much downtime)
3) Could show off some interesting design
4) Could stuff in all of our open source tech and some interesting ideas
Basically, Wejit started as a tech demo.
The concept was all Paul Burke’s, Touch Lab’s Dev/UX/Design guru. First, let’s show off some of the screens…
Intro 1
Intro 2
Intro 3
After the intro screens, you find the home screen. There are “subscriptions”, which are Wejit instances you can put on your home screen. ”Creations” are Wejits you’re publishing.
Home
Edit Wejit
Here’s what a Wejit looks like on your home screen!
I will eventually post a video of the app in action, but for now, enjoy the screenshots.
Technology Details
We used several library projects from the Android community, as well as a few of our own. First a quick note about the server. On the back end we’re running the Play Framework, v2, with a Postgresql DB on heroku. For quick mobile apps, this is a fantastic stack.
On the client end, the following library projects were used:
Jar projects included:
- basic-http-client
- Ormlite
- Apache commons: Lang and IO
The full build takes a little while. Lots of crunching.
Much of the library projects were for enhanced UI featured. A video would be better to show that stuff off.
The apache commons are actually from stripped down versions I did a while back. I yanked out much of what wouldn’t be all that useful on a mobile device to produce smaller final packages. I’m not pushing those too hard until I get a chance to review how much smaller the output will be.
Our Stuff
The project makes use of 2 of our internal projects: Superbus and TouchTrack.
Superbus is used for offline support, but is more generically a “store and forward” library, with specific features for mobile use. Login and Facebook actions need to be online, but everything else should work seamlessly online or off. I crammed in the newest version at the last minute, so you may hit a couple bumps. Remember, Beta.
TouchTrack is a crash reporting and feedback platform. Its similar to everything else out there, except that it includes a rolling log and the ability to upload files, both in time and at the moment of the crash. Conceptually, it’s like a airplane black box. You get (roughly) 30 seconds of activity before the crash event.
An example crash: https://touchtrack.co/r/9qpidz
The logs are kept in a rolling, in-memory log. Files are stored locally. If older than a certain timeout, they’re removed. One of the most useful features is saving data sent and returned from server calls. If the format is understood by TouchTrack, it will be formatted and displayed inline. Currently, json and xml are supported.
There is also a special log level, ‘ua’, short for ‘User Action’. You can see when activities are started, and when Views are clicked. You can clearly see what the user was doing when the crash occurred.
The summary is: some bugs are VERY difficult to reproduce in testing. With TT, you’ll get much more data about what was happening during the crash in the field. This sounds a little like overkill, but it save tons of time when dealing with server calls, and especially when dealing with offline processing operations.
You’ll notice on the left, custom variables, which are app-defined, and a link to a db file. At crash time, we add the local db file to the report, to help diagnose issues.
Security? Obviously there are security implications. You’ll need to decide what data to send, ask the user for permission, etc. You can also change the “mode” of the app from the web panel, which will allow you to turn off data uploading when you decide you’re no longer in a testing mode.
Anyway, that’s TouchTrack.
Custom Crash Screen
Over the past year or so, I’ve become obsessed with ratings in the Play store. We do actually ask for a rating, but only in the slide-out panel. No popups all in your face. I’ve concluded that you do need to ask for reviews at some point, or you’re only going to get bad ones.
When do you get bad ones? Well, I would bet you get plenty of them after the app crashes. Normally when you get an app crash, its pretty abrupt. The dialog popup is pretty cold, and although there’s a “Report” button, I think its a little vague.
Many websites have the “funny 404” page. Finding good 404’s has turned into something of a hobby. It seems obvious now, but they don’t exist just because designers are bored. I never thought about it much, but when are you most likely to turn off a user? When your site crashes. The funny 404 is brilliant, because it turns a negative event into a chance to get your users to “love” your product. Finding one is actually fun. You forgot about the 5 minutes you just lost with whatever you were doing that wound up there.
We put that into the app. May I introduce: Robot Down
I have no real “proof” of this, but here is the logic. User takes some action, wham! Rough, standard crash screen. They’ve possibly lost some data, or just aren’t in a good mood. They want to vent a bit, and the easiest way to do that is hitting the market and trashing the app, followed by uninstalling it. ”Crashes. 1 star. Delete!”
This really helps nobody. The app looks bad, issues aren’t logged, and the person leaving the review has done something arguably negative (I’ll leave out the long theory of self-observational karmic expectations. Short version, being a jerk makes you feel like a jerk, however so slightly). In short, except for maybe waving off potential users from a horrible app, 1-star/delete reviews are bad news.
The solution? Short circuit that response! A funny little pic, an implicit recognition that the app isn’t perfect, and a clear, positive call to action. The opportunity here is to improve the user/product “relationship”, get some feedback that will actually improve the app, and give the user something positive to do. Everybody wins (unless your app is a disaster and you’re not fixing it, in which case, bad reviews are probably for the best).
Miscellaneous
We’ll see how this goes, but the assumption here is that this is more of a “feature” of an app than a real “product”. When making design decisions, the final rule was usually, “hey, this is a tech demo. Don’t worry about it”. The web portion of the facebook app is particularly soft at this point. We used facebook for easy user connection and authentication. For that, very useful. For notifying users that you’ve shared with them, Facebook is twitchy. I’m sure its been heavily abused in the past, so there are many safeguards when sending notifications back and forth, but the down side is it’s difficult to do.
There is no way to interact with the app if you don’t have an Android phone. If people actually use the app, we might build clients for the web and iOS to allow pics to be sent, but iOS doesn’t have widgets, so it would just a private photo sharing app. That’s OK, but it’s pretty “meh” as an app idea.
There are “public” widgets. The idea here would be for bands, brands, artists, etc. Post pics that your “fans” can have on their home screens. If you’d like to hook this into an existing app, or make a locked down, branded version, Touch Lab is ready to help!
Thanks to everybody on the team, and to Paul specifically for his idea and sticking to the vision. We disagreed on a number of concepts. I think the only clear “win” I had was preventing the facebook.com email addresses. On principle, dammit!
