Node creation redesign mockups

You're doing a good job, expecially if most of the tabs do not require server side processing...

Matteo

Looks very good, bring it on, the submissin does need some streamlining, would it still be compatible with htmlarea?

TIA

Some initial thoughts:

1. It looks cool and it is much needed. Thanks for helping us out.
2. The link to the 'file attachment'-screenshot appears to be broken.
3. A Preview-button looks more consistent than a Preview-tab. Comments have Preview-buttons as well. From an implementation point of view, a Preview-tab might be difficult to implement because it (probably) requires a HTTP POST operation.
4. We need to house many more options. I'd like to know where or how you see these fit in. Some examples:
   1. Permissions: grant or deny certain users or user roles access to this node.
   2. Layout or visual settings: show author toggle, show date toggle, show printer-link toggle, show contact-link toggle, show category image toggle, etc. We don't have these today, but they would be nice to have.
   3. Workflow settings: publication scheduling, workflow state, etc.
   4. Various settings: trackback-related settings, URL aliasing (human-readable URIs), e-mail subscription related settings, related links block, etc.
5. Your category selection might not always be that simple. There might be multiple selectors. Some optional, some required. Some multi-select, some single-select (drop-down menu). It certainly won't look as slick as on your mockup.
6. When you edit an existing node, where do the existing 'revisions'- and 'track'-tabs go? How do they stack?

I would like to see the "options" group currently, in the "administer" tab, moved to the "edit" tab. I change those quite a bit and would want easy access to it.

I know it should be as simple as possible, but think another step in the preview process will be very useful. I saw this idea in Textpattern. Basically you have 3 views: Edit, HTML, and Preview.

The first and last views are as you've made them. The HTML view gives you the content in html after all the input filters had done their job. This would help a lot for me because my input formats had the 10% cases where they don't work together very well. It might be useful in other cases too.

Another tab will make the screen more cluttered, and this view could be hidden or only available for some user roles.

I wonder why you placed this option in there: after all, Drupal provides a per-user box to control how comments are displayed, and this information is kept in the user session, not in the node.

However, perhaps we should reconsider the comment controls box. After all, if some people use threaded comments and others use flat comments, I can imagine the flat people might mess up the thread structure without knowing. Still, being able to provide a choice of posts per page and sorting order can still be useful to nitpicks.

Would this act like a desktop application, automatically keeping the input of all the forms as the user switches from one tab to the other? Does pressing "Publish" submits the fields on all tabs?

Or does the user need to keep pressing "save draft" before they can switch to another tab?

Obviously the first is preferable. I imagine a lot of time consuming data entry being lost if we require a two step process.

[MegaGrunt]

hello all-

just a few bits of info... for what its worth-
i have found drupal to be the most amazing cms out there-

but even in my limited experience- the idea of adding more java or javascript in, anywhere- makes me feel bad.

please please try to do as much as possible with php only- in 10+ years of development efforts i have never stopped wondering why people don't see that platform as the slow, buggy- and worst of all different execution results- for the most part dependent on the flavor of java that is executing on the client app or device...

but then again- think of the people that are still going nowhere fast with microsoft apps and os'es (when compared to open source power)- and there you go...

so just my 2 cents on this- but less is definitely more when it comes to java i find...

It looks great. Much needed functionality.

Here are a few comments:

1. Make it optional. Some of the visitors have slow machines, and we must not force on them javascript or java, or anything that would give a bad experience.

2. Integrate it with htmlarea so we get a nice WYSIWYG editor, with the ability to fall back to raw HTML mode.

I'd rather not see it too dependent on Javascript, since many users like to turn it off. Also, it will be more browser-specific, since js DOM differs between IE, Safari, and Mozilla-based browsers.

--
Mike Cohen, http://www.mcdevzone.com/

Overall, using tabs to break the task of creating a node into simpler sections is good.

But I get concerned when tabs are used for a step-by-step process - e.g. when you have to do step 1 before step 2 makes sense. Tabs are BEST when users can do the sections in any order they want and can skip things. Tabs are usually not used for shopping cart steps - where you must do things in a certain order and cannot jump around or skip steps.

We seem to have a mix of "must do it in order" and "in any order you want, if at all" here.

"Attachments" and "Administer" are optional - most users may never care about them, so good to separate. Also, you can do them in a random order - change the admin options BEFORE you write anything, for example. Attach items before wrinting the node content. No problem using tabs.

But "Preview" does not make sense until after you have entered in some content first. Preview makes sense as a button on the edit tab, but not as its own tab.

A similar thought is "Publish" - which you have only as a button and NOT as a tab. That is a good thing since publish only makes sense after other things have been done.

So what makes more sense to me is to have Edit/Preview/Publish as a tab and attachments as a tab and "options" as a tab (the stuff that by default should be OK most of the time).

I will want to use the file attachment' pane to insert images into a post. Having to switch panes to do that will be a pain. Why not have the attachment option inline but hideable like base camp?

And I am really loving this live textile stuff. I'm seriously wondering whether it be employed to create the WYSIWIG soltution.

What if there was a 'live preview' pane that could be toggled to show up below (or besides) the body form. Then textile or html formatted text put in the text area could be rendered in real time for you to see as you type. If you throw in some JScript buttons for the textile-phobes you could have the holy grail for post creation / previewing.

Hi!

Thats a good start.

I thinks that tabs are good in setting preferences, or accessing different parts of a UI, like an HTML composer. Each tabs should be usable as it's own. Going from one tab to the other in order to complete a task is not user friendly.

However, UI-wise, a new player showed me a lot of potential : Gmail!

Instead of going left to right using tabs to complete a task, why not use the Gmail approach! Going up to down (having more that one message with the same subject lets the user look at a message by expanding it and leaving the other messages shrinked).

The node creator might want to expand all views, or expand only the one or two views he want to have a close look upon. Furthermore, once a view is closed, he might see an overview of its content. The administration view, by example, once closed, might display: "Author, 2005-xx-xx xx:xx, Promoted, etc.". And once expanded, we might see the corresponding form part.

However, I'm not certain, but with the GMail approach, each time a view is expanded or shrinked there is access to the server. I don't know if it could be done without any access.

Regards,

- Jacques

My suggestions are available in the Quickpost module, which works with Drupal 4.5.1 (the CVS version does too, and has more fixes in case you want to try it out).

At any rate, I'd like to explain why I did quickpost the way I did to add to the content creation overhaul discussion.

First, here are some screenshots
Quickpost
Quickpost Advanced
Quickpost Hidden

Here are the basic requirements I came up with for posting content on GWJ
1) Normal users should only see the options defined by the administrator (me)

2) Users shouldn't have to specify where their post goes, and instead the form should simply infer the categorization from where the user is currently browsing. Mainly due to the fact that I'm using the categories as pseudo-forums. Forums where you can post events, stories and forum topics, for instance. When you post in a forum, you assume categorization based on what you're currently looking at. You don't say to yourself "I want to post something that is associated with cats and flowers", you look at cats and flowers and say "I wanna post here".

3) Users should see a very similar form for all types of content

4) Administrators should have advanced functionality that users don't know exists

In quickpost I solve these problems by having five features

1) Quickpost presents the user with a form that has all the available node types across the top as tabs. This way, the user knows what they can post, and it's the same interface for all the different node types.

2) I embed the taxonomies and the node types in the URL, you can have a link to post stories about kittens, for instance. You don't click on "create content" then " add a story" then "this is about kittens". Quickpost can assume all that info from the link, so admins can put the links to where they want. This is also optional, so you can post to no taxonomies or use the selection form.

3) There are two extra tabs, the "advanced" and "hidden" tabs. The advanced tab is available to anyone who can post, and the hidden tab is available to people with a certain permission. This allows administrators to hide features from users, or have them tucked away in the advanced tab for power users.

4) Administrators control what features ("form pre", "form post" and "form admin" hooks) are available on what tab from the admin interface. This can also be set per node type (for instance, you may want users to be able to schedule stories, but not events).

5) Finally, all info is transfered between the tabs by a simple JS "submit form" onClick action. This has the added benefit of allowing users to change their mind and switch from a forum post to an event if they desire, their info remains. Any information not visible on the current tab is transferred by hidden form fields.

Hopefully some of these ideas are useful to the discussion. I personally like the Quickpost way of doing things, but I never even considered some of the larger issues of the general Drupal project.

Nice work, Chris.

These mockups are vastly easier to understand than the current
screens. It's much easier for the user to understand what's happening.

However, I think we can do much better. These mockups don't
significantly change the complexity of the work flow. Rather than
thinking in terms of how best to display the current Drupal fields, we
should be thinking of how an ideal new post screen containing all of
the necessary functionality should work. It should be as easy as
possible for the common case, and other options should be as easy as
they can be without making the common case more difficult.

In your example, users see four tabs, five fields, and two buttons
minimum. In practice they'll almost always click on the preview pane,
and probably on the other two their first time around. Overall, it's
still intimidating enough that "Aunt Sally" would just give up and not
post.

Most users only need to see the "Title" and "Body" fields with
"Save Draft," "Publish" and "Preview" buttons 99% of the time. Most
people aren't administrators and don't need to see those fields. Most
of the time people don't attach files, so don't need to see those
options. As others have mentioned, since it's a one step process most
of the time, tabs don't make sense either.

Going through each one of the individual fields:

If categories have been defined for the node type, users should see
the categories pane, just like the mock-up. If there are no categories
defined that space should be blank. That way, sysadmins can easily
decide if their users should see the categories pane on a
per-node-type basis.

No one should never be able to choose input type from the create/edit
node screen. It's a confusing concept for most users. The system
administrator should be able to decide on an input type that makes the
most sense for the site on a per-node-type basis. Probably, if you
need two input types you're really dealing with two types of nodes
anyway.

No one should be able to change the "New Revision" box. The concept is
very abstract and confused me (a programmer) at first. For node types
that need revisions, like wikis, a new revision should always be
made. For other node types, a new revision should never be made.

Users should be able to see their preview and their raw message text
at the same time. Having them on separate screens will mean lots of
switching back and forth between "Preview" and
"Edit." Not good.

Since tabs don't make sense for the simple case, we shouldn't use them
for the more complicated cases of attaching files and administering
the post either. Links/buttons for "show admin options" and
"attach file" that open up panes with the appropriate controls make
more sense.

Having checkboxes for "Published," "In moderation queue," "Promoted to
front page," and "Sticky at top of lists" probably isn't the most
intuitive way to give users access to those features. These options
all do something, so it might make more sense to have buttons or links
that perform the actions, for example, "Promote this to the front page"
or "Make this post float to the top of lists."

Comment options shouldn't be decided on a per-node basis. It's another
option that's currently per-node, but should be per-node-type. Within
one site, forum comments should always work the same way. If some
forum nodes act differently than others, users will get confused. It
might, however, make sense to disable/enable comments on a certain
node for a while. An administrator action to "Disable Comments" could
do that.

That's a lot to digest. I'm interested in seeing what people think.

I appreciate all the work that went into this, and I think that these mockups have good cosmetics. But in terms of workflow, I'd prefer something different.

1. Rather than scattering editing tasks across multiple tabs, I'd rather have them on one tab as much as possible. I agree that the various post options under "administer" are not really administrative in nature, they're really authoring options. Apart from that, I'd rather have them visible together with the actual post content.

2. I think it's time for Drupal to get down with DHTML, especially for authoring and administering. Fewer server trips = better. One way I can imagine dealing with visual clutter is to group as much stuff on a single tab as possible, but group them in show/hide DIVs (with showing/hiding handled in javascript--now that I look more carefully, you suggest this already on a smaller level with the little green triangles--I'm suggesting the same thing at a bigger level). This could even include the node preview, which might be implemented as an iframe. Rather than having a "preview" button, you'd have a "refresh preview" button, since the box for the preview would always be there.

3. Add-on modules can add a lot of additional fields to the authoring view--a custom path, taxonomy on-the-fly, etc. There needs to be a way to integrate these logically into the editing structure. If the editing view is given a fixed outline structure (as suggested by tabs, fieldsets, etc), a module that add controls to the authoring view could include hints as to where it belongs in that outline structure.

Adam Rice

Good job!
Looks like it goes in the right direction, but it surely is not the end. ;)

Dries points out that a "real world" page will look far more cluttered than your mockups. I can only agree. So we should add guidelines on how to add form elements.
Secondly you should not forget about themeability. Its Drupals power to be extendible. Currently there is no way to theme those node form pages, in your proposal they should be. (Case: I make a site where users can keep a blog by using a handheld: I then surely do *not* want categories to appear next to the form, in my mobile.theme I must be able to change that behaviour)
And third: The teasers: by default drupal supports teasers inline, but a lot uof users do not like this, and use flexinode or other methods to heve more power over teasers. In your mockup that seems to break, since you have a "link" for the default teaser system only, that will breeak when one has specific form-elements (e.g. text areas) for teasers.

[Ber | Drupal Services webschuur.com]

I've read through the discussion which is a bit high-powered for me - but would like to make a small suggestion.
On my site, we are working up to a mass of content with a pretty complex system of categorisation. Since this is the first time we have done this I'm sure we'll find we've got some things wrong and will want to re-classify articles.

Trouble is today, every time a want to recategorise an article, I have to reload the whole thing (including the articles - usually quite long) into the database.

It would be nice to have some kind of option for editing eveything except the body and teaser - so speeding up down and upload times.

Come to think of it, it would also be nice to be able to edit the teaser...

Thanks for taking the time to take this on. Great wireframes and a great direction to be going. As you can see, the scalability of the UI design is probably directly proportional to the number of scenarios you come up with to design towards.

The iframe or whatever for handling categories with checkboxes would be a tremendous improvement. The short multiple selection menus posed terrible miss-click usability problems for me with my large taxonomies (If I am selecting multiple terms and let go of the control key, I sometimes lose my previously clicked terms). This version would show more of the taxonomy and would allow for fewer miss-click errors like I describe above.

What I'm most interested in is the handling of categories in the Edit screen and the implied flow implied by the "Add/Delete categories" link. It's difficult to envision your design of the screens for those subtasks without seeing screens for it. Does the clicking of the link maintain what has previousl been entered in the content entry form (title, body, etc.)? Is this handled on the current screen and throw you back to the content entry form or is this handled in a pop up window? I'd like to see more definition around that flow as well.

I have a bunch of modules installed which give users various options when creating a new node. For example: Node privacy by role, Image Assist, attachments, etc. One of my biggest gripes is that the submission page is extremely cluttered.

9/10 of my users have very limited computer expertise. When one of these users first comes to my site and tries to create a new node, they're overwhelmed by all the options they have. I've tried to create submission help where I can, but its getting very long at the top of the page because it tries to explain what all of the options are.

I personally really like the tabs. The first thing the user sees when they load the node creation page is a very simple and clean interface. I really like the check-box style categories. Most users don't know that you can hold down CTRL to select multiple options (even with an on-screen note telling them). Check-boxes are more intuitive. I also like the help icons beside the group sections. It is much cleaner than cluttering up the screen with help text and most users know to click a question mark for further help.

The separate tabs for attachments and 'advanced settings' help to shield the user from a lot of the extraneous settings. The average user won't use or even know how to use many of the options currently available. If a user sees a setting or text box, they'll feel they have to enter something there.

One thing I like about the preview tab is that it makes a very distinct difference between submitting and previewing. I had to turn 'force preview' off on my sites due to users complaining that their posts aren't showing up. There could still be a preview button on the bottom, and all it would do is direct the user to the preview tab.

One of the best features about Drupal in my opinion is the customization available to the admin. The module developer doesn't know what fields the site admin wants on the main detail tab vs the advanced option tab. That should be customizable a-la the Quickpost module. I really like that feature of that module and would like to see that officially supported if the tab method is implemented

Drupal needs to start moving in the direction of creating user interfaces for the computer inept out of the box while retaining its great advanced customization features. I think it's definately in the right direction, but these changes are critical in my opinion.

--Skorch

Looks nice but using flash to show a screenshot!?

I have just been reading this thread, and noticed that in considering the use of javascript/CSS for tab-switching, there didn't appear to me to be a full consideration of the impact of javascript on accessibility.

After testing it and examining the code, I think my (rather niggling) concerns are largely unfounded, but I just thought I'd write this out anyway in case there is any mileage in it. My only remaining doubt is that the technique being deployed seems to rely on an ondocumented aspect of javascript implementation.

It seems to me that two situations covered in the WAI Accessibility Guidelines are relevant here:

para 6.3 [Priority 1]

Where javascript is not available or has been disabled

para 6.4 [Priority 2]

where the user does not have a pointing device

Factory Joe's comment on JavaScript as a much-needed dash of salt confirms that the technique would "degrade pleasantly for those without JS or those who have it turned off", which covers para 6.3.

However, it doesn't cover para 6.4, which seems to me to leave open the theoretical possibility that mouseless but javascript-enabled user would be unable to switch tabs. This is presumably why Bobby objects to use of the onclick() event handler.

I have tried the demo, and keyboard link activation seems to work perfectly for tab-switching in IE6, Firefox 1.0, and Opera 7.54. Well done!

However, I notice that the javascript seems to use the onclick() event handler, so I presume that the browsers are interpreting the click event as meaning either mouse-click or keyboard link-activation. If so, this doesn't seem to be documented anywhere in the javascript references.

I know that I'm getting very pedantic here, but I wonder how future-proof this methodology is?

The W3C's Document Object Model (DOM) Level 2 Events Specification suggests that it's an issue which has not yet been resolved:

Mouse event types

click: The click event occurs when the pointing device button is clicked over an element. A click is defined as a mousedown and mouseup over the same screen location.

Key events

1.6.3. Key events: The DOM Level 2 Event specification does not provide a key event module. An event module designed for use with keyboard input devices will be included in a later version of the DOM specification.

I've just come across this thread ...

why has it stopped? (I'm new to this corner of drupal.org)

where is this project now?

I sincerely hope it hasn't been dumped!

This is what really simplify a lot DRUPAL admin work and user as well. Go Go Go.

P.S. for any new Reader of this Posting:

Module is ready for Drupal 5.x see http://drupal.org/project/excerpt