Posted by Krummrey on September 28, 2008 at 6:58pm
This is my first proposal for changes to the content creation form.
They are minor but yet I feel they will make things easier. I thought let's get a few basic things rolling before we get to the really hard stuff later on. Pease do comment on each of the four changes seperatly.
So here are my thoughts behind this mockup.
- Changing the color for "Create …"
Blue is the color that marks information or help. it is used in that context later on. "Create Page" or Story or whatever is not really the header. What the user will write in the Title field is what will be the header. That's why I think the "Create …" should visually stand back a liitle. It is the most important information text, but less important than the Title the user is writing. Having it the same size as all the other text seemed to small to me. - Increasing the size of the Title field
This is what the user will want the title to be. That should be represented even at the time of creation of the node. It will be the header for the page when it is displayed. I think the user will understand the relation of the input field and it's use much easier just by making it the same size during input as it is displayed later. - Grouping the Input format with the text area
Grouping the Input format with the text field and displaying the options as a dropdown menu. That makes it more obvious that the input format seetings only apply to that text area. It also give fast and easy access to the changable options. Additional information can still be displayed when the fieldset is expanded,
just like the other ones. - Spatially seperating the Preview and Save buttons
When the two buttons are so close one has to read them. Seperating them makes the easier to find. Also when using left to right languages preview comes before saving. That relationship is shown by their location on the form.
NOTE: The Split summary at cursor issue and the problem of the overall length hasn't been my focus on this mockup. I tried to focus on simple things that could be implemented easily. I will post a solution for the length problem later on.
That's my first round. Looking forward to hear your comments on this.
Comments
A few comments: 1) and 2)
A few comments:
1) and 2) are tricky, as that's really in the realm of themes and are likely to be overwritten. The "Create Page" header is still a header, and shouldn't be styled differently from other form pages unless there's really a pressing need to do so. I don't think there is. I'm not sure I like 2) either. Maybe draw attention to the importance of the field some other way? It's not very likely the user is going to miss that field, especially when the overall length and complexity is reduced.
I like 3) very much. Very elegant, and should make a big difference. Only thing I'd change about is that the label should no longer be a list item with an arrow, because the options are now in the list box, and no longer underneath. The label and list box should also not be so far separated physically.
Number 4) I would oppose. Separating the buttons so far from each other causes more problems than it solves. The user is more likely to miss one or the other. There's a lot of research out there that suggests form level buttons should be grouped together closely (usually in the context of "Reset" and "Submit" or "Cancel" and "OK", but it applies here). This is also standard practice and widely accepted, and I don't see a good argument why this situation would be special.
more comments
On 3)
So that invalidates illuminaut's comment (imho)
Btw: there's a long discussion going on attaching input formats to textareas. So maybe we ought to design with that in the future.
4) I think moving the save button way over there makes it practically invisible. So I would advise against it. What we could do is make the buttons bigger and more different, I always need to read the buttons, so I personally think that Garland should
-Niels Bom
-Niels Bom
Right, didn't read that part
Right, didn't read that part carefully. What other options are we talking about that wouldn't be a part of the list box? I was under the impression everything inside that fieldset is an input filter.
Edit: I suppose the help text would still need to be displayed, so yes, that's fine by me. The position of the list box is still open for discussion I think, but overall 3) looks great.
I've looked at the thread you provided, and don't see any reason why this proposed design wouldn't work with the new patch, but I'm no expert.
relevant issue for #3
Please take a look at http://drupal.org/node/304330
-
www.alanpritt.com
Yes, should be coordinated.
Yes, should be coordinated. The quick-select drop-down list in the mock-up right here has the advantage that it's immediately visible whereas the suggestion in the other thread looks nice but is a bit too subtle.
Input Format Open
This is what the opened fieldset could look like. No more radio buttons, just some help text.
I also tried to bind the "split summary at cursor" button to the text area since it only applies to this specific area.
Ultimately it should be included into the buttonset of a wysiwyg-editor i think.
I'll crosspost to the Issue mentioned here.
Im not really a fan of this.
Im not really a fan of this. Split summary at cursor really needs to go though haha.. yikes
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Customize Teaser Text
If 'split summary at cursor' functionality has to be there, I'd rather see it renamed to 'Customize Teaser Text.' (line 39 and 92 in misc/teaser.js)
Split summary at cursor while being the most accurate description of the activity isn't as easy to understand as the words 'Customize Teaser Text.'
'Join Summary' could be renamed to 'Collapse Custom Teaser View'
Save and Publish button?
This is for #4
I have a lot of users asking me how can they save the article they are writing. The 'published' checkbox in publishing options is not too visible (and hard to understand even if they discover it). How about new 'Save' button (for saving draft) and 'Publish' button to publish the content?
So there will be 3 buttons: Preview, Save, Publish.
From my observation, most of users don't have problem with WordPress or other CMS/web app that use this approach.
I guess this is what it
I guess this is what it might look like.
When I had these options I would try to save before I publish, just like in "Word" where I'd save before I print.
I think we should give the user hints on what lies behind the closed fieldsets. Maybe something like this:
I also moved the Menu settings down. In order of importance they shouldn't be right after the title and before the body. Especially for Stories/Articles.
I changed the H2 back to normal. It is true blue is for links.
Preview left and Save,
Preview left and Save, Publish right; why? Why not put the buttons together to the left.
Looking further at your picture; the list box idea for Input format could be extended to Revision information and Comment settings as well.
tried that
I've tried that, with all those dropdown menus and/or Buttons the whole thing gets too crowded.
I guess that's what the presets are for. Most of the times there's no need to change anything.
One could argue that the same would apply for the Input formats too. Maybe a little something showing the current preset would be sufficient for all settings fieldsets.
Making any text the same
Making any text the same colour as (or similar to) linked text is outright bad, I couldn't disagree more with this idea.
Making the title field larger isn't a bad idea, but I'd argue that it's a theme change rather than a core system change.
As you already know, this is a separate, larger issue. Personally I'd like the filter tips to be always visible no matter what.
As Niels mentioned the save button is probably too far to the right. Either increase the current gap and/or make the save button bold.
You're right.
You're right.
Sure it's a minor change and can be done by theming, Still doesn't it make things clearer? If it does, shouldn't the best way be in core?
I crossposted and hope that we will get feedback from the issue cue.
I don't want to introduce a new color of type for the buttons. If you all agree that they should stay where they are, then it should stay that way.
I don't have a problem with
I don't have a problem with #2, I'm just trying to drive the point that it should be applied against the Garland and other themes, rather than Drupal's 'skeleton' CSS.
Also, I believe there has already been some work in D7 to implement vertical tabs, take a look.
As for #2, yes just applying
As for #2, yes just applying it to Garland would be fine.
Vertical Tabs – we were talking a lot about them during our UX Sprint in Szeged. They are part of the big change-packet that I want to roll out next.
Vertical Tabs are not the solution for all problems though. They only work well if you don't have to scroll around to be able to see everything contained within the vertical tabs area. The collapsable fieldsets do not have that constraint.
With this round I was just trying to see what can be done on a lower level.
As I was reading your
As I was reading your comment I had this lightning bolt of an idea; collapsible fieldsets as horizontal tabs.
Input format is different!
Concerning #3:
Even with vertical tabs or any other solution I would still prefer the "Input formats" selector closely linked to the text-field, because there is a fundamental difference between "Input formats" and all the other options, because while th input format applies to the textfield only (and not, for instance to the title-field), all other options apply to the node as a whole. Now I'm a great fan of vertical tabs, but the best way would be to combine the two ideas and not make a vertical tab for "Input formats" (I'm not saying that anyone proposed that, I just wanted to point that out...).
i have a problem plz help me out
how can i move publiching option above the body.