In their short lifetime, mobile devices have undergone a radical transformation from being communications devices, to being computers in your pocket. In fact, the mobile phone is no longer primarily used for talking, but for taking photos, sending text messages and surfing the web. In many parts of the world, mobile devices such as phones and tablets are the primary gateway to the internet.
The impact of the switch from desktop to mobile means that more people are creating more content on mobile devices than ever before. Suddenly, the keyboard-driven, dialog-heavy interface we have loved since the dawn of modern editing is no longer the right interaction paradigm. Impossibly small screen sizes, soft keyboards, tolerances for interaction errors, and allowances for contextual interferences all challenge the status quo of what it means to edit content.
Creating a professional quality text editor for mobile devices is not simply an exercise in responsive design. Our 3-year journey bringing mobile and accessibility into the Textbox.io core editor helped us learn that going mobile required us to re-think a lot of traditional, desktop assumptions.
Fortunately, we have been able to learn from Textbox.io and are now applying the lessons that have withstood the test of over 300,000 IBM deployments, to the development of the mobile editing experience with TinyMCE.
This post is about the things we re-thought for Textbox.io. The features and functionality that you can expect to see added into the core of TinyMCE mobile.
Re-thinking #1: Don’t slavishly copy desktop features to mobile
Our first lesson learned: not every feature we use in a desktop editing environment makes sense on mobile. With smaller screen real estate, eliminating unnecessary features was an important first step. The question, of course, was which features to eliminate, and in which usage contexts.
In developing Textbox.io, we formulated a few common sense rules to help us make these decisions:
- Reduce context switching, e.g. hamburger menus, and data input forms that take over the entire screen
- Order visual elements by frequency of use, e.g. place buttons in the toolbar according to how often they get used and arrange input fields in order of importance
- Re-think the interactions of common elements, e.g. dialogs, toolbars, drop-down lists
- Remember that the “soft” keyboards on mobile devices vary in size and placement, making it difficult to use these as an anchor point for toolbars and buttons
- Don’t ignore orientation. Changes in orientation impact the layout of elements and usability of the editor. To meet accessibility guidelines, at least the toolbar, one line of content and the soft keyboard need to be visible at all times (as they say, constraints inspire creativity)
- Remember the context of use and be kind in your design. For example, picture a user trying to type on a moving bus: could they achieve their task given the likely imprecision of their touch actions? Will our design help them succeed?
We found that keeping these rules in mind led us to develop quite different UI elements for mobile phone and tablet use. In addition, we found that it made sense to vary the set of features that the editor deploys depending on the size of the mobile device one might use.
This means that TinyMCE will automatically use the UI most appropriate to the device and present use case. This goes beyond simply changing the buttons in a toolbar, to rethinking the content creation experience entirely.This means that you will see a different set of buttons on a mobile phone than on a tablet.
Reducing the number of dialogs and accounting for haptic differences led to us re-think some common desktop interactions. In this example, we are trialling an interactive heading zoomer as a replacement for the traditional dialog/dropdown heading formatter.
Re-thinking #2: No dialogs
Text editors are traditionally dialog-heavy, yet dialogs do not work well on mobiles for a number of reasons:
- The smaller mobile screen sizes often obscure parts of the dialog.
- The keyboard pops up and covers half the screen.
- People often hold their phone in one hand and use their thumb to interact, making closing dialogs and navigating between fields awkward.
- Dialogs often mask a legacy of unresolved design issues, à la “not sure, let’s put it in a dialog as a configuration option”.
Deciding to go “mobile-first” gave us freedom to rethink the “normal” editor interactions and come up with alternate solutions. One key breakthrough we made from a design perspective was to utilize the toolbar space as a proxy for dialogs.
We experimented with this under the supposition that leveraging the toolbar space for quick contextual data entry and actions would result in a smooth and intuitive user experience with minimal disruption to editing flow. The examples below show how we re-designed the Search dialog, the Link dialog and the Text-size formatter into mobile-first inline dialog components.
Re-thinking #3: Not all touch is equal
Touch is a fundamentally different UI interaction style to a mouse or keyboard, and unlike a mouse and keyboard, is incredibly personal. People touch their devices in significantly different ways. For instance, we discovered that there were big differences between how iOS and Android users touched their screens.
We observed that iOS users were quite consistent in how they touched a UI element like a button, while Android users let their fingers slide a little past the element they were touching. This observation led to our developers investing many hours into code designed to optimize for these differences. These optimizations are why the next time you are using your phone to create content on a bumpy bus ride, you will have far more chance of clicking on the button you wanted to rather than missing your target.
Differences in touch also added a wrinkle into our regular QA processes. We learned that our automated tests used for desktop testing were inadequate for mobile as they were not capable of replicating the wide range of “touches” that humans are capable of. We found that certain conditions could only be replicated by specific testers, and that things like sweaty hands vs cold hands could have different results when executing the same task. For now, we have added a slew of manual tests into the QA testing process for mobile (a big shout out to the army of interns that help us in this task!).
Re-thinking #4: Out of the box accessibility
One of our goals for Textbox.io was to make the editor accessible right out of the box. On desktop, accessibility is achieved by making all elements keyboard enabled and announcing elements as they are navigated via the keyboard. On mobile, the model is entirely touch-based (rather than keyboard driven). The user taps around on the screen, and elements are announced through VoiceOver on iOS and Talkback on Android. Double tapping anywhere on the screen will trigger the last announced element.
We are rolling what we learned through making Textbox.io accessible into an abstracted UI framework (codename Alloy). Alloy will be released as an Open Source project later this year, and will give TinyMCE developers accessibility and responsiveness “out of the box” for all UI elements created using the framework.
Re-thinking #5: Operating system shifting sands
Keeping up with (often undocumented) changes to operating system updates was a real challenge. Quite often, things that worked fine one day, broke when an operating system was updated the next.
Another source of angst for our development team was managing the inconsistent ways that soft keyboards are handled by iOS and Android. We added a lot of behind the scenes code to account for the different ways in which editors are laid out on different platforms. For example, on iOS, when the keyboard comes up, anything that has position “fixed” temporarily changes to “absolute” which affects how the UI components are laid out. The nuances of cursor positioning was another area that took a lot of coding magic to get right.
For example, on Android, we had to explicitly correct for cursor positioning in cases where the cursor was positioned in the lower part of the screen and covered by the keyboard when it popped up.
What this means for TinyMCE’s mobile experience
The process of developing an editor with mobile capability and accessibility built into the core from the start gave us an excellent opportunity to learn about what a mobile editing experience should be.
With the benefit of the lessons we have learned, and with half a year of in-the-field usage by a cohort of over 300,000 users, we are well-placed to bring the very best to TinyMCE’s mobile capabilities later this year.
For more info on the specifics of how we redesigned our UX components for mobile, you can watch our presentation from YOW! Connected last year, “7 UX Secrets that every mobile developer needs to know”.
Thanks to Morgan Smith, Lead Developer at Ephox, for his help in drafting this blog post, and leading the team to make it all happen on bringing an awesome mobile editing experience to TinyMCE.