Redesigning the Create Content page

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

yoroy's picture Bojhan's picture


The content creation experience is at the center of Drupal, its one of those screens that we want to keep improving. During the Drupal 7 cycle we worked intensively on making this page findable and having a pleasant to use admin theme. However we did not get around to actually improving much of the visual and interaction issues of this page.

  • Creating content will be part of most first-time Drupal experiences. First impressions are critical.
  • When a site is built and launched, creating, editing (and managing) content are the primary tasks for most of the people involved with the site.
  • For many the look and feel of the content creation page is a defining part of Drupal. Redesigning this page allows us to explore a more engaging look and feel for the Drupal admin.

Currently, we don't make creating content as easy as possible. People will manage to type a title and some body text, but quickly after that some serious problems start to arise.

So what do we want to improve? Well, that is step 1. Lets do some research.


Each usability test so far has touched on the content creation page, and we have already fixed a whole lot of issues. In early 2008 we found that the way fieldsets were used on this page was confusing. This is where the vertical tabs were introduced. Every subsequent round of testing and design iteration uncovered new major pain points. During the last test in February 2012 at Google we found major usability issues with links while previewing.

We looked at the current state of open usability issues, what our competitors do and took stock of what contrib does in this space. This should give a complete picture of what we can do and what we can take as inspiration.

This research is not complete, it is not a full overview of everything related to the content creation experience, but rather a selection of the more interesting findings, that we might apply to a new design.

Current state

We have a lot of issues around the content creation experience, some that can be solved by minor tweaking but most of them require major changes in the functionality around this part of core.

A quick summary of the major issues in core:

  • Previewing content is a true DrupalWTF, people are very confused by the fact that preview isn’t shown in the front-end and that the preview shows two versions (teaser and full).
  • Vertical tabs are overloaded with many settings that are not relevant to the user, especially with contrib this area can grow to contain many on-off settings.
  • If you don’t add a menu item, its too easy for a user to lose the content.
  • Text formats are still somewhat of a mystery to people. Instead, people ofthen mention they miss a WYSIWYG editor.
  • We miss the right tools to handle forms with a lot of fields. Currently this often becomes a plethora of fieldsets.
  • It is often unclear what the publishing status of a content item is. Published, unpublised?

There are a lot of usecases to consider, when researching this page we always considered the blank (just core fields), regular (a couple fields) and flooded state (dozens of fields).

What are the others doing?

We have done a quick review of how other CMS’s handle the content creation screen. One of the most notable differences is the amount of “grouping” mechanisms, where Seven only uses a fieldset grouping pattern - Wordpress, Joomla, Textpattern, Hippo all make use of sidebars to promote Publishing options.


Click for larger


Click for larger

We also noticed that the content creation screens are visually often quite messy. Individual fields are not designed and the WYSIWYG editor is often a distraction because it doesn’t match the overall admin visual theme. There is no obvious pattern to where publish/save buttons are placed: bottom, top or sidebar are all used.

One of the major conclusions we can draw however, is that visually many of our competitors have more styled screens. From over the top like Joomla, to very minimalistic like textpattern.

What is contrib doing?

Contributed modules offer valuable insights into what is possible, and hint at what scenarios we should consider. This wasn’t an extensive review of everything in contrib, we looked primarily at a few popular modules.


Click for larger

Integrating wysiwyg editors and other contrib modules such as the Media module is visually still quite problematic. Although the WYSYWYG module does a great job at integrating many different client-side editors, the various visual styles are disconnected with Seven.

Inline editors

Inline editors offer a promising look into what the future of Drupal content editing could be like. Nevertheless, some are straight-out buggy. Aloha editor does a good job, working with several Drupal concepts and providing in line tools.

Click for larger

Inline editing is clearly still very much an experimental field. Things can easily get confusing when editing fields further down a page and it gets saved. However, there is a lot of potential in this pattern.


Click for larger

As we researched other ways of organizing the content creation screen one really stood out, which is the Field group module. This module lets you create groupings such as fieldsets, horizontal tabs, vertical tabs and accordion menus.

We also had a look at how modules embed forms and/or how multi-page modules work. All of these modules offer interesting functionality, but they are visually often very disconnected from the default Seven admin theme.

A clear trend we noticed in customized content creation screens is that people try to find more ways to grouping items beyond the fieldset pattern. In Drupal 8 we will hopefully introduce other way(s), to visually group related items.

Vertical tabs

Since we introduced vertical tabs in Drupal 7 it has become a prominent design pattern, applied to various configuration pages. Its strength is its scalability while remaining relatively easy to scan. Its weakness is its visual prominence, making users feel compelled to check the contents of each individual tab.

An interesting find was that most modules only expose one or two textfields or select lists for configuration. This leaves a large empty vertical space. Occasionally we found more advanced configuration as shown in the meta tags configuration example.

Click for larger


To start, we threw out some sketches to get our thinking started.

Click for larger

We brought these together to compare and review. A trend we noticed in our own sketches it that we where looking for multiple ways to group our configuration, going beyond our current vertical tabs pattern to a sidebar, accordion, dropdown.

From these initial sketches we took a step back and looked at the bigger picture.

Content, settings, actions - 3 zones

We found that on a content creation screen, there are three main areas to group functionality into:

A. Content fields
B. Content settings
C. Publishing options

The ordering in this sketch is what Core does now: it places fields on top, settings in a vertical tab area and the actions to save or preview at the bottom.

We explored different positions of these elements, primarily because B) Content settings are often too prominent.

Conceptually there are at least two obvious alternative configurations:

  1. With the publishing options (C.) on top we mimic the model that a few other CMS’s apply, most notably Joomla. All actions are placed consistently across the top. Taking it a bit further one can imagine to also include publishing options such as date, author, menu, url etc. along the top. This would have the benefit of more focus on these settings, the downside would be creating a one-off design - because this pattern has less use in other screens.

  2. Placing B) Content settings on the side, is a model that is used by most popular CMS’s - where the design often only accounts for a few options. This could be a consistent pattern across core where we place filters for example in a sidebar. The downside is that it can become too prominent and taking up too much horizontal space, requiring the content fields to be more compact.

Settings in a sidebar

A crude sidebar mockup in Firebug, floating the current tabs to the right of the content fields. As you can see, even without any optimisation to the labels and summaries it still manages relatively well within this restricted width.

One of the major challenges of this pattern is not whether we can make content fields more compact but rather whether we can account for complex content settings to be placed in the sidebar. As noted in the research, most of contrib only add simply 1 or 2 options in a drawer but there are the occasional more complex settings. We think a lot of this can be mitigated by optimizing the way that contrib displays these settings by relying more on correct labeling and less on long descriptions.

Publishing options along the top

Click for larger

This wireframe illustrates how we could place publishing options and potentially more along the top. It shows the different settings in a collapsed state while varying between 1) dropdown settings, 2) inline settings, 3) placement of actions in the top area.

We have a lot of breathing space for this concept in core. The current implementation of the shortcut bar could be adapted to swap in or append these kind of configuration options. It will have the added benefit of moving these settings away from the content fields, yet keeping them in view.

This pattern is especially interesting from a mobile perspective, because it allows you to put a lot of settings in a relatively small area.

The biggest downside is that it is hard to apply this pattern to other cases in core. We only have a few pages where you are creating items with a lot of additional settings like for example creating a new content type. However this pattern of “configuration along the top” holds a lot of promise, especially for exposing more contextual configuration in the front-end.


These research findings and design explorations should inform the direction we chose in designing this page. To summarize what we suggest to use as the foundation for more detailed design iterations:

Click for larger.

  • Keep the current approach of listing content fields in the main area but look into more ways to group related fields beyond fieldsets
  • Rework the vertical tabs pattern into a less horizontal space consuming sidebar. (And look into applying a similar sidebar concept to other admin screens.)
  • Move primary publishing options out of these tabs and position them closer to the Publish/Save actions.

We're working on more detailed designs for this, but right now we'd love for you to critique the research and wireframes so far:

  • Do you think this is a viable approach? If not, where does it break, and how?
  • Do you have more interesting examples of things that get put into a vertical tab?
  • Have you seen other ways to group content fields besides fieldsets?

We would love to hear your feedback, we are especially interested in custom content creation screens you may have created or seen.

Thanks for reading this far, more soon!

3-page-areas-variations.jpg35.16 KB
3-page-areas.jpg63.99 KB
5-possible-workflow-states.jpg54.96 KB
Brainstorm-compilation.jpg54.41 KB
Conclusions-large.png89.48 KB
Conclusions.jpg16.85 KB
Publish-settings.png29.81 KB
Sidebar-mockup-seven.png184.93 KB
Workflow-on-top-large.png87 KB
Workflow-on-top-small.png62.2 KB
Brainstorm-compilation-large.jpg551.38 KB
vtabs-pathauto-small.png76.26 KB
vtabs-pathauto.png76.24 KB
vtabs-scheduler.jpg36.41 KB
vtabs-metatags-small.jpg27.33 KB
vtabs-metatags.jpg116.21 KB



jwilson3's picture

Great work!

But, what is a "harmonica" configuration? Did you mean accordion?

whoops! Yes!

Bojhan's picture

whoops! Yes!

Great stuff :). I like the

theamoeba's picture

Great stuff :). I like the actions across the right hand side with all the media under the body. It is a bit, dare I say it, like Wordpress.

Re: Hamonica

tkoleary's picture

jwilson3; you mean you're not familiar with the harmonica? It's a well known design pattern. :)


JohnAlbin's picture

meh. The harmonica pattern blows.

(Sorry. Couldn't resist.)

  - John (JohnAlbin)

You're overlooking something

styro's picture

The harmonica pattern can also suck.


As a site builder, I strongly

CatherineOmega's picture

As a site builder, I strongly support moving the publishing options out of the dropdown. I like the two-column approach, with the publishing options on the right, (Yay, Rubik.) but often have built sites where I simply don't want users in the content creator role to necessarily see any more than the basic "save as draft" options. Moving the most obvious functionality out is a good step to making it easier to hide the rest as needed.

I like the approach described

tvn's picture

I like the approach described in conclusions section! Even though with sidebar pattern there will be a need to design another version of the page - for small screens.

Workflow along the top of course is much more mobile friendly, but right now I don't see any mockup there, which I would prefer to sidebar version (for desktop usage). Besides there is no real need to hide all of the options so much when user is on the desktop. There is plenty of space and it should be used, no need to make people click more than it is necessary. I also support the point of choosing the pattern, which can be consistent across admin screens, this is very important for overall experience.

I am in favor of moving publishing options closer to Save/Preview buttons. If we stop on sidebar pattern, I support moving Save/Preview block to the top of right sidebar. This way we can be sure it is always on same place. While when its under content fields - sometimes content fields longer than sidebar, sometimes it can be vise versa and you'd have to go up to save. Plus this will allow status of the post to be clearly seen right away.

I am not sure now what are the cases when full page width absolutely needed for content fields, but maybe as one of the options we could consider possibility to collapse whole sidebar to the right.

I also think we need to discuss how will preview function work along with all these changes.

Nice to see the initial

yoroy's picture

Nice to see the initial comments picking up on the idea to move publish settings out of the vertical tabs. It looks to be one of the most effective things we can do here.

I sketched around this whole publishing workflow a bit more:

Click for larger


Both obviously go beyond core-only but try to envision more real world scenarios.

Some Thoughts

headdragon's picture

We need to look at this like a book. I mean, a real book. If we are looking at a page we see everything that we need to interact with on that or the facing one. Like figures and foot notes. Laying the page out in Left to Right for LTR languages top to bottom directs our eyes in familiar patters. So new users still look on this page for everything. This is CMS so when you click something like save you don't need to go anywhere else in the book. Using the example 5 when you click "tag" part of the page changes not the whole page.

The main options need to be visible at all times. The least used options need to be under a more options tab/menu.Let that area accordion out to visibility. When it accordions out the main elements of the page should never move.

What I mean take the big picture above and move the save button under the URL and above the Option buttons for tags and keywords. Save should always be just under the main content. That is normal work flow. Traditional databases auto save as you exit fields. So hundreds of little packets get sent into storage. Less chance of loss that way.

Apple wrote a book many years ago called the "Human Interface Guidelines" You do not need to reinvent the wheel. Many large consumer corporations use this book in the interface design teams. Remember you could never get a VCR clock to set because it was some odd combinations of buttons. Then the book came out and the VCRS got a clock, a timer button or an on screen menu with up down left right arrows. So setting the clock got easy. That book is why.

My thoughts

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

How about this concept which

gmclelland's picture

How about this concept which is more mobile first. Then we could use progressive enhancement to expand out to a two column desktop version with a fixed header for the save buttons. That way the save buttons always follows you on top.

Hope that helps,

Pimcore uses a similar concept. See this image at

Yep good point! Mobile should

yoroy's picture

Yep good point! Mobile should do something different than the sidebar thing. A part of an earlier version of the 'conclusions' pic posted above had this:

That pimcore screenshot doesn't look too mobile friendly either though :)

If you want to show images inline, edit the wiki page itself to attach your pics, use the resulting img url for posting in the comments)

button confusion

cpelham's picture

Hey, I see the "Save" button on the top...and understand what that means. :) But what is the PUBLISHING button to the right of it for? Is it even a button? Looks like a button.... And why is it PUBLISHING rather than PUBLISH?

Christopher Pelham
CRS (Center for Remembering & Sharing)

CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.

Publish means update the

headdragon's picture

Publish means update the database. It is not committed until you save. Publishing means the act of doing the work.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Save and Publish

cpelham's picture

Why do we need buttons for both Save and Publish then? What is the difference? Doesn't Save also update the database?

Christopher Pelham
CRS (Center for Remembering & Sharing)

CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.

Thanks @yoroy. Sorry, I

gmclelland's picture

Thanks @yoroy. Sorry, I included the Pimcore links to show how they have the Save buttons at the top that are fixed and always available.

Great job on the wireframes and research.

Considering one of the

LewisNyman's picture

Considering one of the original problems was that the settings kept getting missed at the bottom I don't think it's appropriate to just shove the side bar to the bottom on small screen devices.

I don't think fixed position elements are a goer for technical reasons. We still have to think about devices that don't support it at all anyway.

How about moving the additional options to a second screen in a two stage process? We'll have a whole screen to utilise and it will ensure they can't be looked over.

That is very true

headdragon's picture

I used an Android with OS2.1 and very few pages screwed up it was always the fancy buttons and over large graphics that were the problem not usually how the site was laid out. I have an iPad 1st Gen and really it works just fine on non mobile enabled websites.

Who really works on the site with a phone?

Head Dragon Kid Stevens
Of Web-DrupalDesign .com


ransom's picture

Many people in developing countries use nothing but a mobile phone as there web platform. That and considering how web centeric the mobil envyroment is with many apps being nothing more than a web view on a mobile device it's critical that things be viewable and preferably easy to make so on drupal.

If you ignore the mobile market you will be ignoring an inreasing share of the market. I'm using an android tablet right now while not a phone it's often seen as sutch and I'll often ignore a site that locks me into some mobile only view & forces me to change my user agent string. It's a matter there of an enterprise site you can imply "trust" with and one that dosn't care about it's users and might risk my credit card, privacy, etc.

Some examples of things that are good to handle from mobile devices is a restricted site where you auth users. Rolling a mobile app in a web view with services is more than the average nonproffit arab spring site is going to do. Approving posts on a site that is centered around a youth center is probably not going to get that ideal thing either. Those boath don't really need it either. A little email & a mobile friendly administration would give the users & administers instant gratification.

I for one wish drupal had a better system to enable theming mobile devices, and it was less dependant on non core modules. A nice default css for trargeted devices & good documentation of targeting those devices would grately beinifit drupals mobile life. Not all css rules apply to android that do to iOS, it's better than IE but that's not saying much.


batsonjay's picture

There's an obvious use case: On-the-scene reporters who want to build a story in real time.

Drupal is fairly successful in the "media" vertical (e.g. TV, radio, news). These organizations often say they want their field reporters to create content live, on-scene, whether it is an accident, a sporting event, or a political rally.

These people will definitely:
- Be creating content from a phone
- May need access to fieldsets & publishing options

Extending the responsive

kika's picture

Extending the responsive vertical tabs to a more generic issue: Perfect match with yoroy's mockup here I am seeing just now! ;)

As far as content goes

headdragon's picture

I would like to turn off anything like created by on date or have it on. Great in a blog or forum but horrible in the content on a page. I used a book for the first time and all the created by messages is not needed when I was using it for its organized look. I wrote a long article on data migration for large systems 5 pages worth. Plus that content is so rigid that if you click the up or back or forward links it defaults to the system page. i use Panels and wanted content in the center. That works if you use menu links but I cannot edit the forward up and back to do the same.

In some ways Drupal is too rigid in other just right.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Some themes will give you control of "created by"

David D's picture

Zen, for example, gives you the ability to turn off the post information (submitted by) on a per-content-type basis.

Where are Zen settings found?

Christopher James Francis Rodgers's picture

@David D

I use a Zen sub-theme created by the Zenophile module.

Please tell me where to find, as you say, "the ability to turn off the post information (submitted by) on a per-content-type basis".

I only know of the Core setting: Taking 'Book page' as example...

'Structure' » Content types » Book page: Edit » Bottom-vertical-tab 'Display settings' : 'Display author and date information' check-box.

Thank you in advance.

  • Chris
  • Please do Not 'Reply to my posts;
    so that I can edit them in the future.
  • Thank you; kindly.
  • Chris -

Good news

David D's picture

I mis-spoke, but the upshot is good. It's actually nothing to do with Zen, since checking other sites of mine not using Zen show the same thing, so I believe it is core Drupal. At /admin/build/themes/settings (Global Settings on the Configure tab at Administer » Site building » Themes), there is a column on the right with this heading:

Display post information on
Enable or disable the submitted by Username on date text when displaying posts of the following type.

Below that is a column with a checkbox for each of your content types.

Related idea

Noyz's picture

Here's what we've seen or heard in Drupal Gardens:
1. Users are intimidated by all of the options
2. Users don't know what most of the options do, and most don't care - until they do
3. Not sure of what's what, or what's needed to actually complete what's in front of them, users look through all of the options.
4. Users don't know what Save does, they want to publish or save a draft
5. Users don't read. All that help text doesn't help, it just makes the UI look hard.
6. Admins love features and power, and enable module after module exacerbating 1-5.

I have others, but 1-6 are probably the most relevant for this topic and where I'm going.

Given the above, we need a UI that's simple and clutter free at the starting point. To do that, we need to use the pattern of exposing features only when users decide they want them. For example, don't show a large text area to capture description UNLESS the user says they want a description. You can see this pattern in Views:

Default state:

Full state:

Following this pattern, we should be able to do this:

I really like the idea behind

edward_or's picture

I really like the idea behind

Hide options until they are needed. And in the case of defaults (urls for example) hide the edit widgets until the user wants to edit.

We might have an issue when the defaults are long or their are many of them but it is a big improvement over the current system.

@noyz"4. Users don't know

samwillc's picture


"4. Users don't know what Save does, they want to publish or save a draft"

This is so true! I still don't know why the submit button has to say 'save'. Save where? Save for later? Oh, you mean publish!

That mockup is great. Maybe 'close' doesn't make too much sense though.


I think people are used to this terminology mainly because of their email systems i.e. lots of gmail users.


yep, major usability issue for it

In my world Save should save

headdragon's picture

In my world Save should save it and publish it. Publish it would be to put it up and look at it so you can decide to keep it or not.

In the picture above it a reversed. You always save something to use it. Save as Draft is to be worked on later and Preview is exactly that In panels they use the term update and save meaning the SQL server gets the code and when you drop the overlay if you are on that page you see it. Then there is Update and Preview meaning the temp file gets the code as a save draft copy and then you see a horrible preview but if the elements are there then elements will be there, If you close the overlay the page behind has no changes because the Save to the SQL server never happened.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

Draft Nag

ransom's picture

I think one of the most common problems is them not understanding how draft "works" that it's not "published" and wont be viewable without entering the que. I think that design is grate, however I think some "idiot proofing" would be good to add as swell.

(psudo code)
if ($node.published != true && $user.permission.publish == true && $user.settings.publishNaging==ture ) {
$jquery.Lightbox("Are you sure you do not want to publish this, only you and other users with the proper permissions will be able to view this in the editing que.", buttons["yes","no", "dismiss"]);
(end psudo)

Basically if the user has the ability to post published and the user setting of verify saving drafts enabled then it will nag the user out of helpfulness. With jquery it could be a client side alert you could do a warning message if they have js disabled.

Just my 2 cents though. Its the one thing that trips up people the most I've seen. I usually add a warning when a draft is saved that's not that fancy, saying "You must view this in the (link to que) to make public viewing as a published copy later" to clarify that. Via rules or a small module.

Perhaps some "advanced help" with context sensitive help bubbles could help the default publishing schema. I've not really played with that though, it would be less "interactive" and more destructive to layout without java-script, being as popups are often disabled by default.

Minimum fields, set by the Admin

jimcaruso's picture

I agree with Noyz. For certain sites, exposing tagging and SEO information is desired. Just for the record, I hate vertical tabs because: If fields that are hidden by tabs should be completed, why hide them; and if fields under a tab are not required, why even show a tab. Fully expose what is required, hide everything else.

Jim Caruso
(M) +1.404.788.0188

We'll want to avoid nagging

yoroy's picture

We'll want to avoid nagging people with confirm dialogs, but the issue you point out is very real. I think we just have to work really hard to get the wording and messaging right within the interface elements themselves (instead of waving flags on top of them).

I'm glad a lot of the feedback focusses on this part of the UI, it is a critical part for sure, looking forward to more ideas and suggestions around this. Thanks!

Yup totally agree with this -

shaneod's picture

Yup totally agree with this - looks like big improvements are on the way in this regard, but non-techy users definitely get "confused" when faced with too many options and fields.

As well as the layout improvements, which looks great, terminology is key - I think "Publish" and "Save as draft" are pretty clear.

Pride Web Design Cork

btw, this is great

jimcaruso's picture

Thanks for thinking about this issue.

Jim Caruso
(M) +1.404.788.0188

I agree, and

batsonjay's picture

... will +1 appropriately. :-)

Agree! Looks like Drupal 8 is

shaneod's picture

Agree! Looks like Drupal 8 is going to be a big improvement if these ideas are hammered out and implemented! - Great work folks!

Pride Web Design Cork

Save, View and Publish

NWwaterboy's picture

Save to continue to work on it later. View or preview to see what the progress so far will look like in the context of the page it will be published in, view/preview should automatically initiate a save. Publish - initiate a save and make it available to the general public.

agree with the conclusion.Of

sibiru's picture

agree with the conclusion.

Of course with some toggle permission to dispay less tab editing group for certain user roles

another one big issue is, we

vinoth.3v's picture

another one big issue is, we cant assume that content is the only main area that needs in the middle of the screen, with the power of field api the developer can have any number of textareas (with WYSIWYG) tht can't be grouped inside the side panel.

The best solution in my mind is to use panels, and let the developer design/modify the content creation page of their own.

Vinoth - வினோத்

I agree on the Another Big issue

headdragon's picture

I use panels all the time. I can't stand the placement policies of most themes. In fact that is my only reason for studying advanced theming. I come from HTML 1 and though I never used it until know to make a profit. The placement of elements where you want to is paramount to good and unique web design.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

That is what I get for typing

headdragon's picture

That is what I get for typing half asleep. I mostly have not used HTML and web design to make a profit. Just my personal pages and to teach other people. That is until now.

Head Dragon Kid Stevens
Of Web-DrupalDesign .com

content type

hixster's picture

Just my $0.02 - would be great to have an easy way to see which 'type' of content you are editing.

I've come back to sites after a few months and edit some content directly from the public facing side and sometimes it's hard to tell which content type the node is made from...

I often resorted to building a dev block which prints this info in the tool bar just to make life

I think WP prints 'edit this post' or 'edit this page' - Drupal shows you the content type when you're creating it, but once done, you're on your own :-)

This already exists

David_Rothstein's picture

@hixster, good news - the behavior you're looking for already exists in Drupal 7! :) It was added to Drupal core several years ago via

When you edit content, the page title is now "Edit [type] [title]" so you can easily see what type of content you're editing.

Pagelines for Wordpress

mori's picture

Just found this and the first impression looks good for inspirations:

Pagelines: A Professional Web Design Platform for WordPress

drupal is all about custom

snatzh's picture

posting here with my current editing problems. The way i see it is nice to have a kind of a quick start or u know just ad content option. If you are the only one adding content. what i would like is to have a straight forward customize your own content creation page.
For example i'm making a site for real estate brokers. And i'm looking for the best way to categorize the site.
There is going to be several different search menus with different search options,
I wouldn't want to have to teach new brokers who join my firm how to add new units to the site, Should be straight forward,

For example add sell unit or add rental unit, two main options with different variables.

Only been using Drupal for a short amount of time but seems that i need to use Views and the built in filter system to make it happen,

Ps, if anyone can point me in a direction of a tutorial on how to do this it would be great,

drupal is all about custom

snatzh's picture

posting here with my current editing problems. The way i see it is nice to have a kind of a quick start or u know just ad content option. If you are the only one adding content. what i would like is to have a straight forward customize your own content creation page.
For example i'm making a site for real estate brokers. And i'm looking for the best way to categorize the site.
There is going to be several different search menus with different search options,
I wouldn't want to have to teach new brokers who join my firm how to add new units to the site, Should be straight forward,

For example add sell unit or add rental unit, two main options with different variables.

Only been using Drupal for a short amount of time but seems that i need to use Views and the built in filter system to make it happen,

Ps, if anyone can point me in a direction of a tutorial on how to do this it would be great,

If it is twice i'm really sorry but it asked me to insert a verification code twice, A bug maybe?

Hey just a thought here.

alex_drupal_dev's picture

How about use a different approach entirely. You could make publishing a joy for everyone by allowing all the stuff above in the tabs below and having 10 pages of content at a time.

Allow people to do like 10 pieces of content at a time on one page. Have all the setting be able to be copied across all pieces of content and in tabs below you could add the ability to expand any section.

That would make a better workflow. Decrease work time by increasing capacity to do more at once and it would look awesome.

I have a beautiful layout pic I can post if you want. I know I dream of a mega loader for content myself. Just saying.

This would be the layout:

Title 1:
Body: (4 Lines Space with ability to type any amount.)

Title 2:
Body: (4 Lines Space with ability to type any amount.)

Title 3:
Body: (4 Lines Space with ability to type any amount.)

Title 4:
Body: (4 Lines Space with ability to type any amount.)

Title 5:
Body: (4 Lines Space with ability to type any amount.)

Title 6:
Body: (4 Lines Space with ability to type any amount.)

Title 7:
Body: (4 Lines Space with ability to type any amount.)

Title 8:
Body: (4 Lines Space with ability to type any amount.)

Title 9:
Body: (4 Lines Space with ability to type any amount.)

Title 10:
Body: (4 Lines Space with ability to type any amount.)

Tabs here with expand options for all options listed at the beginning of the post to allow customization of all ten pieces of content at one time with permissions and everything listed. Number 1 - 10.

Want to increase workflow you can get serious about it. This will do it for sure. You would have a lot of happy people out there thanking you for making their job easier. This would be marvelous.

Anything can be improved if your main goal is to build it better. Don't try to fix a problem, try to make it better. Once it is better, try to make it better than that.


Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: