2.0 Disable but display inaccessible links: As of now, Drupal does not know and support this concept. We have to bear in mind that this would have to work globally. So users would see all kind of menu items and links that are disabled. I see your point though. However, from a technical perspective, it is a major security issue — most often, you do not want your users to see things they are not allowed to see. That’s the purpose of permissions. If the system starts to display stuff a user should not be able to see, access, or view, we are in deep trouble. On top of that, it is also a design/theming issue: Such disabled links could not be links at all.

CONTENT

1.0 Number of contents: I think there is a discrepancy in what we call “content”. The mockups I can see here make me assume that “Add content” will allow me to add content on the very same page I am looking at. (Why should that link be displayed that highlighted in the header otherwise?) So, content of a certain content-type is not the only thing I can add to a page. I can add blocks, views, etc. That’s why I referred to “panes”, which is a term of the Panels module, and describes a piece of content one can add to a region on the page. While you can have 10-20+ regular content-types, you can easily have 200+ of re-usable panes that can be added to pages.

If those “Add content” / “Edit content” links are not supposed to add/edit content on the currently displayed page, then I highly believe that they are placed wrongly. The suggested location implies that the user can add/edit content within the context of what he/she currently sees.

VIEW/FIND CONTENT

Yes, there is a difference between selecting all visible and all possible items in a view. The first is what a user expects to happen if “Select all” is ticked, and the user then goes on to “Delete all”. A major “WTF” if the user suddenly finds out that ALL content of the selected criteria has been deleted. However, there are also many cases in which you really want to select all (ANY) items that match the current criteria.

- my thoughts on Vertical Tabs are above (in response to Sun’s feedback).
- I think I agree that tags/categories can go on the main content creation page – the process we’re going through is to pare things back as much as we can and then gradually add things back in – it strikes me that this is a logical add.
- I also agree re: add content type link. It’s coming out

Header
2.o Show to all disabled to some – are you saying that it’s not possible to do this in Drupal? The idea would be that you could see the menu item (so you know it exists) but that it is greyed out (so you know you don’t have access to it, need to find someone with greater access levels than you to get it done). I’m not convinced it’s a great idea from a UX perspective… would welcome more thoughts on that.

5.0 where is it closed? an excellent question – the open will turn into a close switch – stay tuned in the next release.

CONTENT
1.0 I’m actually not a great fan of the ‘on hover’ menu, but others are so I’ve got it in there to be usability tested and we’ll see how it goes. Good point re: scalability tho’. I’d be interested to know what the average number of content types per Drupal site is… (in fact, I might ask that to the world!)

ADD CONTENT OVERLAY WINDOW
Actually, these are really more ‘overlay windows’ than ‘modal dialog’ windows, and we plan to implement them so that the overlay will set the length of the page, so I don’t think this will be a problem. It’s a good pick up re: considerations for this approach tho’, and again, important to consider scalability.

ADD CONTENT – META
We’re looking for the right way to use Vertical Tabs. Personally, I don’t think the Meta page is the best place to do that, as we’re really working to improve the scalability of what can be a pretty intimidating set of options… I think there is a chance you’ll see some vertical tabs action in coming wireframes or page designs soon.

VIEW/FIND CONTENT
Select all items not just those visible. This is another good point. I wonder if this should be the only setting available… is there a strong use case for only selecting the visible results do you think?

I don’t like the content creation wireframe so much. Some comments:

I agree with Sun: Vertical tabs looks a lot more useful than a separate meta page for these settings.

Categories/taxonomy should be on the main content creation page. In most use cases I can think of, tags/categories is something users want to add almost every time when adding new content, for content types where taxonomy is enabled. So going to a separate page for this seems clumsy.

The “add content type” link doesn’t belong here, in my opinion. For most use cases, content types are created by the site builder, after (hopefully!) thinking deep thoughts about the types of information on the site, and how to show them. It’s something that’s done much much more seldom than creating content. So a prominent link to a little used function is likely to add confusion, and result in lots of extra content types.
This can, of course, be solved by not giving most users permission to create content types. But I make sites for small clubs and festivals in my spare time, and then I need to hand over the reins, and the full admin power, to people who don’t have very much Drupal experience. I handle this by:
- making blocks for them with customised admin menu for the most usual tasks
- giving them full permissions to do (almost) everything
- giving them a test copy of the site where they can go bananas with their admin super powers
When doing their usual tasks, like posting content, I want them to only see what they need for that. Advanced site builder options like content type creation is something I’d rather not shove into their faces — that’s something they can find when (if) they feel adventurous and go exploring.

Any more suggestions like these gratefully received (perhaps I should surface all the ‘attention required’ issues in the wireframe and tackle it that way).

To the second issue of recruiting UX people to help work on wireframes for modules like this – I don’t really see much of that happening now. Any ideas around how we can better support it?

What instantly to my mind is the media module http://drupal.org/project/media http://groups.drupal.org/media which takes care of unified media handling and has got serious developer power behind it. Though they could need some nicer wireframes…

And there is more…

2.0: “Show to all, some items may be disabled for particular user types.”: Not possible, information disclosure. If you only grant your users permissions to something, you don’t want them to see more.

5.0: “closes the lower layer (shortcuts) of the header”: Where is it opened then?

ADD CONTENT

1.0: Bear in mind that we don’t want to preload all available contents that can be added on every page. On hover/click will have to load available contents first.

That said, 20 is a nice “attention” warning. The reality can quickly be 200+ available contents. More and more Drupal modules are exposing their content as re-usable and configurable contents/”panes”.

ADD CONTENT OVERLAY WINDOW:

Major issue: Note that overlay windows (proper name: modal dialog) can only use 100% of the available browser window height. There can be more content fields than in this simple mockup. So, when using a modal dialog, it needs own scrollbars. Content can overflow both in width and height.

ADD CONTENT OVERLAY WINDOW – META PAGE

4.0: Layout/Design of meta stuff should use the new and shiny “Vertical Tabs” that have been added to core recently.

VIEW/FIND CONTENT

5.0: Select all: Addition: Should insert a new data row at the top of the table to allow to “select all items/results”, meaning: not just those that are visible, but *all* content the current filters apply to.