The Progression of the Drupal Mobile HTML Prototype

The aim of the Drupal Mobile HTML prototype is to demonstrate the look, feel and thinking behind the design for Drupal’s Mobile Admin interface. It is purely for demonstrative purposes.
This document references the D8MUX Roadmap and everything in that post also applies here.

• It does not have to be written well. Hack and steal your way around the code to make it appear to function.
• It does not have to gracefully degrade. This is a prototype of the best case scenario, let’s not limit ourselves.
• We do not have to support a wide range of devices but let’s make sure we are clear about that to people testing it. We should be thinking about design concepts and not
• No suggestions or additions based entirely on “the desktop version has it’. We start from scratch. If an element or feature can’t justify it’s existence it doesn’t deserve to be there.

Prototype sandbox

Current Progress

I consider step 1.1 of the roadmap to be complete. The basic navigation to get to every page is in place. It is not sexy or particularly fast or great but it hits all the requirements set out in the initial requirements:

• Simple
• Consistent
• Finger Friendly
• Complementary

The next stage (version 3 onwards) should focus on the details of the navigation. How we can speed up navigation for power users by adding short cuts and how we can reinforce metaphors like current location on the small screen.

The Next Steps

We need to start thinking about how we can enhance the current interface through new features. These could be unique to the mobile solution or they could get rolled back in to the desktop interface. Let’s not worry about that now.

Separating back and front - a new metaphor

Sandbox issue

With the overlay looking likely to axed for small and touch screens we must think of a new way to reinforce the front and back ends of Drupal. See discussion.

Speed as a feature

We should experiment with making Drupal’s admin interface as fast as possible. I think we can make the mobile version faster than the current desktop interface. This is pretty technical but it’s so important we should start looking at it now.

Eg. Loading the entire navigation tree on the first load using JSON. Then build each new page without any additional http requests. This is why native apps are so ‘responsive’.

Gestures

Sandbox issue

Gestures are a powerful shortcut in touch based design. Not only do they allow power users to complete repetitive tasks quicker they also have the benefit of being invisible. Beginner users, who struggle to complete tasks at all, don’t get the distraction of these power tools. They only have to think about the slow and simple route. We can layer an invisible, advanced interface over the basic one. We can make Drupal more learnable and more intuitive through gestures.

Here are some examples of gestures in action and an example how they could be used in Drupals admin interface.

Swipe

• The iPhone mail app uses this shortcut to reveal a delete button
• The instapaper app uses this shortcut to reveal actions on each item (Delete/Organise/Share)
• We could use this in Drupal on lists of content/modules/anything to drill deeper without the extra tap.

Tap and hold

• The Reeder app brings up a big list of ways to share the link you performed the gesture on.
• We could use this in Drupal to load contextual shortcuts on blocks.

Pull to refresh

• The Twitter app introduced the pull to refresh gesture as an extension to the standard ‘scroll to see more content’ gesture. Once you hit the end of the content a hidden message appears instructing you to pull down to update the list of tweets.
• This has now become a common gesture on the iPhone even in situations where it doesn’t make sense (foursquare)
• The Reeder app extended this smartly by asking to load the next article when you scroll to the bottom of one.
• We could use this in Drupal to replace pagination.
• The best way to find out what shortcut gestures to add is to watch a smartphone user advance through the app and see where they expect them.

Learnability through smart tips

Part of the problem with invisible advanced gestures is that they are not immediately obvious. Some new gestures can piggy back off the back of standard gestures but not all gestures have that ability because touch interaction is still new. There are not yet standard conventions across apps or devices.

Excerpt from Buttons are a Hack:

• Video games are a good model for how to introduce people to new modes of interaction.
• Coaching, Leveling up, Powering up. Active participation is the best way to learn. Coaching allows you to practice as you interact with a service in real time. If you can avoid forcing people to read in coaching even better.
• An important element of coaching is not revealing everything at once. You start small then build up over time. Ease people into an app with an element at a time.
• The best time to learn a skill is when you need it.
• Levels that require a feature are the best time to teach that feature. The first time through, it is a guaranteed success.
• Think about your app as levels. How can people move between them as they learn how to use it? Where can you help people level up?
• Power-ups are ways to turbo boost your games. They provide shortcuts. Shortcut gestures can tackle common actions that could be streamlined.
• Facebook has a custom gesture to get back to the home screen by tapping on the title bar. This is a useful feature but there’s no affordance to explain it to them. Perhaps the app instead should let people “level-up” by introducing them to the feature after they see its need (after a long browse path, for exmaple).

We need to be smart about when we reveal these hidden gestures. Observe the user’s behavior and power them up by handing them advanced tools. Convert them from new users to advanced users. One example in Drupal is we could observe when one user keeps returning to the same page and point them to the shortcuts tool.

Spotlight for Drupal

Sandbox issue

Use Spotlight/Alfred/Quicksilver on my mac all the time to launch apps. I don’t even have to think about where the apps are or clicking on them I just type a few characters and hit enter.
I’ve seen a big trend towards auto-completion on mobile. User’s don’t want to type a whole word to see their results on a touch screen so the results are presented live as they type. IPhone contains a global search called Spotlight and Firefox mobile introduced the awesome screen to quickly present bookmarks and visited sites to the user.

Excerpt from The secret lives of links:

• If people don't see their trigger words, they click search.
• What do people type into the search box? Their trigger words. They are creating a link. If they don’t see a trigger word, they enter theirs into search.
• Your search logs are filled with trigger words. Have you looked there lately? Match the search phrases up with the pages users search from.

Spotlight for Drupal is the user’s get out of jail card. If they are lost they can type what they are looking for in in a text field and results will be quickly returned. This can be:

• Nodes
• Users
• Modules
• Config pages
• Help pages
• Content creation forms
• Anything we want

This can also be an additional power tool for advanced users. We can add quick drush-like shortcuts into Spotlight like clear cache.

One other benefit, if we make spotlight searches part of Drupal’s anonymous report statistics we can get a very high level view of desire paths how the user thinks.