Posted by stevebayerin on January 22, 2008 at 3:24pm
Please Start a thread for each solution you have and if possible, comments to that solution can be on the same thread (the reply link on the post should work for that)
If you have a new solution, please start a new thread in the story (The comment box at the bottom starts new threads while the reply link (I think the reply option should a button instead of a link) keeps the next post in the same thread.)
(scratch all that, there isn't an option to move or delete misplaced posts. The thread follows on from Accordian Node Add/Edit Form.)
Comments
Vertical Tabs/Buttons Solution
Vertical Tabs/Buttons
http://www.scribd.com/doc/1249777/Drupal5nodes-v2-x4
Whether the buttons tabs go on the left or on the right, I think a usability survey on users new to websites would answer that question.
My reasoning for keeping the tabs to the right (as on http://www.scribd.com/doc/1251053/drupal5nodes-v2-r5) would be to allow users to have a more continuous downward line of sight from the title field to the body field onto the remaining fields, if available, to site users who can access the node add/edit form.
The tabs or buttons would highlight themselves according to which field type (ie. groups, authoring options, comment settings as in the wireframes, etc..) the fields belong to.
(I'm not that well versed in Drupal lingo, which is why I'm calling the field sets as field types even if its not the proper title for it. BTW, what are local tasks?)
Added Tab
Added Tab styling:
http://www.scribd.com/doc/1256095/Drupal5nodes-v2-r6
Thanks for starting a new
Thanks for starting a new thread. Let's try and consolidate node-form efforts here in this thread.
For those just joining, here are links to various different efforts to improve node forms:
The last wireframe (v2-r6) is great! I am working on a prototype like that wireframe. It's beginning to take form at http://drupal.geek.nz/static/node-form/default/1.html
I agree, and I understand your reasoning now. This would be a great place to use the proposed heatmap module. Also, if we can have stable patches for drupal core ready by UMN Usability testing February 26, it MIGHT be possible to include split testing of the two possibilities in the UMN tasks.
Vocabulary
A consistent vocabulary and understanding of meanings is important in these discussions. I hope my opinion of some terms helps.
Field type is usually used in the context of CCK to refer to either;
A
fieldsetis a block-level html element kinda like adiv, but with inset borders (by default). It contains a specially styled html element (legend) that is usually placed top left (by default) and 'breaks up' the flow of thefieldset's border.fieldsets are usually used inside forms to group input elements logically. Thelegendworks as a title for the group of fields.Essentially a
fieldsetis a way of grouping fields.fieldsets can contain otherfieldsets allowing one to create a (probably-not-very-usable) hierarchy.In drupal, many
fieldsets are collapsible, and most or all are initially collapsed in node-forms.The drawers will likely use the existing html structure (or a similar one) and use/move each
fieldset's legend as the tab/link for it, while the content remains contained in thefieldsettag.The grouping of drawers wouldn't necessarily require a complicated heirarchy of
fieldsets -- classes or parentdivs in output html would probably be better. Drawer-groups shouldn't be confused withfieldsets. Afieldsetgroups fields, a drawer-group groups drawers.Drawers are also known as vertical tabs and I guess we're still working out what the best name for them is.
Bevan/
Bevan/
Conitnuing on from the Accordian Solution Post
K, drawer tabs, that sounds about right.
To continue with discussing the vertical tab solution, here's the a quote (so that there's not much need to jump back and forth between the current and previous article) from one of the posts from Accordion solution to Node Add/Edit form.
From:http://groups.drupal.org/node/8305
By Bevan@drupal.org
About not being able to view multiple fieldsets at once in the vertical tabs solution:
There can be a drawer tab option called open all 'drawers' or its future name and when open, another option can be available called close all 'drawers' or implode all other drawers (to keep the same drawer open and collapse the rest.) I'm not sure its necessary having that much functionality when initially implemented.
The idea behind having the next button available right after each field is to give new users a quicker way to get the the next drawer tab without than moving the mouse to get to the proceeding tab (I wouldn't be surprised if in a usability test reported that users asked which button do I click to go to the next step)
In the event that a user feels that they have made an error, a go back option of some sort needs to be implemented (most admins would probably figure out what to do without a go back button, I'm implementing solutions for the scenario of first time users so that they don't get put off using Drupal.)
A submit all button does seem to be redundant. A quick short cut to submit the entry could be useful for users who want to make multiple entries quickly. A way of displaying a summary the current field sets and their fields could be useful after they clicked a submit all shortcut.
Agreed, drawer folders would work great there.
There can be a drawer tab
I think we might not be on the same page IRT user interaction with drawers. That's what prototyping is for :)
My understanding is that opening one drawer closes the currently open one, so that the user can never have more than one drawer open at once. That's what makes this such a great solution.
The idea behind having the next button available right after each field is to give new users a quicker way to get the the next drawer tab without than moving the mouse to get to the proceeding tab (I wouldn't be surprised if in a usability test reported that users asked which button do I click to go to the next step)
Fair enough, although I honestly can't think of a realistic use-case for that giving the rareness that one actually uses more than two of these settings in one node-form operation.
I'm not sure what you mean by 'folders', but the implication of containing drawers alarms me. I think we need to separate them.
See what couzinhub has done with the grouping drawers in a views UI wireframe: http://www.couzinhub.com/Views2-UI/views2-7.pdf
Bevan/
Bevan/
A totally different solution
One solution I've been considering is to go entirely the other way round and replace optional fields for contributed modules by markup.
I.e., instead of having the modules add new fields to the node edit form for their node types, have the module define their options as part of an input type. That way no additional space is needed. And rarely user/optional field in core could go the same way. The optional fields can be preset with their default values as part of the body content to show the available non-visual fields
On the plus side, this can make for easier reading and faster input for users accustomed to the site (regulars / professional editors).
On the down side, of course, it is less easy for casual users.
I'm not sure I understand
I'm not sure I understand what your suggestion is here. I think it would require a rewrite of the node API though -- not something that is easy or likely to happen. There are probably also good reasons it's the way it is.
Bevan/
Bevan/
Prototype
I've prototyped this on a static html page taken from a default drupal 6 rendering. http://drupal.geek.nz/static/node-form/default/1.html
I've also made the starting page available for reference: http://drupal.geek.nz/static/node-form/default/0.html
It's actually quite straightforward to implement technically -- we can worry about that later. Usability:
Anything below the drawers 'jumps' as different drawers are different sizes. I don't think this is a show-stopper but I'm not sure what to do about it either. Animated drawer-sliding could help. I can't imagine this though and I don't think jQuery tabs supports this out-of-the-box.
Finding the right colors for inactive tab's backgrounds and text is actually quite difficult. Drop shadows would be killer here but are out of scope for the prototype and not core-worthy without clean support for IE6 and a clean way for themes to over-ride the images, which isn't impossible but is difficult.
Bevan/
Bevan/
I'm mixed
My first impression is that this looks good.
It is much more compact than fieldsets which I think is helpful, but it suffers from some of the same problems - an extra click to get to the controls and not knowing what is included inside of the items until you click on them. Edit: It's much less visually jarring as I change tabs, which is great, but there is still some repagination that happens. If you could make the height of the area as big as the biggest sub page then it wouldn't have to resize. I think that could be an improvement. Either that or, as you said, use a transition between slides to make the change less abrupt.
My major gripe with accordions and tabs is that they usually lack a way to show all options. I'm not scared by the "cockpit" of seeing all the fieldsets at the same time and often find it useful to be able to see all values at the same time. For a solution to get a +1 from me it would also need a button to "explode all tabs" which would give that view of everything at the same time for people who really want it.
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
Having everything above the
Having everything above the fold is good. However like greggles said it's still quite a lot of clicking, and there's usually a lot (lot) more stuff on node forms in the wild.
I think part of the issue is trying to fit everything in to that small space below the Body textarea, I have a feeling that with a freetagging, multiple select vocabulary and a couple of cck fields added to this form it could quickly end up with some scrolling again, and since these are often things you need to see together (image intro and body fields for articles for example) I'd not want to see them in drawers. Although I've still not used this part of it yet, Panels 2's ability to override the node form looks like a way to do this in actual code - ripping out the theme regions and using panel panes for some common tasks to the right or left of the Body field, so that most of the screen is devoted to editing. This would allow for those panes to be in individually collapsible as well, maybe even with some session variables to remember their state.
Although I don't like it much, the Kupu editor (which ships with Plone and others) does something like this: http://www.onlamp.com/onlamp/2005/04/28/graphics/kupu_1.jpg - except it's got nasty wysiwym stuff in the right column rather than the sort of thing you'd expect from Drupal - if you imagine those as geocoding widgets, book placement forms and the rest I reckon it starts to make more sense.
Form regions?
I agree. But this only applies to CCK fieldsets, as single fields should not be placed in drawers AFAIC. Maybe add a checkbox to the CCK fieldset edit form asking whether you want the CCK fieldset to be always visible? Or we can take this even further and define the drawers as a form region, which all modules (including CCK) can add fieldsets to, using standard Forms API structure.
<?php$form['drawers']['cck_fieldset'] = array(
'#type' => 'fieldset',
'#title' => t('CCK fieldset'),
);
$form['cck_field'] = array(
'#type' => 'textfield',
'#title' => t('CCK field'),
);
?>
$form['drawers']would add a containing div, allowing CSS to style it appropriately:<?php$form['drawers'] = array(
'#prefix' => '<div id="form-drawers">',
'#suffix' => '</div>',
);
?>
One could add other form regions as well, such as a pane like Panels 2 does, although only in Forms API and using CSS to align it to the right or left of the other fields (like in WordPress, or the Kupu editor).
Maybe not like that
Come to think of it, this may not be such a good idea after all. It would be easy to patch existing fieldsets in core, but making contrib modules adopt this is something else.
A much easier way to deal with this, is to simply add a class to fieldsets which are not to be converted into drawers. Alternatively, add a class to fieldsets which should be drawers.
<?php$form['my_fieldset'] = array(
'#type' => 'fieldset',
'#title' => t('My fieldset'),
'#attributes' => array('class' => 'i-dont-want-to-be-a-drawer'),
);
?>
In CCK, you could have a checkbox asking if the fieldset should be a drawer or a standard fieldset.
...
I don't really understand the desire to explode the drawers out so you can see all options. Unless you have a huge screen you can't see everything all at once anyway. You are simply replacing a click with a scroll.
The only way I can really see that being useful is if you can explode it completely out of the page (into a new window), like Firebug allows. Then you can take advantage, for example, of dual monitors. But that is probably going overboard.
-
www.alanpritt.com
This looks great!
Making the drawers slide instead of jump up and down is actually provided out-of-the-box. You can also make it automatically adjust to the height of the tallest fieldset, take a look at jQuery UI Tabs' demo page.
A nice side effect of using jQuery UI Tabs is that one can link from one drawer to another, automatically showing that drawer to the user with a nice sliding effect and all. So instead of saying "Please see the Menu settings fieldset to yada yada..", one would simply link to that drawer (if there'll ever be a need for that).
And I agree with greggles, it should be possible to show all fieldsets at once. jQuery UI Tabs doesn't show any examples of this, but I don't think it can't be done. Using jQuery, we could move all fieldsets into one "special" drawer when its tab is clicked, then move them back out again when the user clicks another tab.
Also, Input format really has to be a normal fieldset below the Body field. A form can have several textfields, each with its own Input format fieldset.
And finally, this is not only applicable to the Node form, but potentially any fieldset-infested form in Drupal.
+100 :)
Edit: One more thing, I think
text-align: left; padding-left: 1em;on.vertical-tabs ul.ui-tabs-nav awould look better ;)Some thoughts
Overall I really like this, a big improvement over the collapsing fieldsets I think!
Some thoughts:
- I think animation is almost never a good idea (especially in core). I could be swayed if we can find something super subtle though...
- 'Exploding' the tabs for power users would be an interesting and useful function to see
- I think it could be interesting to see some indication of tabs that had been changed from their default, and/or tabs that had been visited during that page view
- More technically, we would need to figure out a way of theming a group of fieldsets like this in an optional but reusable way, because the collapsing fieldset is something still appropriate for some other cases (e.g. advanced settings).
Comments and need for research
What is the prevailing usability and user experience thinking out there?
There is a school of thought that says that forms should make it easy to see ALL the things you can do on a form at the same time.
We know that is just no good in Drupal land there is just too much to show so we collapse the field sets - but if someone wanted to they could expand everything.
In this new 'drawer' model that is quite literally impossible. Each click exposes one thing hiding all others.
I like it. I get it. But it doesn't matter what I think - does usability research support a move to this?
On a different note: I know this is just a mockup - but an input format is tied to a field and NOT the entire node. To put it in the same 'cabinet' of 'drawers' is just not correct.
Finally - Your comments at http://groups.drupal.org/node/8305#comment-25484 regarding descriptions as the 'label' - this idea is right on the mark. Regardless of how the interface will look/work - descriptive labels would be of great help.
This content post will not be inserted into any existing menus / This content post will become a child of the "Navigation" menu [change]
This will become the first revision of this content post / Your changes will create a new revision / Your changes will not create a new revision [change]
Comments will be disabled/read-only/enabled when this content is published [change]
You, will be attributed as the author of this content post and the publishing date will be today / is the attributed author of this content post and the publishing date is [change]
This content post will/will not be publicly viewable. If this content post is displayed with a list of other content posts it will/will not be shown above all others.
The specific words aren't important now - but I think this idea is a fine enhancement.
andre
Need for user testing
That is a good rule of thumb, until you get forms as overpopulated as Drupal's node form. I have no research to back this up, but I believe the main usability issue people have with Drupal is that it's too overwhelming and it's difficult to find what you're looking for, especially on the node form and the admin overview.
Anyway, we need to test this concept with real users. I'm not so interested in hearing what the usability experts has to say, I'm more interested in what actual users think.
Also, it really should be possible to show all fieldsets in one view. One way to do this is to add a tab labeled "Show all" which would list all fieldsets, maybe styled with "headers" for each fieldset so that it's easy to navigate.
Admin user
I had some comments on this over here http://groups.drupal.org/node/7965#comment-24396 I have actually done some research on content creation.
I'll reiterate one point. For sites where there are content managers (not website administrators), they do NOT have access to half or more of the node editing options. They basically only have access to the content fields themselves. In those cases node creation couldn't be easier - and there are hardly any usability improvements that could be made.
When examining usability you have to remember that not everyone is user/1.
Makes me wonder if it would make sense to adopt a 'root' user system for Drupal.
During install you would create the 'root'/'admin' user (user/1) AND your primary day-to-day user (user/2) that has reduced privileges. If you wanted to do administrative tasks you would have to 'su' (switch user) to expose all that 'overwhelming' stuff.
How much less complicated would a site appear to be then for a first time Drupal installer?
andre
I see your point
I see your point, and it's a valid one. Not all user roles will see all fields on the node form. But with Drupal being the modular system it is, especially with CCK and more advanced node types, you often do get long node forms.
There have been attempts at classifying the different types of Drupal users, which is a difficult task considering it's everything from only 'access content' and 'post comments' rights to people who like having near-superuser abilities, and everything else in between those extremes. So you do have a lot of users with very long node forms, although they're not logged in as user/1.
I'd much rather see an alternative to fieldsets that cures this itch, considering it may be overkill in some situations, than sticking to large node forms in other situations. Besides, it's quite eyecandy as well.
Edit: One possible solution, although not very elegant, might be to tie this "tabs drawer" to a new permission, so that you can select which roles would get fieldsets and which would get drawers. Just thinking out loud here :)
D7 Feature Request for default "Administrator" role
Andre, I agree!
Support that very simple feature request here: http://drupal.org/node/182023
Please stress as you have here that this is a usability fix. (As soon as I'm sure I'm not talking only to myself, I'll try to make a patch that adds another role-- nothing special about the role, just that it's in core and can be relied on to be there, so modules core and contrib can set sensible admin user defaults.) The idea of also creating a user for this role immediately is a good one.
@ximo, whether fieldsets should be shown or not should be based (as now) on a user's permissions to change what the fieldsets contain– and not have a special permission for that, IMHO.
benjamin, Agaric Design Collective
benjamin, agaric
Great to see a working
Great to see a working example on http://drupal.geek.nz/static/node-form/default/1.html.
The tab grouping looks great on http://www.couzinhub.com/Views2-UI/views2-7.pdf
Concerning designing the wireframes, AFAIK (from whats been explained to me by the person that introduced me to wire framing,) once wireframes are finalised, visual designers (or UI Designers) create mockups or templates with the colors, texturing, shadows etc. There's also no need to be concerned about IE6 flaws anymore, thanks to the mass update to IE7 that's just been pushed by MS.
In the ideal final implementation, tabs revealing themselves on hover can occur.
Exploding all tabs is a worth while option, although thats a whole wire framing session on to itself (button placement makes a huge difference between a functional implementation and a non-functional implementation)
I've got some possible wire frames for what vertical tabs can do for Drupal 7 (similar but not the same as whats on: http://drupal.org/node/211075 .) Right now, I'd prefer to wait till the new wordpress UI and Joomla 1.5 come out to see what they've managed to do with their UI before displaying the to be proposed D7 wire frames on scribd.
More importantly, I'd prefer to work on the UI of current issues (eg. node forms) and then integrate their improvements into wire frames for Drupal 7.
Good!
@stevejb: The jqyery-fied solution to node/add is very smooth and nice.
The views wireframe (pdf) is messy. Because of all the borders going around each field.
Now, I got a solution to views layout. The process could be made in steps.
Step 1 - short information | Step 2 - short information | Step 3 - short information
short information == 2-5 words
this way, the user can see in what level of the process he finds him self in. And he will experience a satisfactory feeling when achieving it.. (reference Ben Shneiderman)
The options that should be available during the creation of a view should only be those who are a necessity to creating a basic view. All other bells and whistles (which is a lot) should be placed in a field set called 'expert options' ..or something in that direction.
Considering how populated
@morphir glad to have your vote on the vertical tabs solution.
Considering how populated the Accordion style Node Forms Thread got with comments, to make it easier to follow the Views UI improvements, a dedicated thread for the Views 2 UI has been started at: http://groups.drupal.org/node/8400 (scratch that, the usability group can discuss the Views UI on a pre-existing thread http://groups.drupal.org/node/6288)
Edit:
After using Bevan's demo on vertical tabs, I noticed a the save and preview button kept changing depending on the number of fields.
http://www.scribd.com/doc/1429276/Drupal5nodes-v2-r7 has an alternative placement for save, preview and cancel buttons. The tabs have been switched to the RHS to see how they could look that way (the display all button is in the wire frame, although its placement would probably need more work.)
Views UI mockup
Ok, I took the time drawing instead of just leaving you guys with words. See link on how I think the Views configuration interface could look like.
This UI has some advantages:
Hope you like it :)
PS! I will be making a live demo of this soon. Be patient, as there is quite some work in progress going on right now.
http://drupal.org/files/issues/views_configuration.png
wrong thread
It's similar as the process to create a panel in the panel2 module. But I'm not sure that the process to create a panel is the same as creating a view.
You should post your ideas on this thread btw : http://groups.drupal.org/node/6288
How would the page would look if you want to edit the view after creating it ?
It's also confusing that you can click on create view or next at the same time.
The Drupal Agency >> www.raincitystudios.com <<
Me on the Web >> www.couzinhub.com <<
Go, Bevan!
Bevan, your working example is great. Now how to incorporate alpritts informations-on-a-glance about all the settings? This would even make it better. http://drupal.org/node/190946
To recall: It would be great, if we show: input format: full html, publishing options: promoted to front page (or maybe just: full html, promoted to front page) so you don't have to go into each field.)
http://drupal.org/files/issues/Picture%209_2.png
Life is a process
Life is a journey, not a destination
summaries will be part of Views 2 UI
There has been a lot of work done in figuring out the UI for views 2. Summaries are a big part of it: http://groups.drupal.org/node/8428
http://groups.drupal.org/node/8429
Thank you for your feedback
Rather than posting replies to each subthread, I've replied to all the comments here.
I've made some changes based on the ideas and discussion here. Check it out and please feedback: http://drupal.geek.nz/static/node-form/default/1.html
The next step of this is to implement it on a larger node-form with all core modules enabled, then later on an even larger form with custom modules and cck fields. We need to see how well it scales.
With 'drawers' this could partially be addressed with the 'Summaries instead of titles' technique that is being discussed and worked on in parallel.
As suggested in one of these node-form threads, it makes sense to work on these separately as independent but parallel efforts and patches.
I think this is a valid task and use-case for advanced users. I'm not sure if or how to address it with 'drawers' as they don't lend well to opening all at once. Summaries instead of Titles wouldn't fully serve this case.
This is a good counter-argument. However most users are much more used to scrolling than tab-clicking. Advanced users especially may scroll with other techniques such as space bar, page up/down or middle click. These accessible methods would be easier for those users, even with the most accessible drawers
Another valid counter-argument is that advanced users are a minority of drupal users that use this form. It happens that advanced users make more noise over here on d.o and g.d.o! lol
Idea: What if this was implemented exclusively for power users with a permission on the ACLs?
I'm beginning to conceive how this might work; http://drupal.geek.nz/static/node-form/default/all-tabs.png
Yes. Continuing on that thought; in the above screenshot, How would you activate 'all tabs'? How do you deactivate 'all tabs' mode? What behaviour occurs after you click on the tabs when in 'all tabs' mode? How do we reorientate the user after each of these behaviours.
I wasn't actually trying to fit it all above the fold -- that was coincidence.
In an ideal situation we would have a well-defined and limited amount of flexibility with node forms. This would allow us to use columns confidently, estimate with some precision where the fold is, and not worry about scalability of UI when the node has a hundred CCK fields. However Drupal needs so much flexibility in node-forms that I think it's too risky to have multi-column node-forms in drupal out-of-the-box. This is something that has been discussed in other threads.
Like CCK, panels and views, multi-column forms is something that is highly-appropriate for contrib though. I think that this also makes sense from a birds-eye-view of the total user experience for the drupal developer too. The advanced users that have lot's of CCK fields are most likely the same folk that know about panels and can configure it to customize node-forms for their sites and improve their users' user experience.
Out-of-the-box, we need something that works for most users on a default system, and scales well all the time with no customizations of the node-forms.
Agree.
Wow! That's cool. I'm kinda new to javascript and jQuery.
I've implemented fast slide and fade. I think they help keep the user oriented much better. I couldn't see how to make it 'stick' at the height of the tallest fieldset though. Can you provide a reference?
As previously discussed, I find RHS confusing. I think it will be easy for users to not notice the tabs on the RHS. Nevertheless I've implemented it to get exposure to the idea and gather feedback. I agree that we should test it more formally and extensively if possible.
I'm not sure if I agree on the placement of the save and preview buttons. In any case, there is a larger issue on the misuse of local_tasks, and drupal needs better and more consistent UIs and separate APIs for setting, getting and theming navigational tabs (what local_tasks look like) and actions (including most form-buttons, save, edit, preview, delete).
The sum of that means that form-submit buttons need to be easier to see and use throughout drupal, not just on node-forms. I think this issue is better tackled separately to node-forms, perhaps in parallel, as there are a number of core API changes that would need to take place.
I can see that becoming disorientating if the link is contained in another tab.
I agree.
I agree, implemented.
tabledrag.js implements an orange asterisk * on rows that have changed. Although IMHO there are other usability issues around the table-row dragging UI pattern, the orange asterisk UI sub-pattern is for approximately the same use-case as what you are suggesting here. Striving for consistency in drupal core, I think we should use the same 'changed'-status indicator.
This is a little trickier to implement, so I haven't done it yet.
I think drawers would be only for node-forms initially -- at least in the first core-destined patch. We would see if and how they can be applied elsewhere later, hopefully in d7.
Views2 seems to be taking to this UI pattern nicely too, and it should be available for contrib functions to implement easily with the theme API.
I'd like to follow this up. Can you provide a reference?
I can see this being extremely disorientating. Perhaps I'm not understanding your suggestion?
Bevan/
Bevan/
References
I'm having a hard time recalling where I heard/read that - just did a bit of googling and haven't found it yet. I'll let you know when/if I find it.
I thought it may have been this doc: http://www.usability.gov/pdfs/chapter13.pdf - but in that the only similar guideline has to do with text-areas being sufficiently large so that a user can see all their data entry without having to scroll (within the text area). So that's not what I was thinking of.
But, the gist of it (from what I remember) is that by hiding things the user has a greater likelihood of missing a data entry error prior to submitting the form. Perhaps, it wasn't about "all the things you can do" but rather "all the things that you've done".
Anyone know what I'm talking about? Am I starting to lose my mind :)
edit: just a thought - Perhaps the yellow asterisks 'notifications' on the tabs/drawers would be a way to address that - if they were checking the form before clicking submit - they'd know to check the tabs that say they were changed (just thinking out loud).
andre
...
Agreed. This is why I think providing summaries is an interesting idea. However, we have exactly this same issue with the collapsible fieldsets so we should be able to take a step forward using these drawers. Addressing the above concern would just make it even better.
-
www.alanpritt.com
2 issues
The biggest problem at the moment is definitely the resizing. I dislike the animation since it slows the interface down and I can't see that it helps at all. We really do need to keep the box at a constant size, otherwise this is going to be too distracting.
The problem with having the tabs on the right-hand-side is the distance the eye has to travel between the settings and the tabs.
-
www.alanpritt.com
I agree
It's possible to keep the box at a constant size, as seen in the demo here. I'd like to keep the fading effect though, as it gives a nice visual indication of your action.
I agree, left-hand-side feels easier to work with, less mileage on the mouse.
In regards to the technical
In regards to the technical implementation, it's probably a little bit early to go to much level of detail. Also note that since this is Season of Usability work, chx has promised to code it.
I think this sort of feature should be reserved for advanced users through contrib. Probably CCK or Fieldgroup module.
I think we need a default behaviour that tidies the form by putting most fieldsets into drawers. We can do this in contrib by adding it as a upgrade requirement or, as you said, moving them into drawers by default and requiring a change in the code NOT be in a drawer. Maybe 'collapsed' could be used as a guide for this?
In the case of only publishing it as an upgrade requirement in the handbook, it might need some 'policing' but I think that most contrib maintainers would catch-on on their own.
As you later mentioned and Owen suggested earlier "you've edited this drawer" status indicator (perhaps with an orange/yellow asterisk?) would help to resolve this issue and I think is a good compromise. What do you and others think?
I agree. I think inanimate changes can easily disorientate the user in these situations. Another option is the 'fading yellow' effect that 37signals attributes themselves for.
Ximo has been helping me a bit by to implement this. Thanks Ximo!
I'm not sure if I'm implementing fxAutoHeight on the right element or if tabs 3 just doesn't support it. I'm gonna check it out now.
In the next round of SoU work I have a bunch of todos:
Bevan/
Bevan/
A few enhancements:
A few enhancements: http://drupal.geek.nz/static/node-form/default/1.html
The DOM changes still need documenting, but can be easily understood by diffing the source of 0 an 1.
IMO there are no major blockers to writing a patch for drupal core. We just need to test it out a little more and add features as above.
Bevan/
Bevan/
Summaries have to be rethought
I go with the "You've edited this" symbol.
I added Summaries in the only logical place (besides the buttons) of your RHS Version.
I don't like it. So it is only to prove it does not work.
http://netzschwimmer.de/dateien/drupal/gdo/Summaries-1.jpg
The whole Idea has a big downside: you show more information to the user, but
you confuse him at the same time, because clarity gets lost: too much information.
The focus should be on the buttons.
You can never get it in one glance. What we also did not think about is that the summaries
can be quite long since it is not always possible to give simple yes/no options, especially bad
with checkboxes like in Publishing options.
To the wireframe guys: I'd love to see alternative solutions to this, wonder if anyone can do it in a way it makes sense...
Only feasible solution I can think of is some kind of tooltip on hovering, but in an inobtrusive way...
Life is a process
Life is a journey, not a destination
I imagined something more
I imagined something more like this for summaries: http://drupal.geek.nz/static/node-form/default/Summaries.html
I agree though it's not straightforward to implement.
Bevan/
Bevan/
wow!
That just blows my mind! Wicked... Pity it wouldn't be easy to maintain (especially with contrib mods)
what about another attribute....
If there was another attribute for what a field's "status" was to display to the user if it was selected I don't think it would be that hard to get contrib modules playing nicely with a system like this. It makes me think of help where help can be written specifically to give additional directions for any widget/module/button/field you want to add to anything,....anywhere! If there was another property for changing the status of the field it's associated to I don't see why you couldn't standardize this across all contrib modules (as long as people wrote useful ones :) )
Really cool idea though, forgot to mention that! Dono if it would be super usable in the way it's portrayed but I definitely like the feedback it provides to the user about their selections. You could then auto collapse sections of the form after choices were made because feedback would always been presented to the user as to what they were currently selecting without them actually opening the fieldset again.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
Here's a way to have
Here's a way to have summaries and the option to Edit the settings at the same time
http://www.scribd.com/doc/1846200/Drupal-Node-Forms-v2-r8
Good proposals
Both got something: Bevans keeps more clarity, as less information is visible, Steve JBs is more flexible.
Bevans Solution has some appeal and is the way It is indended by the others I think, but some problems are inherent:
(It is sure easier to learn if they always read the same)
But maybe we can work on it and find as short as clear summaries, that always point out what is found. I definitely like as little as possible information visible - this sure can be found in some general usability guidelines.
Steve JBs Solution is easier to implement. I forgot about the fact that, no button being active, the area could be used for this information. Still I would go for a formatting that keeps clear the buttons are primary, and the summaries are subordinate. Could be done by smaller fonts and a lighter font color.
Life is a process
Life is a journey, not a destination
A third alternative
Both alternatives are good, each with their own qualities and problems!
The problem with Bevan's alternative, is that the tabs would keep changing as you altered the settings, making it more difficult to find the tab you want. It's easier to find your tab if it's labeled with the text you expect. The good thing about it is that the summaries are directly connected to the fieldsets they represent, and they're always visible.
The problem with Steve's alternative, is that it adds the "View settings" and "Edit settings" buttons/tabs on top, adding more complexity to the solution. Having to switch back and forth between "View" and "Edit" may be confusing. The good thing about it is the clear overview you get having all summaries in one "drawer" - and the tab labels stay the same.
So with those impressions in mind, here's a third alternative :)
I'd take Steve's summary drawer and add a "Summaries" tab for it, that is topmost and default. It should be the first "drawer" you see when you access the form, giving you a nice summary of the node's settings and properties. It could even highlight which fields you've edited just now (in addition to the orange asterisk on the tab itself), which should be useful if you want to review your changes before you press Submit. Maybe even each summary item could link directly to its relevant tab, making it a tiny little dashboard for quick access to each setting?
+1 for the third option of
+1 for the third option of giving summaries their own tab placed at the top of the tabs.
+1 for linking the summary items to their tabs. Question is, does only the title of the summary link to the tab (safest option) or does the summary title and the summary items link to their relevant tabs?
I'm in favor of having recently changed tabs settings receiving highlights. In addition to the highlighting, would a superscripted 'undo changes' option next to the recently changed items be viable?
I think the safest option is
I think the safest option is the best one, that is only linking to the relevant tab from the summary's title (e.g. Menu settings linking to the Menu settings tab). One could even link directly to a field from the summary (e.g. "By Bevan" would link to the Author field), but I think that's overkill and not really needed.
I believe it's possible to add undo functionality with jQuery, but I don't think there's a need for that in Drupal... at least I haven't heard any complaints of there not being an undo function in our forms.
A picture's worth a thousand words
A clickable one is worth 1001 ;)
By the way, where's alpritt, now that we're discussing summaries?
Another option is what
Another option is what couzinhub has introduced in the views2 UI: http://www.flickr.com/photos/89495529@N00/2223673497/in/set-721576038078...
Or see the whole doc for more context: http://www.couzinhub.com/Views2-UI/views2-9.pdf
Bevan/
Bevan/
When I switched the wire
When I switched the wire frames over to a format for 1024x768 and larger screen resolutions (they were previously made using a format best suited for 800x600 screens,) I can see the issues faced by having the tabs on the right hand side if the forms were to have liquid widths (having the tabs on the right side with fixed width forms would preferable to me as to avoid too wide forms on larger screens. If the node forms were to have liquid widths, it would be best if the tabs were on the LHS.)
Now I have a query:
Fixed width forms or Liquid width forms?
If Fixed width, which minimum sized screen resolution should the forms be optimized for? 800x600 (maximum users can be catered for) or 1024x768 (most widely used format)?
If liquid width, what should be the maximum width?
@Eigentor: as per the formatting, there is quite a bit to be done on how to emphasize the buttons over the summaries. Right now I'm looking at how tabs are implemented in gmail as a reference on how tabs are emphasized.
Liquid width
@SteveJB No Prob with the text formatting, it is just my Idea for general direction. Sure you don't go into that much Detail now, and this is good.
We need support down to even very narrow forms. In some fixed width Blog layouts the content Area has 600px or less.
(Subtract side bar width)
The trouble with node forms in Drupal is: normally they are presented in Frontend theme. Though there is an option to use "Admin for Node Form" in D6, it does not help us. In at least half of the cases it will be Frontend theme, so we have to make sure it works. it has to work from about 600px up to a liquid width of about 1000px.
Liquid with is superior, because if the layout is fixed, the liquid gets fixed anyway.
Life is a process
Life is a journey, not a destination
Themes can make the size as
Themes can make the size as small or large as they like. Garland makes it so that a form (not window or viewport) is always at least 480px wide, and no more than about 1000px wide. I think these are good realistic limits to use as guide, even though some themes might allow wider or thinner forms.
The crucial point here is that the width is unknown and highly variable so liquid layout is a requirement for any html snippet in drupal core.
Bevan/
Bevan/
Use Panels 2 for mockups
I just ran across this screencast about Panels 2:
http://blip.tv/file/600413/
The amount of functionality is just devastating - er - overwhelming.
You obviously can style also node forms:
http://drupal.org/node/201916
So just to show things it might help to use it in one way or another.
Merlin claimed that using panels will not considerably impact performance
as if you use other ways to create your forms.
Life is a process
Life is a journey, not a destination
good
@stevejb: The jqyery-fied solution to node/add is very smooth and nice.
The views wireframe (pdf) is messy. Because of all the borders going around each field.
Now, I got a solution to views layout. The process could be made in steps.
Step 1 - short information | Step 2 - short information | Step 3 - short information
short information == 2-5 words
this way, the user can see in what level of the process he finds him self in. And he will experience a satisfactory feeling when achieving it.. (reference Ben Shneiderman)
The options that should be available during the creation of a view should only be those who are a necessity to creating a basic view. All other bells and whistles (which is a lot) should be placed in a field set called 'expert options' ..or something in that direction.
www.oyun-hileleri.org
Another option
Maybe it's a little late to add another option, and this would likely require some JS, but I really like the way Facebook sets up their forms. Essentially when a user chooses an option on a form, other options appear--they drop down from apparently nowhere to below the just-chosen option, expanding the form's length only based on what the user actually needs to see.
Seems like a candidate for Ajax to me, obviously with graceful degrade-ability.
#ahah
With the new #ahah Form API element, it is certainly possible. But with regards to accessibility, I don't think it's such a good idea. The form has to function with JavaScript disabled.
Accessibility or inability
I agree that things need to function when people don't have JS, no issue with that. What I don't understand is, if you don't have javascript enabled then just default back to the way things work currently. Those with JS (which I honestly can't believe the majority of users would have it turned off in todays age) then can take advantage of the new functionality. Just display things the way they currently work, wrap it in a div, if they can access jquery have jquery replace the "bad" way with some new awesome way of handling the issue. I think designing for the lowest common denominator in mind is never going to take us as far as pushing the envelope and just defaulting back to how things work presently if they can't handle it.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
I totally agree
I totally agree, we need to push the envelope as much as we can, while still remaining accessible for vision impaired users and users without JavaScript (some companies disallow JS), by giving them at least something that works.
If I understood IceCreamYou right, he was thinking of a way of hiding all fieldsets initially, then only retrieve them as they are needed using AHAH. While that is possible, it would mean everybody without JavaScript would never see those fieldsets, because there is nothing to fall back on.
So I agree with what you say, but there has to be something to fall back on for non-JS users :)
I must say though, that I think we're doing a pretty good job of taking advantage of JS in order to push the envelope:
http://drupal.geek.nz/static/node-form/default/1.html
http://kreativmango.no/dev/drupal/node_form_drawers_summary.png
(these are just from this discussion, there are other suggestions as well)
Hmm
I don't know how what I'm suggesting would be done, but I would think that the fields could just be moved. So the Ajax would start off by moving the unneeded fields something like 5000 pixels outside the rendered area, and then it could put it back if those fields were needed. The space where the fields would exist if they weren't moved could be arranged in an invisible fieldset so it can be collapsed when the fields aren't in it.
I see what you mean
I see what you mean, but I'm not sure I understand how that would look. Were you thinking of the My Account page on Facebook, or some other part?
In this suggestion, the fields are actually hidden using JavaScript (AJAX is something else), and only shown when you click one of the vertical tabs.
FB is a good example
The way Facebook does it is exactly what I was thinking of. For example under Comment Settings, there could be two options immediately visible: "Disabled" and "Read." When the "Read" option is checked, Javascript/Ajax could move another field option below "Read" called "Write." That way users wouldn't have to look at the extra "Write" option unless they were going to allow reading to start with.
Obviously that's a really simple example, but you get the idea.
There is a working example
There is a working example of verticles tabs for non-logged in users of http://google.com/adsense or http://www.google.com/adsense/login/en_US/?hl=en_US
Granted there are no summaries but there could be a thing or two that could be learnt from how googleadsense implements it.
(Not sure I'm the one to
(Not sure I'm the one to trash Google, but I don't like how they use the pointer mouse cursor for the whole vertical tab cell but only allow clicking on the links. boo)
I agree with that
I agree with that, they're overusing that new adsense rule where only the links in the ads are now clickable instead of the whole cell... I didn't they'd use the same guidelines for their adsense page tabs as well.
What browsers?
What browsers are you guys using? I can click in any area of the tab cell away from the link text using Firefox and Safari on the Mac to trigger the tab.
I usually use it in FF I
I usually use it in FF
I just tried it in IE7
The first 2 cells and the second last cell require the links to be clicked, the remaining cells seem to just need a click on the cell to trigger the tab.
Module that does what's been discussed
http://drupal.org/project/quicktabs
This basically does what (I think) has been discussed here, but in blocks. I haven't tested it.
I recently notice Joomla!'s
I recently notice Joomla!'s forum's user account settings pages are layed out as vertical tabs. They are full page reloads, not inline switching.
Bevan/
Bevan/
Hmm - so who scores first
Does this mean we are more advanced performancewise than Joomla - or we shouldn't bother about page reloads?
I wonder how Views 2 is done. I switched off Javascript and it appeared to be all separate pages, though it loads very quick - a miracle ;) Or just ask Merlin - I mean, he is a wizard, isn't he?
By the way, Bevan: how far have you got? Shouldn't we head at coding what we've got so far and release it as an alpha version? So you could concentrate on other things I do not see so much further miracles to be found here. And if it is found, it needs user feedback. Users got much better suggestions than one thinks. You got help from Tschechia. It is just: I think you should not dedicate your entire precios time of usability season for this, there is so much more... Or maybe you got great plans of improvement.
My presentation at FOSDEM was an amazing success (Well I pride myself I did a good presentation, but more than half of it was sure due to the amazing work done here, and a general interest, or shall I say Hunger, for this topic).
Gabor asked me, what we are heading at with your content entry forms. I said: right into core. He said: Ooh, a bit ambitious. So we don't hurt ourselves going through a contrib phase first, to gain further trust by everyone. This will make it much easier to get it accepted into core.
Life is a process
Life is a journey, not a destination
just a quick answer
yes - page reloads is not a concern with drupal. Drupal currently only have progress bars during upgrade.php (afaik)
RE: Hmm - so who scores first
I don't understand.
I'd love to see this coded. I think it needs more testing and prototyping before we can be really confident that this UI pattern is the answer. (I am having trouble finding time for that right now.) However there was nothing at the UMN Usability testing that said it might not be -- which is quite positive. And there were many things that indicated it would be a great improvement, and not only on node forms but in many admin forms too -- which is more positive.
I look forward to watching the video!
I hope to be able to chat to Gabor about this. I should also have taken the opportunity this past week to get the "U-Gang"s feedback too but there was just too much else to do.
Bevan/
Bevan/
Hi All
I've start to think about different options on how to use summaries for the Node form.
first preview : http://www.couzinhub.com/node-UI/Node-form-1.jpg
This first preview is inspired from the views2 summaries. All the settings are displayed in a summary on the top, and when you want to modify one of the settings, you just click on it and an edit section display the form on the bottom section.
What's bothering me in this version is the extra step of updating the form, that would cause too much clicking imho... but it might be technically possible to have it automatically updated... kinda like when you type a comment on this thread, it automatically update the preview of the comment...
Second preview : http://www.couzinhub.com/node-UI/Node-form-2.jpg
This second version is inpired from the apple.com website, you can see an example here : http://www.apple.com/iphone/ on the section on the top rigth of the page. You would need to click on the title to expand the section you would like to edit, that would collapse all the other sections. Again, I'm not sure about how to validate the changes..
Hope it helps a little. And thanks for your comment Bevan ;) !
The Drupal Agency >> www.raincitystudios.com <<
Me on the Web >> www.couzinhub.com <<
Second preview: +1
Cleaner, less confusing.
The header that indicates the form you are filling out should not be separated from the fields you fill out, as in First preview.
+1 for number 2
A +1 for the second preview from me as well.
It looks much cleaner than the first one. It could be a harmonica, with initially all fields closed.
It would also be possible to
It would also be possible to repeat the header on top of the edit area on the first preview.
The Drupal Agency >> www.raincitystudios.com <<
Me on the Web >> www.couzinhub.com <<
repetition is a form of flattery
and there's no room for flattery in the node edit form
I understand your second preview to provide corresponding fields immediately below any selected "fieldset" (for lack of a better term) such as "Comment Settings". This seems more usable than providing corresponding fields at the form bottom as in your first preview, even if you do repeat the "fieldset" heading immediately above them.
Bevan/
In "State of Drupal" having trouble with perms and svn on server. More later...
Bevan/
Bevan/
Sweet sweeeet!
This /almost/ exactly what I had imagined (I would only do different is set the tab height: 100%;)! But make sure that the entire tab is a clickabl (not just the text).
very nice bevan,
Cheers!
Writing a module
To better see how these examples work in practice, I'm writing a module for us to try them out. I'm starting with Bevan's working mockup of vertical tabs and will later attempt to make a working implementation of Couzinhub's accordian (2nd version).
I hope to have a working module ready for you to download and install in a couple of days, will let you know here when it's ready.
Pretty awesome ! Thanks !!
Pretty awesome ! Thanks !! Can't wait to see a working demo !!
The Drupal Agency >> www.raincitystudios.com <<
Me on the Web >> www.couzinhub.com <<
Accordion now included
An Accordion alternative has now been included in the module, based on your 2nd mockup.
I haven't gotten around to summaries yet (which is quite a puzzle in itself!). I tried to keep it as clean and simple as possible to start with, so there's no Click to edit link or Update button. If you want to work further on the Accordion implementation, you can submit patches in the issue queue, or I could give you CVS access.
And here it is!
Node form layouts - http://drupal.org/project/nodeform
The module is for D6. A nightly dev snapshot will be available as soon as drupal.org gets to it :)
Please install the module and try it out! Let me know of any issues you come across by posting to the issue queue for the module, instead of here.
While the initial purpose of this module is to allow us to trial the different alternatives, it may end up as a complete add-on to the node form and a proof-of-concept. While I'm the maintainer of the module, I feel it's entirely up to this group what we should use it for.
Looks and works great. Can't
Looks and works great.
Can't wait to see couzinhub's mockup in action too.
How about setting importance?
I have been playing with CSS based solutions for better node layouts (I'm not a programmer myself). I really like the improvements that can be made with the nodeform contrib but IMHO we need more than this. I believe the problem is all fieldsets/tabs are treated equally while in most use cases they are not equally important to most users. For example, when I configure Autopath my users hardly ever need to fiddle with the path options. And how often does a user needs to override Author information? So I think the next step would be to introduce some form of division between fieldsets, e.g. 'general' and 'advanced' options, within the standard and admin divs that wrap the fieldsets (since they probably are necessary for the ACL). Then, with CSS I could draw a two column grid that is more suitable for modern widescreens to use our screen real estate even more efficiently ( I know how to do that...)
Any comments on how this might improve things further and on how difficult this will be for a contribution?
Using the theme layer
Hello ximo.
Your layouts look great. My preference goes to the Vertical Tabs layout.
I worked on an equivalent solution using the theme layer. I created a sub theme, using your scripts and stylesheets, and giving you credit of course for them, as well as giving you credit for most of my PHP code.
http://11heavens.com/theming-the-node-form-in-Drupal-6
Maybe you could commit it to Drupal CVS under contributed themes..?
I feel like I have stolen your property, yours and the Usability group's.
Amazing work, and thank you.
Let me know, ximo.
I'd like to propose a
I'd like to propose a slightly alternate route to the solutions above. I realize that this might not work for everyone, but it can be a huge productivity boost for many users, so it could be considered an option.
What about using a frameset to create a jump menu for the page? Explode all the options out of their collapsed fieldsets, as suggested above for 'power-users') so everything is visible if you scroll. But, instead you can click the items in the jump menu to jump to the area. A little javascript changes the css of the active jump menu element to show you where you're at.
When a jump menu item is clicked, it slides down to the right frameset, like what you see at http://jquery.com/demo/thickbox/.
Ideally, the framesets would be alternating colors, to make it easier to sense the barriers between setting groups.
The mockup I put together is based on my Super Nav module, which uses a frameset for navigation. Right now, it will load the local tasks (tabs) into the navigation and remove them from the main content, if the user has that option selected. With jQuery, reading the page for framesets and adding the nav to the side frame should be pretty trivial.
Just thought I'd put that out there. Now that I've throught that through, I might put together a working prototype as part of the Super Nav module, but I'm not sure that I have a solid enough grasp of the scope of how the node form might vary with the addition of other modules yet.
I do like the vertical tabs idea, as well.
Chris
Chris Shattuck
Learn Drupal with over 1700 Drupal video tutorials
Great Job
Ximo, this is good. Now we got a working example.
Life is a process
Life is a journey, not a destination
Got the perms errors
Got the perms errors resolved. Go play: http://drupal.geek.nz/static/node-form/default/summaries2.html
Ximo, I couldn't make your module work on d6. I wonder if I'm missing something.
Bevan/
Bevan/
+1
I like this model, tho would be nice to compare side-by-side with a more accordion approach.
Degrades well with javascript off, but controls do not occupy full page width...in other words, area for control titles on left persists with js off (on FF 2.0.0.12/Mac 10.5.2).
It looks great - me gusta!
The only thing I'm concerned about (and this goes for all summary proposals), is how to actually make this work. How can some jQuery understand the changes you have made to form elements in a fieldset (aka drawer aka panel) and express that in a clear and simple fashion on the related tab? What if a fieldset has 50 checkboxes? What would its summary be?
We probably need some sort of setting added to fieldset elements in Forms API, in order to help jQuery build summaries. A lot of forms would have to be modified to accommodate to this, but that's probably acceptable for D7. I'm not sure what's the best way to go about this, though, would be interesting to hear what some of the core developers have to say (chx?).
We really need to figure out how to actually generate summaries before we can start playing with it.
And you should try to checkout the module using CVS, or wait about half a day from when this was written and download the latest development snapshot. I've reworked the CSS and JS some.
Allready posted on the
Allready posted on the module list, but I thought I could post it here too.. problem with foreign languages, some tabs are too small to contain all the text.
The Drupal Agency >> www.raincitystudios.com <<
Me on the Web >> www.couzinhub.com <<
Why can't the tabs allow
Why can't the tabs allow text to wrap to another line?
Senpai (my d.o account)
Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805
Flexible width
I rewrote the CSS so that the tabs adjust their width according to the text. One could also do like you say, enforce a specific width and simply wrap the text in the tabs. But if flexible widths work out fine, I think that will look better.
Nice one! Looks really great
Nice one! Looks really great now. Text is staying firmly in the tab boxes.
Perhaps we could attempt to spread this kind of CSS coding practice across the whole Drupal project? Hmm...
Cheers Daniel
bevans new summaries
Bevan, you could improve the display of the summaries inside the buttons by making either the main text bold or/and making the summary smaller (same as descriptions?)
I still doubt this is the best way to display them. Maybe this file is a way or a start to one. http://netzschwimmer.de/dateien/drupal/gdo/summaries-different.jpg
Life is a process
Life is a journey, not a destination
Great module
It is something to touch and feel. And it feels very good with the vertical tabs. Going to use this as my standard solution for D6.
Best regards,
Paul
Cool!
While it probably won't be able to break anything, I wouldn't use it on production sites. It's still unstable and very likely to change at any moment and in any way.. It will keep evolving as we try out different ideas discussed here, but I hope it can be used as a real add-on to the node form eventually :)
This works like a charm
Well, I rather continue the thread at the end...
After learning how to use Tortoise CVS, I can now even get the fresh stuff... as Ximos new module.
Dear Norwegian, you keep on being my hero. It is so much better to have a real-life comparison. So what do the others think: which one scores first: accordion or just vertical tabs?
Life is a process
Life is a journey, not a destination
Comments as button Names
Bevans last solution (quite far up in this thread ;) ) is the best to me so far. Sure there is a problem with Consistency and recognizability especially for new users, but the trigger word (revision, menu) is mostly in the Phrase. Maybe it would help to make the trigger word bold, or add it somewhere in tiny letters, or make it visible as tooltip... There are still possible solutions.
Anyway - it might be easier this way round, so the summaries are the major information and the trigger word is subordinate. Easiest solution: test it on new Drupal users. We got a long tradition of user testing.... ;)
Life is a process
Life is a journey, not a destination
About the ....
Hi All,
Just want to acks as an user. I like the solutions proposed very much.
Thank you all for your envolvement in developing more user friendly node/edit forms.
Cheers
Wolfflow
OpenAtrium
You might want to have a look at the way OpenAtrium does it by default. It certainly feels weird initially, but it answers the problem better than plain vertical tabs do.