proposal for CCK UI
CCK as a module has a lot of functionalites and this makes the UI difficult to grasp for new users even if developers made a lot to improve it. Since we’re going to put CCK fields in core maybe we need a cleaner interface .
So I did a mockup for a two steps content type creation form that not only try to make the UI simpler but even introduce new concepts and I hope opportunities. Please note that this is just a mockup I don’t have any working code and probably I wouldn’t be able to code anything. This would hopefully be just a start for a discussion.
Image 1
Users can choose an existing content type or create a new one and label it (hopefully Drupal will take care of creating the machine readable name of the content type so people don’t get confused).
Existing content types could be a selection of ready to use content types defined by the installer profiles or contributed modules (This way drupal core or contributed modules can even make available complex content types that can’t just be created with the user interface. Common content types for the default distribution could be Events, Contacts, Reviews, Blog entries, News, Images, Recipes etc.). If the user select a pre-defined content type the process is over. A new content type is created and can eventually be customized.
Otherwise if ‘Create your own’ is choosen the field creation form is presented.
Image 2
The second step shows an option to add a field on top and the actual content type form with two defaults fields (Title and Body).
Here users can set all fields settings; forms widgets are draggable, ajaxy removable and can be tagged as required and/or made multiple, Help text can be added and default values can be defined by filling the forms (you can use PHP if you enclose the code on the right tags).
Users can choose whether to create a new field or add an existing one provided by Drupal. Again, installer profiles and contributed modules can make additions to this lists providing complex fields that can’t just be created with the UI (This way we can avoid extra settings too complicated for standard users and at the same time provide a way for modules for inject their own fields). Suitable default fields for core would be ‘Name’, ‘Email’, ‘Image’, ‘Video’, ‘Date of birth’, ‘Gender’, ‘Node Reference’, ‘User Reference’, ‘Vocabulary’(a taxonomy select list), ‘Date’, ‘Quantity+Unit’, ‘Time’ and any ready-to-use fields we can think of with sensible defaults defined and/or custom validation functions that, again, can’t be added just using the UI. Pre-defined fields can always be customized once added.
When Users create a new field they have to choose a form type: textfield, textbox, file upload, select list, checkboxe, radio button or fieldgroup (to visually group forms). This fields are basically simple html form elements. During form creation there’s the opportunity to preview to form at any time.
Image 3
Here a node reference field has been added.
If ‘multiple values’ is checked authors will be able to select multiple nodes on the content creation form, (on textfields this could work like on CCK giving the author the opportunity to add multiple instances of the form of the same fields via an add more link).
When finished the user hits continue. The process is over.
Image 4
Links to modify the content type or edit its settings are provided on the content type listing page .
Infact I would prefer to provide sensible defaults for workflow, comments and any other settings making things easier for common users.
That's all. I know this implies a lot of coding work but it should be not to far from what Drupal can do; so what do you think?
| Attachment | Size |
|---|---|
| CCK_mockup_step1.gif | 48.9 KB |
| CCK_mockup_step2.gif | 67.22 KB |
| CCK_mockup_step3.gif | 77.6 KB |
| CCK_mockup_step4.gif | 61.51 KB |
+1 for UI
UI simplification like this would be tremendous. The current UI is too complicated for the average user. It's interesting because the first paragraph describing step 1 is exactly what I was looking for in a possible project I am thinking about.
Some questions about the UI.
What happens if the title field is removed? It becomes quite difficult in a few locations to select a node if one doesn't have a title available. Do we have to edit theme('title') to allow for titles like 'This node does not have a title' in Views of nodes or in the admin interface but not when the node itself is being viewed by itself?
I like the idea of choosing a form element. What is up with the 'decimal', 'integer' and 'text' types all having exactly the same form elements available to them? How about choosing a form element, and then choosing a validation for that form element instead, this seems more intuitive to me?
Dave
Keeping a more detailed
Keeping a more detailed answer for later, just a couple remarks for now :
The current plans for fields in core are that the current CCK UI stays in contrib. 'Fields in core' means the field storage engine and field creation API, and some basic field types, thus allowing core and contrib to rely on it. The ability for admins add fields to content types and tweak their settings through a web interface remains a contrib module
The precision above doesn't in any way make a brainstorming about the UI for this contrib part less useful :-), so many thanks for starting this. It does, however, more or less imply that there will be a distinction between the UI for core stuff (content type creation, settings for core 'fields' like body or title) and the UI for the contrib 'Custom Fields' stuff.
I'd say the most promising track for field admin UI is towards what the Views 2 paradigm, rather than the 'one form includes all approach in mockup 3, but that's only my personal feeling.