Drupal administration user experience survey
Hello, in order to support user experience improvements which will be made during the upcoming Drupal 4.7 code freeze we have conducted over a dozen user experience interviews. The results of those interviews have lead to a web survey which will allow us to prioritize the Drupal Administration issues.
Here is the survey: http://surveymonkey.com/s.asp?u=631841425065
We will be collecting results for a month. The results will be presented to the Drupal community leadership, lead by Dries, and a team of prominent user experience professionals who will help us to prioritize administration improvements in Drupal 4.7. We will then work with the development teams to focus our efforts. The last survey we did lead to over 200 responses and significant improvements in Drupal documentation.
Cheers,
Kieran
After taking this survey...
I guess my top issues would be:
Standard place for module settings
Sometimes they're under admininster >> settings. Sometimes they're in the admin menu itself. Sometimes they're at completely odd places like admininister >> content >> configure >> content types. A single place for all settings (probably administer >> settings >> module name) would be fantastic.
Configuring permissions
This screen gives me headaches. I've worked on Drupal sites with a dozen or so contrib modules and a dozen or so roles to go along with that. In order to configure the permissions properly, I needed to open two browser windows: one skinny one at the top showing the table heading of which roles were where, and another one below that perfectly aligned with the top one where I would check the actual boxes where I wanted permissions to be. This is obviously less than ideal. ;) Not sure what can be done to make it easier, however, unless maybe the table head was contained in a div with a fixed position so that it would stay at top of the screen even as you're scrolling.
Weighting content
Where this tends to rear its ugly head is with Flexinode types. Often you're putting in 5-10 fields in a flexinode, which means that you have to either remember or write down what the last weight was so that the fields appear in the right order. I've also run into the situation where I have nodes with more than 20 fields (don't ask.. :P) and realized halfway through making it that I'd run out of weights! Because weight selection is a hard-coded drop-down of -10 to 10, and I can't type in a number like "1.5" or "2.454646465," I then had to stop everything and first draw up the form on paper, then figure out what was alphabetical in relation to others so I could determine where I could skip a number, and finally go through and weight the whole. I'm crossing my fingers the client doesn't change his mind and want to add a new field to the form, because I'd have to do this process all over again! :( So if nothing else, please turn weight into a textfield where I can enter my own dang numbers. :P But an even better system than weighting would be to show a drop-down of things to put the content in relation to (along the same lines as the book module does it, although that tends to be cumbersome as well once the list gets past a certain length).
Menus
Menus are pretty darn good with the menu.module. But a couple things to help them improve would be (apologies if these have been fixed already since the last time I used this module):
1. The ability to hide/re-order "system" menu items (i.e. "my account") which seem to be locked into position.
2. The ability to add external links to the menu.
3. The ability to add a "home" link in a custom menu.
This is probably skewed though, since I marked more than half of the things N/A since I haven't used them yet. :)
Themes
I just took the survey. This is important to improve Drupal.
I guess the main issue to me is the theming. I am not a CSS pro and I find it hard sometimes to make things work (esp. with drupal.css in place, screwing my theme up more than once).
Secondly I find the documentation somewhat overwhelming and incomprehensive. It would be nice to have a tutorial like, getting started guide.
Otherwise I love Drupal. It gives me choicies that no other CMS does. If you are looking for doing someting besides the mainstream it is unbeatable (IMHO).
Andre
-------------------------------------------------
http://www.opentravelinfo.com
http://www.aguntherphotography.com
working on it
http://scratch.blkmtn.org/index.php?q=Drupal.org-readme
still a lot to add
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Not bad but
Keep in mind, not many people (including me) are going to read that much text. I have to admit that I started without reading anything by messing around with Drupal. In that respect it is not as easy as Mambo. Software for the 21st century has to be intuitive. Unfortunately Drupal is not always intuitive.
This is a big selling argument today and one of the resons Microsoft could dominate for so long with inferior products.
Free software usually lacks in that respect. Developers focus on features rather than usability.
I don't usually mind a steeper learning curve if the results are better which they are unquestionably with Drupal, but I can imagine that a lot of people do mind.
What counts most for me is scalability and userfriendlyness once everything is set up. Not minding the setup time.
In my understanding, although it is harder to get something running on Drupal the final product will be easier to manage and scale better.
Just my 2ct.
Andre
-------------------------------------------------
http://www.opentravelinfo.com
http://www.aguntherphotography.com
People complain that the
People complain that the handbook is too big. I want something to point people too. There is a lot of this information that people should already know or easily figure out that they are not bothering to.
I'm adding more to as sub pages. :)
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Well
Maybe I didn't make myself clear. There is NEVER too much information. If you ran yourself against a wall, its always good to have a place to look. But its too much to get started with.
I truly appreciate all your efforts !!!!!
Andre
-------------------------------------------------
http://www.opentravelinfo.com
http://www.aguntherphotography.com
Well, it depends on what you
Well, it depends on what you are looking for and the time taken to find the solution.
This is a big community and information is scattered in handbook, forums, irc (volatile), drupal users sites etc.
But there are lots of efforts going around to categorize the same according to users needs. I appreciate sepeck for taking up forms api, lucid explanation on how various parts of forms work.
I was looking for this kind of information in the handbook a few months back. But here it is, well by now i have an understanding of how forms work but this would be a good quick ref for me. This is a handbook and not a single long page, so its fine with me. I think you are looking for few words in a line, this is something to do with styling css (fixed positioning) and nothing to do with the content, may be sepeck at a later date will move the content to drupal.org that can be accessed from the homepage.
With respect to usability, there are lot of experts (like jibbajabbaboy) around contributing their time to drupal.
Oh no, I didn't do the forms
Oh no, I didn't do the forms API. That was thehunmonk. I merely provded a scratch site for some folks to rapidly collaborate on the docs.
I liked the idea of a scratch site, so I am keeping it up to write notes or prep for more complex docs.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Kudos to both of you
Kudos to both of you.
The entire forms api in single page is here,
http://drupaldocs.org/api/head/file/contributions/docs/developer/topics/...
The Handbooks seem to come up a lot
I joined drupal a few weeks before the handbooks where overhauled and every time I go looking for info in the handbooks I find something new which is great. But I got to admit when I first started using drupal I found the amount of info overwhelming and that was because I was finding advanced info when I was looking for beginner info, and yes you can never have to much information, but for me at the time it was not productive information. When I was trying to learn how to create my first few pages I did not need to know how drupal builds pages. Important information but not for a newbie.
Every suggestion people make means more work for someone, so I try to make them reasonable suggestions.
How are you going to implement your corporate brochure. You probably already thought about this, but what about creating a beginners handbook with the focus of the handbook being your corporate brochure. Think of it as a practical guide or tutorial. This way beginners can be eased into using drupal. You probably already thought about this.
Another topic for debate has been the Search and again sepeck I got to say it seems like you are every where I look. What you are doing with the search is brilliant, but I personal would like to see handbook search. You can search the drupaldocs and only the drupaldocs since it is a separate site, but when you search the drupaldocs you know the context of your search.
Although all of this is off topic, I still think it is relevant. Teaching someone how to administer their drupal site is just as important as making it easy.
a newbie with newbie ideas
some answers
As you envisioned. Part of the point of the thread is that there are several ways to get to your goal and depending on 'what' you wanted, there may be ways that are more appropriate to your setup.
I want to give a brief outline high level overview (short) and then pick out the 3-5 most suggested scenerios for people to choose from. Feel free to hit my contact form if you have any ideas/suggestions/comments.
Steven is the author of the patch and with nedjo is the instigator of most of the search improvements. I merely try and help people participate effectively within the community so they can find things and contribute more easily. Here is some notes from Roland from the conference :which I didn't get to go to :(
Keep in mind, that anyone can submit a Handbook page. So if you figure out something that is really neat, then you can add it. It goes into moderation and we try and look at the moderation queue regularly to promote new items. Sometimes we miss it so sending a message to the drupal-docs list can help something along more quickly.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Various thoughts
I agree that scalability and user-friendlyness are important. Although i am a programmer and can write PHP code, my approach to Drupal is merely as an end user (in part because i lack any DB experience). While i see so much inherent power in Drupal, it is limited for most users because the interface is so complex. In part, this is due to the rapid growth of Drupal. This is what happens when engineers develop a product in the absence of a user interface road map. This is how M$ developed Windoze, and why it is so difficult to configure/administer.
Think Macintosh… As your guide, think how Apple would do Drupal. Since about 80% of Drupal developers use Macintosh, it should be easy for most Drupal developers to ask themselves: Is this Mac-like?
I think Drupal install and setup should be as easy as CivicSpace. Would be “nice” to have a module installer too. Frankly, i don’t understand why Drupal isn’t as easy to install as CivicSpace?
But administration could be better thought out; more uniform; more user friendly. Sometimes i know exactly what i want to do, but finding the admin screen to do it is the challenge. Some things are tucked away in the most obscure places (although many things are where you expect them).
And some things in administration are ambiguous, or sometimes terms are used which are not well defined. A Drupal glossary might help with the latter.
The Drupal handbook is a good reference, but it can be hard to locate info. For example, i was trying to find out how to do something as simple as display a list of posts each tagged with two specific taxonomy terms. I knew it could be done. I knew i’d stumbled across it before, but it took me about a half-hour of diligent searching to find it. I couldn’t find it by browsing the handbook (although something like that should be in there). I eventually found a reference in one of the forums, which of course was for an older version of Drupal. Eventually, i figured it out (and even found the taxonomy browser module, which is nice).
It seems to me Drupal has some complexity which no longer serves a function. For example, what is the practical difference between a page, book page, and story? I understand that in the past, there were distinctions between them. But pages and stories may be attached to a book, so what is the value in having book pages? And how do pages and stories differ? Sure, pages are supposed to be “static,” but what is the practical difference? What is the value in having these separate types? If there is no value to the distinction anymore, it is simply unnecessary complexity.
some answers for you
There is no longer a significant difference between page and story but it is extemly useful in a lot of situations to have two default node types that you can allow different access control and post type usages. (lots of debate available for you on Drupal-devel).
The book module is not the same as a page or story and has a lot of built in functionality. How you use the book module is up to you.
For the installer until the most recent release of CivicSpace, it flat out didn't work on any of my server installs. See see http://drupal.org/install-system-overview for more information and comments on the status of said system.
Feel free to join #drupal-docs list to give us a hand. There are maybe 5-10 active people working on the handbook at any given time. We'd be happy to have help. It does need yet more work, debate ongoing. :)
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
About books
Thanks for the info re: pages vs stories.
But how is a “book page” (not a “book,” but a “book page”) different from a “page”?
I understand that at one time, only “book pages” could be part of a book; now that pages and other node types may be part of a book, it seems that there really is no need for “book pages” per se. Or am i missing something?
How book module differs from
How book module differs from page or story:
* it must always exist in a book outline (even if it is only a "root")
* it has a "log" field that can be filled out when editing and making revisions
* it has revisions turned on out of the box
* it has the maintain books permission, making it easy to allow a single role to edit all book pages
So, if you are making static site pages, I always use the book module for this, since users *must* select where in an outline the page should go. With page/story, this would be a two step process -- create the node, then hit outline.
Hope that helps...
--
Please turn on the "story" type, so we can use it to have an archive of best practices, how tos, and configuration recipes.
Thank you
Since my post, i figured out the bit about assigning a parent directly (without the two-step outline process), but had overlooked the other items you mention.
Thank you Boris for responding to my post. It does indeed help!
I was thinking about storys
I was thinking about stories vs pages, and there seems to be some justification in the 2 types intuitively but not in practice. It led me to wonder if a logical distinction might be that a page forms part of the navigation system (for example a tree like menu on the left hand side of the page) whereas a story, whilst still governed by taxonomy, would not render as a menu item. This would mean that an about us page would be added to the main site nav but a news story would be accessed from within the body of an index page. Does that make any sense?
Yes, it does make sense
I came to a similar conclusion independently. I am now using Page types for static type content (i.e. home pages for site sub-sections, FAQ pages, etc.) and Story types for the more dynamic, time-related, or one-of-a-kind content. I’m reserving Books (and book pages) for static content which is logically grouped together (e.g. multi-page documents, etc.)
What i would like to be able to do, and so far haven’t found a way, is to present some static content (e.g. a header area) followed by teasers to stories (constrained by taxonomy, type, etc.) I think there should be a way to do that (but that doesn’t mean there is); sounds like a job for an inline filter. It seems to me you might be suggesting something similar.
My needs derive from a
My needs derive from a desire to be able to create a website with a rock solid hiererachical navigation system spanning multiple levels. I ended up using book pages on my last site (www.accesstesting.com), and then inserting php snippets into the pages to generate the kind of thing you are talking about. Unfortunately, the use of pages and taxonomy context requires significant hacks to the navigation system (the page has no idea what book section it is in) and aliasing of urls.
The difficulty I had was in the menu system - using pages for dynamic content so they didnt turn up in the nav system was a major pain.
A filter is needed
I had thought about using PHP code to pull in the content from a teasers page. I didn’t do it because of the need to strip off HTML header and footer data. Didn’t even think about the menu stuff! Duh! That sounds like a major pain in the rear. Not to mention that themes could complicate that to the point where you might need to just stick to a single theme. Although, one might be able to use themes to their advantage somehow (by using a theme to strip out the menus). But no matter how clever you are, it would still be a kludge, and prone to problems.
I definitely think an inline filter module would be the best way to tackle this. Unfortunately i don’t have the time right now to write such a critter (due to the learning curve involved in learning how to write a Drupal module). Otherwise, this might be a good “starter” module to tackle.
Installation or configuration?
I find the installation of Drupal and the installation of modules exceptionally easy (just copy them over and load the database tables). That never bothered me.
Configuration and personalization is a different animal.
First you have to find how to set-up the module. Some show up in admin/settings, some show up elsewhere. Even that is not too hard though.
For me the greatest hurdles are:
-Theming (the ongoing drupal.css issue I guess)
-Customizing
By customizing I mean getting the modules to work the way I want.
Even though it is relatively easy to hack a few lines of php with the help of people in the forums (thx to all), I am now afraid to update to the next version of Drupal. Not only will the modules be updated, but all my hacks will be lost. So I have started to write down every single change I made (hopefully not forgetting anything).
Anyways, I have found nothing better than Drupal. You can have an easy life (Mambo) or do something different from the crowd, and implement functions no other site has.
Sepeck, I appreciate your efforts. If my project ever gets to a point where I can consider it stable and fully functional I will certainly contribute some experience in form of documentation.
I am thinking of a "how-to-setup Drupal in 10 easy steps" style docu.
Right now I am just a beginner struggling with the basic stuff.
Andre
-------------------------------------------------
http://www.opentravelinfo.com
http://www.aguntherphotography.com
making module installation easier
I find that cut&pasting the contents of the module.mysql file into the 'run script' bit of the database module works a treat. Saves me having to open up phpmyadmin and all that rigmarole!
If database.module were included in core, could this provide part of a basis for an even easier (more automated) installer for modules?
a variant of upload.module could take care of :
1. locating the correct version of the new module from drupal.org.
2. copy the module to the modules directory (save having to download to desktop and upload manually).
3. unzip the tarball (don't know how easy that would be).
Forgive me if I'm missing some important point - I know very little about server & database configuring - but it strikes me that most of the necessary functionality might be already available. OK a smooth UI will take some thought, but in principle could this be workable?
BTW if someone could write a module that would apply patches, that would help alot of us server-dummies a great deal! :)
I think their might be a even easier solution
I think that modules should install the database script them selves using a hook. When a module gets enabled cant drupal check for a db_install hook. If there is one it will run the hook. The hook should check to see if the required tables are not already in the database and if not then check to see what database is being used (mysql/ Postgress) and then run create table and insert statements. It should also maybe check to see if the user has create table privileges. If not output a message telling the use that they need to do it manually.
I think this could work using the existing core.
I second this suggestion
... actually, I first it ;-)
I suggested hook_setup() a few weeks back, which should include both DB table creation, and dependancy checking, and illustrated it with a boilerplate example too.
Yes please.
.dan.
here you go
http://drupal.org/install-system-overview
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Never forget that were flying rockets
Adding a blog post is easy: Just register at a drupal site adn there you go.
Setting up your site is going to be hard. With power comes complexity. You cannot expect Drupal to be like MSword, or as easy as MSN messenger. Not from administrator point of view. Drupal is a full fledged system that allows you as administrator do do anything.
If I ask you to set up my webserver with multiple SQL backends, I expect you to at least read some books on server management.
If you are going to *administer* a site you will need to understand that you just *have* to learn about some of the underlying theory.
This all, does not say we cannot improve. We can. We should. We will. I am only saying that expecting that flying to the moon is as simple as driving to the supermarket is just not fair. Not yet anyway.
---
if you dont like the choices being made for you, you should start making your own.
---
[Bèr Kessels | Drupal services www.webschuur.com]
Administration tasks
Agreed on a standard location for module settings. With many modules (especially the spam module) settings are scattered in different places: we have 'spam' under settings, another spam item in the top level of the administrative menu, and yet more settings in content configuration. The e-commerce module has the same problem.
Setting up roles & permissions is a major pain because there's too many checkboxes on the screen. When I add a new module, I have to go back there to set permissions. I usually end up overlooking some permission that has to be enabled. For content, rather than having create/edit/access permissions for each module, it would be great if we could have CREATE CONTENT with checkboxes for each content type, etc. Other non-content-related permissions can be listed by module.
There also really needs to be an option to email the administrator as soon as someone posts a story, so I can check & approve it right away. The modules I've seen only send an email once every few hours and I've never been able to get them working well.
--
Mike Cohen, http://www.mcdevzone.com/
A single place for all
I think going the other way might be a better idea - do away with having a single menu for all module configs. I mean, if you've got a module that enhances Drupal's 'content' functionality, shouldn't the configuration for it be under the content menu? Otherwise, you're splitting things that logically go together into seperate menus, which will just make things confusing.
A rule of thumb I would suggest: if a module doesn't provide COMPLETELY new functionality, there's no reason for it to have a completely new menu.
although I do agree putting
although I do agree putting like setting together makes sense, there is the other side to consider.
When I first installed Taxonomy_access, I was initially confused as to the where abouts of the actual settings. Now, I'll admit, it makes sense to have them in the access control menu, but at the time it was a case of "where did I see those controls?"
I think the individual "settings" page is useful even if it only serves to say "yes this is installed, and you can find the relevent settings controls under..." possibly providing a link to the controls.
If the module's set it up properly, you should be able to "switch off" that menu item, using the menu module, if that page isn't needed any longer.
where to put module settings
I think some standardisation would be a good idea. Some module's settings page rather thoughtfully include links to config options elsewhere. This seems like a pretty good compromise.
The one that really bugs me is having two pages called content-types! flexinode uses one and the other is a tab ... It's taken me ages to get my head around which is used for which! I vote flexinode for core and get this sorted out :)
regarding the admin menu: I don't see a need for separate settings and modules trees. Especially as some core modules are locked on admin/modules (why show these at all?), why not have module settings links from the admin/modules (list) page ? Would there be any harm in plonking the site settings (admin/settings) page in the list of modules and doing away with the admin/settings off the menu altogether?
And while i'm at it, how about trying a more informative listing structure for admin/modules, ie something more helpful than alphabetical listing? I know this is difficult to get consensus on but for example, categorising modules by 'core', 'admin features', 'user features', 'email functions', 'node-type features' etc etc - or something along those lines? Separating bundled from 3rd party modules would be useful when running an upgrade. Structural dependency should also be clearly represented (core and e-commerce modules spring to mind). From a trouble-shooting point of view, being able to see at a glance which modules use which drupal hooks (eg permissions) could be very helpful ?
Control Panel helps
While i concur with your comments that we need more standardization, i have found the Control Panel module immensely helpful in navigating the admin maze.
problem with customising admin UI
I haven't used control panel module but I assume (:?) it offers admin UI config options. Apologies if my guess is wrong.
On my first drupal installation I customised the admin menu links in the navigation block to group things together in a way that suited me. I found this created a big problem when using the help forums like drupal.org - everyone else would give references in terms of the default config (admin/settings/...etc) which left me having to translate between default and custom configs ... which only added to my confusion!
So IMHO I would rather go with improving the 'core' default admin interface. OK it's not going to suit everyone's personal preferences, but it seems more important to standardise communication between drupal admins.
Heh, cute problem.
Heh, cute problem.
And I thought that referring to /admin/node/edit was about the only thing I could say that WOULD be cannonic shorthand when trying to tell someone how to find their settings :-)
It's certainly much much better that giving instructions to "Go to your 'admin' screen, click on settings, then click on 'image', You should see some tabs -click on the one that says ..."
And you have to go and rename them!
It's like trying to helpdesk a user who has gone and customized their GUI beyond recognition, but still don't know the difference between left and right click. If you've chosen to put your Start menu in the top right of the screen, don't blame me if my instructions don't work first time!
I never thought about how the admin itself could be re-jigged, but it IS a menu after all.
... hang on,
Their actual path IS cannonic. You are sure to get to the right place when entering that as a given URL, even though you may have chosen to structure the click-navigation TO that point differently.
Whilst you have the ability to rename 'nodes' to 'pages' and 'create content' to 'write new page' and hide the menu option somewhere under the admin structure ... (all of which you can currently do!) you are neccessarily hindering anyone elses ability to give you advice using common instuctions. I don't think there's an easy fix to this issue!
However, if your vote is just for an improvement of the interface to the point that you didn't feel the need to re-hash it yourself, I guess that's a fair call.
So what's your wish-list? What are the changes you felt you had to make?
I was going to say 'remove irrelevant items from the main admin list' but you've just shown me I can already do so! thanks!
.dan.
my admin UI wishlist?
The most important admin UI reconfig IMO was to separate technical site admin from content admin ... for reasons of delegation and concentration.
User admin already has its own corner (admin/users) which makes sense to me.
My second favourite suggestion (which I think I mentioned somewhere above) is for modules that have a settings page:
Instead of the links in the navmenublock under admin/settings ( I've got dba, event , flexinode ... all 3rd party mods) Wouldn't it be simpler to move these links into a new column on the module overview page (admin/modules) ?
BTW is there a difference between 'settings' pages and 'configuration' pages ? if not there's another opportunity to simplify the UI ... ?
Control Panel is a GUI
No. Control Panel is a GUI interface for pretty much everything under “Administer.” It helps immensely in “running the maze” of Drupal configuration/administration. Sort of like a map of the maze.
I suspect it will work better for some, not as well for others (depending on left or right brain dominance), so YMMV.
I think it helps to enable the “Build Child Menu Panels” option.
It’s worth a look.
For menus
For the menu points raised by webchick, I do the following:
To add external links use the go.module. Add the external link there, then add it's Drupal path in to the menu. i understand this is a 2-step process, the trade off is you get stats on the number of times an external link is clicked thanks to go.module.
To hide 'my account'. Hide the 'navigation' block. Then create a new menu block and put your own custom menu links in it, they can still link to the same paths, such as ?q=user but you can have your own wording etc. You can also re-order them with the weight value now.
What's a "home" link going to do? I'm not sure how this is a problem.
--
www.bargainspy.co.uk
Forgotten localisation
Interesting survey but... there is no mention about managing locales or working with multilingual sites!
There is a lot of (good) work done in this direction and I bet there is a los of non-Emglish and multilingual sites out there.
Thus survey would have been a good opportunity to test the relevance of having the i18n module finally integrated and supported in the core.
My biggest issue isn't there
What my clients want most of all is node_access by category.
We can do that in a nasty, hacky way right now but they're not geeks and the interface isn't there.
The access code is great. But we're a couple of versions down the road now and there's no interface to it in core. Surely we should be prioritising that?
Admins are users too...
[And yes, of course I'll help.]
Say...
Did the results of this ever get posted?