This is a meta issue concentrating on improving the UX in display suite. Code is written in a feature branch called restructure. (git clone --branch restructure

Background info:

Feel free to give your opinion!


  • Restructured the strcuture/ds screen
  • Improved the switch layout screen,
  • Each layout can have a preview
  • Changed "styles" to "CSS classes" in the user interface and in the code
  • Seperated primary and secondary tasks in the UI
  • Contextual links are on by default and can't be turned off in DS extras abymore
  • The revision mode is insert by default and can't be turned off in DS extras anymore
  • HTML5 solution: wrappers for the layout, regions and subregions (Field Group)


  • New template system
  • Region settings (next to the region and not in vertical tabs)

Known issues

  • Field template tests are broken
  • The layout previews are kittens

Original issue:

After playing around with ds again after a long hiatus I had a closer look at how the main admin links for DS are labeled and described. I think these could be improved in how they 'project' what you will find on the pages behind them.

I'm attaching a mockup with my suggestions for discussion.

I removed 'View modes' in this version, thinking these should be found as children of 'Displays/layouts'. I understand that's a more drastic change then rewording existing UI text. I did it also because View modes are hard to explain :)

Members fund testing for the Drupal project. Drupal Association Learn more


yoroy’s picture

before/after screenshot of admin/structure/display suite links

yoroy’s picture


- The ordering seems off. Especially the 'Extras' shown first is just not logical
- Haven't played around with the 'Fields' stuff, so I don't have a clear picture yet of what it lets me do. As is, the description doesn't really help explain what you can do there.
- Layout. Important word to use here. Stubborn me thinks these should be called Displays regardless :) I know this is a potential clash with how Views uses 'displays' but I think on a conceptual level they are more similar than different. You could also rename the module to Layout Suite ;-). Since all other links here are in plural form, maybe this should be too.
- Styles: I think it is important to use the trigger word 'CSS' here and drop the 'if available' disclaimer.
- View modes | Manage view modes for all content. The description doesn't really add anything. Hard to explain what these are. These might make more sense in context of Displays, as variations on displays. No quick solution here.

I'm going to try a patch with only the less controversial changes :)

yoroy’s picture

Status: Active » Needs review
947 bytes
None View

Small beginnings…

jyve’s picture

Could not agree more with the proposed changes.

The term 'layout' is currently used to indicate the templates: 'one column', 'two column' etc, so it indeed makes sense to talk about Displays first. Getting some kind of structure in the use of the words 'Display', 'Layout', 'Template' and 'View modes' seems like an important thing here.

A will try to do some thinking on this too and throw any feedback I have in this issue.

aspilicious’s picture

I made some progress in
It looks a bit like the screenshot in #1 now.

I agree with yoroy that "styles" is a confusing name for CSS classes. I'm planning to remove every single instance of "styles" in the UI and in code. This means I need to update some variable names. I wont change the word "styles" when it is used as a classname because that could brake templates.

Yes I even changed "Layout" to displays, because it's a list of displays that you can manage.

aspilicious’s picture

Title: Thoughts on labels and descriptions for the admin links on structure/ds » META: improving UX in DS (and a bit of HTL5)

Changing status

aspilicious’s picture

Title: META: improving UX in DS (and a bit of HTL5) » META: improving UX in DS (and a bit of HTML5)
aspilicious’s picture

Issue summary: View changes

Changed summary

aspilicious’s picture

Issue summary: View changes

Updates summary

aspilicious’s picture

373.08 KB

Updated summary and zip file with the changes in the restructure branch!

westie’s picture

+1 for the changes, I LOVE DS but the UI / UX can be a little confusing.

westie’s picture

Issue summary: View changes

Updated issue summary.

aspilicious’s picture

Issue summary: View changes

Added background info

cosmicdreams’s picture

is it better to use the provided zip file or the git repo?

aspilicious’s picture

the git repo is always up to date ;). The zip is just a snapshot.

aspilicious’s picture

29.94 KB
60.63 KB
16.58 KB
86.44 KB
38.04 KB
329.6 KB
44.83 KB
14.98 KB
214.63 KB
20.74 KB

Uploading a bunch of screenshots for reviewers.
I'll add more info about the HTML5 solution in the near future :)

Argus’s picture

Somehow the dummy pictures don't load. Me wantz kittyz!

aspilicious’s picture

Are you using the zip of git repository? And if you had DS installed before you need to clear caches and run upgrade.php

And DON'T use it on production sites :)

jstoller’s picture

60.78 KB

I like much of where this is going. But looking at before and after #1, what have you done with fields, styles and view modes? I'm not a big user of the styles myself, but custom fields and view modes are two of the major reasons to use Display Suite. Also, keep in mind that there are other modules you can enable which add even more options to this page. For instance, my current site also includes "Forms" and "Search" (see image).

display suite landing page

aspilicious’s picture

43.36 KB
41.25 KB

Forms and search are still in the home screen. They are part of the ds_forms and ds_search submodules. So no worries they are not deleted ;).

Fields, styles and view modes ARE removed from THIS display because there is no context on this screen what it does. So we moved the links to places with more context. We also renamed styles to CSS classes.

Our main goal is to seperate primary and secundary tasks. Displays should always be the first option.



Argus’s picture

@#14: Testing locally ofc, I indeed didn't run update.php, but after I did (and cleared cashes) the image still doesn't show. It points to http://localhost:8888/sites/all/modules/ds/layouts/ds_1col/ds_1col.png so it doesn't use the correct path. Used the git repo.

jstoller’s picture

To be honest, I never understood the need for the Styles page. I don't know why I would ever want to list classes in a central location prior to assigning them to regions and fields. I would much rather regions and fields just had associated text fields where I could directly enter classes as needed, on the manage display screens. I have yet to think of a use case where the Styles page is anything but a hindrance.

Fields and View modes are different though. By their very nature, they span across entities and they need to have centralized screens where they can be managed. Including links to these screens from within the display management screens is great, but I don't want to be forced to go into some random display management screen, just so I can get to a link that allows me to manage my fields or view modes.

As I see it, there are two possible solutions to this. First, we can leave Fields and View modes as first-class citizens on the DS landing page, listed just below Displays. I would be fine with this myself, but understand the motivation to move them. The second option is to split the Displays page into multiple sub pages, with horizontal tabs for "List Displays", "Fields" and "View Modes". This properly associates fields and view modes with displays, giving them the context you're after, but still makes their management screens relatively easy to access. If we still need to have a Styles/CSS page, then I would add a tab for that here too.

aspilicious’s picture

what is the correct path? Seems I have to add some kind of base path...

1) I'm not going to add all those links back, I talked with a lot of people and they were confused about the bloated start screen.
2) Fields added in this screen *only* appear in the manage display screen when you enable display suite layouts. So they are not "site wide", same for CSS class (aka styles)

I think the CSS classes page is used to be sure the classes used in your project are consistent. But I'm going to verify this once more.

3) View modes is different, I can see cases where you want to add new view modes without touching DS...
4) Making everything a tab would be great if the list of options wasn't that long. I don't want to have 6 primary tabs

So I'm not sure what to do about this yet. I'll ask for more opinions.

jstoller’s picture

I understand Fields aren't "site wide", in the sense that they don't do anything outside of DS. However, they do apply across multiple entities, as well as entity bundles/content types. They're also more complicated constructs, having a number of configuration options and, in some cases, embedded code. When I create or edit a field, I don't want to have to go into a specific display management screen. Fields are more general than that. Same with view modes, which as you point out are very much "site wide" constructs.

I think you misunderstand what I'm suggesting with the tabs. The main DS landing page would be as you suggested, without any tabs. What I'm talking about is what happens when you click on the "Displays" link. At that point you would be taken to a page with four tabs:

/admin/structure/ds/displays <-Default tab. Equivalent to current Layouts page.
/admin/structure/ds/displays/view-modes <-Equivalent to current View modes page.
/admin/structure/ds/displays/fields <-Equivalent to current Fields page.
/admin/structure/ds/displays/css <-Equivalent to current Styles page.

This accomplishes your goal of removing bloat from the main landing page and correctly places fields and view modes within the context of "Displays," but it does so without overly minimizing their importance or burying them inside individual displays. It also allows modules like the Admin Menu to give site builders direct access to these pages, which is a very important use case.

Argus’s picture

It needs before what it uses now, so you would get

$base_path ?

Argus’s picture

31.24 KB

For the Displays page it would be more logical to have nodes on top instead of comments. I suppose it displays the categories (comments, nodes, taxonomy terms) alphabetically now. See attached image.

edit: Another thing you could do is add an indent to the subcategories on this page, eg for Node:

- Article
- Basic Page

This would make it much easier to understand the difference between category and sub-category.

jyve’s picture

A list of my feedback:

Completely agree with #20. Using the tabs like that would be a huge improvement. Especially the fact that you land on the layouts page would be nice for beginners.

The 'Layout wrapper' looks weird in that place. Maybe we should combine 'layout wrapper' and 'HTML5 wrappers for regions' into one vertical tab called 'Custom wrappers'?
I'm also not sure about having the 'HTML5 region wrapper' as an option in DS_extras. Especially since the template files in DS core are already prepared for this functionality. I would think that this is on the same level as custom CSS classes, so could be in DS core too.

And to finish it of, the vertical tab 'Extra classes and...' should then be called 'Custom classes'.

Detail: under the 'Extra classes for...' tab, the human readable name should be used. e.g 'Class for region Content' instead of 'Class for ds_content'.

Speaking of DS Extra's: I would move 'Extra Fields' into the 'Other' vertical tab, so that only two are left.

But of course: very nice work aspilicous, keep it up!

aspilicious’s picture


1) yeah I also agree with #20
2) I was planning to create region settings, when that happens the CSS classes tab and the wrapper tab are not needed anymore. If that is going to happen where do you think I have to place the layout wrapper?
3) I would love to place the HTML5 wrappers in ds core, would remove 3 TODO's from my code ;)
4) "under the 'Extra classes for...' tab, the human readable name should be used." => will fix this
5) "I would move 'Extra Fields' into the 'Other' vertical tab" => not sure about that... if you click the checkbox you get a text field, maybe if we put the option on the bottom of the "other" list.

"It also allows modules like the Admin Menu to give site builders direct access to these pages, which is a very important use case."

I didn't remove the page I just removed the link, so with the current code admin menu can still link to the view modes admin page. But I'm going to implement the flow described in #20.

aspilicious’s picture

15.2 KB

Not yet pushed but implemented #20


aspilicious’s picture

@argus, fixed the base path in the git repo (I hope!)

jyve’s picture

@Aspilicious, I would like to add something to your list if I may :)

With choosing a template, you can choose 'Hide empty regions'. However, if your template is not one of the Fluid ones, this does not do anything, which is very confusing.
Personnally, I would simply remove the option 'hide empty regions' and leave the logic to the template. In this case, all fluid layouts will hide their regions since that logic is in the template file. Other, non-fluid templates will not hide empty regions.

BTW: the new tabs look great!

swentel’s picture

Status: Needs review » Fixed

I think we can safely say the current state is ok (there have been a couple of other commits already as well). Great work already everone!
Let's settle on the current state for a couple of days/weeks to see how this evolves :)

swentel’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

kitten notice