UMN Usability - Put fields links on content type overview page

I personally would still like a workflow where I can set up a field and attach it to multiple content types at the same time (say an imagefield to be used on blog, news and foo types). Would that work for this?

How about adding more links to the top-level node-type page at admin/content/types? E.g. 2 new links: "Add field" and "Manage fields" - so that there is an immediate 1-click to this for each content type?

Patch attached...

note - you obviously have to force a menu rebuild (e.g. visit the Modules page) for this patch to take effect.

This should help with the usability issue, and it'll generally save clicks as well. Nice one.

Agreed this is a great usability enhancement, and a real time saver (for those who don't have admin_menu :-)

I wonder whether the order of the links is ok, though. The patch displays :
add field / manage fields / edit / delete
which makes it unclear that 'edit' and 'delete' act on the type.

What about :

Operations    Fields
----------    -----
edit  delete   manage  add

(Don't bother to reroll, I can adapt the patch myself if we agree on this)

Well, I think of the fields as part of the type - so that's why I didn't make that distinction. However, I don't care much either way.

Attached alter the order of the columns in the table per discussion in IRC w/ catch, plus adds a link below the table.

added 'description' class to the descriptions

And while we're at it,, catch suggests moving the link on the admin screen to where it will be in D7. (note, you can already do this manually with menu module, this jsut makes it happen by default).

Works for me - committed (I only renamed the callback to be more inline with other function names in content.admin.inc).

Thanks !

great! Though this little piece of the last patch didn't make it (if you want it).

maybe better- put the code in hook_enable, rather than having it run all the time.

Yeah, #8 and #9 obviously crossposted :-), I committed #7.

Do we really want to do this ? Won't this confuse people (and people trying to help them : "Go to Administer / Content Management / Content Types, unless you're using CCK, in which case you need to make that Administer / Site Building / Content Types") ?

Tested this and it works, less intrusive than changing all the content type paths as well.

@yched - none of the paths change - so you can always direct someone using the path (though the breadcrumb changes and actually works better this way). So, I can see both ways - might cause occasional confusion, but might also prevent confusion.

I always say admin/content/types anyway which'll work both ways. Hopefully we'll have to help people less if it's in a more intuitive place ;)

probably needs more thought.

For those who might be interested in tweaking the appearace further or just comparing - here are before and after screenshots for the patch committed in #9

In both cases CCK is enabled, as shown by the "Fields" tab at the top. Note in the additional link below the table too.

Is it worth implementing a hook_help entry in CCK for this page to add some more text? An/or adding more text above the table?

In terms of the question about moving the link, see attached screen shots.

I think it's an improvement but I wouldn't put the description on the right. I'd put the operations on the far right.

@Dries - I prefer them next to the type name, so that it's easy to match the type with its links. But I'll solicit some feedback. Attached are comparison screenshots.

Currently the links are in the center, right next to the type name:

An alternative is to put them on the right after the description.

Comments?

FWIW, I prefer the links on the right as well.

I like them on the right as it gives the reader time to digest what the item is before performing an operation.

Putting them on the far right would be more consistent with where "op" links appear elsewhere in Drupal. +1 for that. And dear god thank you for this issue! :-)

Do we want delete on this page? I'm inclined to move that to a button on the edit page (a la nodes) to make it harder to hit by accident.

I lean towards operations on the far right as well. That's as close to a standard as we have in Drupal for "links that affect modifications of an item in a table." Add/Edit icons would be even cooler, but I imagine that would be another world of debate ;-)

ok, well here's the patch for moving them back right. As above - I prefer the way it is now, but it's not a major thing.

Still unanswered (or answered in the negative?) is the question about whether the admin/content/types link is better off moved.

Committed #26.

As pwolanin stated, we're still pending feedback on whether CCK D6 should move this page to Administer >> Site Building like in core D7, or keep it under Administer >> Content Management where core D6 currently puts it in.

(patch to review is #11, screenshots in #19)

#19 - I think managing content types is site design/building not managing the actual content on the site, so I vote for the content types being part of the site building menu. I certainly don't touch content types very often after a site goes live, but all the time during the site build.

liveoutloud2day

OK, to be more specific : the question is not whether the change is sensible - that is already agreed, since that change went in core D7.

The question is : should CCK D6 move that menu item to a different place than core D6 puts it ?
See #12 for my personal concerns.

Re: #26 and the Operation Links position, I am 100% in favor of the action links staying right next to the title of the content type. Move the descriptions of the content type to the far right where they belong. Yes, I know it breaks tradition, but here's why I think it's better:

When the reader comes to this page, it's a pretty safe assumption that they will either be trying to create a new content type or they will be returning to edit an existing content type. What are the new users looking for? An Add New Content Type button. But what if they're not coming to this page for the very first time? They will be looking for an actionable button that let's them edit or delete the content type they came here to change. They won't need to read the description on the content type right now, unless they've forgotten what it does. :-)

So, we have first time users coming to this page to create a content type of their own. They don't need any of the buttons we're talking about in this patch, do they? Chances are good that they only need the Add Content Type tab. Thus, the operation buttons' placement in no way concerns them.

Then, we have returning users. Those people who have to edit a content type, delete a content type, or even create a new content type. I'd venture to say that nobody who comes to this page for a second, third or two hundredth time is seeking a description of the Story content type as their most prominent feature. They need the names of the content types, and they need to be able to do something with them. Thus, the placement of these Operation links is completely for the benefit of the repeat users. the admins. The ones taking care of their sites. The devs who are building sites. The teachers who are following a book's instructions on how to set up a blog for their students. You get the picture.

If I were to place four buttons at the end of your dinner table, and put labels for those buttons at the other end of your dinner table, how fast do you think you could find the right button if I gave you two seconds to run into the dining room, hit the button you needed, and come right back to where you were. Could you do it? Now imagine that I've sextupled the amount of buttons at the end of the table by adding five more content types to the site. Are you guys seeing the problem I'm seeing?

User friendliness is about placing things under the user's mouse before they've even had that thought of "Here is what I needed to click on". Let's go with the placement of patch #9. Please?

what's the bigger picture?

• a page is build of blocks,
• blocks are build of fields (i also consider the body field as a block with the only field body)
• so fields need only be added to blocks,
• for every page template (content type)  i could add block templates
• to each block template i could add fields
• on every page in the admin section there could be a section / block with related tasks

If the mental model is consistent throug the whole system, then it is easier for users to find what they search for.