Make it easy to change node type when creating content

While i normally prefer easy options like this for usability concerns, adding this type of option on every content type really adds confusion for less gain than *I* would personally like to see. I would like to suggest integrating it into the existing text for the creation header and adding a CSS style drop down instead of a html one. Please see image for very rough approximation of what i mean.

Reviewing the patch:

- People would possibly want to leave this out. How can they do that?
- People would possibly want to theme it. Your wired-in HTML code for the form does not allow for that (except CSS styling). I see that your "$(this).parent().parent().parent().find('> #node-form').attr('action')" type of traversal needs to know the exact structure of the form. Maybe if you rework this with $(this).parents('> #node-form'), then you get a parent which has the node form below it, from where you can find your element.
- Just looking at the code, seems to be that the select box is disabled, but people can still modify their form values, while the Ajax request completes, although their data was backed up before that.
- new_form does not look like a nice JS name :) Maybe use newForm or something like that. Same for old_url, new_url, old_title, etc.
- action.replace(Drupal.settings.nodeType.replace(/_/g, '-'), node_type.replace(/_/g, '-')) does not seem to taking path aliasing into account
- I see you accounted for possibly different header levels being used for the node title form title; however, in this case again, people might theme/alter these titles (outside of just translating them to something else which Drupal.t() covers); so not sure about how should we pass that on to the JS, maybe try to pass on the menu title too from node_form_js, even though that still can be overriden by drupal_set_title()
- Noting your code comment on existing nodes, IMHO it does make sense to convert their node types (there is a module for that ;), so it is more accurate that core does not support it

Looks good so far, let's keep it up!

This is how it looks like on the current d7ux mockups:

Hm. This smells like a contrib module to me. Do we have any evidence from our formal user-based training, or, failing that, other more informal testing that shows a trend of users being confused here? I've never seen this trend in other software, and I could see it being especially confusing if you had half of a "product" form filled out and then changed it to a blog. What happens to the data in the fields that don't map over?

This ends up cluttering the node/add form for everyone, on the assumption that very new users will find this confusing. I'm not sure why they wouldn't just use the breadcrumbs to navigate back to the create content screen and choose a different type if the one they're on was the wrong one.

Thoughts?

Original mockup at http://www.flickr.com/photos/mboulton/3570130250/in/pool-drupalredesign/

Oh, ok. So it's a convenience thing to get to node/add/X from node/add/Y.

My question still stands about halfway-filled out forms though, when the fields don't map between types.

"The content is transferred to the extent possible from one node form type to another, and all data is preserved for the case that the user decides to switch back to the original form."

I should really learn to read issue descriptions in full. ;)

/me pipes down now. :D

@webchick: there would be no breadcrumb according to the mockup. In fact, there would be no other way to choose a different content type apart from this form. I think the goal is to present a "default / most common content type" form as a start, which would likely be what people need when they think "accessadd content" (we might even remember this type per user maybe) and then they would not use this form too often. Looks like the goal here would be to let people do their stuff without first needing to think about what type of content they need.

Before going further, it is essential to answer webchick's question first:

Do we have any evidence from our formal user-based training, or, failing that, other more informal testing that shows a trend of users being confused here?

If this is only based on "I think it's a cool idea" (it might be!) then I'd rather see us focus on more pressing issues with the node form etc. If we navigate only on personal hunches we risk introducing more options for confusion instead of clarity.

meh, me should read closer too. apologies.

Still: http://www.flickr.com/photos/mboulton/3570130250/sizes/l/in/pool-903403@N22/ doesn't tell me if this option should remain present after choosing one.

If this is where Charlie wants to spend his time it's certainly his prerogative to do so. All that concerns us imo is its usefulness with regards to form and function as it stands. To that end I like the idea, but I think it might be better implemented as and integration with the existing "Create" Text in the header. I think this translates very well to "edit in place" mentality and keeps the UI from getting cluttered with additional options by doing so.

Keep the tag.

Cross post. Sorry.

This is what I recall:

- Users can preselect the content type from the add button. If they press "add" long enough, they can preselect -via a hover menu listing all content types. That selection drives the selection on the node/add form. Leisa planned on doing A/B user testing to determine if the hover was needed. Not sure of the results.

- If the user changes content types mid way through, fields that exist in the new content type persist. For example title and body would stay populated.

From the tests we have done, choosing a content type was never a problem (as long as you don't choose page - but thats for other reasons). I don't think this interaction is neither faster or more understandable, instead it gives the user more sense of effectiveness since they don't need to make that middle step of /node/add anymore.

I would love to know Leisa's reasoning behind this interaction, I do see its usefulness but as yoroy pointed out there are more pressing issues.

@Noyz Could you clarify your first explanation. Not sure what it means?

Special cases for title and body make sense, however in our ever more field-like interfaces I am not sure if it is a right direction to go - so let's keep to the current issue direction to just save it all somewhere in JS?

First statement... At one point, the suggestions was to click "add" resulting in node/add form. From there, users could select which type of node they were adding. There were concerns that users would want to choose which type to add at initiation - vs waiting for the form to render. As a result, the notion of a pop-up hover came to fruition - where users could preselect prior to painting the form.

I personally am with yourself and yoroy. In its current state, it tested well, so therefor why fix it. However, the new d7ux header is flat. There are presently no mechanisms to allow drop-downs. Said differently, to preserve the positive test results, the header A) have to expand after clicking Content to reveal Create Content B) Create Content would have to expand to reveal Content Types - neither of which is part of the present design. At least not to my knowledge.

I don't think this interaction is neither faster or more understandable, instead it gives the user more sense of effectiveness since they don't need to make that middle step of /node/add anymore.

I hate to be that jerk who parachutes into an issue and tells people to look at another issue instead, but I'm going to do that here :) If our only goal is to avoid the middle step of node/add, there are much simpler ways to do that. See #408160: Normal users should not see the create content link appear by default in a menu called "Management" and in particular the screenshot I posted in comment #3 which contains a "Create" menu with the content types exposed (http://drupal.org/files/issues/Browse_Create_Manage_menus.png). Also note that that issue is marked critical because many people felt that creating content should not be via the Management menu alone, since that makes it look too much like an "admin-only" task; therefore, if the D7UX header goes in, the buttons on that header presumably should not be the only path to node creation either...

So it sounds like the main reason to do the patch here would actually be the one mentioned by Charlie and Gabor -- it allows you to start creating content even before you have completely decided what kind of content you want to create. If the previous usability work suggests this isn't a major concern (or rather only a major concern on sites that have content types which have too much in common with each other), that sounds pretty important to think about, in terms of whether this belongs in core vs contrib. It does feel like there are a lot of situations where the choices here would be overkill; e.g., I cannot really imagine someone starting off creating a blog post and then deciding midway that they'd rather be making a webform :)

Another concern is that sites might often want to lay out these different content creation pages differently (e.g., by showing different blocks), but if you get there by selecting the dropdown you don't see those changes, right?

Also, sites might want to theme the form totally differently for different content types, so selecting the dropdown might cause some crazy jumping around of content on the page - not sure if that is a major concern or not.

The code itself looks very neat, though! I was one of the people who thought this just wouldn't be possible (due to the data loss issues), but it seems like I was wrong :) I think there might be some cases where you would still get data loss (e.g., due to the #tree property of Form API allowing for different name attributes in different forms, even though it is the same data underneath), but I guess that is a pretty obscure edge case.

Sounds like this is Drupal 8 stuff

http://drupal.org/project/node_convert

subscribe

(Merging "node system" and "node.module" components for 8.x; disregard.)

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Given this hasn't had any meaningful activity in 11 years I'm marking this as a won't fix.

I can see many UX issues with what is being proposed in the IS, mainly around different bundles having different fields and data loss.

If anyone is interested in implementing this, I would recommend doing so in contrib and then creating an issue to get buy in for moving the functionality into core.