I've started to implement the proposal of separating the node form to a Content and Meta part as well as putting the node edit buttons on the right top area of the screen in this patch. It is somewhat related but can be totally independently reviewed, applied and discussed to #472066: D7UX: "Save draft" and "Publish" buttons on node forms.

The attached patch creates a new #node-form-components-menu in #node-form. The original node form is capped in 80% width and 20% of the screen takes up this new right area. That area gets all the node buttons, which are as of now displayed below each other. Also, two new links are added: "Content" and "Meta". These are supposed to hide/show only related parts of the form. The meta elements are hidden by default, while the content elements are shown. This is easily done. However, once you switch to one or the other mode, we'd need to show/hide meta and non-meta elements.

To make adapting to this API easier, I've opted to only require a 'form-meta-element' class on meta element containers, so we can hide them. However, when showing elements, we need to know whether they were hidden because they are meta, or they were hidden anyway (eg. because they were conditional parts of a form). Solving that probably needs more thinking. I've tried just naively showing all elements and hiding the meta elements when the content item is clicked, but that showed up items like hidden (non-used) text format help, so what we need to do is not so simple.

Anyway, the patch clearly has this todo to implement those two buttons. Developers have full freedom to identify meta and non-meta elements. The mockup also shows buttons showed on the same line, but that quickly breaks down with more buttons required to be shown. I've opted for a fixed length button look for now. Let's discuss that too.

On the wireframe (image crosslinked from #472066: D7UX: "Save draft" and "Publish" buttons on node forms):

With this patch:

Also, on the todo is to make the links show active and inactive status depending on which type of elements we are seeing now.

Files: 
CommentFileSizeAuthor
#48 content-meta-buttons_6.patch22.05 KBcwgordon7
Failed: Failed to install HEAD.
[ View ]
#42 content-meta-buttons_5.patch22.07 KBcwgordon7
Repository checkout: failed to checkout from [:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal/drupal].
[ View ]
#39 ContentButtonsStyle.jpg29.06 KBGábor Hojtsy
#34 content-meta-buttons_4.patch22.01 KBcwgordon7
Passed: 11541 passes, 0 fails, 0 exceptions
[ View ]
#31 472126-screenshot.png14.2 KBcwgordon7
#30 content-meta-buttons_3.patch21.03 KBcwgordon7
Passed: 11541 passes, 0 fails, 0 exceptions
[ View ]
#27 content-meta-buttons_2.patch20.31 KBcwgordon7
Failed: 11113 passes, 3 fails, 1 exception
[ View ]
#26 content-meta-buttons_1.patch5.41 KBGábor Hojtsy
Repository checkout: failed to checkout from [:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal/drupal].
[ View ]
#16 ContentMeta_1_3.png256.55 KBleisareichelt
#8 meta-1.jpg125.87 KBDries
#8 meta-2.jpg50.35 KBDries
#8 meta-3.jpg95.75 KBDries
#8 project-2.jpg45.54 KBDries
#8 project-3.jpg53.14 KBDries
#3 content-meta-buttons.patch3.56 KBGábor Hojtsy
Repository checkout: failed to checkout from [:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal/drupal].
[ View ]
#3 contentbuttons.jpg53.56 KBGábor Hojtsy
content-meta-buttons.patch2.87 KBGábor Hojtsy
Repository checkout: failed to checkout from [:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal/drupal].
[ View ]
contentswitch.jpg86.68 KBGábor Hojtsy

Comments

Status:Active» Needs review

Note: we can also move out all .form-meta-element items and their children to a new wrapper under .node-form and add a wrapper ont he remaining elements too. Then we can show/hide these wrappers. That might be the easiest solution to not guess on what the inner element status might be.

StatusFileSize
new53.56 KB
new3.56 KB
Repository checkout: failed to checkout from [:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal/drupal].
[ View ]

Implemented this wrapper approach. I took the .standard wrapper assumed, which is emitted by theme_node_form (It adds the .node-form and inside that the .standard wrapper), and added a #node-meta-elements wrapper after the .standard wrapper. All meta elements are moved into this wrapper and then the .standard and #node-meta-elements wrappers are shown/hidden based on the link clicked. Coloring of the links according to what is shown is also done.

The look only changed a little (inactive link coloring and bold links as on the mockups):

There are obviously some questions here.

- What is meta and what is not? MBD mockups show taxonomy as meta. I did not mark that meta now, but we can obviously do that.

- Are all vertical tabs meta? (The patch marks them so). Probably not. Some content types might have vertical tabbed items, which are not meta. I've had an internal working state where the meta class was added on the vertical tabs container. However, that is wrapped and furnished with other items around it in JS, so we'd need to grab and propagate that class to the ultimate wrapper parent instead. I did not go down that whole path in the published patch so far, but have half-done working code for that, which is easily completed. We should strive for letting developers decide what is meta and what not, so a customized site can change core decisions. Propagating the class from form API as opposed to hardwiring in the vertical tabs JS is therefore preferred IMHO.

- The vertical tabs are broken for me in Safari and Firefox regardless of this patch applied or not. So the meta tab is consequently somewhat broken.

Ultimately the proposed patch is a work in progress and posted as a starter for discussion. :)

Erm. This meta/non meta approach directly collides with vertical tabs, which is another way to classify some form items.

Why not having a meta / non-meta vertical tab, or something similar? It seems very weird to have two unrelated classification widgets.

Well, while the attached patch only marks those elements meta which are already in a vertical tab container, there will be many more elements, which are meta, depending on your node settings. Such as the taxonomy terms for certain content, other module added content like whether the node is a feedapi feed node, or what kind of voting API settings apply, etc. There are tons of little used meta settings, which this area is supposed to absorb.

Well, the vertical tabs have been designed as a way to put widgets into containers that reduce the space taken on the screen while not completely hiding the content from sight (thanks to the small summary line in the tab itself).

The proposed horizontal tabs have very little added value over the vertical tabs. Moreover, having both the horizontal tabs and the vertical tabs as ways of classifying widgets on the node form makes very little sense.

If we want to move away from vertical tabs (and I assume this is the idea), let's do it. But I think we should avoid two pitfalls: (1) implementing a custom UI for the node form that would be inconsistent to the rest of the administration area, (2) add another, inconsistent, layer of widget classification on top of the current vertical tabs.

StatusFileSize
new53.14 KB
new45.54 KB
new95.75 KB
new50.35 KB
new125.87 KB

The meta tab will be the home for a lot more. Personally, I think it is a Good Thing that we can move some stuff out of the way -- with our without the vertical tabs because I think it might go well beyond the information that is currently captured by vertical tabs.

For example, just look at an event node on groups.drupal.org and you'll see that there is a lot of stuff that might fit under meta for quick editing/access. The current events UI looks pretty horrible at the moment, and I think meta provides an opportunity to clean some of that up.

Ditto for project nodes -- I assume that some of that might also belong under meta which would clean up some of the UI:

Issue tags:+Favorite-of-Dries

Even though I don't quite know how the meta stuff will work out -- it might need more design work -- I think the potential is huge. Tracking it. :)

I'm not sure sticking everything under meta would be wise... but indeed groups.drupal.org event node is a great example to work with. If we can manage to design a good UI for this particular node form, everything is possible.

Following this issue for a more thorough review tomorrow, not sure how much of the design we can really think out - without looking at MDB wireframes - because doing this in Garland is going to be hard.

Re @Damien:

The proposed horizontal tabs have very little added value over the vertical tabs. Moreover, having both the horizontal tabs and the vertical tabs as ways of classifying widgets on the node form makes very little sense.

If we want to move away from vertical tabs (and I assume this is the idea), let's do it. But I think we should avoid two pitfalls: (1) implementing a custom UI for the node form that would be inconsistent to the rest of the administration area, (2) add another, inconsistent, layer of widget classification on top of the current vertical tabs.

The vertical tabs is not the end to all means. In my mind, vertical tabs have their own limits. Once you go beyond 10-20 items in the tabs, when you click a tab downwards in the list, you need to go up to see the content. The lower items in the tabs might not even show up on your screen (think netbook screen size used by many on-the-go content authors). In that case, you need to scroll to the tab, and then scroll back to the top of the right content area. If on nodes like Dries' event node example, we'd stuff all meta stuff into a unified vertical tabs, it would not work either.

With the node forms being on one screen, we might see multiple groupings of items in vertical tabs per logical groups to cover this many details. This content/meta separation puts the more complicated data away and lets the user focus on the simple content entry. What is truly meta and not will obviously depend on the content. A date field might be meta information or might be core content information depending on what you use it for, so we should keep flexibility there.

On not using this in other forms, I've been thinking of things like the taxonomy term addition form, which could also use a similar focus on the main items and meta items separately. The JS is now in node.js, since how we wrap items depends on the markup used. We can generalize this approach so that other forms can use it. I did not approach it initially that way, because we only have mockups for the content forms so far and I did not intend to shoot way above our goal of working with the content forms for now.

@Bojhan: with the core Article and Page content types, it works in Garland. At least the vertical tabs are broken for me in Firefox and Safari, so they are not worse in Garland. Also, I assumed only markup which is output by default by Drupal as far as I've seen, so hopefully that should fit in with other themes. Validation there would be highly useful however.

@Gabor I don't think you are completely following what I mean. I am saying that unless we actually design this page better in Garland it will not be able to visually fit this interaction pattren.

Regarding the meta page, people should just guess what is there? So can we get a design up of the meta page, instead of just talking about it? I don't see how we can just throw all this stuff on a meta page and make it more usable? We will definitely make just adding content easier, but how it will doing the meta stuff any easier - I don't really see. This might be more of a discussion for MDB as well.

We are totally missing rationale for such a huge change, other then look at all the possibilities. This issue is to big to discuss both, placements of buttons and a new meta section. Please split the discussion of placement of buttons back to http://drupal.org/node/472066.

Tracking…
I'm also missing rationale and agreed that Garland is not the right environment to present this in.

- Why a Meta tab?
- What is the proposed design of this meta page?

The meta page wireframe is in http://d7ux.org/docs/Wireframes_1_1.pdf - in the wireframe it's 'everything that's not title and body'.

One thing which having a meta tab might make easier is when you want to be able to quickly publish/unpublish/delete something without having to look at title/body first (even with vertical tabs those options are quite far down the page). That's only going to be the case if there's direct access to the meta tab from the content view page though - which isn't what's suggested from the wireframes.

StatusFileSize
new256.55 KB

hi all,

Mark is working on the visual design of this page as we speak and it should be available sometime tomorrow for you to take a look at.

a couple of things:

- 'meta' is a working title and should probably change (it's not very human friendly) - suggestions welcome

- rationale 1 for the meta tab - we want to keep the content entry form as simple as possible and try as often as possible not to show 'stuff' when 8 times out of 10 people don't need to see it (that is they're not going to make changes away from the default setting).

- rationale 2 for the meta tab - we want to lay out the 'meta' (aka other stuff associated with/that you can do to a node that is being published) in a way that is much more scannable and presents the most likely changes at first glance and hides the complexity that most people never need to get access to well away. To do this we need a different presentation style and more space than we have with vertical tabs.

- when you toggle 'Edit' on a meta strip will appear at the top of the published page so that you can access key tools like publish/unpublish/delete (as Catch noted above) quickly, and also gain access to the more complex 'Meta' controls.

- I'm going to propose that for some nodes (like events, groups and projects) there will potentially be some division of content between Meta and People (which should hopefully be mostly pretty obvious). I'll be writing some proposed rules up around these shortly.

- the wireframes were done a couple of weeks ago and since then we have started to get a more of a detailed sense of what exactly will go into Meta and how it will work (re: menus/navigation/taxonomony in particular), this is not reflected in the current wireframes (although I don't think it will vary dramatically from what you can see there now)

Did I miss anything that I can answer now?

I've attached a copy of the wireframe under discussion for ease of reference.

I agree that more information would be useful.

I think having a meta-tab is better than not having one (i.e. the current situation) -- just look at the event example that I shared above. I can't see how we solve the event example without putting it under some sort of tab.

Gabor's patch is obviously a work in progress -- I believe Gabor is trying to focus on getting the wireframe/structure/flow right -- the visuals and design obviously need work so it feels premature to comment on the design aspects. At this stage, we need to consider this to be an incremental step, and have faith that we'll get the design right as well.

Having faith is not always easy, so I think it would be helpful if we could try to work out the event example in more detail so we have better understanding of how things will fit in. I've pointed Mark and Leisa to this issue so hopefully they'll get to that shortly.

I don't believe one can split flow, from visual design. I was trying to look at the bigger picture, hence the request for what we where actually discussing. Since that is a discussion we have to have sometime, if this isn't the place - that is all right, please say when and where is the place.

I don't think its about faith, its about making an informed design decision. For these large kind of changes in the user experience, we need to carefully look at implications. If you think we lack faith in MDB we are totally misunderstanding each other, assuming that was addressed to me. Doing code before design is something we have been doing all along, and it rarely drives an informed design decision rather it leaves us with a solution we have to continue (even though we know it has large usability problems) because its already half-way to core.

I will remove the tags, just tell us when we can review.

Issue tags:+Usability

Oops, one tag to many.

Tracking...

BTW, Mark and Leisa have reformed their model - the "Visual" tab is now the "Meta" and taxonomy is not listed as Meta.

Issue tags:+D7UX

Adding to d7ux.

subscribing

We should strive for letting developers decide what is meta and what not, so a customized site can change core decisions. Propagating the class from form API as opposed to hardwiring in the vertical tabs JS is therefore preferred IMHO.

Exactly, seems like that's the key here. Both vertical tabs and "meta tabs" have their use case and there's no perfect answer for exactly what should go where. But if core provides both as well as an easy way to move stuff between them, then everyone wins...

Thinking out loud it seems like drupal_render() is the natural place to deal with this kind of grouping? In fact, didn't the vertical tabs patch go in with some kind of '#group' key? Not sure how applicable that is here, but it seems like if you could call drupal_render($form, 'meta') and have it pick out everything with #group set to 'meta' (as well as things like submit buttons that might not have a specific group), then it would be easy to move individual items back and forth in hook_form_alter() just by changing the #group. Obviously I have not fully thought this through, though :)

Also I'm thinking here of a situation where 'meta' would have the ability to be a menu callback, not just a JavaScript thing - not sure if that's the goal here, but if Dries's example in #8 is any guide it almost has to be. In particular, for the meta tab to be useful, it seems like it would need to get its own URL.

Regarding drupal_render($form, 'meta'): This sounds amazing. In fact, this really sounds like a (very much simplified) version of Steven Witten's fquery (http://drupal.org/project/fquery). fquery allows to select certain parts of a drupal_renderable array tree with a CSS-like syntax, matching properties of the elements in the tree. This is a topic which I have given some thought recently, once again while reading #455844: Allow more granular theming of drupal_render'ed elements. While fquery as it stands is not exaclty suitable for inclusion in core, mostly because it's much more than needed in the first place and also because it would likely be far too slow due to the use of regular expressions, a simple method to render or select specific elements of a renderable array tree would be very useful.

drupal_renderable arrays are being used in more and more places, which is great. drupal_render() has already undergone some improvements which made parts of its new applications easier. But in many places it would help a lot if we could explicitly render some parts of a renderable array tree. So a very simplified version of fquery, that allows nothing more but matching simple #properties of elements and selecting/rendering those elements could solve this issue and also allow much much finer grained and easier theming. Not only in the context of forms, but also for everything else that uses drupal_render, which fortunately is more and more stuff. I will try to get some code together that tries to do that, but I'm quite low on free time currently. Anyways, that doesn't necessarily belong into this issue. I will start a seperate issue should I get around to write some code.

There are likely other issues, usability wise, that are not yet solved - IMO discoverability of the "meta" part of the form is too low in the current mockups. Clicking a text link called meta in the top right corner to promote a post to the front page or make the update create a new revision is not as straight forward as it could be. With the current vertical tabs, here is not too much screen space used but you get a quick yet easy to skip overview of the available options (esp. with the descriptions on the vertical tabs). It's also true, though, that vertical tabs really are not suitable for, say, more than 8 tabs. I'm not saying that I oppose splitting the node form into two pages, not at all. But I think that the findability of the meta options should be improved, e.g. by making the tab visually more prominent, by improving its name and by including some more information (visually and textual) on what is to find there.

David, form altering any field to be meta is already possible. The meta elements are just picked up by having a certain class. So you don't alter the #group or whatever tag (which is used by the vertical tabs), but you alter #attributes['class']. We can obviously make that a top level attribute or somehow try and overload #group but that would imply that this meta behaviour is to be extended to many more forms, which is not yet clear (but as said above, I see possible use cases).

Also, on making the meta tab a menu callback, to my understanding, this tab works on the fly, as in you are not required to save your node before going to that tab. In fact, if you'd save your node, you would get your overlay closed, so you'd need to somehow navigate to that overlay to get to the meta tab. That clearly adds a new concept to Drupal: a "tab", where you *should not* save your content before clicking, unlike with the menu tabs. This should be put into core with great care. Drupal people are not much used to such tabs (except maybe those using the Views 2 admin UI).

StatusFileSize
new5.41 KB
Repository checkout: failed to checkout from [:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal/drupal].
[ View ]

Worked on generalizing out the marking of vertical tabs as meta. Before this patch, you'd mark items as meta with #attributes => array('class' => 'form-meta-element'), but vertical tabs always got that. I did the following changes to make vertical tabs not hardwired to meta:

- Added #attributes support to #type vertical_tabs, so that form.inc expands that to actual HTML
- Added the class attribute to the vertical tab item
- Since JS adds a preceeding element and a wrapper, we need to propagate this specific class to the wrapper. I've added custom code for it, since I believe we should not just propagate arbitrary class names. Those could easily break the layout.

Patch still works for me as before.

StatusFileSize
new20.31 KB
Failed: 11113 passes, 3 fails, 1 exception
[ View ]

This updated patch abstracts the meta tabs logic into a "horizontal tabs" forms api element. It also removes vertical tabs from the node edit form, which make less sense when everything is separated into horizontal tabs anyway. This is also partially in anticipation of the cool interface designed for the "Meta" page at http://www.d7ux.org/content/.

Status:Needs review» Needs work

The last submitted patch failed testing.

I created #491846: Modifying collapsible fieldsets on the node add/edit form to initially better present information for discussion/review of the code implementing the "Meta" tab interface as designed at http://www.d7ux.org/content/. I intend to look into the poll module failures in the morning. (As an aside, this is a perfect example of the importance of our automated tests - had I broken something in poll module, no one would have noticed for a long time, because no one cares about poll module).

Status:Needs work» Needs review
StatusFileSize
new21.03 KB
Passed: 11541 passes, 0 fails, 0 exceptions
[ View ]

Fixed the poll test failures, they were legitimate bugs with the patch.

StatusFileSize
new14.2 KB

Here's a screenshot of what it currently looks like.

Will it be possible to choose between having the Save/Publish/Whatever buttons stuck on the right (and I assume there is some js magic to make them stay visible no matter how far down you scroll) or having one set at top of screen and one set at bottom?

What happens if the admin/node entry theme already has a full right bar?*

Some layouts already cramp the middle even with a single side bar and not all users have wide-screen monitors.

IANAUX (I Am Not A Usability Expert) so my comments are probably invalid :)

* Looking back over the screenshots, it looks like this is in an overlay window so that probably doesn't count.

Yes, this appears in an overlay. What is on the mockups, but we did not yet account for is to display the buttons BOTH at the bottom and on the right. The right side buttons (and metadata information area) shows on both the basic fields and the meta fields.

Reviewing the patch, my notes:

- the vertical tabs attribute/class handling is still there but not used elsewhere in the code; while I think it is a good improvement, it might not belong in the patch anymore (but it mirrors how you handle the horizontal tab theming, so it makes sense to keep them in sync)
- IMHO great generalization on the horizontal tabs concept
- I see you adopted the #group marker instead of the more specific #tab marker; I think this makes horizontal vs. vertical tabs more interchangeable, even if vertical tabs in the node form case might not have many of the items marked; however you missed completely updating the docs on _form_expand_horizontal_tabs()
- code comment in horizontal-tabs.js says it does vertical tabs :)
- not sure why did you remove the vertical tabs container wrapping code in vertical-tabs.js?
- tried to follow the login on why #tabs is required on the form itself to point to the element which defines the horizontal tabs; is that to avoid going through the form and trying to find a #tabs element?
- as said above, the patch lacks support for keeping the buttons BOTH at the bottom and on the right, which still should be done

Good work, keep it up!

StatusFileSize
new22.01 KB
Passed: 11541 passes, 0 fails, 0 exceptions
[ View ]

Thank you Gábor and Balefire. I think I've addressed most, if not all, of your points in the attached patch:

Balefire:
- I added some cool javascript to make the buttons on the right sticky as you scroll down the form.
- I added a set of buttons at the bottom, as specified in the mockup at http://www.d7ux.org/content/

Gábor:
- I removed the vertical tabs attribute/class handling - you're right, it no longer belongs in the patch, although I agree it's a good change (separate patch?)
- I changed the documentation of _form_expand_horizontal_tabs().
- Code comments in horizontal-tabs.js now refer exclusively to horizontal tabs ;)
- Didn't mean to remove that wrapping code, whoops. It's back there now
- It's theoretically possible for a form to contain more than one horizontal tabs element (e.g. horizontal tabs within horizontal tabs). In that case, elements on the entire form could only be assigned automatically to one of them (it doesn't really make sense to think about it the other way). The #tabs attribute indicates the default horizontal tabs element for the form, the one that all other elements will be sorted into; without being referenced by the #tabs attribute of the form, any horizontal tabs element would have to have its children placed directly below it, as with fieldsets, rather than arbitrarily scattered throughout the form. So yes, partially to avoid going through the form and trying to find a #tabs element, but for deeper reasons as well. :)
- I added the buttons at the bottom. Easy enough. :)

I tested this patch using the d7ux svn repository. It does not yet feel like an improvement to me. Personally, I think the vertical tabs are a great enhancement. This basically hides them or discards them.

How will this help the event node that was shown? Where do you see signup tabs fitting in? The devel tabs?

Dear Drupal Friends,

If "Save" button is top right
is it a sticky ?

When there is a long, long
text I have typed
as in a blog article
do I scroll up all the way
back again to click a
save button?

The other problem
I remember with stickies
is that many users
just don't like it
when things do not scroll
when they scroll the browser.

I'm with Moshe. I thought the vertical tabs were a great enhancement but that's now lost completely. The nice thing about the vertical tabs and the page top tabs that are being removed is that they provide a hint of what additional information is in them with an easy and obvious way to find out more about them. Hiding everything under a global 'meta' heading gives no hints at all of what is there.

I was at the usability testing in Minnesota where we saw people dealing with the last big 'usability' improvement, collapsed field sets. They ended up opening them all up to see what was in them so they could decide what they needed to do next. Hiding that information was not helpful, it was a hindrance.

And everyone missed information in the top right corner when they were trying to figure out how to take some action, like adding a new field. The eye tracking software clearly showed that they never even looked in the upper right corner of the page.

This also adds at least one extra click to a lot of processing. Where you could have seen a 'signup' tab and then clicked on it, you will now see a 'meta' tab, hopefully know enough to click on that, then see a signup tab, and then click on that.

I see module developers resorting to things like adding 'signup' buttons to the face of this form to make it easier to find and get to their information, and there goes your DX.

Anyway, my two cents.

Putting the button on the top right area is evil from my point of view. And it is a big loss of space.

Why not consider keeping the buttons below. Or, else, copy the buttons below so that we would not need to scroll up to find the buttons, especially on mobile devices.

Furthermore, content/meta might be a good idea, but I would go further. Why not replace the top right button with a summary of all meta information? That way we would not need to click on meta to see the content.

I see that when editing content I'd see a summary of all meta on the right column. And when editing meta, we'd see a summary of the content on the left of the screen.

Let's use everything learned while developing the vertical tabs (with summary on each tab) and apply the tabs UX concepts here.

D7UX is a good start, but we must improve their design, not stick with it.

StatusFileSize
new29.06 KB

@ronia: well, you seem to have points on both sides. If the buttons are not sticky, you need to scroll to them (to bottom or right top), if they are sticky, then some people might not like that either; in the current patch, the top right buttons are sticky

@KarenS: I can only give an answer on the top-right corner concern. I think Mark and Leisa tried to provide adequate styling for the top right section, so it stands out and draws attention, so people find out that the buttons are there. For the overlays, it would be a pattern to include such tabs. For the node form, the buttons area is colored (colored buttons and background) for it to stand out. The tab and button area on the current mockups look like this:

We could obviously only prove that this works if user testing is done on a properly advanced version of the patch. That would require getting some of this admin theme into core and dependent patches such as overlays, tabs on overlays, the header, etc. added. Picking out only this part might not test well. Putting it together might. We can have assumptions but unfortunately don't know until we put it together. Obviously if we have no faith in that it would test well, then there is not much incentive to put it together. So far I've seen people look at these changes within themselves, and not in context with the other changes planned, which might obscure the perception.

@xmacinfo: Looks like Mark and Leisa already took some of your idea to heart and added some summary of some meta items to the button area. See image above. This could be improved and will probably be overridden by contrib modules.

Dear Gabor,

You said "you need to scroll to them (to bottom or right top)"

I meant to "right top"

When I am typing an article
as I go the end of typing
that is the last line
I see "Save" button
just below - so it is easy
to click without scroll.

Thus "bottom" is the normal
usual and easy position.
Right top or the wordpress mu-way
is somewhat cumbersome as
one has to scroll up, up and up
to save.

To avoid confusion
the super admin can be given choice
of three positions :
Save at top Save at Right top Save at bottom
He can enable any one or
more than one for his users.

Similarly if the admin wants
he can enable this multiple
choice for his users too.

I cannot remember what cms
this was which has floating button
that can be dragged at
any position of the screen
and based on cookie it
remains 'locked' there unless again
changed by the user.

StatusFileSize
new22.07 KB
Repository checkout: failed to checkout from [:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal/drupal].
[ View ]

Here's a patch with refactored javascript to only use a single set of floating buttons on the right. Tested with Firefox 3, Opera, Google Chrome, IE7, and Safari, all on Windows.

@ronia: the current patch shows two sets of buttons, one at the bottom, one at the top right. You can use whichever. Also, these can be altered by developers to not show up, show up elsewhere, etc.

Dear gabor,

Thank you. That is great!
I have nothing more to say
in this issue.

It seems to me that the only real advantage of having the save/preview/publish buttons appearing on the right (instead of only on the bottom) is that it makes it faster to edit the categories and tags of content (when content categories and tags appear on the right.)

Here's my take on what appears in the Content section and what appears in the Meta section:

Content:

CCK fields created by administrators/site builders ought to appear on the content screen. If field content can be entered/edited by most registered users it ought to appear in the content section. I would suggest the default behavior for CCK created fields is that they appear in the content section unless they are configured to appear in the Meta section.

Meta:

Contains module related settings such as user access permissions, user relationship settings, feedapi settings, etc...
I would gather that settings/fields which are only editable by an administrator or user roles with admin/site builder/site maintainer level privileges (eg. roles that can change path auto settings or similar) are to appear in the Meta section.

Basically, fields that can be added and edited by content writers/moderators are to appear in the content section while the meta section contains admin level editable fields. I do see vertical tabs continuing to be a benefit in the content section especially on sites with a lot of end user editable fields.

Looking good. That it is now visible no matter how far down you scroll is good.

Now on to my "Help out the thickie" question. Is the word Meta fixed as the title for the tab? I only ask because I didn't know what it actually stood for in this context so had to go hunting for the meaning. Still not 100% convinced I now know, but at least I have a vague idea. Is there a less technical but still descriptive title? Like Actions, Options or something?

I wouldn't obsess about the word 'Meta' -- I'd expect that it is one of those things users would quickly learn. It sounds like a nice /container/ word to me.

Either way, Leisa said the word 'Meta' was a first attempt (placeholder), and that they'd do more user testing on it to see if it works.

Lastly, I believe Joomla! also uses Meta, but I might be mistaken. If they do, that doesn't mean that it is the best word to use -- it's just a data point.

StatusFileSize
new22.05 KB
Failed: Failed to install HEAD.
[ View ]

Here's an updated patch with slightly cleaner javascript code.

Status:Needs review» Needs work

The last submitted patch failed testing.

Since my #6788: Submit without scroll got duped, I read up on this thread. I see two issues in this node: 1) moving the buttons to the right, and 2) creating a meta tab. I'm focusing right now on the buttons on the right and what I see is a lot of theming markup going into core. I don't like markup in core because contrib theming has to un-do what core does to change it.

I think it's great and fine if the design for the new MB template calls for buttons on the right side and that makes all the marketing people happy and joyful, but I think this is breaking the natural flow of forms. IMO, you start at the top, and end at the bottom. You don't then go to the top, fill down, and then right again.

If I might actually cite some research from my PhD for the first time ever, a guy named Don Dillman, who wrote Internet, Mail, and Mixed-Mode Surveys: The Tailored Design Method (in multiple editions), spent his entire life showing that multi-columnar surveys don't work as well as when you take all the questions and other items and simply list them down the page. He tries to prove with research that the form should be BORING, because it's the easiest for any idiot to follow. The research was in part because of people who put survey items and splatter them all over a page in an effort to get it on one page or save paper. I wasn't there the usability testing, but #37 makes sense to me in this context, where people apparently didn't look at the right.

Anyway, all that aside, it seems to me that if you keep the flow of the form as it is now, and whether you add in another submit button through #6788: Submit without scroll or not, contrib/themers/optional X can move the buttons to wherever they want if they are sufficiently tagged with CSS ids, without having to un-do core moving it to the right. At the very least, maybe this should then be moved to Garland's queue?

For the record, I dislike this direction and prefer the simpler #6788: Submit without scroll. I added a few comments in #35, and KarenS expanded in #37. I can't believe we are discarding vertical tabs on node form in favor of this experience.

Lets note that this patch and vertical tabs are not necessarily mutually exclusive, we can keep the vertical tabs on the "meta" tab if we really want to.

Thats a good point, charlie.

Still, the point of meta is to reduce clutter on the node authoring form and i feel that core has already achieved that. We had not achieved that when these UX mockups were made. Moving stuff off to a meta tab is no longer needed nor desireable, IMO.

I am so tempted to turn the status of this issue to "won't fix" or "by design".

Vertical tabs are a lot more finished and usable as what is proposed by the D7UX experts. They are reducing clutters, remove the need to scroll down and up and remove the need to click on the (meta) tab to see the settings.

The design made by D7UX looks nice, but, like someone else mentioned, that type of design should be done at the theming level. Also, the D7UX teams loves to hide information behind tabs (again the meta information hider).

I prefer a more opened design, where a summary of each setting is clearly visible in the node creation form.

So, can we close this issue with "won't fix" or "by design"?

OK, let's slow down...

1. Can we all agree that regardless of whether or not these horizontal tabs are a good idea for the node form, that they are a useful new Form API element that should be provided by Drupal, for developers who want to use them? I really like the way this patch makes them similar in implementation to vertical tabs; although it's not 100% of the way there yet, it seems close to allowing you to switch a form back and forth between vertical tabs (as they are now) and horizontal tabs with just a line or two of code in hook_form_alter(), and maybe switch individual form elements from appearing in one or the other place too... That seems pretty neat.

2. Perhaps the decision of whether or not to use them by default on the node form could then be made later. I think the concerns raised above are very valid, and for many of the node settings vertical tabs work great - but sometimes you do want to hide information away and that is what the horizontal tabs were designed for. This may be crazy, but thinking about the core node types and what they're intended for, it almost feels like an Article works better with the horizontal/meta tab, whereas a Page works better with vertical tabs? (This might not actually be a good idea, but the point is that the API could give you freedom to make that kind of switch easily.)

3. Can we also all agree that this issue is getting really confusing to follow, given that it is discussing two totally different things at once? I think the stuff about the button placement should really be moved somewhere else - possibly #6788: Submit without scroll (I am not sure why that should be considered a duplicate).

I have been playing around with the new Admin module in D6, which has a right section with buttons and taxonomy and everything else below (no meta page), and I can see some advantages of being able to split the form into two side-by-side sections and move some things. like taxonomy, to show up beside the body instead of below it, if I can control what goes there. And one place where it would be nice to have buttons at the top is when deleting a node (it's a PITA to have to scroll all the way to the bottom of the page just to get to the delete button). And I can also see situations where it would be nice to tuck some less used information away on a second page, like the meta tab does here. But on some sites I don't have room for this side-by-side form, I'd prefer a longer, narrower form. On others I would move lots of things to the right side.

The problem is that I might want to handle this differently for different contents types and different audiences on various sites. We're having trouble coming up with one solution that makes everyone happy because our content types can be so very different now that we have flexible content types with flexible fields (this example doesn't yet have all the many fields that real-world forms might have, so it over-simplifies the problem). There probably is no one-size-fits-all solution. We're almost to the point now where we're talking about a node form with regions (left front, right front, bottom front, meta page) and a slew of elements that might go into these regions, and what we probably really want is something where you can see a form with all its regions and all the available elements and be able to drag and drop the elements into different places. You don't want a meta page for this content type? Drag all that information to the bottom of the form as vertical tabs. You want buttons on the right or on the bottom or both? Drag them there.

I think something like this could be done with formbuilder, if someone gets it ported to D7 (and quicksketch has already said he's not sure he has time to do it). That's a big project, so I'm not sure it is feasible, just saying I think that's the only way you'll get something that everyone will like. At the very least we're going to need to give administrators and developers options about what goes on the meta page, what goes on the right, what goes to the bottom of the form as vertical tabs, and where the buttons are displayed.

Field API fields will definitely need a way to tie with this. Field A will be relevant for the main section, while field B will be eligible for the 'meta' section.
This is true for admin-defined fields, but also for module-defined fields ('taxo as field' - not in yet).

The CCK D6 notion of 'fieldgroups' seems to have much more flavors in D7: (HTML) fieldsets, vertical tabs, 'meta' section here...

So I'm not sure this topic can be decoupled from the reflexion on Field UI (whether based on form_builder or not).
Just in case I didn't spam enough issues already, I'll re-link to my UI-oriented summary of D7 Field API

@KarenS: not with drag and drop, but the proposed changes make it totally possible to move stuff around, group things into a meta tab or not, remove the meta tab, etc. by just using PHP level form altering. Because we do need to make some defaults, we need to define some behavior but obviously all custom defined fields will have their customizations even on the UI, maybe not with drag and drop, but in some way through the field configuration.

Status:Needs work» Closed (won't fix)
Issue tags:-Needs usability review

Not going to happen anymore, is it? :-) We'll see how what we have now performs.

Version:7.x-dev» 8.x-dev
Status:Closed (won't fix)» Needs work

I think this should be moved to Drupal 8 - maybe someone will revive it then. The 'horizontal tabs' form element is a pretty neat thing for Drupal to provide, even regardless of whether the core UI winds up using it or not.

Or that :-) np.

#482816: Make a consistent wrapper around submit buttons might help because it adds a wrapped div around the submit buttons. Then you could probably move the buttons up there using CSS.

Status:Needs work» Closed (duplicate)

There's a recent effort to implement a similar design here: #1510532: [META] Implement the new create content page design