Usability: Hide machine readable name of node type by default.

Bright !

Tested.

Another of those small but well worked UI improvements that makes an administrators life just that little less stressed.

Applied the patch, does exactly what the movie shows.

dmitrig01, keep them coming :)

OK, works like a charm. :)

I think this is a nice little improvement but ...

1. It didn't occur to me that clicking the link would allow me to edit the type. That is certainly not what I expected.

2. Clicking links on a form is scary because my mental model expects that I'm leaving the form.

3. This introduces a new interaction design pattern. The pattern that we have been using for this (i.e. the "hide details pattern") is a fieldset.

In other words: I like the goal and objective, but I'm not convinced this is the proper implementation. I'd like to discuss this more.

This is quite nice. While there will be users that may want direct access to the machine readable name, I suspect new users, especially non-technical users, will be tripped up by adding a two names. I know I was.

While I'm a huge advocate of maintaining interaction models, I'm not positive consistency would create a better experience in this case. Consistency suggests that we should take advantage of Drupal's expand/collapse model. Shown here...

http://skitch.com/jeff.noyes/wand/www.jeffnoyes.com

Using Drupal's expand/collase model, you could title the section "Machine Readable Settings" (or something to that effect) but this would hide the resolved name and force users to guess. Not good. We could push the resolved name to the title of the expand/collapse, e.g. "Machine Readable Settings (Blog)", but that too is unconventional, and depending on the name - quite confusing.

That said, perhaps the interaction model we should be hanging our hat on is "click to edit" - which is happening in this video. At the end of the day, if it's usable in the context of other modules, I say go for it. That said, have you tested this with other users? If not, I highly suggest you do, and could perhaps help with that effort.

Clickable 'summaries' of (a) setting(s) seems to be a nice alternative to fieldsets. To me the demo and patch make sense. Fieldsets is exactly what we should try not to do here for the reasons Jeff gives in #6. In general I believe we should be looking to replace the expandable fieldset pattern with something better. Again, a clickable summary/click to edit seems better. Especially for a single setting as dmitrig01 points out.

Also, clicking a link is less and less tied to leaving a page in an increasinly ajaxified internets.

And: should this be marked a duplicate of http://drupal.org/node/226726? That one is older, but the solution is right here me thinks.

Anyway, +1 for this proposal.

I agree completely that it is scary for users who see a link as a link. But as the others pointed out this interaction in context is better due to the assumption that beginning/novice users are unlikely to use this function, so hiding it for them is better.

However as we haven't tested it with someone who would acctually use this function (dmitrig01 tested it with someone who wouldn't use it), so we cant be sure that the actual user of this functionality will be confused or miss it. As Noyz said its all about whether it works in this context, we shouldn't be to concerned about the other interactions (as most links in forms are broken interactions anyway -- think : More information about formatting options) but whether its clear for those who will use this function. What we know, is that someone who wont use this function, isn't as confused by it any more. Is it possible to test it with someone who will use this function?

I think the concept of "click to edit" is becoming a more common interaction (Plone with it's titles for example), however it is not quite there yet. Although the visual appearance of a link is becoming less tied to leaving a page, this still very much still concerns tab like interactions. I think what we are missing is a "state glue" in which you clearly see that clicking this link means a new field will appear (Basecamp does this nicely by a animation) -- also they acctually display a edit link (upon hover) beside a title or link, but that's an important detail this patch doesn't do.

I am always very cautions talking about consistency, but can we acctually repeat this interaction in other situations? As Noyz pointed out, since I am not sure we can.

(Holding his +1 or -1 for just a little bit - Great job explaining it, I loved it.)

Sounds like we still need to discuss this a bit more. Sorry, dmitri. :(

I had suggested Type: blog [edit] since I agree that clicking on the name of the type is a non-intuitive way to be able to change it.

I don't really like the idea of "Yet Another Collapsed Fieldset" for this, even though it's consistent, because a) I think collapsed fieldsets in general are a visual hack we use to mask our complex stuff instead of just making it simpler :P, and b) it's logically grouped beside the name since the two are going to be identical or at least very similar in 99.999% of the cases.

So I /like/ about this patch that on add, it changes the type name no matter how many times I change my mind about what the Name field should be called. however, it also does this on edit which is NOT a good idea, since it will break my themes, views, and other things. So let's get that fixed, and discuss more about the best interaction model for this.

Attached are two screenshots from Wordpress showing a similar implementation, but it does use the edit link like webchick suggested. It works very well from my experience. This also has similarities to the way the Views 2 interface works. It is a design pattern which has a healthy adoption rate.

Re. clicking links on forms being scary: I think the major problem here is that other links on forms _do_ take you to other pages where you lose the work you've filled in. Perhaps this patch should be postponed until we have changed all the existing links on forms to open in a new tab/window. We know from our lab tests that people do click on these links; it seems to me that the negative mental model is something users learn after clicking one of our help links rather than what they originally expect to happen.

I don't think we'll fully get rid of the Fieldset because we need it for JavaScript disabled browsers.

Although I really like this patch, I have to agree that clicking a link on the form would lead me to think I'll be losing my changes.

For those that talked about the confusion in typing the same word twice, we can solve this by duplicating the string. It should make it clear for beginners to ignore the machine readable name since it's already generated for them.

Just my 0.2p on the subject.

Can you please make textual representations of those options here in this issue, since it seems to just be variations of parentheses or not, square brackets or not, etc. Would make it much easier to compare/contrast than having 18 windows open.

After looking at all proposals, I have to completely agree with Dries comment above. This does not feel right. My first thought was that I would leave the page upon clicking this link - loosing already entered changes. It might work, if there was a symbolic indicator/icon, like we have for collapsible fieldsets, which also look like links, but the arrow implies that I'm not leaving the current form.

However, having such links that expand into completely new form elements will most likely be a pain for themers. The whole approach reminds me a lot of the new UI in Views 2 -- but that is using a completely different interface, projected onto the content-type edit form, where all properties of a content-type are presented using such links in the first place. If the user clicks on one link, the corresponding edit form is displayed. Such an approach would also make perfectly sense for the content-type editing forms, but would require to abstract the Views UI.

I prefer:
Type: blog_entry [Edit]

Because the text is already small, you don't need parentheses to indicate "this is less important). And the [ ]s don't make sense as part of the link.

Patch doesn't work for me, but I like the suggested changes - assuming the [edit] link, and not changing the type name automatically apart from on creation.

The patch in #24 seems to be the vertical tabs patch.

Works like a charm. Committed to CVS HEAD.

The content_types.js did not get committed with this patch.
http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/node/?pathrev=HEAD

Committed. Thanks.

needs a tag

Issue against this feature #477020: Content type machine readable name field does not recieve focus