Shortcut Gestures for iPad Safari
Brief: This concept interaction demonstrates multi-point shortcut gestures for switching and closing tabs on the iPad Safari, removing the need to constantly reach for the tiny tabs and Close buttons.
Context
This is a self initiated two-day project, as a practice for interaction design and getting familiar with the prototyping tool Framer.
Motivation
I enjoy using the iPad but often find myself going back to the laptop for extensive web browsing. One of the reasons is the subpar tabbed browsing experience on mobile Safari. I hope to improve this interaction to make the iPad a more productive device, especially with Apple’s initiative in entering the Pro/Enterprise market.
Problem
Opening and closing tabs many times are common in a regular browsing session, however the small Close button on the mobile Safari’s tab bar makes tabbed browsing slow and difficult. While the button works well with a mouse or trackpad, its small size requires too much precision for touch, and also a higher cognitive effort to hit accurately.
Alternatively, users can also press the Show All Tabs button or pinch out to enter the Tab view then swipe right to close the tab. This requires less precision but the added steps also increase its interaction cost.
Premise
The interactions I am designing will not replace the original Close button as it is highly visible and necessary for regular users. Instead they will be shortcut gestures that accommodate advanced users who prefer a faster way to navigate between tabs, similar to the edge swipe shortcuts for back/forward. Efficiency is prioritized over discoverability for this design.
Scenarios
I imagined two scenarios where users would want to close the current tab:
- Closing the tab soon after opening an irrelevant search result or external link, without scrolling down the page.
- Closing the tab during/after reading the page.
The main difference here is that in the first scenario the top UI bar is fully visible, while in the second scenario the bar folds to a smaller title bar upon scrolling. Since the interaction should stay consistent across different scenarios, a successful design must accommodate both versions of the UI.
Inspirations
I then began to look for inspirations from existing apps. The Google app implements a drag-down-to-close interaction as the user reaches the top of the page, or drag the top bar if they are in the middle of a page.
However, combining page scrolling with the close tab action may confuse regular users familiar with the iOS signature ‘bounce’ that occurs at the top/bottom end of a page. Accidentally closing a tab while scrolling can also be very annoying.
The only thing I could borrow here was the drag-to-close interaction which I believed was quite natural and effective.
Ideation
My first idea was to swipe-down on the tab to close it, effectively turning the entire tab into a bigger Close button. However as more tabs were added to the bar, the tab would become so small that it wasn’t much easier than pressing the original button.
The second idea was to expand the draggable area to the entire top UI bar, similar to dragging Google app’s search bar. This solved the mentioned problem and according to Fitts’ Law, would make for an even faster/easier interaction for the increased size.
Prototyping
I took a few snapshots of my iPad and imported into Framer to quickly test out my idea. It was very exciting to use this new tool for the first time. Prototyping with code has a steeper learning curve but is also more powerful than most drag-and-drop tools.
I first replicated the Google app’s transition to get a feel for the interaction.
I found switching from one “window” to another rather awkward. With the entire top bar visible it almost looked like switching apps than just the tabs.
I really liked the “folding UI” action upon scrolling so I incorporated that into the interaction to make each tab feel more standalone.
User Testing
For some quick user testing, I demoed the interaction to my roommate and asked him to try closing the tab for 10 times with the full top bar (Scenario 1), and another 10 times with the shrunken bar (Scenario 2).
The design failed.
For more than half the time he had accidentally triggered the iOS Notification Center by swiping the top edge of the screen. The problem was even more prominent with the shrunken top bar.
It was surprising to me how much realization I got out of this two-minute test with just one user.
Iteration
Based on the user test I learned that gesturing on top of UI elements wouldn’t work too well. So the only alternative would be to adopt multi-finger gestures that don’t depend on the UI itself.
I chose to use three-finger swipes as four-finger swipes were already used by the iOS app switcher, and two-finger swipes may cause false triggering during pinch-to-zoom.
Since users are already familiar with swiping a card up to close the app in the iOS app switcher, swiping up to close a tab would match the user’s existing mental model.
Similarly, the next tab would appear from the side instead of the bottom to match the horizontal layout of the Tab View.
And since we have up-swipes, it made sense to add left and right swipes as shortcuts for switching tabs. A happy accident! I also added the folding bar animation to make the tab names more identifiable and to prevent users from confusing it with app switching.
Outcome
The final design prototype was tested and received very positive feedback from the Framer Facebook community. I am personally quite satisfied with this simple yet effective design, and would definitely hope to see this implemented in a future version of Safari.
I’d love to get more feedback from you!
