When I was first researching Entityform and other survey form modules, I had four basic questions I was trying to resolve.

1. I don't want to create a survey form, so why would I want to use a survey form module?
2. How does Entityform help solve my problem?
3. When should I use it
4. How is it different from other solutions?

After doing some research and talking with Tedbow, this modules author, I think I can start to answer these questions.

I don't want to create a survey form, so why would I want to use a survey form module?

I just had this same discussion with a friend of mine the other day. She wanted to include a signup form at the bottom of an event content type node. This sign up form would allow people to register for the event. (Yes, I know she could’ve used the signup module. However she needed more functionality than the signup module offered.) I suggested she use either Entityform or Webform. Her immediate response was "I want to create a signup form, not a survey form". And therein lies the confusion of “survey” form modules.

Legend

= Recommended style to use
= Style to avoid using

Contents

• Recommended resources
• Including new users and visitors
• Person-to-person communication
• Drupal-specific terms
• Referring to a specific module or theme
• Explaining version differences
• "Upgrade" vs. "update"
• Naming
• Industry-related words
• Acronyms and abbreviations
• Numbers and Dates
• Punctuation
• Symbols and Icons
• Writing style
• Voice
• British/American differences
• Miscellaneous notes on usage
• Titles and headings
• Procedure style
• HTML and code formatting
• Links
• Paths and navigation

Notes

Organizing content in Drupal can be very liberating — or very frustrating, depending on what methods you're used to using.

Almost all information in Drupal is stored as a 'node', the basic unit of content. By default, there is no hierarchy or structure imposed on these nodes: they do not reside in specific 'sections' of your site, and different kinds of nodes (images, blog posts, news articles, etc.) are not automatically grouped or sorted into different groups. Rather than hard-coding specific hierarchies or styles of display, Drupal treats your content as a giant soup, with each piece of content having properties like a title and an author, a 'published' flag, a publication date, and so on. Specific kinds of pages, specific sections of your site, and so on are created by pulling up any content with certain properties and listing it.

Some examples can help clarify this concept.

1. Default front page

A single web site could contain many types of content, such as informational pages, news items, polls, blog posts, real estate listings, etc. In Drupal, each item of content is called a node, and each node belongs to a single content type, which defines various default settings for nodes of that type, such as whether the node is published automatically and whether comments are permitted. (Note that in previous versions of Drupal, content types were known as node types.)

When you first install Drupal with the default installation profile (in contrast to the minimal installation profile), you will have two content types defined: "Article" and "Basic page". When you enable other core and contributed modules (by visiting Modules), you will find that you have other content types available; you can also create your own content types (see below).

Content types in Drupal 7 and 8

Article