Home / CCK & Fields UI improvements

CCK & Fields UI improvements

I've spent a bit of time looking at the CCK UI for D7 and it has some real pain points. For starters, all content types have custom fields, yet upon submitting the basics (title and publishing options), we send users back to the listing of content types vs. port them into fields. I could go on, and gladly will if you call me out on it. For now, I want to focus on how I've tried to make it better. It's lofty, and probably still needs some tweaks, but I think it's a huge improvement.

To begin, I went about tackling this UI with some guiding principles in mind:

  1. Use existing interaction models. Drupal already has too many models, so the last thing I wanted to do was add a new one.
  2. Don't remove functionality (even if I think its bad). Id rather first focus on streamlining whats there.

With that in mind, I designed a solution based on Form builder, and the newly built way of managing machine names.

Thus far, feedback has been good, but people often miss my approach to setting instance level fields vs. field level settings, so take note when I cover the "properties" tab. Additionally, I've been asked, "where are the fields coming from?" The library of fields gets created as you build content types. For example, if you're building an "event" content type, and you add a "location" field, that field will then be in your library and accessible to other content types.

I'd love to hear your feedback:


Posted on by Jay Batson.

Very clean, very nice. I like it a lot.

One small thing you didn't consider: In the Manage Fields page, you listed the fields already defined in the system; but that view didn't really include any kind of easy way to navigate amongst all of them if you have a lot. In your listing of fields on the content type creator page, you showed an A B C ... pager at the top. You might consider at least having this type of thing at the top of the Manage Fields page. Even better: a search box.

Posted on by Jeff Noyes.

The page devoted to fields is probably the weakest concept of the bunch. It was originally conceived prior to figuring out that adding fields could be accomplished via the same UI as building a content type. Said differently, I was trying to restrict the number of tasks needed to build a content type, e.g., use existing fields only, and add fields via the fields UI. Later I learned adding fields could seamlessly fit into the process of building a content type without jeopardizing the experience. As such, I'm not even sure a UI dedicated to managing fields outside of creating a content type is even needed anymore.

Related... one community member mentioned that field reuse was an edge case. I'd love to hear from others on this matter? Are you more likely to define new fields or reuse existing ones?

Jeff Noyes
Interaction Designer