Share your favourite Drupal User Interface gripe. Big or small.
The buttons and tabs in the sequence of screens when "requesting a new password" have labels that don't reflect what the buttons actually do, and the instructions are incomplete and misleading. Novice Members, especially those who don't have much computer savvy, can be severely flummoxed throughout this process.
- The "Request new password" tab should say something like "Forgot my password." (The "Member" isn't actually going to be given a new password, he/she must eventually change their own password. This is NEVER made clear.)
- The instructions on the following screen should say "Enter your {name of site} Username if you know it. Otherwise, enter the e-mail address where you receive {name of site} 'mass e-mails.' If neither is successful, send an e-mail to webmaster with a brief explanation."
- The "E-mail new password" button on this same screen should say "E-mail password reset instructions." (Again, this is actually what is going to happen. Nobody is emailing you a password.)
- The default text in the email that's sent to the Member needs to say things like "the following link," not "this link," because there are several links in the text. Of course you can edit and improve the text, but the default needs to make more sense.
- The instructions in this email should remind the Member that after clicking on the link, they will have only one opportunity to CHANGE THEIR OWN PASSWORD.
- The screen that the Member sees when returned to the site by the email link needs clearer instructions. (Some of these Members have no idea where they are or what they're doing.) Suggested:
One-time Login (title)
To take advantage of this one-time account access, you must assign yourself a new password. If you log out before completing the steps below, you'll have to repeat the password-recovery procedure that brought you this far.
* Click on the link below to bring up the edit-password page.
* Type your preferred password in the first password field.
* Type it again in the second field to verify.
* Press the "Save" button at the bottom of the page.
If you don't save your entry, the new password will not be registered in the system.
- The button at the bottom of the page should say "Go to the Edit-Password Page," not "Log In." (The confused Member doesn't necessarily even know what Logging in is, much less that this instance is "abnormal."
Search the issue queue for the thing that's annoying you. Someone might already be working on fixing it.
Link issues you'd like to see reviewed.
Post links to forum posts that point out usability issues for newcomers.
Feel free to use this as a link-dumping ground
If you want to help fix existing issues, please have a look here
Editing note: Precede your section titles with # for h1 or ## for h2 and so on. More info on Markdown syntax
Administrative Interface
Taxonomy
- User should be able to one click delete a term when looking at a vocabulary list /admin/taxonomy/[vid]
- When you delete a taxonomy term, Drupal should tell you how many nodes are tagged with that term.
- offer you a list if you want (which would open admin/node to that term
- let you combine the term with another term
- there should be an option for moving a term (or parent and all it's children) from one vocabulary to another
- add taxonomy weight setting to the admin/taxonomy screen so you can easily set all taxonomy wieghts
- add a "disable" taxonomy function, so you could disable taxonomy terms, parents terms, entire vocabularies buch in the same way you can disable a menu or menu item. Why? what if you want to stop using a taxonomy going forward, but don't want to kill the old stuff?
- Create a taxonomy view that allows for hidden children
- If you have a really detailed fine grained heirarchical taxonomy, you might not want to give the uisers an option of browsing all the 2nd 3rd and 4th teri terms, but you want users creating nodes to be able to assign fine grained terms. In this case, parent terms would encompass all their children terms. All terms would be displayed on a node, and clicking anyone would have the same behaviour as you would current experience.
- Per Node type taxonomy weight: when you are creating content types using cck, you or configuring content type settings, you should be able to override the taxonomy weight and set a taxonomy wieght for a particular vocabulary on a particular content type. So on "directory" nodes "issue" vocab might be a -8 but on, but on articles it might be a +8
Node Administration
- User should be able to add multiple cireteria in the node filter on admin/node at one time
- Filter by date range
- filter by author
- user should be able to sort node list by each column heading and reverse sort if they want
- there should be a "check all nodes" box
Content Type Administration
- there are two places to adminsiter content types, and niether refers you to the other.
- /admin/node/types
- /admin/settings/content-types
- On the admin/settings/content-types screen the user should be bale to admin content type behavior like work flow through a matrix, and not have to edit each one individually.
* Fieldgroups: when creating a new content type from scratch, it is not obvious how to add fields to a fieldgroup. See http://drupal.org/node/327223
Module Administration
- Too much information/modules to scroll through for sites that serve more than a handful of authors.
- How about classifying module by module package/function (social network, e-commerce, newsgroups, etc?)
- How about a D6 style, book outline system to select/filter modules?
- How about classifying module by module package/function (social network, e-commerce, newsgroups, etc?)
User Administration
- Administer user settings in a matrix
- User roles
- user block setting
- user contact forms
- admin function for resetting and sending a user's password (yeah i know they can just reset it by requesting a new one, but an admin should be able to "reset password and notify")
- Set user role on user create
- user roles that users can apply for on signup
Block Administration
- Add a matrix view for block administration that adds visibility setting, default viz, and enable disable by user choice
- Add visibility by user role
-
Add a duplicate block function: this would be a link from the block menu, it would create an identical block with all the same settings, and open it to the edit form where you could change details.
-
Add an "enable/disable block title" check box . If you have a block that consists of images, you should be able run the block without a title.
Menu administration
- Create ability to work in one menu at a time (so if you are working in the heaviest menu, adding menu items, you don't have to scroll all they way down, or find the right menu in the drop down list of parent menu items)
- Create a multi menu item add form that allows you to add multiple menu items by entering them into a matrix with all necessary fields
- Duplicate menu function: this would open up a add menu item form, all filled out for the menu you just duplicated, but then you would be able to change specifics
- duplicate menu item and children: this would open up a menu item add matrix allowing you to change the specifics. Super helpful if you have a number of menu items that have the same children menu items (that go to different links.
Path Alias (URL Alias)
Admin Path Alias
- Improve ability to browse path aliases
- Add an alpha selector
- filter path aliases by node type
- filter by manually created path aliases vs. path auto created path aliases
- Add ability to search for path aliases by partial path alias
* this would allow the admin to search for all paths like "publi" and get a list of all paths with "publi" in them.
1. Add ability to create multiple path aliases at the same time
1. Add ability to edit / delete multipl path aliases at the same time
Path Auto
- Add option to delete some auto generated paths en mass
* this would allow an admin to delete all auto generated paths for a specific content type and then recreate just those paths.
Comments
Better theming of Input format fieldset
Added a link to this issue, would be great with more eyes on this.
Also
What are your thoughts on how to provide decent feedback in the issue queue. We'd want to avoid adding to the "+1, subsribe" noise.
Advice people
If we do create some sort of readme/introduction page for the group, we could give some good advice for providing constructive feedback in the queue. I absolutely agree that "+1 subscribe" should be discouraged.
here goes
A few ideas, none of them that great.
If something which changes the UI or user interface text doesn't have a screenshot or the text changes directly in the issue, ask for it. Patch authors (or other people) are happy to apply the patch and do a screenshot, but they often don't. Demo sites and/or screencasts are more work, but we should be trying to facilitate that for far reaching changes at least.
From my point of view, seeing annotated screenshots and other stuff like that is really, really helpful - either to highlight issues or suggest changes or whatever. So starting an issue off with a screenshot but no patch can go a long way to getting it coded and fixed.
While +1/subscribe is annoying. Saying that you've seen it, have no objections etc. can be a big help. Even if it amounts to +1, if it's "I've actually looked at what this does and it's fine" that can be enough - especially for minor changes.
steal from twitter
a tiny little button at the bottom of the post just above the comment that says
"Follow this post"
or
"Subscribe to this post" (or whatever)
We can just rip from ajax code from the 5 star module modify it with two states
"Subscribe to this post"
and
"Unsubscribe to this post"
That'd quickly get rid of the +1, subscribe noise.
-Jacob Redding
-Jacob Redding
Project moloch
As I understand it is not so easy.
The functionality appears not to be there in project module - which again appears to be very special due to its historic growth, I guess no one loves it but everybody needs it, and updating it is especially hard as you cannot dare a buggy new version.
But still: what jredding suggests should be a very high priority. Anybody around here that knows project module well enough to estimate the effort or explain the implications?
The amount of discussion and developers being aggravated that constantly arises from this one missing feature is definitely silly. Read also Bèr Kessel's take on this and the comments.
Life is a process
Life is a journey, not a destination
Here's one that comes to mind immediately.
Wiki pages don't show the original author, making it impossible to determine who is asking the question (at least in node view.. you can see it if you get into the group panels display). This node is a great example.
D5 only
This was fixed in D6.
Added one about "Select all" in table headers
I couldn't tell if this was a larger or smaller issue (I erred on the side of larger), but something I'd like to see looked at by one of you fine folks is our current "Select all" table header feature, which looks like a bug.
See http://drupal.org/node/308468 for an illustration of this concept.
Only one enter for autocomplete
The behaviour of the autocomplete when only one term (with one or more words) is needed its very odd: you need to hit the enter two times. The average user hit the enter and wait, and wait until he see one enter more is needed. It can be very frustrating.
http://drupal.org/node/309088
Neurotic web design
Total nodes displayed on content management.
A couple of things I would like to see in the content management layout:
Site Offline artwork
The "site offline" page presented to visitors when the site is in offline mode could be smarter. I mean, I like that cheeky Druplicon guy. But rather than defaulting to a white screen with a Druplicon, it could default to the active theme's background color and active icon. It would be a nice convenience for new users, and still themeable for advanced users.
Batch delete
There are places where the admin interface works fine if you want to delete one or two items, but becomes a nightmare if you need to delete fifty.
Add multiple delete to taxonomy terms page (http://drupal.org/node/305574) (Actually, even deleting a single taxonomy term takes a surprising number of clicks).
improve UI to delete multiple path aliases at once (http://drupal.org/node/186571)
Losing your work!
Drupal really shouldn't discard your work without warning you. There are few ways to generate user hatred faster than by losing their work.
The obvious ones are the help and input filter links in IE6. But how about using drag-and-drop to re-order a complicated menu, then absent-mindedly clicking a edit link to change the title of one of the menu items. Poof, your work is gone. Guess you should have scrolled down and read that message on the bottom of the page.
Warn before losing changes (http://drupal.org/node/193799)
Update: Whoops, I didn't see that this was already listed above.
the content search is horrible
Sorry, "undo" and "reset" are the most rancid buttons I've ever seen in a search. :P Not picking on anyone's work, just picking on the choice. The default content search admin form UI/UX needs a review - please.
::ducks from tomatoes being tossed::
Chris Charlton, Author & Drupal Community Leader, Enterprise Level Consultant
I teach you how to build Drupal Themes http://tinyurl.com/theme-drupal and provide add-on software at http://xtnd.us
Publishing process is horrible
The out of the box ability to publish content is absolutely horrible. I think this is the main reason most people DON'T use Drupal. Even with extensive modification the publishing process is clunky at best. Whenever I bring this up people just tell me to install a WYSIWYG editor, but this doesn't really solve the problem. WYSIWYG editors generally suck IMO.
All most people need is a few simple buttons that wrap their content in the appropriate tags and allow them to upload and insert images, audio, and video. This functionality should be part of the default installation of Drupal. If you want an example of a good interface for publishing content, just take a look at the page for creating a post in WordPress, especially the HTML view.
I think Drupal is brilliant in many ways and that's why I use it, however, if a content management system can not easily publish content, what good is it?
I'd love to hear how others have made publishing content in Drupal an easy process that just flows, and I'd be happy to help write-up the solution.
A whole long list...
Here are a bunch, some maybe fixed in 6, i don't know, that's my disclaimer:
= Administrative Interface =
== Taxonomy ==
1. User should be able to one click delete a term when looking at a vocabulary list /admin/taxonomy/[vid]
1. When you delete and taxonomy term:
1. drupal should tell you how many nodes are tagged with that term.
1. offer you a list if you want (which would open admin/node to that term
1. let you combine the term with another term
1. there should be an option for moving a term (or parent and all it's children) from one vocabulary to another
1. add taxonomy weight setting to the admin/taxonomy screen so you can easily set all taxonomy wieghts
1. add a "disable" taxonomy function, so you could disable taxonomy terms, parents terms, entire vocabularies buch in the same way you can disable a menu or menu item. Why? what if you want to stop using a taxonomy going forward, but don't want to kill the old stuff?
1. Create a taxonomy view that allows for hidden children
1. If you have a really detailed fine grained heirarchical taxonomy, you might not want to give the uisers an option of browsing all the 2nd 3rd and 4th teri terms, but you want users creating nodes to be able to assign fine grained terms. In this case, parent terms would encompass all their children terms. All terms would be displayed on a node, and clicking anyone would have the same behaviour as you would current experience.
1. Per Node type taxonomy weight: when you are creating content types using cck, you or configuring content type settings, you should be able to override the taxonomy weight and set a taxonomy wieght for a particular vocabulary on a particular content type. So on "directory" nodes "issue" vocab might be a -8 but on, but on articles it might be a +8
== Node Administration ==
1. User should be able to add multiple cireteria in the node filter on admin/node at one time
1. Filter by date range
1. filter by author
1. user should be able to sort node list by each column heading and reverse sort if they want
1. there should be a "check all nodes" box
== Content Type Administration ==
* there are two places to adminsiter content types, and niether refers you to the other.
* /admin/node/types
* /admin/settings/content-types
1. On the admin/settings/content-types screen the user should be bale to admin content type behavior like work flow through a matrix, and not have to edit each one individually.
== User Administration ==
1. Administer user settings in a matrix
1. User roles
1. user block setting
1. user contact forms
1. admin function for resetting and sending a user's password (yeah i know they can just reset it by requesting a new one, but an admin should be able to "reset password and notify")
1. Set user role on user create
1. user roles that users can apply for on signup
== Block Administration ==
1. Add a matrix view for block administration that adds visibility setting, default viz, and enable disable by user choice
1. Add visibility by user role
1. Add a duplicate block function: this would be a link from the block menu, it would create an identical block with all the same settings, and open it to the edit form where you could change details.
1. Add an "enable/disable block title" check box . If you have a block that consists of images, you should be able run the block without a title.
== Menu administration ==
1. Create ability to work in one menu at a time (so if you are working in the heaviest menu, adding menu items, you don't have to scroll all they way down, or find the right menu in the drop down list of parent menu items)
1. Create a multi menu item add form that allows you to add multiple menu items by entering them into a matrix with all necessary fields
1. Duplicate menu function: this would open up a add menu item form, all filled out for the menu you just duplicated, but then you would be able to change specifics
1. duplicate menu item and children: this would open up a menu item add matrix allowing you to change the specifics. Super helpful if you have a number of menu items that have the same children menu items (that go to different links.
== Path Alias (URL Alias) ==
=== Admin Path Alias ===
1. Improve ability to browse path aliases
1. Add an alpha selector
1. filter path aliases by node type
1. filter by manually created path aliases vs. path auto created path aliases
1. Add ability to search for path aliases by partial path alias
* this would allow the admin to search for all paths like "publi" and get a list of all paths with "publi" in them.
1. Add ability to create multiple path aliases at the same time
1. Add ability to edit / delete multipl path aliases at the same time
=== Path Auto ===
1. Add option to delete some auto generated paths en mass
* this would allow an admin to delete all auto generated paths for a specific content type and then recreate just those paths.
http://www.CivicActions.com
http://www.GregoryHeller.com
http://GregoryHeller.com
The "Navigation" menu
Hmm, navigation. Isn't this what all menus are for?
We should categorize the "Navigation" menu items, perhaps split the menu up, and give it proper name(s).
This is inconsistent with all other menus. Give it a fixed label, and move the username somewhere else.
I couldn't agree more
This is one of the things I had trouble with when I first started using Drupal. I remember some thought somewhere of moving the Administration menu to its own menu. I'll have to try to find that item.
I found it.
http://drupal.org/node/279399
Agreed
"Navigation" is unclear as a menu name when it really is a holder for admin stuff. Placing content in there is seldom good design.
I always have to start a site by building a new public menu where the real Navigation goes - and have to invent a non-ambiguous name .. like "main menu" :-/
Primary Links is the Main Menu in D7
It seems primary links as been renamed to main menu in Drupal 7 ( http://drupal.org/node/254940#menus ) so that rules out calling it (navigation) the main menu as there could be confusion between the two.
How does 'Default Menu' sound?
There's still time to change
There's still time to change the change. Not unheard of in Drupal. Frankly I think "User menu" is the correct term to rename "Primary links" to instead of "Main menu". There is nothing "Main" about that menu.
pegleglax
the "vertical tabs" module should be in core ;)
split up navigation
If I remember correctly, catch asked us at Szeged what we'd think about moving "administer" out of "Navigation". And I think we all said: "yes, yes!". This is a first and very needed step and could also improve the chaos in the menu selection dropdown (when you add a post to a menu while creating it).
And yes, Navigation is a bit misleading. Name finding contest (Hey, bikeshedders welcome!) can begin.
Life is a process
Life is a journey, not a destination
Why is Navigation
Why is Navigation misleading?
http://www.cisco.com/en/US/docs/net_mgmt/element_manager_system/3.0/user...
http://avtecmedia.com/tools/web-design-glossary.htm
http://www.studiodog.com/glossary-n.html
http://sven.mayer.net/university/seminar/hypertext.html
http://docs.rinet.ru/WebLomaster/appa.htm
http://www.mitraworks.co.uk/index.php?p=952#n
http://www.usadata.com/marketing-glossary-eMarketing.html#N
and others.
-1 on renaming Navigation.
Navigation is misleading
Navigation is misleading because all menus (except for utility links) are used for navigation. It is like providing a default vocabulary in core and calling it "Category".
Take out Administer, and
Take out Administer, and what is left are (default) My account, Create content and Log out. My account and Log out are utility links (Help would fit in there nicely). So, where would Create content go?
create content stays
Hehe, this is a matter of the "where is my content" group - the basic menu is a per-user menu with standard links. "Create Content" and - soon - "My Content" are top Priority Links that have to be there.
What Name would be appropriate for that? Dunno. Should try to see it through the user's eyes, especially those not used to Drupal.
Life is a process
Life is a journey, not a destination
It's really just a
It's really just a personalized menu, and the name should reflect that somehow. Navigation is too broad and, as has been mentioned, confusing because we have several areas that are part of the navigation. If all I see is the term "Navigation", I'd expect it to be site-wide, not personalized, and in fact that has thrown me off the first time using Drupal.
As for what name to use instead, I can't come up with anything off the top of my head either. Something like "User Menu" perhaps.
We're getting somewhere
I feel like we're getting somewhere. Three default menus instead of one:
Administration
- ...
Content
- My content
- Create content
User menu
- My account
- Help
- Log out
("User menu" could be better)
Side note: people, please use "Reply" to keep the discussion structure clean.
Yes
And "User menu" can replace "Primary links".
prior art over here
Issue on splitting and renaming Navigation: http://drupal.org/node/273137.
This has problems: breadcrumbs break. Underlying issue for that is here: http://drupal.org/node/279399.
Have a look please and comment in the issues as well, seems we're having roughly the same idea here.
really?
'Primary links' is what goes in the special themed $primary_links variable - are you sure you want to change that to 'user menu' - what's secondary links then? 'secondary user menu'?
The Secondary menu doesn't
The Secondary menu doesn't work well with the Garland theme anyway. A javascript list on mouse-over of the secondaries should replace what the current menu does with it. So it becomes a question of action rather than an adjective. A checkbox for "Display secondary menus"? Or maybe "Display child menus" to give it a deeper level meaning.
Another item...
All of the little, collapsible menus under the text area should be subsumed under a single, collapsible menu. 'Options' or somesuch. One need only have a couple of contrib modules installed for these to wind up taking half a page to display, and many of them (Pathauto, Publishing Options -- "Hey, should I change the name of the author on this? Sure!") are plain confusing to the average user.
Agreed. That's something the
Agreed. That's something the vertical tabs module is trying to address, and really the way it should be handled in drupal forms in general.
Another thing that drives me
Another thing that drives me nuts are the default search results. Have you ever tried searching for "Views" on drupal.org downloads? I have no idea how the drupal.org search is weighted, but I can tell you the main project page doesn't show up within the first 20 pages. The core search module only allows to factor in keyword relevance (and not very effectively so), recency of last post, and number of comments, but there's no concept of popularity in terms of visits, which would be good indicator of relevance.
Yeah, me too.
There was some discussion a while back of moving d.o search to SOLR, but I'm not sure what became of that. The inability to search and actually find things is probably a big contributor behind modules that duplicate functionality of another module. I always search d.o using Google which gets better results, but it's really annoying to have to go somewhere else to search.
It's annoying but
It's annoying but sometimes i spend less times going to google and searching there rather that searching on drupal.org (drupal.org sometimes is slow or don't find what i need). However search needs to be reviewed, i always have difficulties to find modules project page or something at the same way popular. Not only search, there is too much space between the search results and the page needs to be scrolled too much.
More cool than annoying
I don't find it annoying, I prefer Google. I can even specify a site:drupal.org/project/Modules/name if I'm looking for a module. Or specify site:drupal.org/project/issues/views if I want to search the issue queue of the Views module. I have my Google UI set to open a new tab for each link I visit and can open several tabs before reading the first one.
search
Drupal.org is currently using Xapian search, mainly for performance reasons. IMO the search results aren't much better or worse than core search - I'm not sure how the rankings etc. are done in Xapian. However, a lot of work was done on performance and other stuff for Drupal 6, and plenty is being done on search for Drupal 7 and in contrib - so we could see lots of changes there.
Permissions
This is really really bad. And ihmo needs to be fixed.
http://www.group42.ca/user_facing_content_management_view
Another thing: the permission page is difficult to understand: how can a user understand that if he set "administer nodes" the following settings (specific per content types) will be jumped?
I propose that if you click upon it the following checkbox will be disabled.
Agreed
This is another one of those things in the issue queue already. The permissions page has been discussed since I started using Drupal. Ugh, all those checkboxes just drives me nuts. And then I forget which role is in which column as I scroll down the permissions list. IMO, the change should drive toward role vocabularies such as Access, Admin and Edit And then each of those have a multi-list box for Content, Comment, User, Profile, myModule, etc. We currently allow too much flexibility for the modules to be creative.
Navigation (or main menu, as you like)
Another unsopportable thing about drupal 6, everytime you click on an item, such as "create content", you have to wait that the pages reload before viewing which content you can create. Same thing for any other expandable item of every menu.
A simple javascript that expand menu without reload (with enabled/disabled checkbox from menu admin area imho) could make navigation less boring and quick.
DHTML Menus
Hi,
Here a first reaction of a bit of a Drupal newbie (only did 3 websites with drupal now) but still, here goes:
DHTML Menus does just that: http://drupal.org/project/dhtml_menu. I suppose it could be a standard in next drupal versions... I have it installed and it works like a charm!
grNico
http://www.druifdesign.nl
http://www.druifdesign.nl
Single Click to open list, double click to activate link
DHTML Menu has been a staple for me when it comes to building websites save for one caveat, a user has to double click a link in DHTML Menu for the link to work. The only action a single click has in DHTML is to open a collapsed set of links. If a variation (where a single click activates a link if there are no sub items or expands a list of links if collapsed) of DHTML Menu was used in core it could work out well.
I prefer a mouse over to
I prefer a mouse over to activate the list of links. A single click on the link itself would activate that link.
Core Charts
Nico Druif: What should go into core - this is simple. Look at download charts. As we don't have them on drupal.org, look at drupalmodules.com's "Most downloaded" top 4 modules. http://drupalmodules.com/top-downloads
No wonder all these (apart from No.1, strangely) are in discussion for inclusion into core. You might find some reflection of DHTML Menus there.
As to the Term DHTML itself - it refers back to times in Webdesign one does not really want to think of anymore. So maybe the module author should think of a renaming. If I hear that term, it makes me shudder and search for a door...
Life is a process
Life is a journey, not a destination
So we can assume..
So we can hope that the most downloaded module will be included inside drupal 7 and if it happens, DHTML menù will be unnecessary, because they cannot cohexist inside the same drupal site?
no
Including any module into core is a process which requires a lot of thought and work, it's not often that modules simply get dropped in out of contrib.
Also, I'd be hesitant to rely on drupalmodules.com for module usage - those stats don't include drupal.org downloads themselves, or cvs checkouts - they also don't account for people downloading a module, trying it out but not actually using it on a live drupal site. Probably the most accurate metric at the moment would be the update status reports - at least for Drupal 6 - since we know these sites are at least somewhat live.
Not to mention that number 5 or 6 on that list is poormanscron - a module that should be used only in extreme situations - i.e. not even on the vast majority of shared hosting accounts. So popularity is no guarantee of quality or appropriateness unfortunately.
Things which might get into core for D7:
CCK - very likely.
Pathauto - Dries has mentioned it, but there's no patch.
WYSIWYG - unlikely, but I think we'll have much better APIs for editors so that contrib modules can work better.
Views - very unlikely unless there's a really, really long release cycle.
poormanscron?
What's the argument against poormanscron? There is a reason it is hugely popular - lots and lots of people not want to, don't know how to, or simple don't have access to configure a standard cron process. And without something running cron, Drupal is crippled.
yep, no access, one of the
yep, no access, one of the first modules to go in. My hosting outfit has requests to add cron jobs, but don't have it yet. poormans cron seems to be doing a good job
yes. poormanscron may seem
yes. poormanscron may seem futile to some. But after installation it's one of the few things that would forces you to configure something outside of the Drupal (from the command line). Which is a stumbling block for many.
well..
I used it when I first started using Drupal, but we should be encouraging people to get cron running themselves as soon as possible - it's a useful thing to know how to do. So while I can see the use case for it, I'm amazed how high up it is on drupalmodules.com - I'd much rather work on simplifying cron instructions for new users than promote the module though.
From a system management
From a system management point of view poormanscron is a good thing. It's one less point of failure, one less thing to worry about when managing servers and software.
Poormanscron is said to have impact on performance, but I've never seen any numbers. There is however a nasty problem, preventing it from running in combination with e.g. simplenews.
About the installer
I see lot of guys that renames settings.php file instead of copying it. In a huge number of cms you have to rename it, in Drupal you have to copy.
When you rename that file, no errors will be displayed on the page that require the info to connect to db.
A message will be useful.
patch on it's way
I think Cornil has a patch to do this. Will post back here if I see it.
Are you referring to
Are you referring to http://drupal.org/node/312677?
unfortunately not
That's not the same patch - I'd discussed the mv bug with Cornil in #drupal, then he posted this patch, so I wrongly assumed it was the same thing. This is some obscure notice also in install.php which he found while patching for the main bug. Apologies for the noise on that issue.
Poormanscron
What is wrong having Poormanscron running by default? Anyone who is "pro" enough to set up "real" Cronjobs will be able to disable it. And anyone who cannot probably won't understand what a cronjob is at all.
It is not even a performance hog, I'd say.
Enabling these things is a nod towards the end user and turning away a bit from a purist "pro" install.
Having had some discussions about whether a Wysiwyg editor should be in core, I am thinking more and more that there should be a "purist" and an "end user" install profile for choice by default. The "end user" profile, which can be a bit heavier in pure size also, for sure would have a Wysiwyg by default, just as well as some things an "End user" probably wants (just take some from the whis list), for sure Poormanscron would be enabled, as well as Admin_Menu, maybe even Advanced Forum would be an option?
How about collecting a wishlist for that, Acquia did quite successfully for Carbon.
Life is a process
Life is a journey, not a destination
Yeah, a key to Usability is
Yeah, a key to Usability is seeing what the users are actually doing vs what we wish they were doing.
Use clear, plain English
The Drupal UI is stuffed with redundant, IT-centric jargon.
It could be vastly more friendly, given a dose of "Plain English" reform.
In that spirit, I'd love to see these "verbal bloat" cuts:
1) Trim the Administration menu:
(the subset shown here runs 20 words/146 letters)
Those terms can be slimmed down to just 12 words/77 letters:
...making it much faster to read, as well as easier to understand.
2) "Administration" can be trimmed: "Site", "Setup", or just "Admin".
I'm sure a beady-eyed pass over the whole UI would yield similar savings -- and make translation simpler, too.
3) Rip out the term "users".
It's distancing and demeaning to the people we're here to serve. The only industries that cheerfully refer to their ultimate customers as "users" are a) the IT sector and b) drug dealers!
Instead, use "Members", "Visitors", "People", "Folk"; even "Community" -- anything but "Users".
4) Fix the euphemistic "Access rules" -- it really means the exact opposite: "Banning rules"!]
5) +1 to prior comments about the redundancy of "Navigation" -- and for splitting its schizoid fragments apart (Setup bits, vs. Member-specific tools).
cheers,
Adrian
Adrian Russell-Falla
412 NE 57th Ave
Portland OR 97213-3716 USA
+1-503-381-4678 [mobile/Jajah] * +1-503-235-9570 [land/Jajah]
adrianrf [im: GTalk/Skype/iChat] * zxadrian [im: AIM] * 478122434 [im: ICQ]
cheers,
Adrian
Adrian Russell-Falla
412 NE 57th Ave
Portland OR 97213-3716 USA
+1-503-381-4678 :mobile/Jajah | +1-503-235-9570 :land/Jajah
adrianrf :GTalk/Skype/iChat | zxadrian :AIM | 478122434 :icq
"4) Fix the euphemistic
"4) Fix the euphemistic "Access rules" -- it really means the exact opposite: "Banning rules"!]"
not true :p, when creating a role you do not automatically inherit access to all permissions, so you are setting the access
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
access rules != permissions
It's for banning particular usernames and e-mail address according to certain rules.
Although in this case it's already fixed in Drupal 7 - I had a patch committed which removed pretty much all the functionality from core, and it'll be IP address blocking in core, and the 'user restrictions' module in contrib. Part of the reason we removed it was because it got confused with access control (now permissions in D6).
It'd really help on this thread if people would actually download and try out Drupal 7 to see if their gripes have already been fixed - some of these were even dealt with in Drupal 6 but are still showing up here.
Agreed
I agree with Catch. I've seen several posts in this thread that call out items which need to be fixed, but they're already been discussed, patched, and committed to core. They're fixed already. Maybe the people who keep finding these little gripes should compare their personal lists against the latest working version of D7 to see just how bad it is or is not.
That step should help us all to focus on the really, really annoying D7 UI things that are still outstanding rather than writing D7 patches for what someone's decided is a problem (within D5) but really isn't since it's already been addressed and fixed.
Deal?
______________________________
Senpai (my d.o account)
~ Build a better WorkHabit ~
Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805
Right shit i was thinking of
Right shit i was thinking of permissions, forgot about the access rules haha.. my bad
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
yes please.
I'd really, really , no REALLY like to see an effort in improving our interface copy by making it shorter, more consistent and more humane. Clashing terminology in the interface is an "official usability issue" for Drupal 7. Let's work on this.
I'm all for renaming 'users'
I'm all for renaming 'users' into members and removing the wording of 'content' from the sub items of Content Management.
satisfy everyone
I suggest that no one wording will satisfy everyone. Why not make it variable and allow the system settings interface to change the wording as needed? Not everyone uses Drupal for Social Networking.
I can see how this would be
I can see how this would be a bit easier to understand for the average person, then again members does not really accurately cover anonymous users as well, seeing as they are not members. Personally I do not see how the term 'users' is hard to grasp but 'anonymous members' does not seem to make sense.
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
List content option in navigation
Hi People,
I am not up to speed in all usability issues since I'm quite new to Drupal I don;t know if this could be called an issue, but it's one of my big annoyances in Drupal.
There is a create-content link in navigation with sub-options for the different content types, that's clear and simple to use.
But somehow I miss the 'List Content' functionality that has the same content-type sub options as the create content option.
I know there is a content list that can be filtered but it takes at least 2 or 3 more actions to get there and filter your content.
Don't know what your thought are on this ?
Cheers
Good idea
You mean you expect that node/list/page would give a list of all nodes of content type Page? And node/list/story would give a list of all nodes of content type Story? And these be listed in a menu named "List content" just like there is a "Create content"?
There may be some contribution modules that help with this. Be sure to check http://drupal.org/project/Modules.
X-Actly
Hi Earnie.
Something like that would be my best guess / solution too ;)
Even more helpfull would be to have the menu options, and the node/list page would display the content-types and the last 10 entries from that content type ... I always forget some little thing when creating a new node and would like to be able to get back to it quickly.
I know there are a couple of contribution modules available like adminmenu but I think I'll give it a go myself on of these days ;)
Cheers peepz
Working on it
Finding your content after creation is one of the big usability issues we want to solve for D7. Have a look at http://drupal.org/node/301902 and review if you can.
So is any of this stuff
So is any of this stuff turning into feature requests for D7? :-p
first post
If more than a couple of people had followed the guidelines in the initial post, then they might. But unfortunately many of these are already fixed, or alternatively don't have issues associated with them at all. So unless people go back and work through turning them into issues or linking to existing ones, then they'll probably sit here forever.
the wiki way
Hmm... this is actually a wiki. we've been using it like a discussion forum. (though wikis do often have comments, it's usually for the meta-conversation)
Using the wiki function on this page from now on would be superior, because we can begin to cluster and organize.
I wouldn't mind taking up the task of trawling through people's comments here, marking them as "in the queue" and then adding them, and marking them. I just started with Gregory Heller's post, since he had it in a wiki format. What do you think? Easy to see where to add things?
Please edit the page, and add your comments to an appropriate section, or add sections if needed.
thank you heather
Disabling comments for now to encourage updates to the wiki. Everybody thanks for sharing, it's indeed time to see which ones can be translated to issues.
See all current usability issues for core