Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Feb 13 2012
Feb 13

Need a simpler UI to let administrators manage fields? We recently created a new contributed module called Simple Field. This module simplifies the UI for creating fields and adding them to content types and entities. It also provides granular permissions, so you're not stuck with a single catch-all permission for managing fields. You can see a demo of the module in action at simplefield-demo.ewdev.ca (login: demo/demo).

Why do I need Simple Field?

Imagine you're creating a Drupal site and you want to let your users create fields, but you don't want to give them the 'Manage Fields UI'. The Manage Fields UI is very powerful, but it also provides a lot of settings and configuration that can be confusing for non-technical users. Giving users permission to manage fields allows them to delete fields, and you might want more granular permissions to prevent users from deleting data on the site.

Simple Field Types

The Simple Field module includes a set of Field Types. Instead of a long list of cryptic types which can intimidate non-technical users, field types are things like 'Multiple Choice' or 'Yes/No'.

List of built-in Simple Field types

Simple Field types include a core field type, plus some field widget settings. For example, rather than choosing 'Boolean', users can choose 'Yes/No', which is a Boolean field with pre-configured options for yes or no. The user adding the Simple Field will not see the 'Options' field and won't be able to change the option values.

Of course, we can't anticipate all the Simple Field types that other sites will need, so the module is extensible and allows developers to define additional Simple Field types in code.

Creating Fields is as Easy as Pie

With pre-defined field settings, creating fields becomes much easier for users. Users just need to enter the label, whether the field is required, and help text. Some Simple Field types, such as 'Multiple Choice', have an options field, but that's it.

Creating a 'Yes or No' Simple Field

Attaching Simple Fields to Content Types

You can enable Simple Field on a per content type basis, which provides a nice UI for managing the Simple Fields for that content type. The module uses modals to keep the UI concise. You can create and attach files from the same page.

UI for attaching Simple Fields to a Customer content type

An Alternative UI for Creating Fields

The Simple Field module provides an alternative UI for creating fields, which only exposes some of the field settings to users. Other administrative roles can still be given access to all of the more advanced settings through the Manage Fields UI. The fields are stored in the database in exactly the same way, so everything like Views integration still works. All settings and weights are synchronized between the two interfaces.

Simple Fields appear in the Manage Fields UI

Granular Permissions for Fields

Permissions for the Simple Field module are very granular. You can control which roles have access to which field types and whether users can delete fields or remove fields from a particular content type or entity. For example, you can configure your site so that the users with the 'service rep' role can add Yes/No, Multiple Choice, and Short Answer simple fields to the customer content type. This way, service reps can add fields on-the-fly if they realize that collecting a particular piece of information from customers is valuable.

Simple Field Permissions

Adding Simple Fields to Entities: Fields as Content

While the Simple Field module can be used to add fields to bundles (i.e. content types) it can also be used for adding fields to entities. This opens up a ton of new possibilities. For example, you can create a survey entity and allow users to attach fields to each individual entity. Used this way, the Simple Field module is kind of like an alternative to the Webform module, allowing you to add fields to pieces of content.

Presentation at DrupalCamp NJ

Alex Dergachev presented a case study at Drupal Camp NJ on February 4, 2012 and included a demo of the Simple Field module. The case study shows our original use case for the module in the context of a Drupal project for a university.


For information on creating new types, among other things, take a look at the documentation.

Feb 13 2010
Feb 13

From the announcement on drupal.org presenting Sabir: a user-friendly news platform for multilingual communities.

Over the past year we saw two parallel community initiatives heavily influencing the development of Drupal 7: a huge effort in improving Drupal's usability that led to the introduction of solutions and features, radically changing the user experience in building sites with Drupal 7. At the same time, advancing on the direction taken with Drupal 6, many internationalization improvements were introduced in core and many more will be available through contributed modules.

Both initiatives were driven by key contributors of the community, to promote them and push them forward. Self-organized sprints were held both for UX and i18n improvements, which allowed people to know each other better, work together, drafting ideas, and participate in designing and developing ideal solutions.

As a natural consequence, we launched the Sabir proposal: a community-driven project which aims to produce a platform dedicated to communities with minimal technical expertise, allowing to easily share news in multiple languages.

May 17 2009
May 17

We are a Drupal shop and as such we deliver ready-to-use websites to our customers. We always tweak interfaces to deliver better user interface alongside our projects.

I'm following D7UX discussions and looking forward better and cooler and I've noticed that in the moment there's a focus on content type forms and other administration issues. Of course this is very important to Drupal World Domination, but when it comes to Drupal usability, I'm far more concerned with the underprivileged (i.e., without too much perms) content editor. How do we make a great node editing interface?

Here are my two cents on the "publishing options".

As we of today, Publish options comprises three checkboxes: Publish, Promote to frontpage, Stick at top of lists. They are actually loosely related.


It is quite common for CMSs to have a "publish" boolean in all its content. So has Drupal. But... why do we have to show to our users such a booleanish checkbox?

I like Wordpress approach better. There's a big blue Publish button. If we save (or better, "Save as draft"), we're just saving it, as an unpublished node for later editing. If we press the "Publish" button, we know for sure it's going live.

It is easier for our users to understand. "Being published" is not a characteristic of a node, like a taxonomy tag or an address. It's an action we inflict on it. "Publish it!", said the editor, not "make it with get the 'published' status".


The approach described above for publish would help a lot on drafts. Most people need some time to write a whole text. In Drupal, when we need to have a draft, we unmark the "Publish" checkbox and press "Save". But it is just too uninvinting for "drafters". If Drupal is uninvinting people to write drafts, it's not invinting people to use it as a text editor at all.

A simple change from a publish checkbox to a publish button would be very benefical and would allow people to easily save drafts.

But, what if we push it a little further? I'd love to see an automatic draft saving in core, just like - well - Wordpress. There are some issues, though: validation of mandatory fields. There are lots of fields that must be filed before puting a node on air: title, one or two obligatory taxonomy vocabularies. All of them waiting for completion, before getting the node on air. Imagine a complex node type with thirty CCK fields. How could we save a draft of it? Moreover, there always are pathauto URLs, triggered actions, etc., that depend upon node creation.

Draft Module circumvents this issue by saving the form, not the node. It works, but it is not ideal. It's too confusing to have two different entities: drafts and unpublished nodes. How could we tell them apart without confusing the heck out of our users with tables and internal Drupal structure? Perhaps we could relax validation on draft (unpublished node) saving, and enforce them on node publishing. But is still a topic open for discussion.

Promote and Sticky

In today's world of Views and Panels and custom ways to exhibit content in fronpage, these two options are quite meaningless for most sites we build. Consequence? We must get rid of them, in some node types, to avoid confusion by our users. Or give new meaning for those booleans in other node types. Not nice.

I propose that we allow admins to choose, for each node type, whether that node type is "promotable" or "styckiable". For instance, blog posts would be promotable, but pages would not -- even to overprivilege user!.

Moreover, in the same way as "publish" described above, we could convert those two options into buttons. "Promote to front page!" and "Make it sticky!". It would be very interesting to see implement in the edit on page form proposed by Mark & Leisa.

Next steps

As we speak, our interface guy, Danillo is implementing these features in a module in Drupal 6 and we'll port it as one or more patches to Drupal 7. Stay tunned.

Mar 19 2008
Mar 19

Here's a small one-line usability fix for all module developers that I think will be a huge help to users.

In the early stages of a project, I'm often playing around with quite a few new modules: testing them, seeing if they meet my requirements, installing and uninstalling. After downloading a module, the sequence of steps is always the same:

  1. copy to /sites/all/modules
  2. enable at /admin/build/modules
  3. configure all exposed settings
  4. use!

However, sometimes just finding the settings page takes the longest time out of all those steps. Is it in User Management? Content Management? Logs? Who knows!

I'm going to use the example of the Bio module; not picking on the Lullabot team or Bio module maintainers, this one just happened to be the first example I thought of. :)

Bio's settings page is difficult to find, as it's not in "Site configuration" but rather in "User management". It also hides itself quite nicely using the title "User biographies" instead of "Bio settings", as one would expect. The readme.txt file doesn't mention how to find the settings page at all.

So what I had to do in this case, after becoming frustrated with searching for the settings in the menu, was pull up the source code and check out hook_menu() to see exactly where I should go.

And here's my suggestion: we're all used to seeing the "installation successful" messages (and looking out for php errors on install of course). For example, the Bio module has these:


What if this message held the link for the settings page? Then it's just one click away, instead of a potential 2 minute search to find it.


This is just one line of code in the bio_install() function:

drupal_set_message(t('You can edit Bio settings at ') . l('admin/user/bio','admin/user/bio'));

Seems like a small change, but if every module did this, it would collectively save me hours in the module evaluation stages of a project, because I find that plenty of modules seem to hide their settings and not explicitly detail them in readme.txt, requiring me to either hunt them down or open the source.

Since I talked about the Bio module, I've provided a patch in the issue queue. Hate to be a complainer that does nothing about it... :)

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web