A first wireframe for a create content screen for small screens

yoroy's picture

Sitting in at the Denver mobile sprint I spent some time coming up with a wireframe to explore how we could organize the create content page for small screens.


The general idea

  • Content creation and editing screen consists of fields, settings and publish/save buttons.
  • Show each field on its own line. One line for each field.
  • Do not show the field label ("title", "body" etc.) but show as much actual content as will fit
  • Put all non-content settings (the stuff that goes in vertical tabs) behind a single point of entry.
  • Save/publish buttons should follow what we come up with in the new design (see http://groups.drupal.org/node/214898#comment-716094 and further)

Click for larger

This is just an additional idea, so fire away with your remarks, or even better, your own sketches and wireframes :)

Mobile_create_content_page.png118.09 KB
mobile-create-content-2.png61.51 KB


Noyz's picture

iphone/android app for Drupal Gardens. Take what you will from these designs:

UI for adding a content type titled 'photo' which supports two taxonomy fields - category and tags:nnhttps://skitch.com/jeff.noyes/8mpkq/adobe-fireworks-cs5

Settings for content types (basically streamlined vertical tabs): https://skitch.com/jeff.noyes/8mpmj/adobe-fireworks-cs5

UI for blog where photos can be attached to WYSIWYG: https://skitch.com/jeff.noyes/8mpcd/adobe-fireworks-cs5

UI for multiple fields: https://skitch.com/jeff.noyes/8mppd/adobe-fireworks-cs5

Native vs. Responsive/Markup is relevant

chipk's picture

Jeff - can you say a little about the choice to build a native app over a mechanism for generating mobile-specific markup? I've raised a related question below and would like to understand the thinking around your choice. Thanks.


Noyz's picture

Your wireframe seems like a good first swag. Couple thoughts:

  1. Most vertical tab settings are rarely used though, so maybe hide those under a 'settings' link.

  2. Form items are probably going to have to list vertically. Not doing so seems like it would be problematic both developmentally as well as usage wise (scrolling y and x in order to complete)

Thanks for the input

yoroy's picture

I figured the horizontal multi-item form elemens would be too fancy.
Will look into how to handle those settings items yeah.

We just had a look at drupad.com, looks pretty good too. Focus on content creation and sysadmin tools, all the builder stuff is missing, interesting approach.

I think it is technically

LewisNyman's picture

I think it is technically possible to support horizontal scrolling using touch events and css transforms.

Because we can't have a fixed position elements, how about we include a publish button at the top as well as the bottom of the page?

Nice. Just a couple comments,

lisarex's picture

Nice. Just a couple comments, one of which I mentioned in person :)

2 Select lists, tags etc: I a 'tap to expand' might work better than swipe, simply because it might be too easy to select another option during the swipe.

The '...' to indicate there's more options is possibly too subtle.


swiping conflict?

jwilson3's picture

Lewis: How would you think the swiping functionality here interact with the proposed admin navigation swiping you demoed yesterday that simulates browser forward/back buttons (http://nav3.d8mux.org)?

I think we would need to have

LewisNyman's picture

I think we would need to have a much wider border around the edge of the content/form. If there are swipes within a page then they should take precedent over the global page swipes.

To get back to the previous page the swipe would have to start from the very edge of the screen. Tricky maybe, that's how a lot of (non-iOS) system wide gestures work.

Looks good! I think we should

edward_or's picture

Looks good!

I think we should have some differentiation between a textfield and a textarea. I think they are different sorts of things and very different content gets added to both. Just showing two or three lines of a textarea would work.

Most vertical tab settings are rarely used though, so maybe hide those under a 'settings' link.

A mistake we made with vertical tabs is that not all vertical tabs are created equally. I like the idea of having some way to sperate out commonly used vertical tags from ones that get rarely changed. Then for mobile, like was said by Noyz, we could have a different screen.

I really like how this is

calvintennant's picture

I really like how this is starting.

I generally disagree with the idea of removing the field label from the form. Forms often become too complex to leave this key instructional text out. It could become unclear which text field is which.

I would prefer to go with something like https://skitch.com/jeff.noyes/8mpmj/adobe-fireworks-cs5 for the original form that brings you too a break-out screen for that particular form item. This could then be adapted into a split screen approach for the iPad/tablet form factor, showing the form labels on the left and the selected form item on the right.

Apologies for not providing comps, I am computerless for the next couple days as I lost my laptop in Detroit on my way back from drupalcon (doh).

Important distinction re: Responsive Design..

chipk's picture

Hi folks - enjoyed meeting a bunch of you at Drupalcon and at the mobile sprint on Friday. Just wanted to raise visibility on the notion that the approach here looks more like custom markup for mobile, rather than a responsive admin design. Not making any judgment about that - just raising the idea for discussion since Responsive Design is on a lot of people's minds and it's not clear to me whether any preference might be evolving re: responsive vs. custom mobile markup, for the admin generally or for the content edit form in particular.

I'm of the opinion that

LewisNyman's picture

I'm of the opinion that Responsive Design is not restricted by the limitations of CSS.

Responsive Design means one solution, one url, one system that adapts to different devices and different capabilities. There is only so far CSS will take us to a decent 'mobile user' experience.

If we have to use javascript or some other technology to get a better product at the end of it then it is more than justified. Design should dictate implementation, not the other way around.

Hi Lewis - I might agree -

chipk's picture

Hi Lewis - I might agree - design/UX is generally paramount - but the implications are potentially deep for custom admin markup served to mobile devices, so it probably needs to be considered outside the specifics of design to assess the ultimate impact to core.


yoroy's picture

Anyone for sketching a couple iterations? All these words are getting in the way :)
We need to explore variations with labels, location and prominence of 'settings' and how to communicate the page's current publishing status.

Yep, absolutely. I will be

calvintennant's picture

Yep, absolutely. I will be getting a new machine either today or tomorrow, will work on it then.


therustyrobot's picture

I'd love to do some wireframes - I'll try and plow through my work-load here so I can jump on that soon.

scrolling and separation - redux

loophole080's picture

Hi yoroy, it's me again :-) Like these ideas, the accordion will work nicely for mobile...

But I still find myself asking the same questions as for the sidebar on the desktop thread. Do we need all the settings on the same screen as the content? Shouldn't we trying to reduce clutter rather than cram in as much as possible? (Isn't that one of the key findings of the latest D7 usability study?) And phew!?! Having to scroll all the way through settings and content to get to the publishing actions... please no!

(Scrolling is even more painful on mobile than desktop... Although yes of course I realise we need to compromise and inevitably there's gonna be a lot of scrolling.)

Not to keep banging on or bashing you, (late to the party again!) but this can so simply be improved by:

a) separating the general settings in their own tab and

b) grouping the publishing info/workflow options/actions into a floating/sticky toolbar.

From this we gain easily accessible and prominent placement for both "publishing actions" and "general settings", plus we significantly reduce the scrolling, and get less clutter/confusion on one screen. All we lose is the ability to see content and settings at the same time, which, frankly, on a mobile is never going to be possible without scrolling up and down between the two, and how much of a necessity is this anyway?

Here's a quick sketch to show some ideas of how this may work, in a pretty conventional but convenient and intuitive mobile app pattern:

Only local images are allowed.

Right, OK, I'll keep my mouth shut now! :-) And thanks again for the great work so far.

Off-Canvas pattern?

ry5n's picture

Just throwing this out there as potential inspiration: Jason Weaver/Luke Wroblewski’s Off-Canvas design pattern is pretty awesome and may be useful here.

v. 2

yoroy's picture

mockup with a top right settings link and labels for each field

Looking good so far.

RobW's picture

Looking good so far. Thoughts

  • Another direction we could explore is a form without chrome. We'll always need padding on each field -- some text heavy applications make their forms bleed to the edge of the browser window to make room for an extra couple characters. The iOS Gmail app is a good example.

  • Swipe interactions add an extra layer of action for the user to keep track of -- considering the possible complexity of a content add form, it might be best to keep everything we can simple.

  • Scrolling on a phone is a pain. These forms may be long. Publish button placement is going to be a hard decision, but the bottom seems a better solution to me. If I spent the time filling out twenty fields on a mobile phone, I could imagine feeling very annoyed if I had to scroll back to the top to submit. Give me my reward at the end!

  • What does everyone think about site branding in mobile? Will add content forms look identical across all installations of Drupal, or is there room for a theme specific mobile header and footer?

Beware the native patterns

I know these are just wireframes, but thought I would mention we should beware of native design patterns sneaking into design decisions at this stage. Have you ever looked at a mobile site that pretends to be iOS on Android or Windows Mobile? Or Android on iOS? Eargh, jarring.

Once we get to actual visual design, a consistent experience between large screen and mobile will probably create the best ux.

I think it makes sense to

LewisNyman's picture

I think it makes sense to have the publish action at the bottom at the top. There is no shame in this :)

What if we combined the toolbar from the html prototype with this page? We can add a publish + others button group and have a bigger, thumb friendly version at the bottom. Here's a really quick modification:

Only local images are allowed.


Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: