An iMessage app post-mortem
Project background
One of the new features of iOS 10 that super excited us was iMessage apps. Taking into account the number of people that use the Messages app every day, we wanted to experiment with this new context, to explore new interactions and experiences.
What we did
Some coffee and brainstorming later, we conceptualised a little utility game called Decider! Using "Rock, Scissors, Paper" logic to allow decisions to made quickly during a chat. To add some fun to the mix, we wanted to portray the ‘fight’ with funny gifs and emojis. To hopefully avoid any copyright issues, we used the Giphy API.
Exploring iMessage framework
Armed with an idea and a loose understanding of the iMessage framework, we quickly sketched out different ideas and flows. After some intense discussion and furious scribbling, we had a rough concept.
– Attacker starts the game by opening the app and selecting their fight move. A challenge to fight bubble is added to chat.
– Defender taps bubble, selects the relatiation move. The bubble is updated to conclusion, showing who won.
– Tapping the conclusion bubble, opens the fight replay, a sequence of funny gifs for Attack, Retaliation & Winner, each labelled with who did what.
Simples… right? So we called in Sergio, friend, former colleague and kickass iOS developer, to review the concept and do some technical scoping and investigation.
In the meanwhile, we refined the flows, and quickly worked up some visual mockups of the key stages of the flow.
Learnings
So... we founded the iMessage framework incredibly limited, and this makes sense as a starting point for Apple, particularly from a privacy perspective. That said, this seems to massively restrict what experiences can be built, for now… but understanding the restrictions of a new medium, is key to design for it effectively. During the build, most of our conversations went something like this:
Matt: “...oh… so if that’s not possible, how about such and such?”
Sergio: “Nope, but we could do this, but that means something else isn't possible”
Judit: “Well that’s gonna suck for users, we need to re-think the flow, as that is not useful or funny”
This is what we found out:
– All messages need to be explicitly sent by the user
– After the defender responded with their move we wanted to immediately send a message with the result of the fight, but because messages need to be confirmed by the user we couldn’t show the result of the fight or else the defender will see it, and if they’d lost, could cancel the message and make another choice.
To go around this, we needed to change the game logic a bit:
– Attacker, starts the game by picking a fight move and sends
– Defender receives the message, select is move, and replies
– Both attacker and defender need to tap on the message send by the defender to see the fight result. The any of the players could send an extra message to confirm the result.
– Bubble & screen effects must be selected by the user
– We wanted to Slam the message bubble, each time it was updated, and when the winner was declared in the conclusion message, fullscreen Fireworks would fire. Apple says no…
– The message bubble is limited to a template
Working around limitations
If you have a look on the mockup you can see that we had a custom design for the messages with big fonts overlay on top of the messages.
However, we found out that the message format is limited to a template that Apple provides. We could have tried to go around this by creating a custom image on the fly, but that will make the code more complex.
Only in the custom message template you have access to the name of the participants.
Apple, because of privacy concerns, made it impossible to have access to the app users real names. You only have access to user identifiers that when used on the caption or message fields of the provided message template are replaced by the real username.
This means the fight replay videos can’t use the real user names, we could have used "You" or the "THey", this is pretty terrible experience if more than 2 people are in the chat, as if someone who didn’t fight, would just see “They did this", "They did that", "They won". The only workaround we found was to use "Attacker" and "Defender", and hope the user remembers who started the fight and figure out if they won or not. Certainly not ideally, but better for chats with more than one other person.
Animated Gifs don't play in the message template
Our plan was to represent the fight moves using animated Gifs, but when did our first experiment we found out that if you use an animated Gif on the image property of the message template they animations didn't play.
After some research, we found that if you set the mediaFileURL property and used a mp4 file the video played correctly. This ended up being a good thing because mp4 files are smaller than the equivalent animated gifs.
All the content used in the messages need to exist locally on the device, before it's sent to other users
Our initial plan was to send messages containing the URLs to the relevant Gliphy videos, and then download and display them on the fly. However, the message template requires the videos to be stored locally and then attached to the message. More frustratingly, even after receiving the message with the playable videos, the videos need to be re-downloaded again, if you tap to watch fullscreen.
To avoid all this extra downloading we decided to add a series of videos to the app bundle. This way we avoid unnecessary data usage, but results in a larger initial download.
No support for iMessage apps in macOS Messages
The custom messages aren’t displayed, just a video, from the person who last interacted with it. The only possible workaround for this is to provide a custom URL that points to a website that show the full fight but this was well beyond the scope of this project, and probably would be wasted time, as iMessage apps are bound to get to the Mac... eventually?
Soooo…
As we faced each limitation, we had to adapt the logic, so the experience was still fun and engaging, based on our improved understanding of what’s possible. The concept, while similar, had to evolved a lot to deal with these limitations… possibly too much...
Takeways
We didn't release to the AppStore, but we shared our findings and open-sourced the code. If you want to find out more, check the Github repo.
