There are numerous usability issues centred around the administration of nodes. Of particular interest in this discussion is the admin/content/node page. The aim of the discussion is to identify the problems, propose solutions and then break those solutions down into specific tasks that we can put into the issue queue.
The discussion really began at http://groups.drupal.org/node/12507#comment-40213, and so the points made there are summarised below. (An issue has also been created at http://drupal.org/node/270912, but we will probably have to implement several issues to fix this.)
Our priority should be to fix a 'major' issue found in the University of Baltimore study of May 2008 (http://groups.drupal.org/node/12447). Issue 11 states:
Participants found it difficult to find content once it had been created.
Participants attempted to use the create content link to try and find existing pages - expecting more from the link
The obvious solution is to provide a clear link back to the admin/node/content page. For users with 'administer nodes' permissions, this link does exist in the navigation menu and on the main /admin page, however it appears that users have difficulty finding it so we need to consider how we can make this more visible.
However, this also raises another issue. For any users who do not have 'administer nodes' permissions this solution is useless since they will be denied access to the admin/node/content page. The link will also disappear if the 'access administration pages' permission is off for that role.
In order to obtain some focus, we should consider first working on improving the actual admin/content/node page, and then progress to solving the problem of solving this page afterwards.
In addition to the permissions problem, the filtering user interface is confusing. The solution to the filtering mechanism will likely be related to how we solve the permissions problem.
There is also a desire for more granular permissions for changing sticky, published status, comment settings, etc. (for example http://drupal.org/node/214190).
One solution (proposed by kingmoore) is for admin/content/node to be a list of content types and for admin/content/node/[type] to display the actual table of nodes for each content type separately. This may require a page showing all content types (for example at admin/content/node/all). It would also require the user to navigate through another screen, which could be annoying if accessing this page is a frequent task for the administrator.
The implementation of 'update options' on this page has also be brought up as needing attention.
Comments
Although I love discussions,
Although I love discussions, I don't see them particularly effective if they cover several subject at once. Please state clearly what you want to discuss and actionable changes that could improve it. We know that the admin/node/content page has quite some issues, however it wasn't found as a main issue yet due to the major other issues.
Please, download the latest version of Drupal it already has some improvements in place to get to your page after you created it. The obvious problem also stated in the issue que, that that's it.
I am not sure if kingmoore's idea is so much more usable, you have to consider some scenario's there.
Anyhow just freaking place a search box there already :D and it will be fine for now.
afaik, users have always
afaik, users have always been shown their node immediately after creating it, the issue is that they then navigate somewhere else and can't get back to it. I'm not aware of any changes to this basic workflow (or much about node administration apart from moving modr8 out of core) since 4.5.x
IMO these are the main issues, found at both UMN and UB, which I think alpritt's post outlines pretty well:
2a. If you don't have administer nodes permission, even 2. isn't an option - afailk there hasn't been formal usability testing for users without administer nodes permission.
The admin/content/node UI is nasty, but it's only a one part of these issues, however, IMO, 1, 2, and 3 are best solved by either replacing or massively reworking that page and node permissions in general - to dashboards, a 'my content' block, more granular administration permissions. Adding a search box would help with some of the filtering weirdness, but it's not going to help the permissions issues themselves.
One option which just occurred to me, if there's an admin role added to core would be making 'create page' available only to the admin role, not authenticated users - then auth users don't get the confusion of two near identical choices, their posts end up on the front page (and maybe in the default tag pages too), and it's another distinction between the two content types as initially set up.
Simplicity Hits Reality
There is clearly one subject here. In fact above I suggest focusing specifically on a single page of the admin screen to start with. Sure, I've brought up surrounding issues, but if you want to design something that works well as a whole, it's useful to think of all these problems in context. I'm moving towards narrowing things down I think. But I'm not going to jump the gun.
You ask me to 'state clearly ... actionable changes that could improve it' as if that isn't the very point of starting this discussion (as stated in my first paragraph).
Unless these improvements you talk of in the 'latest version' of Drupal have landed in HEAD overnight, I'm going to struggle to find what they are.
I certainly will be considering some scenarios to the idea of splitting that page by content type. In fact I have already stated a problem with the approach. This is why we have the discussion. If you have further input here it would be very welcome.
A search box will solve a relatively minor problem. What we have is a major permissions problem. Only administrators with full permission to administer all nodes are allowed onto this page. Everyone else will get an Access Denied message. The solution proposed in the usability study and restated in the issue queue, therefore, turns out not to be quite as simple to fix in reality.
While I have clearly not stumbled on the right formula for progressing usability issues to solutions and implementations, I do have some experience of what hasn't worked well so far. There are issues which can be easily isolated, a solution proposed and a patch agreed upon quickly. This isn't one of them. Or if it is, nobody has bothered to state the simple and obvious solution.
One of two things will happen if you focus in on the obvious solutions too quickly: either we will implement a solution that doesn't actually fix the issue (and may even make the overall UI worse) or the issue will just stall for years.
[edit: grrr at the bad nesting of this comment. :)]
-
www.alanpritt.com
I am kinda hesitant to
I am kinda hesitant to adding more functionality to solve this workflow, that's why I pursued you to look for actionable changes as in we can change it right now, without having to add too much functionality (Which is a hard mindset to get into). We should try to avoid looking for completely new solutions to solve issues, sure dashboards could solve a lot, but will we see them any time soon? I am not sure why a obvious solution could be any worse then a complete redo of how stuff works. (I totally agree there should be some ground breaking changes, but lets experiment more with that (ie modules), rather then getting in the changes in core without testing it in the wild.)
I haven't encountered the issues that are presented, so I wouldn't be able to give hands on feedback. Thats why I gave search as feedback, I have never understood why it wasn't there, since search is probably #1 way of finding information. Almost all my content editors have a view with their own content, and with newly added content so I have really never encountered these issues. Since most of my admins, just avoid the admin interface since they don't understand it anyway.
Alpritt, I don't think there is a "right" formula, there is a way to somehow get it in if everyone agrees is issue ques. As far as I know, you now land on the page and get some feedback that this is the page you created, that wasn't before, but maybe I am completely wrong here.
Maybe its just in the presentation of your information, I couldn't differentiate effectively between context, scenario and action-able stuff. Sorry for that.
---
Depends how hard we work ;)
It is not the size of the change, but whether it is the right change that counts. My point is that obvious changes are not always correct.
Some things are not entirely possible to implement in contrib. But I agree that when they are and can be tested prior to entry into core, that is a good idea. But the permissions problem is a pretty black and white affair (do we need to test if getting access denied is a usability bug?). That said, it may be possible to create some kind of quick and cheerful module that recreates our solution ready for test purposes. The implementation could be inflexible or rely on non core modules such as views, but still be worth building simply to test out the UI. Much like the nodeform project for the vertical tabs, which has provided a little feedback concerning its implementation (point 10 in the report).
I agree that search would be a good idea and should be discussed here. But it is probably not the biggest priority for implementing.
I don't believe there is a 'right' formula either. But there is probably a skill in managing and pushing through the more important improvements. That's what I'm working on.
The status messages are less generic now. In Drupal 5.x we had 'Your Page has been created.' and now we have 'Page [page title] has been created.' Maybe that is what you are thinking of? Changes like that are a nice improvement and easy to make.
And I will endeavour to express myself more clearly :)
-
www.alanpritt.com
Just a friendly crosspost:
Just a friendly crosspost: http://groups.drupal.org/node/12972 is about planning a Usability Sprint of some sort at the coming Drupalcon. If you are coming to Szeged and want to work on this, let us know over there!