While the rise of internet-capable mobile devices has solved a lot of problems, it has also brought a host of new problems with it. One problem you may encounter is that as your customers are now using multiple devices to access your service, they are having to continuously switch context between them.
Context switching can lead to both frustration and lost time. So what can make this context switching easier?
This is the question that Priyank Vyas, Yasser Fadl, and myself (aka Team Hack’N’Slash) set out to answer for our Caplin mobile hackday project. Our use case was of a trader who uses his phone/tablet to view some data for a set of financial instruments while traveling, and then wants to view a more detailed analysis when he logs into his desktop at the office.
Caplin Thrower
Team Hack’N’Slash dubbed our project “Caplin Thrower”. Caplin Thrower is not an application in itself, but a mechanism to transfer context data between applications. This meant we had to make two web applications; one that was intended to run on a mobile device and one for a desktop computer.
For the desktop application we used the reference implementation of Caplin Trader. This allowed us to focus purely on how we injected context data into the application without having to write a fully fledged trading application from scratch. For the mobile application we created a very simple page that displayed a set of trade tiles.
Keep it simple
The reason context switching is a problem is that it pulls the user out of their current workflow in order to facilitate the context switch. If your solution requires the user to stop thinking about what they are doing to think about the context switch, then I would argue that it is not a good solution.
Taking this into account, we opted for a simple “flick” gesture to initiate the context switch. We chose this gesture as it felt like the user was literally flicking the tile from one device to the other! This action felt very natural, and gave an intuitive experience to the user.
Don’t re-invent the wheel
The next question we had to answer was “how do we get the context data from one device to the other?”. For us, there was only one answer to this question: Caplin Xaqua. If you have a world leading streaming server at your disposal, why look elsewhere?
We used SL4B to send small snippets of context data from the mobile application to our Xaqua server. We then listened for this data in our modified Caplin Trader.
Remember, your contexts are different!
The last part of the puzzle was to determine how to inject the context into our desktop application. As one of the key features of Caplin Trader is its content management, this turned out to be very easy from a technical standpoint. However, there was still the question of what should be displayed to the user after the context switch.
It is important to keep in mind that your two contexts will be different. If they are not, why would your user make the context switch in the first place? The key is finding how the two contexts differ, and why the user wants to put in the effort required to move from one to the other.
In our case the biggest difference was screen size. A mobile device cannot be expected to display the same amount of data as a desktop computer. This suggests that the primary reason a user would switch from their mobile to their desktop is to see more data.
To take advantage of the extra screen size we decided that instead of just transferring the tile, we would launch an entire new page with multiple components relating to the context of the flicked tile (ie, its currency pair).
The power of simplicity
When we demonstrated Caplin Thrower, it received a large round of applause. I believe this was due to how it made the context switch seem completely effortless. What seemed like a complex problem was disposed of with a simple flick of the finger.
Team Hack’N’Slash was a runner-up in the Caplin mobile hackday (you can read about the Caplin mobile hackday here, and the winning team’s project here).