Design iterations for the content creation page

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

yoroy's picture Only local images are allowed.

Over the last few months we have been working with Jared Ponchot, on redesigning the create content page. Based on our research and further discussion we chose a direction for which we developed more detailed designs.

The research primary conclusions that we applied are:

  • Keep the current approach of listing content fields in the main area but look into more ways to group related fields beyond fieldsets.
  • Rework the vertical tabs pattern into a less horizontal space consuming sidebar. (And look into applying a similar sidebar concept to other admin screens.)
  • Move primary publishing options out of these tabs and position them closer to the Publish/Save actions.

The model below gives a good idea of how this works out in terms of placement of actual interface elements.

Image showing how we should use a sidebar, to show meta information

During this process, Jared Ponch created visual designs as shown below. Together with Bojhan and Roy each iteration was reviewed and researched further where needed. The sources of some of these iterations are attached.

We researched existing systems, contrib and various custom Drupal content creation screens, from which we brainstormed loads of ideas - we have a few of those drawings listed below.

Applying the design model

The first thing we did is introduce the concept of a sidebar that holds meta configuration that is now contained in the vertical tabs. To avoid taking too much space, a accordion pattern would work best. It allows for complex forms to scale vertically and lets short forms be easily collapsed/closed.

Showing sidebar in a detailed design, with buttons in the top right sidebar

As you can see in the concept above, this allows for a whole slew of additional designs from moving the position of our buttons to showing one or more tabs in an expanded state from default.

The major issue we saw, is that this introduces a visually very heavy sidebar which distracts attention from the content area. In the next iterations we focused on placement of the buttons and making the sidebar less visually prominent.

As you can see, Jared also applied significant changes to the visual styling of the Seven admin theme.

Placement of buttons and publishing options

Next, we focussed on the placement of the buttons and publishing options. As noted in the research these two are currently too disconnected which causes major usability issues.

One of the patterns we noticed from looking at other systems is having the current publishing state (published, unpublished) of the content item close to the Save button.

This assumes that in the future we will have more states than just published and unpublished - we hope improvement on the content staging front will make this happen.

Image showing the publishing state close to the buttonImage showing the save buttons in the shortcut barImage showing save buttons in the button with dropdown of publishing state close to the button

Above are various ideas around button placement and display of publishing options.

  1. This example has the buttons in the sidebar, using a background effect you see that clicking save means you publish your changes. Using a dropdown here instead of separate buttons, lets us to scale this to N number of publishing states. The obvious advantage of this placement is that its directly in your view and hard to miss. Which is also the biggest drawback, its visual prominence distracts from the content fields.
  2. Another idea we explored in our research is placing the buttons in the shortcut bar. This clearly separates the forms you have to work with from the Save action. This creates a dedicated space where you can expect buttons to show up. Systems like Joomla, Hippo, ModX (links are images) do this too. A downside is that it’s an unusual web pattern.
  3. This example puts the buttons at the bottom and adds some visual styling to seperate it more clearly from the content fields. This is how we already do things across core. By applying a bit more distinct styling we increase its visual prominence. The advantage is that this is an expected pattern for many. The downside is it being visually less prominent in the layout of the page, likely out of the initial view port.

These initial explorations of where we could place these buttons seemed to favor either 1, or 3. We wanted to explore 1 further, to see if we could incorporate more publishing options - something that would be far harder to do in option 3.

Publishing options

You can see a few explorations below, incorporating more editorial workflow configuration into the area. Much of this was inspired by reviewing contrib modules doing this, for example scheduler and workflow.

showing five variations of publishing options near the save buttons, from checkboxes for frontpage/published, to publishing schedules

One of the interesting things that we found is that we can bring these settings more together without requiring significantly more vertical or horizontal space. Even if we don’t get many content staging improvements in Drupal 8, contrib modules could implement the patterns shown above for scheduling, revisioning and staging content in the create content UI.

These explorations created the idea of separating the top part of the sidebar from the scalable accordion pattern. It made sense to consider the top ‘publishing’ zone as an area where very explicitly designed (customized) publishing options can be added. The second ‘settings’ zone could then make use of the more generic accordion pattern to capture all other items. This primarily to benefit the top publishing information to stand out more.

The explorations where followed by more detailed designs, where we explored how we could incorporate more configuration into this publishing area.

We concluded in this iteration that although there is merit to placing more configuration in the sidebar top it is also gets distracting. It does seem to make sense to explicitly organize this sidebar into two areas. The top zone for the primary publishing functionality, the bottom zone for the accordion with all the other settings and config forms.

We imagine that contrib solutions could then be configured to show either in the top or bottom zone. To become part of the top zone would require a very precise and minimal UI. You really want that area to stay calm and just not look like its all a lot of work. To add functionality to the accordion would allow for a bit more UI noise as most of it would initially be hidden from sight. This is not to say we should lower our standards, but lets be pragmatic here.

Extending Seven theme: detailed reviews

On top of these more fundamental iterations we also did a lot of smaller changes to the visual styling of Seven. Mark Boultons original design deliberately focussed on toning down most of the page elements to create a sense of calmness and introduce a clear seperation between backend (Seven) and the actual front-end (your site) which is to take central stage. There are some issues with how Seven styles certain page elements like the overlay close button, the secondary/primary tabs and the lack of button state styling for example, but we do want to maintain the established visual design direction.

For this we have done various rounds of more detailed feedback, from thoughts on the actual visual styling, to concerns from an accessibility and legibility perspective. Below are two examples of this type of feedback.

review of yoroy on visual elements on the page

While working on these visual details we continued to iterate on:

  • Reducing the complexity of the top of the sidebar. We started out with quite a lot of bells and whistles there but continued to move towards more static information to reduce the visual clutter.
  • Placement of buttons at the bottom.
  • Stress-testing the accordion pattern with contrib projects that add lots of options.
  • Styling of individual form elements.

Where we are now

We wanted to get our final ideas out before Denver, to give our perspective to a lot of the discussion around our content creation experience. The proposal below is not final, there are still a lot of parts that we need to discuss and iterate further upon. On the other hand, we hope this post has shown that we have a solid basis to work with here.

Below is the latest version of our design for the content creation page. A .PSD of it is attached.

To recap, the main changes we propose are :

  • Introduce a new grouping pattern in the form of a sidebar, to allow for easier scanning of settings and avoid the space-consuming vertical tabs.
  • Placing the primary publishing options closer to the action of saving.
  • Update the look & feel of Seven to solve a number of visual design issues.
  • Introduce a more consistent pattern for actions.

We would love to know your thoughts. What do you think works well? What do you think needs further investigation?

AttachmentSize
create-content-small.jpg83.14 KB
8_add-content_b.jpg217.54 KB
8_add-content_d.jpg230.66 KB
placement1.jpg22.97 KB
placement2.jpg23.31 KB
8_add-content_e.jpg233.99 KB
8_add-content_f.jpg243.19 KB
placement3.jpg24.07 KB
Joomla.png106.59 KB
ModX.png138.58 KB
Hippo.png169.96 KB
5-possible-workflow-states-small.jpg37.97 KB
5-possible-workflow-states.jpg54.96 KB
Publish-settings.png29.81 KB
sidebar-publishing-big-save.jpg36.17 KB
review-jponch-v1-small.jpg62.24 KB
review-jponch-v1-big.jpg284.07 KB
siebar-detailed-review.jpg101.21 KB
final-design-small.jpg127.1 KB
Latest.jpg230.67 KB
latest-iteration-contentcreation.psd4.05 MB
publishing-horizontal.png83.63 KB

Comments

I'm not sure I understand how

Dave Reid's picture

I'm not sure I understand how this design will work for modules like Meta tags or Redirect or any module that is currently in vertical tabs but isn't a simple few form elements and therefore needs more horizontal space.

Senior Drupal Developer for Lullabot | www.davereid.net | @davereid

You can't rely on horizontal

LewisNyman's picture

You can't rely on horizontal space as a constant. Once Seven becomes fully fluid and mobile friendly there will potentially be a lot less horizontal space to work with anyway.

These modules should redesign their interface to fit into their new homes. I don't think they would be intended to just drop in and work without changes.

Not only horizontal space,

Dave Reid's picture

Not only horizontal space, but also vertical. Some of these (like Meta tags) will be fairly substantial vertical-wise as well. The mockups only account for three meta tag fields when in reality that number is significantly more. :/

Senior Drupal Developer for Lullabot | www.davereid.net | @davereid

The interesting thing we

yoroy's picture

The interesting thing we found about the modules that bring (much) more than a few simple form elements to vertical tabs is that some of them straddle between being content and configuration. Meta tags fields could be considered being content. I'd have to look into Redirect, haven't seen that UI yet.

We pursued this direction because the majority of contrib that adds things to vertical tabs doesn't need the amount of space. But yes, there will be instances where what fits in vtabs will not fit in the harmonica. Possible solutions are:

  • Move (parts) of the UI over to the content column where appropriate
  • Simplefy the module UI to fit
  • Provide for 'big settings stuff' to spill over in a predictable way
  • Make it possible to do multi-step configuration within a single accordion pane
  • Combinations of the above

We hope you want to work with us on this!

Great. I'm of course always

Dave Reid's picture

Great. I'm of course always open to how I can improve the UI of any of my modules that touch content forms so I'll be sure to keep an open mind. This would be a drastic improvement for the majority of people that hit the create content area of Drupal.

It's just a matter of will I have the time and resources to make major changes if they're mandated or required to be able to work for D8. But that's nothing new.

Senior Drupal Developer for Lullabot | www.davereid.net | @davereid

vertical & horizontal space

andypost's picture

I think this depends on modules used.
For example, page_title & metatags needs more space so they could be placed into content area because their direct relation to content. Suppose same could be applied to redirect module

translation

Gábor Hojtsy's picture

Is translation taken into account in the plan somehow? Translations are currently a tab on nodes with a list of translations but are being reworked to use the edit form with language tabs at http://drupal.org/node/1282018 - seems like neither the existing nor the planned UI would fit into this model?

Multilingual

Bojhan's picture

What is required for multilingual to work in this screen, is for us to put forward a design for tabs and secondary level tabs. We haven't done that yet, mostly because of time constraints. We do plan on trowing out some iterations for it, the top of the overlay has a large number of usability issues.

Workflow ftw

aaronbauman's picture

I really like how these designs deal with the concepts of saving vs. publishing vs. workflow.
I just spent way too much time implementing a simple publishing workflow for a client, which provided a similar streamlining of these concepts. What takes literally a few minutes in other CMS, e.g. Plone, had to be refined over two weeks.
It would be great to see some simple workflow patterns like this in core, or a drop-in contrib module.

I also love the publish at the top of the form, and visually distinguished with a bright color.
Personally I still can't stand overlay, but that's another issue.

I think it's an interesting

AdamGerthel's picture

I think it's an interesting proposal. It's very similar to Wordpress (which in some areas is better than Drupal when it comes to content editing). The downside of this design is that it feels like it will make things less flexible. Drupal shouldn't decide which fields are "publishing fields" and which fields belong to content. That's up to the developer.

Today it's possible to create your own vertical tabs to group large quantities of fields which in my opinion make Drupal great because it adds a lot of flexibility. I don't see this design working very well together with that, but perhaps it could with some tweaking.

Another thing that I do not agree with is putting taxonomy as a group in the right sidebar. Taxonomy is a field and should be treated as such.

I also personally would like to see "sticky" and "promote to frontpage" become integer fields instead of a part of nodes, but that's a separate issue.

Anyway, this design only works for nodes, so calling it "content creation page" is slightly misleading. I don't think entities in general should be forced to use this sidebar because it doesn't really fit in most scenarios.

In conclusion: Wordpress has (I think) suffered a bit because it's grown out of its rather fixed content creation design. It's become less easy to use because their good looking interface worked well when it was just a blogging tool, but it doesn't work as well now that it's growing in functionality. Is it really a step forward for Drupal to be going in the Wordpress direction? I would have said "yes!" two years ago but now I'm not so sure. Today I often hear that Drupal is easier to use than Wordpress.

Ps. Forgive me for my Wordpress comparison, but I'm sure you're aware that it's very very similar to your approach.

/Adam Gerthel - Projektledare, Odd Hill

Same opinion

netsensei's picture

Without even skimming the text (I admit, it's late and I'm tired), that was also my first impression when I saw the mockup. The form is constructed on some of the same principles Wordpress has. From a UX standpoint, this is great since WP outrun us with a far superior interface, yet, I agree with Adam on this.

Without knowing all the in's and out's, I would be a bit wary of introducing an interface which "restricts" the flexibility we have now when one defines Fields, Entities and Bundles. "Content" creation is only a part of a wider system. Maybe we should break this open? Swentel did something cool with Renderable Elements. (http://drupal.org/project/rel) which allows one to manage the layout of any form in Drupal. Including entity (thus node) forms.

Of course, translating this kind of structural flexibility into something which is consistently visually attractive is quite the challenge.

I don't think the UI should

Bojhan's picture

I don't think the UI should be a restriction. I wonder if that's a standard response we should do for any UI we create :)

Dreaming, the layout/field ui initiative should allow you to configure where stuff goes and if needed not even leverage the sidebar. Realistically we will provide technical implementation that allows you to put stuff in the sidebar or not - I don't think it visually really matters what entity, field or bundle it is for.

Layout Initiative

stevector's picture

Thanks for thinking through the node form in this level of detail. As I understand the The D8 Layout initiative, we have a chance to satisfy many of the concerns in the comments.

To translate this proposal into Layout Initiative terms, l think Bohjan, Jared and Roy are proposing that, by default, the node edit form use a layout plugin with three regions:

  1. Main
  2. Sidebar Top
  3. Sidebar Bottom

And core would use sane defaults for which fields, checkboxes, options go in which regions.

If the Layout Initiative fully succeeds, it should be easy to change which layout plugin is used as well as which form elements appear in which regions of layout plugin. This technique of moving form elements into different regions of a layout plugin is available in D6 and D7 using Panels.

So the question of "how does this form adapt when viewed on a small screen phone?" could become "how does this layout plugin adapt when viewed on a small screen phone?" That's an easier question to answer in my opinion.

Yea, what he said

cosmicdreams's picture

If we are successful in implementing a default layout for the node edit form (like panels allows for today) then we could easier implement our own layout. So this way offers a lot of flexibility.

There's also the outside chance that something like aloha editor changes the game during D8's lifetime. Having alternative layouts for edit pages (or even per-content-type layouts for edit pages) would be an awesome thing.

Software Engineer @ The Nerdery

Love it!

alexweber's picture

I think this is great and definitely a HUGE step in the right direction!

One thing I'd consider is taking a page from Rubik duplicating the action buttons, having them both at the top of the right sidebar and also at the bottom of the page.

Oh and there's no shame in taking inspiration from Wordpress here, their content creation UI is light-years ahead of any other CMS and I'm exicted by the progress being made with Drupal! :)

Awesome!

Agreed: Publish buttons at top and bottom

rootwork's picture

The use cases are these:

a) I'm creating a new node. In this case, I (theoretically) end up at the bottom of the page. There's the publish button. Huzzah.

b) I'm editing an existing node. I'm just changing the title, or a taxonomy tag, or the first field of whatever. But I have to scroll down to the very bottom to find how to save my changes. I think the Drupal usability tests have borne this out -- people hunt for that "save" button, because most CMSes — and other programs with which they're familiar (think Google Docs) — put it at the top. WordPress, of course, puts it at the top right.

So I'd support these buttons being in BOTH places.

publish button all time visible

arpas's picture

I agree with idea to put publish buttont at top ant bottom. I think the better mettod is to display publish button all time at top If I have very long list of content fields.

Publish options at top and bottom

dcmistry's picture

I agree it should be at the top and the bottom.

Dharmesh Mistry
UX Researcher | Acquia,Inc.

Yes

headdragon's picture

Or floating. When in modules or permissions even a save between every category would vastly speed up work.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Simple vs. Advanced settings

cosmicdreams's picture

If a horizontal-limited sidebar isn't enough for complicated settings we have a few patterns we can turn to:

  1. The Additional Settings/Whitelist pattern : see Views Slideshow's additional / advanced settings where you can add extra arguments to the cycle jquery-based script.

  2. The Simple/Advanced Settings toggle : provide a seperate UI for "Advanced" settings. For mobile, this set of settings would be another level deep in the workflow trail.

  3. Tabbed UI : allow multiple field groups to use the same vertical space in the UI by providing a set of tabs and break up the fields into fieldgroups to be itemized as tabs.

I can't think of any others, but I'm sure there are other possibilities.

Software Engineer @ The Nerdery

Looks great but I fully agree

HnLn's picture

Looks great but I fully agree with AdamGerthel that "Drupal shouldn't decide which fields are "publishing fields" and which fields belong to content. That's up to the developer." and with stevector that the answer to this probably lies within the layout initiative.

It's already hard enough in d7 to get stuff out of the vertical tabs (you can get there with panels node edit form or renderable elements). I want to decide what shows in a right column and what shows in a horizontal tab (where I like to put metatags using fieldgroup and some form altering) or in a vertical tab, fieldset, ... For some sites you'll have a ux where node options are important but you could as easily have your own workflow based on a custom field that you want to position similarly as the node options. Or your user basically only has a create permission so that right column would be nearly empty, ...

Good Concepts

tyjamessmith's picture

I agree with HnLn and AdamGerthel generally. Many of these ideas seem to be leading to a very drupalish edit form: one that can be easily customized. We spend so much time trying to determine what is best, but that is different for everyone and every project. I'm sure it could become very crazy to do but think for a minute about an edit form that is customizable with blocks.

It could allow for the ui team to build a default layout, module developers to specify recommended blocks where their form elements should live, and allow a site builder to change those according to project, permissions, etc. I know that I personally spend a lot of time trying to make it so editors and content creators aren't confused when they see drupal forms.

Why note drupalize forms? Just my thoughts.

Tyler Smith
Developer

Defaults for which fields go where

cpelham's picture

RE: "Drupal shouldn't decide which fields are "publishing fields" and which fields belong to content. That's up to the developer."

You presume that there is a developer. A tremendous number of sites were/are created using Drupal without the assistance of a developer. And for Drupal to compete more with WordPress for this (enormous) market, we need to make it simpler and simpler to use, a la Apple.

This project/thread is obviously about creating easier-to-use out-of-the-box defaults, while not getting in the way of D8 layout UX/UI efforts (a la Panels/Superblocks everywhere) to allow for greater and simpler customization of which elements get placed where.

So, it's not an either/or. All I'm saying... :)


Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org

CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.

Complex Content

jeni_dc's picture

I love the ideas here, but have found that when creating complex content types the actual content area can get quite cluttered or just way too long. So I like to split up various sections of content into vertical tabs and then vertical tab the entire form, even the title. That way I can slip in a vertical tab with fields that might not appear on the main node display, but might appear elsewhere on the site such as views, front page, etc. Those are optional for the user entering the content.

So the form would show main content, images, media, front content, etc... with then other options such as menu items, meta tags, publishing options, etc, further down in the vertical tabs. I've found that clients find this easy since most stuff is hidden and they can just concentrate on what is directly in front of them, then move on down the tabs if they need to do more.

I'd love to see the concepts above include options for splitting up the main content area. The horizontal tabs idea is interesting, but then adds more complications with more areas to look in for more options.

I absolutely love the idea of "dupalize forms" from above, to make it easy to move things around as you see fit. Then forms can more easily be customised per project, content type, etc, as needed.

smell like a teen spirit...

karlos007's picture

i started using drupal. i love field_groups, my customers and users love that. and now you are to give me wordpress? no, thanks.

field groups would stay

stevector's picture

Nothing in this proposal would eliminate field groups. Field Groups is a contrib module and could work the same way it does in D7.

I really don't like this.

IceCreamYou's picture

I really don't like this. Workflow should be a single pass down the page. I don't want to have to get to the end of a long content creation form and then have to scroll all the way back up to the top just to look at another column of settings. It's awkward.

FWIW, OpenAtrium does this (or at least they used to, I haven't used it in awhile) and this is near the top of my list of things that annoy me about OA.

scrolling

cpelham's picture

What if the right sidebar content scrolls down with you so that it is always visible?


Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org

CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.

scrolling

cpelham's picture

Ah, but then on smart phones it will likely all be in one long column anyway....

but if the settings are at the bottom, then sometimes that placement will be inconvenient. say you re-open a node just to change a setting. Then you have to scroll all the way down.

it seems there would be scrolling no matter where everything is placed...


Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org

CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.

Doesn't matter, it still

IceCreamYou's picture

Doesn't matter, it still disrupts the natural top-to-bottom flow.

Longer forms

Robert Castelo's picture

Very much enjoying reading through the design discussion going on here!

Would be great to see a design which includes field groups for the content fields, a logical grouping of fields is one solution to make longer forms less intimidating.

I'll hold up my hand and say that I'm one of those people that switches of the overlay as soon as they start a project - the transparency effect is to noisy and distracting, prefer the whole interface to be dedicated to the mode I'm in, so would also be interested to see the form design without an overlay.

Like the direction

Noyz's picture

I'm in favor of the design. It addresses a lot of the issues we see in Drupal Gardens. I think URL redirect and Meta Tags could fit into this modal - as well as any other module that I've seen. Yes, it will take some work, but IMO it would be worth it.

I also believe that workflow will mostly be a single pass down the page - at least most of the time (which should be our goal). Most vertical tab settings have pretty good defaults - meta tags being one of them. As a content creator myself, 9 times out of 10 (maybe 9.9 times out of ten) I skip right over the vertical tabs - they're just in my way.

Right direction.

Clean's picture

My design. See attached:
Only local images are allowed.

Idea:
Surpass wordpress in one leap, more zen. Aim Apple.
We don't need much texts.
Make it shorter, scroll less.
Compact things and utilized those waste white space.
White space and line must have meaning to exist.
Kids can use minimal Apple UI, so people should know how to work with minimal UI nowaday.
Minimal is standard of mobile interface. The day of desktop is passing.
Go the right direction for most users, accessibilty could be solved in the process because that's smaller group of users. Even that's almost requirements, there should be some flexibility. If apple can break, we can break (some of them) too.
The 2nd column can also simply place under the first column when in small screen mode. Move publish button on 2nd column to the end, so there're 2 place to find publish button at the middle and the end of page. Simple.
In fact, on the 2nd column I prefer define things by white space than line or gray area, they are noise when repetition happened. I like those glowing& gray out buttons. It mimic real world appliance buttons. I'll find more time to improve and minimize it even further.

Suggestion:
Comments should attached a proposed design or images to explain your problems. Otherwise it should not be so important because you can't find time to do it, right? . Skecthes help finding solutions. your ideas can come by doing, from even napkin sketches.

Wish everyone all the best ;)

Youtube screen size button.

Clean's picture

Only local images are allowed.

I think there should be 'Youtube screen size button'-like.
To toggle normal/concentrate/full-screen writing area.
Otherwise, those wordpress full-screen mode.
This design also shown that the 2nd column space still able maximize, which design to solve when we have long 2nd column to scroll less ?

Big writing mode is a must-have.

2 Column have clear benefit.

Clean's picture

Only local images are allowed.

2 Column have clear benefit:
- More infos can be glance at the same time, less scrolling.
- It's simplify things for complex site.
- If we can shorten the page, Sidebar save button can be disabled/enabled.
- We should considered scrolling distance to be an important part of usability.

To get the benifit of 2 Column, we may don't have to lessen the main writing space.
To my analysis, 2 columns give clear benefit. I've experince some site which have 3-4 screen back-end to scroll. That's horrible!

I found modules UI could try re-think about minimal, I find many have too much white space and end up very lon scrolling is needed. And some element is not that much necessary to exposed.

What about ?

Clean's picture

Only local images are allowed.

If we can break the 2nd column like this, we could gain a lot without lost anything much with new design.

Sorry, if they may look out of principles. I've nothing but passion.
Mainly I'm architect who design buildings.
So I apply building space planning on it.

Thanks to everyone who drive this initiative, especially yoroy and a few others.

Thanks virtual, your passion

yoroy's picture

Thanks virtual, your passion is clear! I put in width="100%" height="100%" for your images to make them fit. If you can, please attach your designs to the original wiki post above () so we don't lose them.

Don't know even how to do it!

Clean's picture

Don't know even how to do it! Please put it as another alternative design.
I don't know where to put in that brilliant post. Also my english is troublesome, someone better do it.

And I means thanks to Yoroy, Bojhan and others.
My alternative design come from your post and sketches.

I really think people should do screen capture their preferred and use-case for Drupal backend. So others could understand what priority of problems need to be resolved and the impact of changes.

-1

Noyz's picture

The original proposed design is better because it follows the rule that fewer left edges results in a cleaner, easier to grok design. By center justifying, you're breaking that rule. All of which works against the issue that Drupal is intimidating and looks hard to use.

Other issues:
1. sidebar links are lacking affordances that information is underneath. Some might think those links take you off the page.

  1. Text is easier to read in smaller widths - which is why news papers print in small columns. Stretching the body to fill the width goes against this rule

  2. Sort of an additional thought to my original issue, but this is a form, that really seems to be broken up now.

  3. Side by side fields can create tab orders, and I'm not sure how it would work with manage displays.

I do however like the Publish drop button. I assume you are leading with Publish, but Save Draft is underneath. Very nice.

The fixed green save button

westie's picture

The fixed green save button in the top toolbar looks great for me. We have so many long content types and it saves the hassle of having to scroll all the way to the bottom (or top as others suggested) for those quick edits...

The problem with fixing the

karschsp's picture

The problem with fixing the green buttons in the toolbar is, what if toolbar.module is disabled?

Don't assign it to the

headdragon's picture

Don't assign it to the toolbar module just assign the green button to the green button module and let it display in a fixed position. I am so tired of scrolling to the bottom of the module area looking for any dependencies and the save when I can just hit save in the menu.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Agreed. Think of most desktop

westie's picture

Agreed. Think of most desktop apps, like MS Office... they always have the save in a toolbar fixed to the top of the screen.

Really exciting!

fschaap's picture

Wow, this is really exciting and I hope this gets into core.

It's almost exactly what we have created on Drupal 6 with the Node form module and custom publishing states + custom Dashboard.

We've created a 2 column content creation page, with left column = content and right column = meta.

We're using pretty much the same exact content staging states as you're proposing.

Since you're both in the Netherlands, feel free to contact me if you're interested to have a look at our implementation.

Field descriptions

eigentor's picture

So you decided to kill the regular field description in the UI.
While I welcome this, I was looking for some rationale for it in the explanation.

Maybe you can add a paragraph on why this is much better.
Else: way to go!

Life is a journey, not a destination

Not quite

yoroy's picture

There are a few descriptions in http://groups.drupal.org/files/Latest.jpg
But yes, we've dropped quite a few. The main reason is outlined by Jeff in his comment in the research thread:

  1. Users don't read. All that help text doesn't help, it just makes the UI look hard.

But you can't penalize users

RobW's picture

But you can't penalize users that do things right, or sites that require descriptions because of complexity, because of a lazy majority. It's akin to cutting off the hand because the finger hurts. The default may be empty, but descriptions have to remain a configurable option.

A little off topic though.

The descriptions should be

westie's picture

The descriptions should be available because often they will be important enough a user might want to read them. Imagine an Intranet with strict compliance guidelines for fields.

I don't think the full text should be too dominant and clutter the UI but we could have a tooltip...?

It is available, just

Noyz's picture

It is available, just disabled.

Wow ! Really impressed by the

jide's picture

Wow ! Really impressed by the work here. Finally something visually appealing, well thought, well designed, clean, logical.

Your proposal gives a new notion to the node form : Content on the left, attributes in the sidebar, and that totally makes sense.

My only concern with the last iteration may be that we have publish status at 2 places : at the bottom, near the "save" button, and at the top of the sidebar. It may be confusing to have 2 things saying the opposite : (Save) [Published] and "not published", although one is the current status of the node, while the other WILL be the status once it's saved. Maybe there is something to be done here.

Good work guys !

bootstrap?

lathan's picture

The UI elements look a lot like bootstrap (github.com/twitter/bootstrap) is this an indication that we are looking at implementing that framework in Drupal with this theme? I know there are some licensing issues that have prevented many them developers using that framework.

We've designed this without

yoroy's picture

We've designed this without thinking about implementation, those considerations come later :)

what about updating the media field?

idflood's picture

Great design, can't wait to see it working :)

I've showed this to a colleague who build mainly wordpress sites. He found this great but also pointed out that the media field could be better.

  • Display description on top to stay coherent with other fields
  • use the "html5 drag and drop"

Here is a quick mockup:
Only local images are allowed.

This is something that

Bojhan's picture

This is something that contrib could surely do, sadly in Core this will require some significant work. I would love for this to happen though.

drag and drop would not be

westwesterson's picture

drag and drop would not be very relevant on a tablet or touch screen phone... like bohan said, probably not core material.

very nice

joedag32's picture

I'm really impressed with how this is looking. While I do agree with many of the concerns in the comments, I know many of the clients would really love these changes.

how does it look when contrib fields are added?

cpelham's picture

I continue to think that a right sidebar for configuration makes sense, but I think it is really important to recognize that it only looks really neat when the columns are more or less the same length. In actuality, many sites will have a variety of content types and contrib modules, making the column lengths very unpredictable. So, we needn't get hung up here on trying to make it look really pretty. Just rational.

Having content on left and config on the right (with save as draft/preview/publish/etc buttons on top and bottom) may be a sensible default and good UX guideline, but we will have to leave it to the site builders to make it look visually pleasing in all cases. The Panels in core tools that we end up with in D8 should hopefully make this easy to adjust. In fact, as part of the workflow of creating a new content type, site builders should at least be given the clear option to (quickly and easily) drag and drop these elements around and save the revised create/edit content template for that content type.

We may also want to consider whether the edit screen should have a different UX than the create screen.


Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org

CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.

Great work, some thoughts.

RobW's picture

Great work here, I'm looking forward to these ideas becoming a reality. Some thoughts:

Save/publish buttons on top and bottom: Drupal too often tries to make everyone happy, resulting in most people being not unhappy, but also a directionless ui. I think the emphasis should be on designing for clarity, even if it may require some current users to go through an adaptation phase. It may have some current users grumbling, but after a month they'll wonder how they ever did it any other way.

[edit] My point here is that it's better to pick a single place to put the save/publish button, and let users adapt. Either the bottom or in an always visible sidebar seem like the best choice to me. Perhaps a few options need to be prototyped to see how they function in a live application.

cpelham: "So, we needn't get hung up here on trying to make it look really pretty. Just rational." Exactly.

Vertical and horizontal space: Content creation forms are going to have to be responsive. That's it. No use resisting, it's inevitable.

Some sites will need to shuffle things between the "content" and "sidebar/meta" areas of the form. Any system that makes forms more configurable (especially without hook_form_alter), be it D8 Layout initiative or something else, will be a win for the Drupal community.

What about if the save and

Robert Castelo's picture

What about if the save and workflow state controls are on a row at the top of the form which stays at the top of your browser as you scroll down through a form?

Similar to the table headings on the permissions page.

That would make them accessible wherever you are on the form.

Absolutely agree. Some node

Graeme Blackwood's picture

Absolutely agree. Some node edit forms can get very large indeed, so even top and bottom isn't going to be ideal. Drupal already does this with table headers and there is no reason why it can't and shouldn't be done for node save draft/publish buttons.

That sounds exactly like the

headdragon's picture

That sounds exactly like the right idea. LOL I had to go check.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

It depends on the more common use cases

shmilov's picture

First guys, you did a great work and generally I think your proposal is very interesting.

Would like to share few personal thoughts:
Before I got addicted to Drupal I worked also with Wordpress and your proposal is similar to the Wordpress UI (as already mentioned above). When editing and updating existing content this is a comfortable solution since you can submit the changes without the need to scroll down. Moreover, this is a great saver for content types with many fields.

But on the other hand there is something very important as I see it in the current Drupal 7 UI - the need to scroll down the page makes the user to review all the content once again and only then submit it.

Creating a content is very similar to filling a form and submit buttons are always appear at the bottom - the last stage of the process.

I think the optimal solution will be somewhere in the middle and the suggested layout by "Virtual" can be the beginning. I disagree with aligning the elements to the center.

Thanks. will keep following.

The plan has every thing else

RochelleBr's picture

Only local images are allowed.The plan has every thing else in its favor.Only local images are allowed.

Right direction 1st picture is hot.

headdragon's picture

I really like that design.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Floating Buttons as alternative?

dotmike's picture

I was at today's UI Core Conversations. Love this group's dedication!

I dont know if it has already been suggested, but what about we look into having floating buttons when the bottons scrolls down. This will enhance the user experience because the button's are:

  1. Always available
  2. They are at the same location

Here is a possible mockup:

Only local images are allowed.

Magento has the same implementation and it works pretty well for those cases where the user is doing something quick 'in the middle' of the page.

The same design pattern can be applied for pages like the module admin page where the page is long and the buttons can be accessed quickly without requiring the users to scroll all the way down.

I like this mockup. In

karschsp's picture

I like this mockup. In addition, that floating bar can be used for other functions as well, such as a WYSIWYG editor (depending on which field you're in), etc. I was in the "5 Things We Need to Do for a Completely Awesome Content Editing Experience" session with webchick and Chris Strahl where they demo'd other CMSs such as CQ5, Squarespace, etc. One of them had such a toolbar across the top.

Of course, with Toolbar, Shortcut bar, this new content editor bar and the Panels IPE bar at the bottom in D8, we'll have no room left for actual content! office_ribbon.module, anyone? :P

I set the Admin bar to float

headdragon's picture

It took a bit to get used to. It floated on the page down about 1/4 inch instead of sitting at the very top and I kept thinking my Drupal install was in trouble.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Nice mockup. I think this is

RobW's picture

Nice mockup. I think this is a good a good direction to explore.

Instead of a 100% width bar across the top, I think it might be simpler for the buttons to stick in the sideabar, and allow wysiwyg floating toolbars to take care of themselves in the main content area. Probably going to need to prototype all of this to see if it's worthwhile though: I can see a constant waterfall of sticky headers disorientating users and reducing usability.

Also, it's good to know that there's some high level interest/discussions on content add/edit ux at Drupalcon! Thanks for the reportage, karschsp.

I have used floaters in

headdragon's picture

I have used floaters in regular HTML that had buttons or links in them so I am sure it can be done in Drupal if it kept small about 120 pixels wide that worked well years ago.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Here's a peep at floating

Mojah's picture

Here's a peep at floating buttons we've been having tremendous success with in our user testing of the node form.

Only local images are allowed.

Thanks for the great work and awesome comments everyone.

[edit] I wanted to add, that we tried the buttons at the top, but from our testing, we found that our users (right brained, non techo creative types) understood and preferred the buttons at the bottom.

I'm sorry for the cross-post

alex.designworks's picture

I'm sorry for the cross-post from http://drupal.org/node/1510550#comment-5872880, but I could not resist.

I've also placed buttons in bottom-only OR right-only OR both on my D6 and D7 sites, but it usually confused users: the ones that firstly saw buttons in the bottom always scrolled to the bottom, despite having buttons on the right at the top; the ones who got used to the buttons on the right would usually scroll to the bottom to check that content is correct and then would go back (!) to the top right to save the content.

So, IMHO, the idea of buttons in the semi-transparent sticky panel is great, but I would put them at the bottom of window.
They would be always visible and accessible when any field is filled-in and also on validation error with long forms (you would not have to fix-scroll-save -- just fix and save).

Also, placing panel at the bottom would avoid the confusion with top admin bar.

That looks very nice

headdragon's picture

That looks very nice

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Conclusions

Bojhan's picture

I have done a walkthrough all of the comments, it is really interesting to see the variety of feedback and all the visuals to support the discussion. It is really exciting to see this much great feedback, it is always a bit scary to put proposals like this out!

My conclusions are purposely short, and do not cover each comment, they try to draw from the trends in the discussion:

  1. In general there is consensus that adding a sidebar is the right way to go, although there are some concerns regarding mobile friendliness - suggestions are proposed to solve it.
  2. "I want to decide where stuff goes" is often voiced feedback. We imagine that with the Layout initiative, any developer/sitebuilder should be able to configure where fields/settings go - and core only provides a default (which can be overridden).
  3. Buttons everywhere! It's clear that people want buttons on other places than just the bottom. However we have not reached consensus where that might be. This is a tricky issue - there are many arguments for and against to be made. However more importantly, it is a discussion we can continue to have while we move towards implementing the ideas that reached consensus (to keep in mind our timeline).
  4. Contributed modules will require some redesign to work within the boundaries of the proposed design. We will need to provide clear patterns to help with this transition, and figure out a few unresolved issues; tabs, secondary level navigation, embedded UI's (token UI) and field specific designs (media).
  5. There is a lot of support for improving the way we handle workflow within core, and its positioning close to "Save" (either as dropdown, or dropdown part of the button).
  6. Further simplification is proposed by several, a prominent example is noyz his screenshot. Which we can support by providing configuration to hide certain VT's per content type - where core provides defaults.

Does this sound about right? If it is, we would love to start moving towards implementing this! Anyone up for helping out with getting this major improvement done?

My hope is that at Drupalcon Denver, we can resolve some of the design challenges around tabs/secondary tabs and make a start towards putting this into actionable issues.

Thanks!

If we change the core

headdragon's picture

The contributed modules shall surely follow. Though some modules are already ahead in the UI. Maybe we can get them interested. I for one would love to see panels and cTools as core items.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Denver sprinters

yoroy's picture

Bojhan provides a good summary I think. For the Denver code sprint I'd be interested in rough prototype code that takes a first stab at:

1: Moves existing vertical tabs and submit button into a sidebar. Buttons first, vertical tabs second
5: Move the publishing settings in the last vertical tab out of that tab (the tab is removed) below the submitbutton

So, some code that mocks up a sidebar with: submit/preview/cancel, then published/sticky/promoted options then finally the vertical tabs. Aim for a sidebar of around 30% width.

Any other thoughts on how to break this work down technically most welcome.

For Denver code sprinters wanting to work on this: I require crappy code for this! We want to be able to test drive the general concept as quickly as possible.

Issue?

karschsp's picture

Is there an existing issue for this or should I create one?

Side note, we should find a

Noyz's picture

Side note, we should find a way to organize people willing to do prototype work. It's a huge need.

Ready and willing

BJ___'s picture

I'm in room 401 and ready to go. How quick of a mock up is needed ? Would it be an idea to do this with panels ? Or is it important that it's closer to the eventual reality ?

It should look like the mockup

Noyz's picture

how its built shouldn't matter as long as the test participant isn't exposed to the build.

Possible to get the actual mockup file ?

BJ___'s picture

It would be great if it's possible to get the actual fireworks, photoshop, or whatever file.
Is it possible ?

A personal github repo with

dotmike's picture

A personal github repo with an agreed name might work

I like a lot of these ideas.

KarenS's picture

I like a lot of these ideas. I think everyone is in agreement that we are setting defaults not locking this down, so anyone who wants/needs fields in different places will be accommodated so hopefully we can avoid too much bike shed discussion about which fields go on the left and which on the right.

A few more thoughts:

  • I agree that omitting the descriptions makes the form much cleaner. But there is also a reason for the descriptions. I would like to see a help icon by each field that could bring up the description, either in a modal window or by expanding the field to display it. Having them hidden by default is a good move though. Especially once you've done this a few times you don't need the descriptions any more and they just add clutter. Or we could do what some of the apps do -- show the descriptions to someone who has never used the form before and hide them after that. Not sure if that is good or not since the new user then gets the more cluttered look.

  • Just noting that we will need a right to left alternative for right to left languages.

  • I agree that using the triangles to indicate that more information is hidden below is really important.

  • After listening to all the mobile conversations at DrupalCon, I am wondering if we should be designing for mobile first, rather than as an afterthought? Create a design that works on mobile and unfold things to the left or right for wider screens.

  • We need several regions and layouts and the ability to put any field into any region. We also need an easy way to indicate if the field should be displayed in a vertical tab (and what would the mobile version of a vertical tab be?) Maybe when you select vertical tab you get the standard vertical tab in a wide region but it automatically switches to a collapsed fieldset if the field is in a narrow region or on a mobile screen?

thanks karen

yoroy's picture

I put up a first idea for a mobile create content screen in http://groups.drupal.org/node/218594

thx for your work

therustyrobot's picture

Thanks for your work on this Roy and Bojhan - I look forward to getting involved around here.

This looks great!

jphelan's picture

This looks great guys!

  • I agree with RobW that we should choose one location for the buttons and stick with it.
  • blencorp's mockup make a lot of sense to me, it solves the "buttons not were I need it when I need it issue" It's always accessible whether your at the bottom of the page or the top.
  • Have you guys seen this module? http://groups.drupal.org/node/217434#comment-717959 I don't know if any if its code could be used to accomplish this, it would at least help create a working model.

Descriptions

jphelan's picture

Descriptions can take up a lot of the screen real-estate. Have you all considered something like this for field descriptions?

Only local images are allowed.

Using icons to hide

Mojah's picture

Using icons to hide descriptions worked naturally with the folk we tested on. We implemented something similar to @jphelan and like @KarenS suggested we set the tooltips to hide descriptions by default with an option to switch this behaviour on/off via theme settings.
Only local images are allowed.

The user has to click the icon to make the description appear in the modal. Clicking anywhere outside the modal or the X closes it. We did not have to teach users that clicking the (?) icon means that there was more help available. Users sometimes required copy/paste functionality on the description field, so it's important that the modal remains open when copying and pasting description text. We colour coded all elements related to help or more information.

Only local images are allowed.

This is GREAT

headdragon's picture

This is more in my mind as the best way to get info. A long enough delay they don't pop as you move over them but short enough to not slow you down.

In Tigra menus for HTML you can adjust every single function of the menus on a case by case basis. On the pops and delays I have found that the time before it pops is less than 150 milliseconds will be to short and cause site flickers whereas over 250 is like where is it syndrome.

I hate to say it, Javascript functions bring more viruses to windows so if there is way to pop the help text without javascript say in PHP that would be a huge plus. I use Safari in developer mode and the number of scripts that never finish loading is insane. I rarely have those code loading problems with PHP.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Hover Description

dcmistry's picture

I like the idea to show descriptions on hover. Also, we should make sure that the (?) icon should not attract attention plus it should be closed to the field. In one of the early prototypes, it was way to the right of the field and the field title was on the left. This is against the Gestalt principles. Users read the field title, and if they do not understand it, they go to help (?). Hence, this should be in closed proximity.

Dharmesh Mistry
UX Researcher | Acquia,Inc.

Perfect solution

alex.designworks's picture

Some field description may contain not only general submission guides, but also additional information, that explains values meaning. This is especially important for custom fields with multiple hierarchical values, such as hierarchical selects.

I've used this approach on one of the websites and, as it greatly reduced the height of forms, user feedback was quite positive.

One note here though. As description can contain HTML and therefor links and other interactive elements, it would be good idea to display the hint when (?) is clicked rather then hovered. However, this particular setting can be adjustable.

Descriptions

RobW's picture

Great discussions and direction. I really want to try and find some time to commit to this.

Re: descriptions

Proposed solutions (and some I see myself) with pros and cons:

  1. Descriptions are shown in the normal fashion or hidden entirely by site builder in config.
    • Pros: clean, simple, uncluttered
    • Cons: Binary choice, this descript is either important enough to be shown all the time, or hidden, nothing in between. Decision on what descripts available lies entirely with sitebuilder
  2. Descriptions collapse, expand within document flow when placeholder is clicked. Site builder specifies default collapsed/expanded state.
    • Pros: Allows descriptions to be available to the user if desired. Simply understandable and maintains site flow
    • Cons: Uses more space than the other options. On expand pushes all content below down, if animated possible performance hit (?)
  3. Modal Dialog for descriptions
    • Pros: Very compact, very uncluttered
    • Cons: Descriptions require user input to be read; users could skip important instructions if lazy. Modals overlapping other content (sidebar) adds visual complexity that could overwhelm a user. Does not necessarily work on mobile design; ui would probably follow two patterns.

We can also think about combinations and refinements of the above three. Modals with important descriptions inline, modals that become visible when the user gives focus to the field. Let's keep mobile and touch in mind as we make these decisions as well -- that bridge will have to be crossed soon.

Descriptions

jphelan's picture

RobW you make some good points. "modals that become visible when the user gives focus to the field" is a good idea. MailChimp does that.

Only local images are allowed.

Only local images are allowed.

I tried implementing something like this on my sites. It works well on textfields and textareas but is some what inconsistent on select and checkbox/radio elements. MailChimp mixes it up a bit, sometimes they show the description under a checkbox, other times they have a more info link and small window similar to my concept above.

Only local images are allowed.

I would think a combination would work well like they do. It would also be nice if descriptions had more classes to give better styling control depending on which element they are associated with. (e.g. class="description description-textarea")

Another consideration is that

RobW's picture

Another consideration is that unlike the Mailchimp team, we have no control over what people are going to write as their descriptions. Two sentences? One hundred words? "Plaintext only"? If this is going to be more than a theme (i.e., a new set of cross theme functionality and recommended patterns) we need to take that into account.

Modals that cover other information that the user may be looking at/relying on to fill out the current field could cause problems. Imagine that a user is filling out a "Short/Small Screen teaser" and a "Full Teaser": it would be a usability fail if when they activated the modal for the "Full Teaser" the "Short teaser" field they were adapting was covered.

jphelan, I like your "Message Subject" example -- it keeps things in the document flow and, I assume, pushes the content below it down. Placement under the field wouldn't necessarily work for large text boxes or field groups/collections (see [#314385] for more discussion).

I can see an argument against expanding descriptions within document flow as well though: if every time you select or tab into a field the entire page shifts, it could be disorientating and potentially cause text field visibility problems on screens with touch keyboards. A flat block shaped modal that covers the sidebar in desktop size screens on focus could work well... there's not going to be a 100% perfect solution.

All very valid

yoroy's picture

All very valid considerations, I like the thoughtfulness here. Then again, we don't have to necessarily change how descriptions are handled to move forward with this. It seems like the lack of descriptions in the original designs triggered this discussion. Maybe we just proposed to use descriptions less often, only where really needed. There's a lot of 'because we can' descriptions in core right now that are redundant with the form labels.

My worry with initially hiding is that when descriptions are shown on focus the attention is directed to the description, which is not where it should go. It'll be hard to balance that. Basically, I'm not sure we need to change too much here, just work hard to reduce the amount of words used.

Agree

RobW's picture

No need to tackle all problems at once -- your initial proposals make huge steps forward in usability and grasp(grok)ability of the content creation form at a glance, and I'd love to see it working sooner rather than later because of something that could be better tackled in contrib. And when there's a lot of discussion and alternate viewpoints about how something should be done, contrib is probably the solution.

jphelan, seems like you have

RobW's picture

jphelan, seems like you have opinions on descriptions and have done some of the work and testing needed already. If you'd like to collaborate together on a small contrib modal/expandable descriptions module once the new workflow/ui gets solidified here, I'd be into it.

contrib module

jphelan's picture

RobW that'd be great. I agree with everyone's feed back, it's going to be difficult to come up with a solution that will work such a broad system. I'm pretty new to module development, I'm still tinkering with me first one but I'd love to discuss it more with you down the road.

Not sure if this is then the place to mention this but I still think some more specific classes in core would at least give themers the option to style different descriptions for different elements differently (e.g. class="description description-textarea")

I'm not an expert module

RobW's picture

I'm not an expert module developer either, but this sounds like a good excuse to practice. Let's get in touch as the design and ui/x recommendations solidify.

Totally off topic:

.form-type-textfield .description {} or even more awesomely input[type="text"]+.description.

Not a problem for clicked description modals

alex.designworks's picture

Modals that cover other information that the user may be looking at/relying on to fill out the current field could cause problems.

@RobW
IMHO, your point is valid only for the modals that are automatically shown when you tab to or hover the field. If the modal is shown "on-demand" when user clicks the (?) it is expected behavior and user should not be confused.

Also, I think that "modals" is not the right term here, since description hints may be triggered by click and closed with (x) button - they stay opened and allow using other UI elements at the same time.

As this post is about simplifying the GUI, removing extra noise, such as descriptions, is totally related to the main topic and therefore may be considered as a part of this whole issue.

How do we move forward

therustyrobot's picture

jphelan - good ideas
RobW - great points
Loving the work being done so far.

I guess I'm feeling like Drupal Groups is insufficient to organize the entire UI/UX development process - I'm not really sure where to jump in or how to get beyond discussions. Call me crazy, but is there a way we can break this all down into a project management system that would eventually end up as a list of milestones and tasks that we could volunteer to take on as we are able? In my opinion, the best results would be achieved if someone was making the hard calls and approving/disapproving work as we go along. Of course I'm new to the Drupal community but have a great desire to see it move forward by leaps and bounds.

Moving things into another

yoroy's picture

Moving things into another system than what we have is sure to make things invisible to most of the community, so we'll have to work with what groups and drupal.org itself has to offer.

Yep, technical breakdown into actionable issues is next. We'll want to open a meta-issue in the core queue. The discussion around descriptions is great, but shouldn't stop us from moving forward implementing the proposed new architecture for this page.

I'm looking for a tech lead for this!

It's on

yoroy's picture

We just posted an issue to start implementation: http://drupal.org/node/1510532

Explore the top toolbar idea further...?

loophole080's picture

Hi, I've been following this discussion avidly for a couple of weeks now. I think this is great work on an area which is really critical for the progression of D8, as highlighted in Dries's Denver keynote. Much needed, very informative, beautifully executed mock-ups and thoroughly thought provoking... But there's something that has been nagging me as I watched the discussion unfold.

I just don't think the sidebar will work.

1) SPACE / SCROLLING

It's too reliant on/restricted by horizontal screen-space and therefore not very responsive/mobile-friendly/adaptable to custom themes. For example, I can easily imagine long URL aliases that wouldn't be fully visible in the limited width of the sidebar. Or, to go the other way, cases where there may be many modules with settings to show in the sidebar or complex, lengthy settings, which means very, very long pages and lots of scrolling.

2) SEPARATION

Why do we need the settings (in general) accessible alongside the content? Also there is the very common case where a content editor may not have permissions for the general settings, so the sidebar would be blank or contain only one or two settings, which results in a lot of wasted real-estate.

Besides, don't we want to reduce screen clutter, not stuff in as much info as possible in a limited/variable screen-area? It would, I feel, be clearer and cleaner to keep them distinct.

Conversely, I totally agree that there is presently too much separation between the publishing/workflow status settings (relegated to vertical tabs) and the actions (save/submit/publish/delete buttons). These are logically more strongly related and should be grouped together. They clearly need prominence and should be easily accessible. They also apply to both the content and other settings for the node/entity, so does it make sense to have them in either one or the other section (sidebar/content form)?


In fact, I reckon you were on the right track initially with "actions on top" layout (http://groups.drupal.org/node/214898), I'd like to have seen more exploration of that. (The only polished mock-ups were with the sidebar... I feel this may have anchored the discussion a lot...?)

Which got me thinking, how about a "publishing actions" toolbar?

  • Shows publishing status summary info (moved from top of sidebar section)
  • Groups submit buttons and the publishing/worlflow settings
  • Could be floating/sticky at top of screen for easy access (degrade to top of form, or maybe both top and bottom, where fixed positioning not supported - don't think this should be in the shortcut bar)

Do we really need all the settings on the same screen as the content?

Why not stick the other settings (ie non-workflow/publishing options) on their own page/tab? That way they have more space, don't obscure/clutter the content edit form, can elegantly be hidden if not relevant and we can include a settings summary/overview. Much simpler.

I hope it's not too late to wade in on this, and not trying to set the cat among the pigeons! (I'd been working on some mockups when you opened this new thread.)

:-)

ps Can I also suggest a colour "LED" or background to indicate the Publishing status and make it more noticeable?

Interesting idea

Bojhan's picture

@loophole80 Thanks for chiming in and moving the discussion here! I wanted to give more detailed feedback on your proposal - because we did really give the "publishing actions" on top a lot of consideration.

A "publishing action" bar would mean that we could visually group meta information like we do now in the sidebar in one top bar, and group the actions there too. This is an interesting pattern, I have seen applied in small number of more enterprise CMS's.

One of our major concerns with that pattern, wasn't necessarily that its not usable. But primarily that its not a common web pattern, and not necessarily a pattern we can stretch to many other places in core. And if we do stretch it to other places in core, it would often contain far less meta information as the content entity which simply has a lot.

Perhaps a sketch/wireframe could help us explore this idea more?

Onto the separate page, this was actually a proposal for D7UX. This was met with a lot of disagreement in the community, because 1) Users will easily miss that page all together, 2) there is a lot of disagreement about the importance of the settings in VT's - we felt it was fine to move them of in a separate page, but for many people in the community they are essential settings to be kept close to the content creation process. 3) It would introduce a pattern that is hard to apply in other places, where else do we have the need for separation of object and meta information? I can only think if content type creation.

I hope I have given clear feedback on your proposals, it would be interesting to explore the toolbar idea more.

thanks

loophole080's picture

Hi Bojhan,

Thanks that's very insightful. (I just chipped in on the mobile thread btw ;-> )

So, I appreciate what you are saying about the top bar being unusual and not very relevant to other forms. A few thoughts in response...

  • The content edit screen is arguably a special case and may deserve special treatment. (Isn't that why this thread started?)
  • Another major advantage of this pattern is it solves the button placement issue nicely. They're easily accessible and prominent. This definitely would be useful on other admin forms. It also helps make the current pub status more prominent, which has been previously stated as a goal.
  • I agree there's not really other stuff with meta-info the same way as publishing status for nodes. But let's think more broadly of this as a "status summary and actions" bar... Perhaps this is an opportunity to introduce space for some summary info on other screens? For example total installed and enabled modules info on the module page? Total active, blocked users on the user config pages? Last login on user edit page? Just a few ideas... I assume we'd let contrib modules add stuff in here if they wanted too.
  • I can live with the bar being empty apart from buttons on other forms, don't see that as a problem really.

I didn't follow the D7UX conversations and wasn't aware that the separate settings page had been discussed before. My thoughts...

  • I'm a bit surprised people felt the need to have them on the same page as the content form. I'm also not convinced it works. For me, scrolling down to reach the VTs is a pain and I'd rather have them on a separate tab/page (1 click vs x scrolling?).
  • On a separate page we could provide a front/top VT with a nice full page summary of all applied settings. (I'd really like to have that!)
  • Who are these people that want the settings right next to the content? Are they developers, site builders, Drupal geeks and power users by any chance? (Who would have to be editing advanced settings frequently.) Did we ask the plain old CONTENT MANAGERS/EDITORS? You know, them lot who do all the grunt work and 80% of the time only care about the publishing options and status? From my interpretation of the recent D7UX research and Dries's keynote, I wonder if perhaps the D7UX initiative missed the target audience for feedback/testing? One message is clear - we need less clutter (ie more separation) to make things digestible and usable for the everyday Drupal user. (And we need to make the publishing status and options more prominent and accessible, as per toolbar idea above.) Maybe us Drupal fanatics need to compromise here and put the everyday user's needs ahead of our own convenience? Who are we designing for?
  • As for the general applicability of this separate settings page to other forms, I agree it's perhaps not very wide. (Although I can think of at least one other main interface where there is content and settings to handle: blocks) But there are always exceptions - this form is in many ways a special case (frequency of use by "normal" users, publishing status and options, volume and diversity of additional contrib settings in VTs) - maybe the usability benefits outweigh the consistency principle here?
  • Having said that, to take things a step further, maybe we could put the primary and secondary tabs into this too? ie have the "settings" as a tab for the content editing screen. (I believe the placement of these nav items hasn't yet been fully explored in these D8 iterations, so let's start thinking about them too.)

Ok, well here's a couple of quick sketches to explore these ideas...

Only local images are allowed.

Only local images are allowed.

Assuming the ship hasn't sailed already and I've persuaded you, I'm happy to do some polished mock-ups of this. (May need you to add some finishing touches, I don't have the expert eye for design nuances you guys do.) Couple of questions... Are we/should we be assuming use of the overlay? Are we/should we be assuming Seven theme/admin theme or just keep things as wireframes at this stage?

Then perhaps we can run a survey between the two concepts (sidebar vs toolbar and settings page) and try and include as wide a user base as possible, at the least see what the folks in the web managers/content editors group think?

Thanks again for your explanation before and I hope you find these ideas constructive, as they are meant to be :-)

I did explore horizontally

yoroy's picture

. I found it didn't allow for a good flow in reading/relating the options. Add the potential requirement to have a revision that needs an explanatory note and it breaks. Nor does it necessarily play well with toolbar and shortcut bar already taking up space at the top of the page.

I like your sketches but my biggest worry is scalability, that you're designing for ideal situations, whereas we always have to keep in mind that things will be added. We found vertical tabs provides too much room to scale things, hence the sidebar. I'm not sure a horizontal bar allows for the same flexibility.

No guarantees on ships having sailed or not (we never know either), but I invite you to take that last sketch and produce some wireframes for it. You're right that tabs and secondary tabs need work still. Thanks!

I get what you are saying

loophole080's picture

The horiz is tricky and far from ideal for even a short form, I agree. However, some of your earlier sketches gave me some ideas, so I'll have a play and see how they flesh-out. Will explore some responsive/scaling variants too.

Summaries, and default state

David_Rothstein's picture

Really interesting things going on here!

One issue I noticed looking at the designs is that between http://groups.drupal.org/files/8_add-content_b.jpg and http://groups.drupal.org/files/Latest.jpg, the summaries of each setting in the sidebar (i.e., the text like "No menu item") were lost.

To me, that makes these look exactly like collapsible fieldsets in Drupal 6. I think we know from previous rounds of usability testing that there were problems with collapsible fieldsets, so why would we go back to that? By keeping the summaries, the first mockup may be more promising in the sense that it takes some of the best aspects of collapsible fieldsets and vertical tabs and combines them.

On a related note, I haven't seen any discussion yet about what the default state of each of these fieldsets would be. Is the idea that they all start off collapsed when the page is loaded? Or would some (e.g. those with non-empty settings) start off expanded?

Summaries on accordion tabs

Bojhan's picture

@David Thanks for your feedback!

In general we did not really make a decision whether we want summaries or not. I think once we do some testing, with and without we can decide with better arguments. If you want, we can easily bring them back though. We should probably get some patches rolling soon :)

We removed them from initial view, because in testing the summaries did not seem to stop people from just looking through each tab. When we tested intermediate users, they hardly ever looked at the summaries. So its a bit unclear, for whom this functionality is - even though theory behind it is solid.

In terms of what is shown on default view. I would love for that to be configurable like, http://drupal.org/node/1510566. I am not sure if we need to expand any of them by default, we don't do that with VT's either (well menu, but that one is super weird for all participants :D)

When you are a beginner in

headdragon's picture

When you are a beginner in most case you are wrapped up in "I just want to solve this and get back to it" By the time you have become an intermediate user you have slowed down to see what the use for that did or actually read the summary. That is my experience with users in computers, shooting and machine shops

By the time most people have used a function several times they like to understand it better especially if they found something related to it not working right.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Summaries

dcmistry's picture

I think the summary field right now is not working as efficiently as it could is because the design does not handle them well. In the study that I have done, I have found this to be an issue.
The issue has been that people do not know what it is. On reading the description, they found it to be useful. Will they use it or not? Is it a 80% use case? I think so.

Dharmesh Mistry
UX Researcher | Acquia,Inc.

Oh yes, do not lose the

eigentor's picture

Oh yes, do not lose the summaries on the vertical tabs.
If there is a feeling they jump to the eye too much, the text need not be black, could be some middle to dark grey.

Beginners probably won't read the summary (would need testing) so it should be O.K. if they are a little bit fainter.

Life is a journey, not a destination

If the vertical tab-settings

svenryen's picture

If the vertical tab-settings are moved to the side, what's wrong about just showing the settings as a long list with sub-headers that don't collapse/expand?

Currently, the only logical reason why they should collapse/expand is to limit the time it takes to scroll past them and reach the save button at the end of the form.

Assuming the sidebar with those settings scroll independently from the content edit form, would most users prefer these settings to be readily available at a glance through scrolling, or would they prefer to click and expand the sections that they are interested in?

Cheers,
Sven

I think a good user

RobW's picture

I think a good user experience is the logical reason to start with the fields collapsed. A sea of settings creates a perception of complexity, which can be daunting or scary to a user who is unfamiliar with the system. It also increases the possibility of confusing accidental settings changes (although settings that a user isn't comfortable with should probably be hidden from them with permissions, this doesn't always happen).

Tests need to show if people

eigentor's picture

Tests need to show if people will find the menu settings...
But this may be a problem that comes later: if some settings need to be more prominent than others, which might apply to the menu settings.

Life is a journey, not a destination

D6 was at the bottom of the

Noyz's picture

D6 was at the bottom of the node add/edit field, where as here they are on the side. That may make a huge difference in testing. I suspect it will. Said differently, just because collapsible fieldsets failed in D6, that doesn't mean they'll fail in D8 given the new location. The new location is a more common pattern in applications, e.g. canvas in the middle, tools affecting the canvas on the right. Such use of patterns found in other tools may help to pull the design through user testing successfully. I think Bojhan has the right idea to test it and find out.

That said, I do think that data that has been set, or overridden by one or more users has to show. An interesting problem here is Meta Tags, where a given node will have defaults applied. I think the design should look hard at meta tags and ensure the solution works given how critical this particular use case is.

Also, for what it's worth, so long as we can get a prototype together, I'm happy to have our usability team put some tests around this and help guide the design to the next stage.

Make this two-column grid optional?

brantwynn's picture

Drupal calls for a number of workflows where this two-column grid setup simply will not fly. I think it would be beneficial for Drupal users to have some type of workflow configuration. Much as I am prone to turning off the "Overlay" module, I would love to be able to turn off this two-column grid and go back to the vertical workflow of past Drupal versions. There is a large amount of people who will need a different workflow configurations or simply do not want to move over to this two-coumun interface.

It has already been stated

cpelham's picture

It has already been stated that via the new D8 layout engine, we could expect to be able to override the proposed two-column solution. It has also already been pointed out that a one-column solution will be need to be provided for mobile users. Brantwynn, could you point out other use cases where a large amount of people would not want two-column as their default?


Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org

CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.

brantwynn's picture

Basic "Page" content bundle only has two actual fields. Title and Body.

Now tack on a few configuration modules to this bundle. Menus, Taxonomy, META tags, Comments, etc.

All of these configurations live in the sidebar.

The user wants to see everything involved with editing this content. They expand all the collapsible field-sets and now have an extremely long content configuration sidebar that dwarfs their content editing column.

See: http://drupal.org/files/createcontent-redesign-basic-node-1510532.jpg

Note how this looks with just META tags fieldset open and imagine if ALL of these were open. You end up with a large amount of negative space and unnecessary scrolling created by the narrow second column.

So in the case of this content type, it makes sense for the configuration to live below the body field in a single column layout ala "classic" Drupal.

Where's actually the Meta Tag

svenryen's picture

Where's actually the Meta Tag Token list in all these mockups? On my sites, the Vertical Tab for Meta Tag always gets a token list "long as a bad year" and I'm a bit puzzled how that's going to fit into the sidebar?

Also see: WYSIWYG

brantwynn's picture

Many WYSIWYG configurations use the full page width to their advantage. Users can set up layouts and do HTML in their WYSIWYG. Based on the width of the editor, What You See will vary. They can assume that their layout will carry over because the editor window is the almost same width as the actual rendered page. Using the two-column layout, the WYSIWYG becomes a WYSIAMMNTWYG (What You See Is Actually Much More Narrow Than What You'll Get). This is going to happen a lot more in the two column layout than it already does now. The small amount of chrome/padding created by the current WYSIWYG already causes this problem, but its at least manageable by simply extending the width of the admin theme to accomodate for the WYSIWYG editors imposed margins.

I thin it's in all of our

RobW's picture

I thin it's in all of our interests to wean clients off of trying to lay out pages inside of text areas. WYS is going to be different from WYG on every browser, device, and context that you serve content to, in varying degrees.

One column authoring option

makbeta's picture

Chiming in here on the use-case of one-column solution.

From experience I find that folks of the older generation (50+) don't find tabs intuitive (I've had a client call me at least 3 times because they couldn't find an option because it was under a tab), however, scrolling is something that's easier to understand and see.

I personally would like to see the toggle option for 1 or 2 column layout, so that those who are tabs/accordion challenged can create and maintain content without frustration.

re: WYSIWYG

cpelham's picture

THis is an excellent point. I don't recall much reference to making it a priority to achieve a more WYSIWYG node creation/editing experience. It is worth noting that now final rendering may vary (e.g. for mobile or for rss) so which WYSIWYG outcome should we be trying to approximate? If more views and editing will take place on mobile devices than on laptops/desktops, should it still be a goal to approximate the desktop theme's final look and feel within a WYSIWYG node creation editor?

I am slowly becoming more and more persuaded that a default one-column layout is the way to go.

One way to overcome any perceived hassle of needing to scroll down past a long node body form element to reach other settings when editing a node would be to create an anchor link at the top to "settings" that would quickly jump the page down to the settings fields.


Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org

CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.

re:WYSIWYG

headdragon's picture

I use wysiwyg mode a lot but for checking. I work in pure html unless css is glitching. If you use WYSIWYG mode and add styles look how much more code is added for that little change in the color of something. color: 0,0,045 font: serif, margins: 0,0,0,0 and so on. The browser must read all that. Now since the site is already using Serif and nothing but the color is changed then color is all that is needed. In the HTML days I would promote my business by looking at the source code of sites and telling the future customer I could speed up their site.

Back to my original thought if I go back into source code and remove all that, sometimes it comes back. WYSIWYG needs to generate only the style code that is really needed. Drupal is a great product and the teams and developers have been doing a wonderful job. I first used 4.10 and I did not use it again until 7 because of the improvements.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

OK, throwing my two cents

RobW's picture

OK, throwing my two cents back in here:

We are Drupal / We are not Drupal

We have to remember that Drupal is a huge collection of disparate users. As a result of its very strengths there are going to be hundreds and hundreds of use cases and workflows. One collumn or two collumn layout, publish options at the top or on the side: these conversations are important to have but only if they are working toward a solution.

If we are discussing what's best for our use of Drupal we'll just go around in circles forever -- each of our use cases is valid and positive. But what Bojhan and Yoroy have done is listened to the conversation about the future of Drupal at the highest levels, defined from that audience and goals, and made informed suggestions for the default content creation page. The audience is wide, nontechnical, site users. The goal is friendliness, approachability, ease of use.

I'm not at all saying that we shouldn't put our most constructive, critical eye towards this redesign to help make it the best it can be. But the constructive part is understanding audience, goals, and the proposed future direction of Drupal, and giving critique inside that framework. We'll still be able use our particular workflows, most likely with some additional configuration or custom code. But to keep this issue productive we have to consider Drupal as a whole, which may not fit with how we (and I'm including myself here) have become accustomed to using it.

Exploring the toolbar idea further

loophole080's picture
  • toolbar concept, edit tab
    Only local images are allowed.

  • toolbar concept, settings tab
    Only local images are allowed.

loophole080's picture
  • node edit narrow
    Only local images are allowed.

  • node edit mini
    Only local images are allowed.

  • node settings narrow A
    Only local images are allowed.

  • node settings narrow B
    Only local images are allowed.

  • node settings mini
    Only local images are allowed.

loophole080's picture
  • minimal toolbar for node create screen (quiet mode)
    Only local images are allowed.

  • standard toolbar for node create with inline help and breadcrumb
    Only local images are allowed.

  • standard toolbar for node edit and breadcrumb
    Only local images are allowed.

  • standard toolbar for node edit variant with breacrumb inside status info box
    Only local images are allowed.

  • node edit toolbar with extra checkbox and textarea
    Only local images are allowed.

  • node edit toolbar - edge case with "quite mode" status info (ie minimal info) and expanded options textarea
    Only local images are allowed.

loophole080's picture

A few more mock-ups to follow soon, demonstrating the toolbar pattern with different uses for other admin screens (blocks, content, menus and modules including example contrib module integration)...

Same pane, but at the bottom

alex.designworks's picture

I'm really glad that someone considered another angle for this issue.

My thoughts about your design:
- Currently, the panel takes too much vertical space because of font size. 'Published' and other ones can be reduced a bit.
- I love the idea of status indicator - it really catches the eye.
- The panel can be put at the bottom and will be always sticky - title, body and other fields will be the first items on the page (content first, then settings) and content info with buttons is always visible. Also, the BG can be made 90% opacity (but all elements are 100%) just to demonstrate that there is content behind the panel.
- If the panel is moved to the bottom - breadcrumbs will stay on the 'white' part of the page as in D7.
- I like the idea of separate page for settings. I do not know how ppl would not be able to find such tab, especially if it's location is demonstrated to them at least once.
- Mistakenly considered content parts, such as taxonomy, should be placed to the content editing (taxonomy is a field, not a setting, and is directly related to content, therefore its placement on the content editing page is logical). Maybe because of such content parts other community members do not want to have settings on separate page.

Taxonomy

RobW's picture

Good catch, I hadn't noticed that taxonomy was in the settings pane. I suppose some other cms's might use that pattern, especially if they only allow one type of taxonomy per page, or if taxonomy only serves one function across the site...

I can imagine arguments both ways, but I see two winning points in favor of tax in the content section:

  1. Taxonomy is a field, and fields are content. Content in the content section, settings in the settings section.

  2. Even in cases where taxonomy could be considered a setting, settings have defaults, and never require user input. Taxonomy, as a field, can be required and very often needs user input. To keep workflow consistent, tax in content seems best.

Settings tab/ Taxonomy

makbeta's picture

I'm not a fan of having settings as a separate tab:

  • Hard to find for novice users, especially for those who don't work with web on daily basis.

  • For those who edit pages day in and day out, it will require an extra click to get to the settings, which gets very annoying very quickly (CMS Made Simple has that I find that very cumbersome each time I work there). Anytime I edit a page I want all my options to be under my fingertips and quick to access.

Agree that taxonomy should be part of the fields as they are part of the content.

Imho, you guys did a great

thomastorfs's picture

Imho, you guys did a great job.

As for the comments until now, I would like to add that, even while in the FOSS community you will get a lot of positive criticism, design by committee kills it every time. There has to be a leader pushing through one single vision. Otherwise you might end up with a half-baked concept that doesn't please anyone.

Thumbs up

leanderl's picture

Hello, I've been semi-following this thread without ever getting the whole picture of the discussion, which disqualifies me from having an opinion.

That being said, I would just like to chip in with a big thumbs up for the work being done here and also concur with the opinion expressed by several participants that the primary goal must be ease of use and intuitiveness for non-technical, non-drupalist users. Customising the cr*p out fo Drupal for particular situations/workflows can always be done afterwards by us who are deeply involved with Drupal. I also agree that we should in som instances take a step back and sacrifice some of our opionions and preferences and avoid design by committee, by allowing someone to lead with his/her vision.

Well, that's me stating the obvious perhaps :-)

Usability

Group organizers

Group categories

UX topics

Group notifications

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