The first problem we need to solve is how users get around Drupal's interface on devices with small screens and touch screens. See the D8MUX road map.
Let's do some brainstorming and prototyping over how we get this good on mobile.
What do we need?
- Simple
- Consistent
- Finger friendly
- Complementary - The navigation can't upstage the main purpose of the page or task.
Current pain points
One page many purposes
Designing for mobile forces you to really focus on the purpose of each page. The majority of users come to a page for one purpose. Drupal has a tendency to get in their way.
Take the 'Content' page as an example. It's primary purpose is to browse actionable content. Before we even hit the list of nodes we are treated to a content/comments tab choice, a call to action to add content, a filter form, and a bulk update form. When we hit the list, we are given a link to navigate to the front facing view, it's vital statistics, a link to navigate to the author's profile, a delete action, and an edit action. Sounds like a mouthful doesn't it? It's painful when the viewport is shrunk.
You can see similar issues on the 'People" page, the 'Content Type' page, and the devil itself; the 'Modules Page'.
What would an iPhone app do?
iPhone apps have three main metaphors for navigation. Apple's SDK comes with most of the code ready made so app developers get it way and Apple users don't have to put up with mystery meat.
Deck of cards
Imagine several cards placed side by side. Each one contains related information. Users flick backwards and forwards through the deck. It's impossible to jump to a particular card in the list.
All the information is displayed without any scrolling. This metaphor is clearly not meant for complex navigation, Apple hard codes the card limit at 20.
Tabs
The tabs metaphor needs no introduction. Drupal's current navigation toolbar uses this metaphor, allowing users to jump between top level sections of the admin interface to perform tasks one after another. It's worth bearing in mind that the Drupal Seven usability testing at the University of Minnesota revealed that participants didn't actually use the navigation in this way.
How does the iPhone handle the tabs metaphor? Well it makes them big and fat, adds some icons and fixes them to the bottom of the viewport to make them thumb friendly. It also limits the number of visible tabs to five. Add any more and they become hidden behind a "More" tab.
Tree structure
Image a list of a list of a list. The iPhone handles this information structure with sequences of pages full of menu items. Tapping each item takes us deeper towards our objective or actionable item.
Comments
Ok, so these are native
Ok, so these are native solutions. Are we looking at how other sites manage this too, or are we just exploring native solutions?
I am not sure I understand, how from the research we have done people didn't use tabs?
I included a link to the
I included a link to the usability study results in the post above:
I don't see a distinction between a native app and web app from a user perspective. All the concepts and models they use in native apps we can use on the web. I used Apple's own iPhone apps as examples because of their design authority.
Patterns
This site can be useful for inspiration:
http://mobile-patterns.com
Mobile Best Practices
If we can use this site as a reference, I think it would give us some useful guidelines.
http://mobilewebbestpractices.com/
Also if you haven't yet seen http://futurefriend.ly that would also be good to keep in mind.
http://lukebrooker.com
Thanks guys, I've added a
Thanks guys, I've added a resources section to the bottom of the post.
I'm working on a html prototype of how the navigation could work. If anyone has anyone has any ideas jotted down I would love to see them.
Static HTML Prototype
I've been working on a static html prototype of how this navigation could work on mobile.
Type nav.d8mux.org in to your mobile browser to used the prototype. Bear in mind this was not fully cross device tested so there may be some bugs. I'll go over the main points of the design.
Consistent Navigation Pages
All navigation screens have the same layout and basic elements. The pages are currently using table layouts now use the same list format as the others.
Tabs have been dropped in favour of another navigation level. An example is the content page.
The touch target size of the list elements have been increased.
Separation between navigation and action pages
A page is either used for navigating to an item or performing an action against it. This prototype doesn't include the actions pages but it demonstrates how much superfluous information we can hide in the list views. Compare the content in the modules page with the current modules page. Another example is the content list page. (See original)
Focusing on one action per page is great. It removes clutter and only introduces extra functionality when you need it.
Re-purposing the tool bar
As the tool bar no longer contains the top level navigation, it opens it up to other opportunities. I've add some examples of secondary page actions to the tool bar. On the content list page the tool bar contains the actions 'Filter' and 'Sort' which expose forms that modify the current page. On a Menu page you can add a new link or edit the menu itself. This is pretty similar to how the top toolbar is used in iPhone apps. Placing all the actionable items in one consistent location is a nice improvement.
Good job! I think it was
Good job! I think it was sensible to do it as a static HTML prototype first. I wonder if the additional options (view / edit) in the top right on certain pages should go in an "options" drop down or something, as they may not always fit? I would imagine this working on a press action, e.g. the menu button here: http://m.deeson.co.uk/online/our-work
Awesome. Immediate design
Awesome. Immediate design feedback would be that the right-aligned arrow icon is attracting attention to a meaningless area, would either drop it or put back in front of titles/lables.
Awesome. I do miss a publishing status on content listings.
Have you seen the mockups for a mobile-optimized modules page? See http://drupal.org/node/538904#comment-5274428 and further.
Awesome! Great choice on the prototyping tool indeed.
We briefly discussed the
We briefly discussed the prototype during ux open hours yesterday. Copy-pasting some comments:
"it's like most mobile versions of task-based like this - much easier to use than the 'desktop' version, ha. be interesting to see how it would handle actually adding/editing content."
"i think one thing that could be used for mobile navigation is some kind of 'contextual' sub nav, to get around that you can find yourself a bit lost 3/4 levels deep in the nav"
"e.g. so i thought i wanted to add content but i actually want to list content. How? Without going back"
"the way we've done it in editorial sites with a page hierarchy is to use suggested (curated) next links. not on task-based sites tho"
"on a task-based site like this i'd look at the key use cases and for me as an editor it's add, edit, move, delete. it's content and menus not configuration."
Initial review
So I have been using the prototype on various devices the last few days. From that my following ideas, and concerns. In general I do wish to state, that its great to see this happening - as I used it, I was surprised by the many things that where considered. I truly liked the calmness of the experience, I never felt the UI was in my way.
1) Navigation is easy, but clumsy. Whenever I navigate around, I generally feel like I am wasting time going down endless tree's of navigation (more than once, I felt lost). This is because when you land on the object /node/1 or admin/content you are listed with another tree of options (view, edit and list). Although I understand handling something as tabs in a scalable way on mobile is more difficult, we can use more method with better progressive disclosure - e.g. going straight to the object but adding quick-links (options menu, context menu) that allows you to go edit the page, or list comments.
Another point would be that navigating back to /admin or even just one step back in your admin is troublesome without using native mobile back functionality.
2) Listing pages, should make more use of progressive disclosure - why are descriptions shown by default? Even on something as the admin/content page I am surprised to see the level of detail we present the user. This isn't a very big problem on most listings, but I saw configuration is one of those pages where navigating it truly suffers due to long descriptions.
3) Actions such as Filter, Sort, Delete, Publish. Are placed in the toolbar. I am unsure if they should, most listing filters don't really help the user anyway and for actions on the object, I would defer it to the object editing screen. Besides that it creates a feeling of clutter, the title should have lots of spacing to allow users to quickly notice it.
4) Navigation on the tablet felt a bit bland, there is a lot more space available on the tablet. This makes some of this navigation for an awkward experience, very stretched out panes, and whole area's of nothing. I have shared some screenshots below, I sadly couldn't save any andriod screenshot. I believe if we want to tackle this as a whole, we need to consider how tablets are part of this initiative. In general it feels bland, compared to more native apps that offer a great experience (facebook app).
http://bojhan.nl/misc/foto1.PNG
http://bojhan.nl/misc/foto2.PNG
http://bojhan.nl/misc/foto3.PNG
5) There where some minor visual issues, for example the font-type was too small. On my Andriod it occasionally became quite hard to scan and the tabs in the toolbar, sometimes moved to below the title.
6) This all needs a lot more research and prototyping, this feels like a first good step in a direction where we want to amaze people with our mobile experience. We should explore several directions for navigation. We can do a lot more research on how other personal publishing platforms do it (wordpress, tumblr, squarespace, site core), but we should not limit ourselves to just our neighbor and go beyond from http://www.tappgala.com/ to complex enterprise apps (http://www.jivesoftware.com/products/engage-employees/modules/mobile and http://www.salesforce.com/mobile/apps/).
Just some first thoughts :)
Thanks for all the comments
Thanks for all the comments Bojhan, it's good to get some meaty conversation going. I'll address these points one at a time.
I don't think removing tabs is the cause for that feeling. We actually have some pretty deep navigation already, I've only added one or two more layers but the main thing is all the navigation pages now look the same. This is a good thing, we just need to improve user orientation.
Exactly! A of native apps include a back button but all mobile web browsers already have that functionality built in. Why waste space recreating what native controls can do better?
Also in the latest version of the prototype I've added a shortcut for getting back to /admin from any page.
Originally I was planning to strip out the descriptions or just hide them by default, I spoke to Roy about them early on during prototyping V1. After I came the conclusion they are a good thing and handy for new users who aren't sure where to go. If we are going to have an option for less verbose lists we should hide it in a config page instead on every list.
It feels like the toolbar is a good place to put actions like this. It's a good replacement for just letting these forms hang above the main content whether they are used or not and it looks like these actions are going to get used on other pages in the future so it would be nice if they were in one consistent place. I'm up for the conversation of whether we should have two levels of toolbars at the top, one for navigation and one for interacting with the current content. The problem is most mobile web browsers give us two already, eating up a lot of vertical space.
4/5/6 These are the kind of issues I'm happy to polish up as we go along. I don't have the time or resources to create a sexy experience on this prototype and there's a ton of technical issues I'm sure we haven't even touched on yet. I'm excited to get to a point where we can talk about that kind of stuff.
great work Lewis ;)
great work Lewis ;)
Navigation Prototype 2
I'm really grateful for the comments and feedback people have been throwing my way on various channels. I've been spending some time polishing up the prototype and implementing some of the suggestions from here an over IRC. Check it out on nav2.d8mux.org.
You can see the main change log on the first page of the prototype itself. I'll go over some of the thinking behind the more complex decisions/non-decisions here.
1. How do we handle the switch between front and back end Drupal?
It is pretty clear we need a way to quickly return to the page the user was on before they entered the admin area. That was one if the benefits brought in by the Overlay in D7 and I think it would be a shame to lose it. It keeps people from forgetting where they were. We should have a persistent icon in the toolbar that sends the user back. I don't know if the 'close' icon is a correct representation when the admin interface takes up the whole page. It depends on what visual metaphor we use to separate the front and back and I think that has to be decided later on once we can experiment with different styling support across devices.
A related question that was raised was whether we should have a persistent button in the toolbar that takes you back to the top level admin navigation. I original kept the home button in the first prototype but then we realised that it wasn't actually a common use case. I was reminded of my own recent mention of the Drupal Seven usability testing at the University of Minnesota and that most users actually closed the overlay every time they finished a task before starting a new one.
2. Should we we recreate/improve functionality already supplied by mobile web browsers?
Examples:
My initial lean is no. Our canvas is limited as it is so why waste it recreating a feature that will be inconsistent with the user's other experiences. Some devices provide native functionality way, way better than something we could do in a browser. We should leverage native controls as much as possible.
3. Should we provide shortcuts to help power users complete tasks quickly?
Definitely. We should definitely provide a learning curve for advanced Drupal users to allow them to get around the interface quicker. Touch input is only just starting to prove itself in this area. There are a many gesture shortcut conventions that have appeared over the past few years.
However...
4. Does this prototype need to do everything for everyone?
Not at all. In fact I want it to do just enough. The purpose of the D8MUX road map is to give us direction and focus.
I don't want to fall into trap where we spend ages talking about this or that use case instead of actually getting it in front of some real users. One of the benefits we have here is we can start from scratch, implement the basics, and then see what pop ups later and iterate on in it. It's very hard to take stuff away we have already added.
I'm going to reiterate the objectives I laid out in the initial post just as a reminder.
Old school solution
I know that this is an old school suggestion, but regarding front end vs. back end: the target attribute was the easy fix for that. Not as 2.0, but definitely workable on a mobile device. ;). Let the user manage tabs how they will.... Admins should have that level of sophistication. I find the overlay issue a distraction.
Nice work lewisnyman Couple
Nice work lewisnyman
Couple thoughts that came up to me
great
The interactive prototype is great and very useful, so much that I decided to make one (I was playing with jQuery mobile) to explore a couple of ideas starting from lewisnyman v2.
It's here http://dl.dropbox.com/u/1312381/d8ux/index.html .
It's the main Administration page.
The back arrow on the left appears only here and should bring you back to the live site where you left it (it doesn't work in the prototype).
The user icon on the right links to your user account (try it. it works). I was missing the logout button and I think that could be the place. And I believe it is useful to have a persistent link to your account.
If you click on "Content" (it's the only other working link). You'll see the content page. I re-introduced the tabs as a navbar (I'm not completely convinced of the idea of getting rid of them, especially if it requires an extra page load).
What I think it could be interesting is a contextual back button/breadcrumb that could help to give context.
The action items are back in the page and out of the toolbar. I think that semantically the toolbar should remain separated from the content and its elements.
This is just a stub to explore some ideas. It's true that we loose the simplicity of lewisnyman prototype but I believe that by maintaining existing drupal patterns and elements (like the tabs and the link to the user account) it could be easier to eventually code this on top of the existing implementation.
What do you think?
Thanks
Thanks for posting this prototype fork dodorama. It's good to see a different take on the concept.
jQuery mobile is a nice development framework but we should be careful about how early we involved it in the design process.
It's good to have a look at what they have standardised and whether it is worth pulling into our design or not. I like the tabs, they work for a small screen but what happens when we have more than two? I'd like to see that.
I wonder if we do need the user section in the toolbar on mobile? Mobile phones are different to desktops partly because they are personal, we carry them around in our pockets all day. What are the chances of someone wanting to sign out all the time? I think it's pretty low and we can hide that option so it doesn't appear on every page.
Thanks for the feedback. I've
Thanks for the feedback.
I've been trying to refine the prototype. I have just an image to show this time
In this second attempt the idea is too keep all existing drupal admin elements (So that it will eventually require just an interface lifting not changes to code).
In the image you see the Find Content page in different states.
The Admin menu on the toolbar becomes a drop down. The shortcut drop down stays in the right side as well the link to the homepage on the right.
There's an idea of how tables could be reformatted in a mobile environment, like an accordion.
Please have a look here http://cl.ly/0l1D0u0u0P3A2T3j221Q
regarding jQuery Mobile I used it just as a prototype environment. I didn't mean to suggest using it.
Focussing on the main admin nav / header...
I thought it might be helpful to focus on one thing, the header nav / admin toolbar; see if we can get that right first and speed up agreement through one bite at a time. Rethinking the admin toolbar for mobile is I think a main priority, as it is the first point of contact with the admin interface.
I see a couple of ways of doing this: using a list or a select menu, and both are probably quite acceptable, but I have opted for a list, as this allows greater theme customisation, due to the device UI often taking over select lists.
http://labs.deeson.net/d8-mob/nav.html
My thinking is as follows:
The space available in the header is very valuable, particularly in portrait orientation on mobiles. All the primary top level navigation functionality needs to be readily available in this space, so...
I have removed the page title from the header to free up the space for important nav. Longer page titles would need ellipses and therefore become far less useful anyway.
Added a slide down "Main menu" for quick access to all admin areas. This is a big step toward dealing with the tree navigation issues.
In response to the suggested (and imo valid) focus on content creation and editing, rather than site building, I have also added create and find content buttons to give them particular priority in the header.
To save going via another server request and page which are costly to the UX on mobile, the create content button works as a slide down menu to choose the content type you wish to create and get straight to it
Please share thoughts and I will iterate, or feel free to take this code and iterate yourselves.
G
Prototype #3
I've been iterating on my prototype and coded a working version.
This is now a small module that makes the admin toolbar responsive. Using CSS and jQuery it makes the toolbar admin menu collapsible and moves the toolbar user menu in a fixed position at the bottom of the page.
This must be considered a proof of concept since the code is very rough, fixed positioned elements don't work in every mobile environment (iOS 5 supports it, other platforms I don't know) and the interaction with the shortcut toggle isn't without issues.
The idea is to be consistent with the current desktop implementation rather than rethink it completely.
The advantages I see are that it won't require many high level code changes (almost everything could happen at the presentational level) and people already comfortable with the desktop UI won't experience a completely different environment. (The home link, the shortcut toogle and the user links are all still available).
There's a live demo available here:
http://www.trentaquattro.me/drupal/
user: demo
pass: demo
Login and then resize the window to see it in action on a desktop browser.
So far I tested it on Safari, Chrome and mobile Safari.
The module is here:
http://cl.ly/410k211c330r401r3R1r
Download, install and disable the overlay to test it.
I'm curious to hear what you think.
Paolo
Nice work Paolo. I liked your
Nice work Paolo. I liked your approach of being loyal to the desktop interface
I think it's too much protagonism for that bottom bar: "hello user" and logout button. The main action of a site is not logging out.
About fixed toolbars: you’ll notice that the header and footer toolbars aren’t actually “fixed” as you would expect. Instead, they scroll with the page, and then are dynamically re-positioned.
This problem happens also in the library jQuery Mobile. This behavior will be fixed in jQM 1.1. See : http://www.bentedder.com/jquery-mobile-1-1-to-include-true-fixed-toolbars/
So it seems there is a work around. I don't know how hackish will be
I completely agree with your
I completely agree with your comments. Ideally the Hello user and Logout button should go in the footer of the page inline with content (not fixed) I'll try to see if I can code it.
I'll try to update my prototype in the following weeks. I found this example of responsive navigation that seems very interesting and I'd like to rewrite my code following that. http://filamentgroup.com/lab/responsive_design_approach_for_navigation/
In fact I just removed the
In fact I just removed the fixed toolbar at the bottom. The module now prints a user menu in the the page_bottom region for mobile users.
So the link to the account and the log out are at the bottom of the page.
Working proof of concept (just resize the browser) is always here http://www.trentaquattro.me/drupal/
user: demo
pass: demo
Something I wondered early on
Something I wondered early on was whether we actually need to have the user and logout links on the page in the mobile version. Just because we have it on the desktop does not mean it makes sense on mobile.
Mobile devices are pocket sized. They are personal. We carry them around with us eveyrwhere we go. Do you log out of facebook, or twitter, or your email account often on your phone?
On the desktop it's more common that you would log out to let someone else use your it or if it's a shared computer. That's why it's important to show who you are logged in as and a way to quickly log out. We don't use our mobile phones in the same way.
By all mean we should make it possible to log out. But I think we should hide that in the admin menu tree. It's not important enough to take up space on every page.
What do you think?
I think it just has to be clear
And by that I don't necessarily mean present all the time, though having it pinned down at the bottom of the page isn't bad. But if we put it in the navigation I would think we'd want to make sure it's present in the same spot on the desktop admin navigation too - so we build an association with that location. I think many problems of context come from knowing where something is on one platform and not being able to find it in a similar fashion on another.
Awesome stuff though - have really enjoyed following this thread and hope I can contribute.
Jason Pamental
[ @jpamental ]
The idea behind this
The idea behind this prototype is exactly that. Explore the feasibility of a mobile admin solution that is not too distant from the desktop version so that users don't get lost (keep context) and we don't have to study, test and code a completely different solution.
I'm trying to keep as much as possible (home menu, admin menu, shortcuts) but the user/logout links can't really fit there.
Google puts these links on the bottom of page and I think it's a good idea. They are not too much on the way but they are still available when you need them.
Another option would be to put them in the shortcut drawer.
There is also the page slide
There is also the page slide pattern. see http://srobbin.com/jquery-plugins/pageslide/ for an example.
The idea is to place the
The idea is to place the logout (and possible other technical links) in a slide container?
Yes, you could create one
Yes, you could create one "admin" button that does a page slide from left to right. Inside it would contain an expandable accordion with drupal navigation menu.
On the right you could have a user avatar that when clicked does a page slide from right to left that shows a user menu. Example. My dashboard, My bookmarks, My profile, My activity, Sign Out, etc.
Examples:
Path - http://itunes.apple.com/us/app/path/id403639508?mt=8
Facebook mobile site - http://pttrns.com/www/imgcache/320x480/screens/navigations/Facebook_Soci...
National Geographic National Parks iphone app -
http://pttrns.com/www/imgcache/320x480/screens/navigations/National-Park... and http://www.nationalgeographic.com/mobile/apps/national-parks-by-national...
http://meer.li/designs/menu-concept
http://meer.li/designs/marmiton-restos-2
http://meer.li/designs/pintale-menu-view
http://meer.li/designs/festcollect - shows menu icon on left, user avatar on right
That does make sense. I am
That does make sense. I am sure something like that and like what dodorama proposes, will be implemented ultimately. If not as a part of core, than as a module. Definitely.
Also, I think we should also
Also, I think we should also stay away from any fixed navigation on the bottom. I don't think that works cross browser/device in a reliable way.
Keep it simple
2 cents..
From my experience, mobile development is not easy or straight forward (the web/tech/standards support is still rubbish IMHO). Combine that with a drupal site that traditionally can be quite complex and you have some tasty challenges.
For my own website (wordpress) I created a highly custom design and attempted to provide mobile support. It's sooo not easy. For this reason I was delighted to use the WPtouch (http://wordpress.org/extend/plugins/wptouch/screenshots/) theme which consistently represented my menu nav and content in an easy to use manner.
Web Dev, Consulting and Design
DynamicDan.com