Drupal 6 usability suggestions?

Does this belong in core? It already exists with the comment info module.

When caching is disabled the session is where the information is stored. When caching is enabled jQuery and cookies do the work. Caching and session storing of this information just don't work together.

If this is worth putting in core I'll write the patch. Is it worth it or is a contib module where it should stay?
--
Matt
http://www.mattfarina.com

Thanks a LOT.

Some small suggestions :

1) Ability to have "read more" "comments" links below or *above* the teaser,
as the site admin wants

2) Pagination ( where multiple pages ) both at top and bottom if wanted by the site admin

3) Below each webpage the following links :
Previous page javascript:history.go(-1); Go to Top javascript:scroll(top);
and Print this page javascript:printWindow()

4) Providing check box for user at time of login to toggle "remember me" ( or not remember )

5) Flagging any item in a listing by icon for a later read

6) Track my posts as "My new nodes", "Nodes I commented", "My nodes that got comment"

7) History of visited pages in this session

8) Edited stamp when something is edited and keep in chrono order instead of dumping edited one at one end

-------
9) Ability of admin to define min and max words for any input

10 ) Get a 'more' link in online block when more than n users leading to a page of full list

Best regards

Not agreeing with point 3 above

The book page node acts as a good wiki ..... I wish it stays there.

Best regards

These comments originally appeared elsewhere. Nonetheless I believe that certain widespread trends should be highly prioritized to help spread interest in Drupal.

Of these current trends I see the following at the top of the list:

1. Social Networking has become such a defining force in the growth of the Internet that the industry is starting to refer to this as the Social Web. The existence of many supporting modules in Drupal along with the popularity of relevant groups should make it simple to include in the next release -- "IT" being the recognizable "profile" with content and capabilities that all of us are familiar with.

2. Widgets have successfully taken the leap from my desktop to every website I frequent, allowing me to customize and share my web experiences everywhere I go. The good news is that after the summer of code this concept should be able to explode -- but not simply for the use in Modules. The Widget should work the same way it does everywhere else and allow registered users to import their own content and export it to the web.

3. Mash-ups are the third word of the day and each of the above simplify the process, save one: Content Creation. For the life in me I can't figure out why different Modules have competed for the role when Content Defines the Drupal application. Separate modules help complicate the issue while many of us struggle to create a video or audio site, as well as the rest who simply want to add a business profile. Content Creation deserves Core Consideration.

My thoughts and prayers go out to the contributing developers to consider these basic building blocks of the Social Web.

[Edit: Fixed your link -- Maintenance]

When you click the 'submit' button after entering content on a page, the button should immediately change to 'please wait...' so that the user knows that the button has been clicked and they don't keep clicking it and possibly creating multiple pages/comments with the same content.

Suggestions for "small" improvements, hmm, my cup of tea :-) ... Here goes.

1) In the documentation, add something with regard to the location of files, especially css files... I have css's in my theme folder, there are css's in the various core modules folder, in the various contributed modules folder and who knows where. Come to think of it: it would be nice to simply (?) have one single /css folder! It usually takes me about 1 minute to find out where I could change some PHP, and then about 1 hour (oh well, you know) to find out where this or that style is originating from. Drupal's distributed use of css's is highly confusing. At this moment, there are about 17 (!!) css files active on my site, spread here and there.

2) Make a distinction between the "contributor" of a node and the "author". In larger websites, very often the "contributor", i.e. the person who puts stuff online, is not the one who actually writes the text.

3) Include "something", probably in the documentation, explaining which "elements" can be tweaked through a .tpl file. For instance, I'm still not sure whether I can use a taxonomy.tpl.php or not.

4) This may not be a "small" issue, but still, since The Boss started this thread, here goes. At this moment, caching does not yield a whole lot of advantages to the registered user. Take drupal.org: when you enter anonymously, the site appears to be working moderately fast, apparently because many things are cached. But enter as a registered user, and you have to wait 20 or 30 seconds between pages. Something similar happens on my own site. This is a very strong dis-couragement to register!! Why would you? Entering as a registered user only makes sense when you want to write something. For the rest, being a registered user results in a dramatic DE-crease of speed... That really shouldn't be the case. But I agree: this is not "small" to implement :-)

5) Make comments editable by the original writer at all times, also after comments has been given. For instance: I have to get back to work in a minute, but I would like to continue making some more suggestions later on. Chances are I won't be able to do this, becauses most likely new comments will have been published by then, effectively "locking" this text.

6) Make it clear to the administrator which module is taking care of what. For instance: at this moment, I have two times "Categories" in my menu, one coming from (I guess) Drupal's core taxonomy, the other from the contributed module "Category". Give some kind of "map" of the various places where modules are "visible".

7) Give me a good excuse to explain to my boss why I need to continue with this list and not with what he as in store for me :-)

....

100) Make it compulsory for contributed module authors to include a readme.txt of at least 10 K :-) Above all: make them explain in Human Words what the heck their module is doing :-)

Ludo

John and Matt wrote some code that provides the basis for #6 in their Pro Drupal Development book. Maybe some proud owner of the book can whip up a patch from that? (See page 200 for the pathfinder module).

Improve path alias administration. Add a search form to the path alias administration screen. On a site with hundreds or thousands of path aliases, it becomes impossible to find the path alias that you want to edit.

- Robert Douglass

-----
Lullabot | my Drupal book

I cannot agree more with point 3. If Drupal could improve its handling of outlines, its usability would go through the roof. There is already the Category module and Outline module but neither will be sufficiently safe to use without core support. It wouldn't take much:

- Choose which content types can be outlined.
- Add per-outline rights - rather than any user with outlining rights being able to add pages to any outline

Another huge improvement to Drupal usability would to improve mass actions (such as the Mass Taxonomy Edit module or User Plus). There are so many things in Drupal that are almost useless because of the amount of work it takes to maintain them. The administration of aliases is one of them. I actually use phpMyAdmin when I want to make any changes there. Here are a few simple things in that area that would help:
- Choose how many nodes get listed at once on admin/content/node
- Select nodes that do not belong to a category in admin/content/node
- Select nodes that match a search term
- Select nodes based on date of creation
- Assign one taxonomy term to multiple nodes
- Change authorship of multiple nodes at once
- Change input format on multiple nodes at once
- Change content type of multiple nodes at once
- Resave multiple nodes automatically in one go (useful for some modules)

Other miscellaneous usability improvements:
- Display weights on the list of menu items so that it is obvious what a new menu item should be assigned (like in Blocks or Outline)
- Offer weight and location as an option when creating or configuring a block (it takes two steps to get a block up at the moment)
- Offer User group assignment when creating a new user (similar to User+)
- Ajaxify the ordering of items in lists

I wish I could contribute development time but I lack the coding skills.

______________________
Dominik Lukes
http://www.dominiklukes.net
http://www.hermeneuticheretic.net
http://www.czechupdate.com
http://www.techwillow.com

As a non-coder, I don't know how easy these suggestions are to implement:

• Tracker page filterable by nodetype. I used to visit drupal.org almost every day and read through recent forum postings and try to offer assistance. These days, drupal.org has so many forum postings and issue tracker posts, that I've been discouraged from doing so. So this is a usability benefit for improving drupal.org participation.
• "Check all" box on admin user, comment, and content listing pages and any other page with check boxes that allows deletion. This would be a handy feature for mass deletion.
• Vew nodetype access control. Now that each nodetype has edit and creation access controls, users should not have to add in a separate permissions module for this basic control, and is an excellent addition for controlling access on a site given that Drupal 5 has built in creation of new content types.

-----
Charlie Lowe | cyberdash
Tips for posting to the Drupal forums

While looking at making structure a bit better, it would be useful if the book.module replacement could handle ordering in other ways than just by weight. Specifically, if would be good if users could specify some kind of linear ordering. I explained this much better over here: http://drupal.org/node/37923. We did develop something like this locally, based off of book.module, but it was for 4.6, and it was very fragile and clunky, and we weren't actively using it yet, so we abandoned it. But if the code we wrote would be of help, I can probably excavate it from somewhere.

About point 6:
Is it possible to move the Pathauto module (or add something similar) to the core ?
With the possibility to use custom separators (i.e. for a title like foo bar, one would have the option to choose one or more characters to replace the white spaces: - => foo-bar, _ => foo_bar, ~ => foo~bar, etc.). Another cool option would be the possiblity to add suffixes and/or prefiexes to paths (e.g.: use article_ as a prefix and .html as a suffix, which would normaly result in article_123.html).

And another thing... is it impossible to remove the jQuery or add the option to remove/replace it ? With jQuery around, users are forced to use it and maybe some of them don't like jQuery, or don't have time to learn it, or just want to use other libraries or none. So what do we do ? Leave jQuery there and add another one on top (i.e. another 100 K)? I'm sure it's possible to declare an interface and implement it with jQuery by default and let developers reimplement the methods using their favorite JavaScript library.

The #new links in forum.module, tracker.module (and views.module in the comments .inc) don't work when comments span multiple pages. This makes it very, very difficult to follow long discussions on forums.

There's a three year issue and numerous patches here: http://drupal.org/node/6162 that try to fix this, but none RTBC. I'd be very, very happy if it got fixed for Drupal 6, and have one solution working fine on my live site.

Also

Improve path alias administration. Add a search form to the path alias administration screen. On a site with hundreds or thousands of path aliases, it becomes impossible to find the path alias that you want to edit.

+1 Not tried them yet but: http://drupal.org/project/find_path looks like a start

Hello

It would be nice if the admin menu could have 2 layouts: simple and complex. Simple for everyday tasks, complex for site building.

Jordi R Cardona

Possibility to choose on which link or type of links you put a rel="nofollow" tag. Not only links in comments but also internal links.

If it's already possible and I don't know how please tell me before you remove this comment. :)

BTW I will love the implementation of true internationalization.

I would like to see more flexibility in the menu permissions..

For example, in setting up a site that is primarily maintained by others, you'd want to give them access to the menu system so that it shows up in the node create pages for them to allocate the node to a menu. But when you do this, they automatically have access to administer => site building => menus as well, which reveals to them the entire menu structure.

More for comment.module and forum.module:

1. an option for "truly flat comments" in comment settings - hierarchy is still stored in the database, even if you're displaying comments flat/expanded - this can affect things like deletion, use of comment mover etc. etc. http://drupal.org/project/flatcomments is a start on that.

2. linked to the above, making the "reply" view of a comment allow for a review of the entire thread instead of just the individual comment itself - to save trusting the back button and/or multiple tabs for following one discussion. I couldn't find a feature request for this, so just posted one here: http://drupal.org/node/141059

3. Different classes for subforums in the default forum index - to ease things like different styling and/or collapsibility. At the moment 30px indent is the only difference I could find in forum.module

4. comment submit redirect back to the comment, rather than the node

4a. As Dries pointed out in the issue, this won't work for moderated comments. A follow-on solution to that (and lots of other issues with comment.module) would be comment permalinks: http://drupal.org/node/131428 which might also fix my pet issue http://drupal.org/node/6162

I would like to see some improvements to how the menu editing works. It would be nice if you could set the weight on menus on the admin/build/menu page instead of having to go and edit each individual menu. Also on that page, for big sites I've had lots of menus, it would be nice if you could collapse certain menus on that page. Maybe possibly some jQuery goodess to allow inline editing right on that page (not sure how it would affect page load time, etc), but just a thought.

---------------------------------------------------------------
Proxous, Inc.
http://www.proxous.com

Some things, I think, could easily be improved. I think these two things fall into the "small annoyances" and "learning curve" categories.

Consider the "Enable or disable the submitted by Username on date text when displaying posts of the following type". To a new user it's not necessarily obvious this is a theming issue (especially since new users often avoid theming at first), instead it seems than a content-type concern. I know I Googled that countless times before I remember where y'all kept that checkbox hidden. If the option can't be moved along side the publish and sticky settings, maybe a text reminder pointing the right way would be helpful.

A second little one ... the assigning roles page. If you have a handful of roles (and of course countless permissions) it becomes hard to keep track of: OK ... I'm assigning 'edit own story' ... to, um, whom? Any time I find myself with post-it notes under my screen to remind me what column I'm in, I know it's not clear enough. Sectional restatements of the roles, or even if the mouse-over text could indicate columnar in addition to the row help, would be huge. Going through the Roles menu instead would almost be awesome, except I can't tell which permission are inherited from Authenticated user do I don't make redundant permissions. Maybe a second column (perhaps greyed out, uneditable, or otherwise reduced in significance) could be presented also so one could avoid redundant permissions with the always-inherited case, or perhaps something as unobtrusive as tinted rows or something to make this a viable alternative to the "big grid."

Those are the two that leap to mind. I'd also like read-access granularity to parallel write-access granularity in the node settings, but I don't think that's quite so small.

9) Ability of admin to define min and max words for any input
This is a big one for me too. Mainly so I can stop people from making comments like 'yeah' or 'cool', on sites where users get points for each post the y make.

I'd also like to see a way to automatically make any link that's to another site (IE, not the same as the home URL for a given site) open in a new window.

And how about a core edition that allows unregistered users to post content on a site that requires registration but keeps it in the mod queue until the user has completed their registration, then auto releases it. With the register page coming up automatically when they hit 'Submit'. <-- Guess that doesn't sound too small, but it would be nice.

Thanks,
David
http://www.floridapets.org

I was just posting a story on the "translations" and "internationalization" groups pages with a GUI critic on the current locale translation editing interface, so we can quickly collect some ideas to improve it. There is a lot to improve there, the current translation interface (as far as I see) is very close to being completely useless. Join in the discussion about redoing the locale module translation web interface!

Here's a very useful feature that may still be added to Drupal 6:

I think it both be a usability improvement and would help site owners to create communities easier if the comment and story submit forms or any form which requires log-in had a built-in quick registration form.

Let's suppose a visitor who isn't member of my site wants to submit a comment.

1) In the case comments are allowed to anonymous: he enters his email address (if he wants to register he also suggests a password) on the top of the comment form, he types his comment and then he has to chose between clicking on "submit comment" or "register and submit" comment.

2) In the case comments aren't allowed to anonymous: he enters his email/password, types his comment and and clicks on "register and submit"

3) In the case email confirmation is enabled for registering and comments aren't allowed for anonymous: he does the same but receives the email verification and the comment remains unpublished until he confirms his registration.

The same applies to other content such as stories, pages or whatever requires authentication on your site.

There's something similar to this idea already on production on sites such as engadget and I found it was really cool for creating communities which is one of the missions of Drupal.

Quick start install profile. I'd also like to ship core with an optional install profile optimized at jump starting your installation -- for example, one that sets up a working contact form and creates a dummy about page with a clean and human-readable URL.

I said this would be part of my battleplan for D6. We're going to need a lot of CRUD, still :P

I had already started a wiki page for this on groups.drupal.org -- see http://groups.drupal.org/node/2404. Please come over and join us!

--
The future is Bryght.

Backup module would be fantastic!

A few things I've found awkward:
1. Drupal forms don't remember their content when I accidentally go to a new page and hit back. I don't know why this is -- but I know other forms on the web remember.

2. finer control of access control, particularly for content creation / editing / deletion. Eg, I'd like users on my site to be able to sticky nodes, but not have full admin control.

3. some sort of system for taking a test site live. Most people seem to develop a drupal site in a subfolder. I'm not sure how easy it is to move it from there and replace an old site -- not got to that bit with my site yet! ;)

4. weights for menus should be on the main menu admin page (I think I heard this is on the way)

5. no menu items should have their weights locked -- having a locked item on 0 effectively halves the number of weights if I want it at the top or the bottom

6. maybe it's because I don't yet fully understand how to use theming, but it seems to me that there should be a way of applying theming common to all themes. Eg, theming comment links, taxo terms, or views -- those seem independent of the actual Theme to me.

7. comment links seem to show up where I don't want them. On a locked-down site, users see 'You can't post comments', which is a bit weird

8. add the word 'version' to the description of the admin item where you get version info, for people who use Firefox type-ahead to find stuff in the list

Last of all, I would really LOVE it if image.module could be brought into core, or made more promiment to new users. I found it very hard to find out about how to use images in drupal when I started -- and images are important to most people making websites!

Thanks for reading, and keep up the good work -- Drupal rocks :)

Please do not, under any circumstances turn Drupal into a clone of Wordpress as some of the many forum comments seem to want (makes me wonder why the heck they aren't using wordpress instead of trying to mangle drupal).

And please continue to have no fear in breaking backwards compatibility, that is my number one reason for using Drupal.

Hi all,
I would like to see improvements in Search Module and Multipage Forms in 6.x.

1. Search: As far as I know, it is still imposible or very difficult to customize the search interface through custom modules. What is very important for me (and for many others I think) is to be able to customize the search form through my custom module so that, for example, the search is realized only in certain content types. There are lots of discussions without solutions about this in the forum. There isn't any information util in Documentation either.
There are discusions about this in following nodes:
http://drupal.org/node/124167
http://drupal.org/node/130519
http://drupal.org/node/124963
http://drupal.org/node/68571

2. Multipage forms: The forms API and the multipage forms functionality was changed by Drupal 5.x. There was a working example for 4.7, but for 5.x some things don't work well, i.e. hiding or disabling buttons in certain steps, passing form_values to form_validate function etc.
The discussions about this functionality are:
http://drupal.org/node/136929
http://drupal.org/node/75237
http://drupal.org/node/125145
http://drupal.org/node/113701
http://drupal.org/node/68936

Best regards.

• Different default filters depending on role
• If you have a menu item that isn't a node, list all nodes under it. And the ability to add node to the menu but not showing it in the menu item drop down list. So that menus is treaded like menus and not nodes
• Ability to place/move a menu link anywhere

isn;t it great if drupal had his own standar pre made web. new user install pree made database + theme
oh this is dupal, this is what can u make with drupal.
pre made web with menu, customes menu layout, custome theme, custome block, custome profile layout, custome node etc. this is what can u make with standar drupal + modification.

i'm a new user
1. i want an example
2. i want 2 know how to show my node (with frontpage option check) to be 2 teaser layout or customize my front page 2 be dinamic.
3. the other page i can make it with only html code and assign it with page content type.

i think it's the important think for new user and also for me.

Here is a very small suggestion!

Add the number of comments that will be display in the "most recent comments" block. The same way has in the "active subjects" block. It is currently lock at 10 in the code.

Thanks.

Alexandre Racine

www.alexandreracine.com - mon site perso
www.salsamontreal.com La référence salsa à Montréal

1. The ability to have a multi-page registration form.
   I've seen this asked about many times in the forums, and even had to kludge a similar feature for a website I'm building. The FAPI currently allows for creating multi-page forms, but only when the form was designed to be multi-page in the first place. It would be nice if any form could be extended into a multi-page format through use of the API.
2. The ability for themes to have a settings page.
   Themes can define regions, but they cannot have a settings page in the way modules do. Themes are usually hard-coded with site-specific information, which makes re-use very difficult.
   Example: In my node.tpl.php, I want to optionally display information, depending on the node type. As a designer/programmer, I can easily write different .tpl.php files for the node types, but how do I let my end-user change this later on? Or what if they create a new content type, and want to include/exclude the information there? There is currently no way for themes to have their own settings page.
3. The ability to exclude an individual node from being indexed by Search.
4. The ability to include non-node pages in Search (module generated pages, for example).

Just a few observations.

- Corey

installing modules has become rather easy during the last couple of years. but i have seen lots of new users wondering all over the admin pages to get it right. so how about a small wizard (profile?):

* when you check in the modules menu a new module and press submit the next screen is
* access right, directly pointed towards right spot in the complete menu or only the checkboxes for that module(s) then after submit ("next")
* the settings page of the new module(s), then after submit ("next")
* optional if enabled the throttle page for the module(s)

some sort of wizard for installing modules in core will really help people getting to know drupal.

--
groets
bert boerland

1) Outline: it'd be great, at higher-level book pages (chapters, indexes, whatnots), to jump to the next page on the same level. For instance, use the "next" link to go from chapter1.index to chapter2.index - don't go down one level from a chapter page.

2) Outline: I'd love to be able to outline 1000+ -page books. Currently, that's pretty much impossible.

3) Date: a default date format which accepts years in the 1800s would be wonderful.

4) Taxonomy blocks: when terms in one vocabulary go over 10000, it should be possible to prune the block view, either by taking out all terms on the same level, or by taking out all but, oh, say 20 terms on either side of the current term.
CKK field support of taxonomy terms might take care of things, too.

Thanks!

Great article css drop down

http://www.tyssendesign.com.au/articles/css/dropdown-low-down/

The Script is inspired by Sons of Suckerfish and Drop-Down Menus, Horizontal Style and is based on jQuery.
http://pfirsichmelba.de/artikel-scripts/suckerfish-accessible.html

Already a module multidomain and
http://drupal.org/project/multidomain

in dev module PressFlow Multidomain
http://drupal.org/project/pressflow_multidomain

http://bryght.com/blog/adrian/multidomain-module-for-drupal-5

It will be great if its on core, with multilang we can have multidomain with same database

of Dries suggestions, I'm casting my vote for

#4
#7
#8

My suggestion

We need the ability to restrict the affiliate login websites to specific websites.
The IMAP module does it already, but not the Drupal website network login .

Marcel
http://www.BlogPostsForSale.com
http://ComputingNews.com

How about allowing html in node titles?

newms

Will there ba a Daylight saving time feature? We've been waiting it for so long...

Hello,

A suggestion what I'm missing right now:

Please make a possibility to change the layout AND the text for the teaser. Give the administrator the possibility to turn on or off for certain types. IE, no change possible to the teaser for blog-entries so that a teaser is shown the normal way, but make your own teaser, with his own pictures, layout, text,... for pages. If left empty, then take the teaser the normal way

Or is there already a module doing this ????

I was thinking if any menu customizations are thought to be in place for ver. 6.
Saying that I am considering something like :

1. User to be able to select the order of the menu items
2. User to be able to select the positioning of the menus between left/right sidebar or even break the menus to left AND right at will
3. User to be able to make a certain page as his home page and even customize it with several other parts of the site as content
4. User to be able to save his most frequent searches
5. User to be able to use the search form about postings, of any of the content types, either from him or any other user, with various filters such as date of posting, title of posting, taxonomy of posting etc.

I hope these are not suggested somewhere else, if are, accept my apologies.

David Oster aka George Pasparakis

#5. check out "update_status" module - it's available for 5.x http://drupal.org/project/update_status

i don't like to see a username per default in articles and comments. This is security related information... if i have the username i only need to guess the password... and not both, what makes things much more complicated and took much much longer. So only display the real name and not the username that should be different...

I once posted a question here with regard to a "dummy menu item" or a "menu separator", i.e. a menu item that does nothing, except separating two groups of menu items, for instance:

Dogs
Cats
____

Mercedes
Honda
BMW
____

Soup
Pudding

Its the "_____" I'm talking about. Judging from the replies I got, this is not so trivial as it appears. As a small improvement, I would like to see this added. It can definitely add some cosmetics to the menu. As it is now, I think it takes too much tinkering to add "nothing" to the menu.

Ludo

Ideally, the Drupal Folder should not contain any user files. Currently, it contains the settings folder, user installed modules, themes, etc. It would be better if those files lived in a folder at the same level as the Drupal folder (i.e. sibling), rather than inside the Drupal folder (i.e. child). That would make the process of upgrading Drupal to a new version clean, easy and simple.

Isn't that what the "unpublished" state is for? Otherwise this could fall under the workflow module, which is making it to core Drupal 6. For instance unpublished > draft > published. But I feel this will add complexity.

Perhaps "unpublished" should be renamed to "draft"? The simplenews module allows an option "Don't send now" which technically comes down to "keep state unpublished" but has a "draft" feel to it.

Maybe it does not seem important to lots of people, but I would suggest to provide functionality during site setup to enter SMTP server address. If for some reason (which is often the case) I do not have some mail transfer agent set up on box where I am playing with drupal I would like to avoid using 3rd party module for this.

The arrows, arrow-desc.png and arrow-asc.png, for sorted tables are confusing. They point in the opposite direction IMHO. I believe they should point in the direction of the grow. I suggest checking some desktop applications and considering a switch in the images.

Another problem is that the default sorting order is Ascending. ("default sorting order" = what happens when you click an unsorted column header.) I believe the default order should be Descending. This is much more useful for numbers and dates (BTW, for this reason I'm tired of clicking twice on the "Created" column here in the forums). I admit that it's less desired for strings, but I think sorting by strings is less common. I find myself almost always clicking twice on column headers, because this default order is usually the least useful.

(Another thing I don't like is that the "order" URL parameters, as in "order=Created", contains the localized human-readable name of the column instead of the field name. I feel it's wrong.)

Currently, only those who have the "administer comments" permission can edit comments. So bloggers on a site cannot edit comments posted on their blog. Allowing this is a matter of changing a few lines of code in core -- it's hardly possible by writing a new module. (But I don't know yet what changes in core deleting a comment would require.)

There are 3 classic permissions for each node type right now:

"create story content"
"edit own story content"
"edit story content"

I suggest adding another:

"edit own story content comments"

(or "administer own story content comments")

These will appear (in q=admin/user/access) under the "comment module".

- Enable the <blockquote> tag by default. It's not in "Allowed HTML tags". I'd also suggest adding to garland the CSS to display a quotes image in the background.

- It's possible now to have a different theme for the administration. It would be nice to be able to specify a different language as well.

- Add a "clear cache" button? (to the admin/settings/performance page maybe). As a developer I use the 'devel' module for this, but I feel it should be in core.

Some more small things here and there that can improve usability:
(at least from what i would like for drupal 6)

1. In Views: a way to assign your own wrapping to the fields, including unwrapped values, which saves theming time.
Contemplate does something like this, but per single node instead of listings and only one template per content type.

Also, now that modules can use content types from core, perhaps the same trend could be done with Views for all filtering functionality.

2. Expanding "edit all nodes" to have view permissions and to restrict "administer nodes" to the selected types.
Those who can edit unpublished nodes should be able to view them too.
I'm not sure if this is already done for owned nodes, but certainly not for roles with "edit all nodes".

3. Let contemplate handle unpublished nodes, which won't be related node permissions much in the way views work.
It is easier than making a view for each type, because you can theme it right away.

4. Make the check for "administer nodes" return false for access control, thus allowing non-global editors to benefit from many modules that require "administer node".

5. A separate "publish nodes" permission that includes revisions, sticky and promote, since "edit all nodes" don't cover it.
This will be like the way modr8 module prints its checkbox for users without these permissions.

6. Be able to add multiple authors in the author field. Perhaps a split and loop on the string would do.

7. As suggested on this thread, let the book module be used for hierachies.
The current book wrapper from category works good for grouping nodes into child pages, but can be extended for full integration with other modules.
This doesn't sound like an easy task.

8. Use collapsible fieldsets on the access control pages, to hide permissions checkbox rows per module.
Also, this could follow the same grouping as the module page, instead of the current alphabetical order.

9. Uncollapse of the taxonomy/category fieldset on node creation pages.
Hopefully the content_taxonomy module would replace this need or already does.

10. Some degree of integration of all fieldsets on the node creation pages with the cck fieldgroups, so that you can collapse, uncollapse, weight, hide, widget, edit and group them for custom needs.
Fieldgroups already handle the title, taxonomy/category and og fieldset weights.

If this is difficult, a group function like that of the form filtering module would be good, except because it also wraps the taxonomy/category fieldset and that should be uncollapsed, as mentioned in the previous point.
This would separate the cck input fields from the rest of the "advanced options".

I'm pretty sure my suggestions aren't quite simple, but they are so critical for me at this moment that I can't resist to post it here :) (If anyone would like to copy/paste/move this to another thread be my guest. It mainly concers about internationalisation since I've read this is going into core)

1) When you 'click' create translation, I'd like to see all custom fields created with cck to be filled in by their original node values. This way, the user doesn't have to copy/paste exact fields which will be the same in every language (eg birth date, drivers licence ...) Before you say, hey, use the clone module, read on for my second wish ..

2) When you have have a custom field type from the node reference and when you click 'create translation', I'd like to see that the corresponding selected node id from your desired language is also chosen. I'm not sure if I'm clear enough, so here's a simple example.

You have a content type which is called 'fruits' and you created nodes called 'Appel', 'Sinaasappel' and 'Tomaat'. You translated them to English, so you have 'Apple', 'Orange' and Tomato'. Now in another content type, let's say 'Drinks', I've created the node reference field where you can select values from the fruits ct. I've made a node called 'Fruitdrank' and selected 'Appel' and 'Sinaasappel' as references for this node. Now when I click 'create translation', I get the english values in the select list but they are not selected. In this case, there aren't many, but I've had a real life experience where I had more then 200 values and searching and clicking them was really hard. So what I'd like to see, is that 'Apple' and 'Orange' are selected.

I'm going to dive into the code myself this weekend to see if I can fix it (I will, but since it has to be done on monday, I don't think it will be thàt clean).

I also have a third small issue, but I've read also the menu module has been rewritten and there are modifications on the book module, but still here goes: 'Associate' nodes automatically to parent menu item, but never show this menu itm on screen. I'm doing a css trick where I set 'display: none' when the menu gets into the third level. I don't want to see it, but I want the parent menu to be expanded so one knows in which section of the site he's surfing.

Anyway that's my 2 cents. I'll probably talk about them with you Dries somewhere in June (friday the first if I'm correct) when we meet on a small discussion evening with Wim (from Across).

Apart from these issues I'm having now, I'm really falling in love with Drupal, so keep up the monumental work! (And I'll start contributing patches any time now!)

It would be nice to be able to integrate story comments into the forums.

I would use the vBDrupal method: on the story submission form, add a "Publish as forum topic on" and a drop-down with the list of forums or let the administrator define a default forum in which stories can be handled.

Another possibility, probably easier to implement would be to let people duplicate the forum content type on the "content types" admin page and let us add CCK fields to forum-based content types. In short, allow us to create our custom content types with forum behavior.

When I think about the problems I did encounter and the e-mails I received from new-druppalers after announcement of some of my sites (e.g. http://www.drupal.be/node/453 and http://drupal.org/node/7443#comment-82760 ) the common question is:

How do I create a menu with some pages attached to it ? and I want to be able to publish some images on my site ...

When I think further about it, it is even worse. Sorry, but it is not only drupal 6.0, nor 5.0, nor 4.6 related, but also how drupal is marketed (from a new user point of view). I must admit I was really "scared" when I first encountered the page on my first drupal encounter:
1. download drupal
2. security vulnerabelities
3. upgrading
ref: http://drupal.org/drupal-5.1
....
I didn't even had a first look at drupal and was already scared about the security stuff.... still I downloaded drupal ... next thing is figuring out how I get a simple menu with some pages attached to it.

In my opinion this should be something like:
1. on the drupal homepage I click: "download latest release" (this is how I and many others first encountered drupal)
2. select an "installation profile":
- blog
- community : default menu enabled (with easy explanation on how to extend it)
- sports club
- charity organisation
- clean, lean drupal (as we know it right now)....

especially the combination of drupal marketing and default installation profiles for drupal enable to really reduce the learning curve.
I'm really convinced this will reduce (1) the learning curve for new drupallers, (2) time to market for new sites and thus improve the acceptance of drupal by webmasters (sorry for some of you, but this is not equal to expert php nor to expert drupallers)

Let's share some ideas about this and get it up and running! I'm willing to spent some time on this to get the concept right.
Wouter

I think it would be nice to have comments administration right from the node, with admins only links such as 'unpublish', 'delete', 'block user'. Major bonus points if Ajax enabled!

---
Biology News Net

Don't know if this counts as a "small" annoyance, but:

I'm putting together a website for my company which includes, among other things:

* when deleting comments etc, make the "delete" and "cancel" both submit buttons like in most os-es instead of one button and a text.

* when previewing is needed, dont name the submit button "submit" but put the text "next" in to it, wizard alike
--
groets
bert boerland

1. Integate "Global Redirect" module into core, please
2. Add an SSL Cert to Drupal.org
3. Force secure logins.
4. Drupal.module must force SSL (http://drupal.org/node/93048) and drupal themself must do, too. The login dialog on a different site must force SSL, too - if someone likes to authenticate against Drupal.org database. It must be prohibited to sniff/log passwords inside Drupal.module. I don't know who have done this pice of code, but i'm shocked how careless my password is managed/transfered/saved.

Don't know if this is what you're asking for, Dries, but perhaps something involving just a basic theme with a larger default font? Most Drupal themes have smaller fonts: perhaps a very Web 2.0-ish theme with larger fonts and rounded corners would make for a nice starter theme. My users often complain that every theme I've picked for them is too small, and taking a theme but just making the font size larger just doesn't look right.

my apologies if that is not the right place or if I have made the wrong assumptions! I am just a newby here with little experience everything but appreciates the works of a wonderful Community here.

img_assist plugin to tinymce is cool but seems to be conventional. all image insertion tools seem to be similar and follow the pattern of: a popup with thumbnails filtered by a dropdown box of some 'albums'. i was always wondering what if the images list got too long?

I am hoping in img_assist plugin that you would add the ability to customize of the dropdown box(es) so that they can filter by:
-user
-date
-albums
-any other tag (set from administrator menu?)

Thanks.

I don't know if this would still qualify as a "smaller" improvement as Dries meant it in his original posting, but here goes.

Drupal's granularity in its access control is already way ahead of the rest of the pack, but still, when you go that way, you'd want it all the way. Would it, therefore, be feasible to include "something" in Drupal's core which allows module makers to granularize administrative access to what their modules produce?

An example. My site publishes a number of "newsletters", which are not administered by me, but by the respective newsletter editors. I would like to give each one of them access to the View(s) which actually run their newsletters, but as it is now, I can only give them access to All Views or to No Views administration. It would be nice if this could be more finetuned, so that User A could administer View A-J, user B View K-Z, and me, the super admin, View A-Z.

Same thing, for instance, to Panels, to ConTemplates etc. It would be ever so nice to be able to provide granular administrative access to their "results".

As I said, I don't know if this is "small" or not, but maybe it's worth a thought.

Ludo

At this moment, putting "bad code" in a block can break your entire site, including the administration, making it entirely inaccessible, also to the site administrator. Of course, code should be tested first on the node level, not on the block level, but that is not always possible (or it simply doesn't happen, people being lazy and all :-) ).

If this is "small" enough to change (which I doubt...), I would like to see this made impossible, i.e. make the block die gracefully in such a case, but prevent the whole site becoming inaccessible. As it is now (and as it will probably remain, I'm afraid) Drupal's visitor access and admin access share the same interface. That has its advantages, but not always. Could it be considered to create something like an Administrative Backdoor, password protected probably, and always accessible, so that, for instance, a bad block could always be eliminated without having to go to phpmyadmin or something like that to manually plough through the database?

Ludo

I'd like to see an option were you can select were to upload the file(s). Let`s say that i`v created 2 directories: /music and /programs. And when I post, to could select were to upload my file. I think this is very useful to have an organized website.

( sorry 4 my english ).

Link Directory - Linksdb isnt ported to 5.x but this should be part of the core, and please add subcategories if u do this

Ratings - ratings for comments/stories...

AFAIK - the only way to customize the search results (such as whether the use name & date shows for each item) is by overriding the theme function (as shown here: http://drupal.org/node/141779).

Rewriting this code so that it can be customized via a decent UI as part of the search admin pages would be a simple but helpful.

i run large community site and a several smaller homepages/blogs (for me, friends), and very annoying thingies for me are:

1. multiple comment pages - #new is not working properly
2. remembering data of anonymous guests that comment blog/site
3. admin interface - lots of things to do with mass renaming, moving stuff to another category etc.
4. simple node conversion? eg. changing blog node to article node and vice versa (same with page and other plain types)?
5. profile.module fields advanced search would be great!

anyway drupal's best cms...

Well after a year in the community I feel a little more confident to jump in this kind of "would be great if" threads...

1) Menu system administration should allow to easily modify the menu item name, parent and weight, directly from the admin interface, without having to click on the menu item to change it

2) I think there should be a small core module that would allow to actually easily list all terms from a vocab in a block or on a page. This would allow to easily create taxonomy menus without using any contrib module

Hummm that's it for now lol
Later,
Patchak

Nº4: "Save as draft" feature: It would most helpful-useful if nodes could be filtered or searched according to its draft/published status.
Also, integration of/with tinymce would be great and i think is a much requested improvement.
Any Estimated Time of Arrival for version 6?

# 1 automatic extend text area
I have seen somewhere else (tikiwiki?). The text area increases as you are closer to the bottom. A nice feature when you write long post that avoids to use your mouse to resize the area, and let the display closer to natural writing.

# 2 automatic edit / view switch with one clic on the text area
Extremely practical and easily addictive.

# 3 edit post per section
Same comment. It is secure... and allow editing and reorganizing long post. I do not know how to manage the display and the interface so that the sections are save into the same node. I note that WYMeditor had the potential to resolve this type of problem.

# 4 simple display image module into the core
Attach image to post and display as thumbnails either at the bottom or by the side. A extremely basic module, but something that lets to manage image simply and out of the box.

# 5 simple iconize module into the core
Manage the file extension and display the corresponding icon.

# 6 A taxonomy display module into the core
Something previously noted in drupal usability reports.

A have a strange feeling with Drupal.

It is the only one CMS that lets me unable to memorize interface. Thus I always do mistakes when I navigate into the admin interface... Why ???

In my point of view because
1) My brain,
2) Drupal interface is only verticals list of fields difficult to distinguish,
3) The long debate between organize per function or per usage,
3) Too much addition of long texts supposed to be informative but that add noting to my understanding (look at the later opened page, or the title field is sufficient), but simply overload my limited brain. Most of the case, long descriptive texts should be shortened to one line.

Simplify block 'Page specific visibility settings' on /admin/build/block/configure/*

The question of how to show a block on particular vocabulary/taxonomy terms and/or node types continues to regularly appear in the help forums. Personally, my block settings never holds the custom category php when I edit the configuration and I have to look it up every time.

I think a simple pair of check lists (maybe similar to the ones used in the module, Taxonomy Theme) would make this task much easier. Not to replace the custom php, but as an extra, like the 'Role specific visibility settings'.

8. Backup module. How hard would it be to make a simple backup module, and how many people would be helped by it? It could be really simple but highly effective.

- similar to this backup module ?

I would like to include more information about the search results.

1. Something like Displaying results 1 - 10 of 24 for searchkey1, searchkey2. You can see this in action at http://drupaltr.org/search/node/erdem. I am using a modified search.module. (the line below "Arama sonuçları")

2. Add the above information in the watchdog log. Current implementation requires me to re-search to see if it returned any results.

I created a patch about the 1 and 2.

3. Make it possible to search for non-whole words. When I search for "erdem", I'd like to be able to see "erdemkose" in the search results. This is very important to support different languages, as an example, Turkish is a suffixed language and it uses suffixes very often (See a comparison at Turkish Wikipedia).

I am currently using a modified search.module to support 3, but I'd like to see it in core. See this in action at http://drupaltr.org/search/node/erdem - note that the 4th result (BUEditor) couldnot higlight erdem because it doesn't contain erdem as a whole word (I couldn't fix highlighting issue in my modified search.module).

Some may advise me to use a porter-stemmer but this is not what I want. Here is an article that shows porter-stemming is very hard to implement for Turkish (Search for Turkish on the page).

--------------------------------------------------------------
http://erdemkose.com/
Drupal Turkiye

Multisite + Pictures - release of files directory restriction for pictures!

http://drupal.org/node/132988

I think this should be rather brief to implement, but I haven't delved into the core, so I could be wrong.

Currently we have a text box where we can enter strings(with wild-cards) to block the display of certain blocks on specific pages or groups of pages. My guess is that when people decide to disable blocks on certain groups of pages they use it in more than one place. My request is for a way to make this simpler(and less error prone-typos, bad patterns, etc)

Stage #1 - a few predefined choices such as all admin pages. There are lots of blocks I'd like to see when on normal pages but which serve no purpose when I am doing admin functions(examples the google-analytics and adsense)

stage #2 - make this list controllable/update-able by the admin (add/drop and modify entries)

This predefined exclude lists could either be selected by check boxes(for short lists) or maybe a multi-selection menu. The selection could either be processed when the page is submitted or maybe if done via JavaScript, the appropriate string pattern could just be inserted in the text box and then processed normally.

I hope this description makes sense.

-------------------
http://www.PrivacyDigest.com/ News from the Privacy Front
http://www.SunflowerChildren.org/ Helping children around the world

I use drupal to author large amounts of content with a team of editors: Few people create content, many people just consume it.

I know it it may be old fashioned but to have a decent possibility to export all or parts of a drupal site to static pages would be a huge plus.

Let us keep in mind that even in Web 2.0 times not all people need to be logged in since they simply do not edit but "read" content.

Look at drupal.org as an example. It really takes seconds to only switch to a different section of the site. When I am logged in it seems to be even slower. All the dynamic stuff is nice for editing but simply kills performance. Serving static pages is a no brainer and allows to use cheap hardware. Even a lame PIII could handle thousands of requests with static pages.

There was a static export module for 4.7 (I think) called boost but I have seen nothing for 5 and I do not know plans for drupal 6.

I would vote for an "static-export-module" with some of the following options:

- define what content should be exported to static pages
- define the export folder or site (in order to have a development server and a live server)
- define export times or export rules (e.g. export all published files or export every day a 12p.m.)

I think basic features like that should be part or the drupal core.

Martin

I know there are some modules about it, but, would be great to have a built in, or default module that detects the language and acts according, and that makes easy to do and manage translations.

Leo

Starting off with the easier ones, before it becomes more and more tricky (probably, I'm a newbie so the categorization might not be totally correct...).

REALLY EASY:
1.Automatically focus the first field (username) in the log in box, when visiting the page.
2."Remember me" checkbox beneath the log in box.
3.Ability to “Add separator”s ( like this: ____ ) between a group of menu items.
4.Dries said: “I think a lot of people want to have more control about how a node is displayed. They want to control the location of the 'read more' link, the want to hide/show the username, the date, the printer-friendly links or even the taxonomy terms.”

I'll second that! One especially nasty feature is that the tags currently are styled the same way as links such as “read more”, ”Write to author”, etc. They are thus mixed in between these links. The result is both ugly and confusing! A simple workaround is to style the tags differently (preferably in a smaller font, at the top of – not beneath – the teaser). Major advantages. Minor work.

QUITE EASY:
1.Polish the Blog Information module (http://drupal.org/project/bloginfo) and make it into core. (Description of bloginfo module: “adds a blog title and description to your blogs. It is a simple module that adds 2 additional fields to the users account screen, for those who have permission, to have a blog title and blog description.”)
2.It should definitely be possible to give permissions to roles to “Edit own story content comments". Muffie also suggested this.
3.Per menu item permissions would represent a major boost in usability. If one wants restrict access to a single menu item now, one have to go through a rather obscure and clumsy process:
1. Create a new block (Site building -> Blocks -> Add block);
2. Set the right region and weigth for the new block;
3. Click “configure” and set the right permissions, and finally:
4. Move the menu item one want to set restricted permissions on to this new block.

It would be soooo much easier if one just could
1. Go to the right menu item (Site building -> Menus -> edit (to the right of the desired menu item)) and set the proper permissions directly!
2. What are you talking about. There is no step two here.

MEDIUM:
1.FabriceV had two excellent suggestions. The first one was an “automatic extend text area” that increases the text area as one are closer to the bottom.
2.The second one was to put a “Simple iconize module into the core” which would “manage the file extension and display the corresponding icon”.

HARD:
1.An admin theme that would present the administrator's menu as friendly icons, ala Joomla.
2.Ajaxifiy reordering of menu items! Should have an upward arrow and a downward arrow as well as move to top and move to bottom arrows.
3.Ajaxifiy reordering of whole menus and blocks! Should have buttons for moving it to the left, to the middle, to the right, as well as up, down, top and bottom.
4.Ajaxifying everything from submitting comments, to moving menus and blocks, searching, personal messages and basically everything else.
5.More core install profiles.

REALLY HARD #1:
Plone emulations (no I don't use Plone it do have some VERY nice features):
1.Live search (Plone has got this and it works really nice (though I guess it's resource intensive as hell)).
2.WYSIWIG editor (Plone has a beautiful one – it should almost be copied straight).

REALLY HARD #2:
An out-of-the-box social networking site (by choosing the “Community” core install) with:
1.Ajaxified personal messages;
2.Ajaxified block which shows your online buddies (showing their user icon as well their username);
3.Subscription-like feature which lets you follow the stories of your liking just by clicking an ajaxified icon positioned after or before the story headings (for instance an idle star when not following the story and a lit star when you follow the story – which one can do by clicking the idle star without worrying about page refreshes);
4.Block for showing which stories you follow (the ones with new comments at the top, in bold, with “([n] new comments)” after it). Should by default be formatted as a special kind of sticky “story” at the top of the startpage.
5.Block for showing which stories your buddies follows (only headings, and not formatted as a list, but as text, like this: Link #1 | Link #2 | Link #3, in order to show the maximum amount of stuff your buddies follow). Should also by default be formatted as a special kind of sticky “story” at the top (beneath the former mentioned block) of the startpage.
6.Button for giving props/kudos/whatever-you-wanna-call-it beneath every submitted story and comment, and a way to see who you've given props to and who you've got props form, somewhere in your own user account.

I look forward to gain enough skills to contribute, but alas it's not right now.

BTW: Nice to hear that workflow will be included in version 6 again, and I liked a lot of the other suggestions of Dries and others as well!
___________________________________
Be realistic! - Demand the impossible!

I know this the second time I've mentioned it on this thread (or third maybe), but this thread itself has just become the most recent example of the issue.

Try: http://drupal.org/node/141043#new

You won't get the new posts that you've not read yet, you'll get Dries' first post on the thread. Then to see the new posts, you'll have to scroll down the whole page, click "2" on the pager, then possibly scroll again.

four clicks instead of one. If you keep checking back (as many people on busy discussion sites), it becomes 8 clicks instead of two, etc. etc.

Can Ten Billion other sites be wrong? They all allow you to create your own password at registration.

This should be built into the system and not be part of another module (i.e. LoginToggan).

Having your password defined by the system and only afterwards being able to change it is guaranteed job insurance for the Help Desk and guaranteed frustration for users.

If you're going to make "Remember anonymous comment posters" part of core, this certainly should be included as well.

And for the people who think this would provide a horrible breach of security, allow "user sets own password at registration" at least as an option for those of us who have other concerns.

As a usability guy by trade I tend to follow the industry rags. This is an article that I happened across by James Robertson where he discusses 11 usability principles for CMS products. This is good stuff and can really help out Drupal with becoming more user friendly.

http://www.steptwo.com.au/papers/kmc_usabilitycms/index.html

Something to keep in mind - good usability is not about more features that can make it quicker to do things. It's actually making things easy to use in the first place - matching how people think about the item they're interacting with.

I don't code, I'm not a graphic designer, but I do design the end of the interface that users see from a structure and layout point of view - where things go and how they work as opposed to how it's coded or what it looks like.

If that's something that could be useful to the project, I'd be interested in helping out. Someone drop me a line if that's the case.

Thanks.

Tim

Many of the solutions to requests on the support forums involve implementing some hook (hook_link, hook_form_alter, hook_nodeapi, ...). But to do this the admin first have to write a skeleton of a module: an '.info' file and an empty 'mymodule.module' file.

It would be nice if Drupal already came with an empty 'home' module in the 'sites' folder. I would be enable by default, of course. (Maybe it would be possible to turn 'settings.php' into such a module?)

As a bonus, Drupal would check the 'modification time' of this module file on startup and clear the various caches if it has indeed been modified since last check. This would save the casual Drupal admin messing with the cache.

It would be better if validations are provided for some common form fields ....

It is possible to reasonably scrub a server's IP logging. It would be very helpful for Drupal to be able to use IP addresses, but have an option to not log IP addresses. That feature request is important for Indymedia sites and others to use Drupal.

Completely unrelated, I'd love to see the various profiles as nodes solutions partially moved to core, at least so that profile fields become just CCK fields. Has there been any action in this direction anywhere?

~ben, Agaric Design Collective

Hey Dries,
I want to take you up on your offer to work on an interface for external javascript editors. I'm not sure that I could create the interface, but I can try to offer input. Could there be a separate forum posting for this topic?

It's frustrating to find a module emitting markup with no easy or mnemonic way to control that markup through CSS.

Could we make it a rule that whenever a module emits markup, it wraps it in an outermost SPAN with a class that is the module's name? (I say SPAN rather than DIV because DIV could be interpretted as whitepace above and below, but SPAN can be inline or, with display set to block, just like a DIV.

These are two separate menu items, but for an admin, they're both means to the same end: Finding a user that meets certain criteria. So, combine them.

In fact, the same logic applies wherever there is a "Show only ____ where" form item, as in "posts" -- a search box should be present because the task is the same.

(And make the search box either additive to the radio buttons, or not, at user option.)

In the heading.

Spam.module has this, but not all admin forms do. But every time there are 50%+1 items in a list you want to perform an action on, it's simpler to check everything, and then uncheck what you don't want to perform the action on.

If, by adding a search box to all "Show only ____ where" form elements, retreiving items to administer is made much more precise, then such a select all check box is even more likely to be useful.

Why does it need its own?

I'm not a usability expert, but I find several things frustrating about the dropdown used for organizing books:

1. Very long titles make the dropdown way too long. It should truncate them, perhaps with a uniqifying number if need be and an ellipsis

2. The same chunk of content can't appear under multiple branches. If one was doing serious bookwork, that would make things like boilerplate very hard to do.

Other thoughts about books:

3. There should be an option to search within a book (put the field in with forward/back/up).

4. There should be an option to collect the links within a book, give them titles, and store them. Then the store could export a bibliogrpahy node. The store could be refreshed, and a new bibliography generated.

5. The same idea could be generalized to create a TOC, so authors could be associated with posts in a table of contents navigational page.

Drupal still looks like a blog the first time it's installed. I do believe a fair number of users like to make it look like a news site with multiple information instead of a vertical series of updates. In the spirit of shortening the learning curve:

1. Include several pre-defined CCK nodes, e.g. Article with 1 picture at the top right; Two-sectioned article with a picture in the middle and center; Review article with 5 star rating at the end; Picture of the day with caption. Make these as CCK rather than as separate modules so that the user can play with them (and learn a thing or two).

2. Include a 'busy front page' view or module without resorting to Views. Rather than letting the user build it block by block, give him/her a default standard one, e.g. In main content: Static Banner (like Drupal's), Headlines/Recent Blogs, Topics in smaller blocks; in side bars: Content menu, Recent Comments, Users online, Ads. Create default primary links and footers, such as News, Blogs, Pictures, About Us. Since there is no content, the links would lead to an error page which explains something like "Content not yet created. You will need to create a page with the taxonomy 'News'"

The user thus modifies or subtracts from it without going through Views. Almost like the block configuration but this is meant to only show on the front page. You can always put a comment "For more functionalities, please use the Views module" i.e. the user cannot complaint if he doesn't like it :)

3. Include a theme which looks very 'newsy' to support the above - smaller fonts, boring hues, simple blocks, solid colors, rounded tabs. Modifiable with the color module.

Second part of suggestions:

As an admin, I would like to have a simple way to view all the configurations at once.

4. I wish there was a button to expand all the collapsed sections without going to press each arrow. (Well, I could do it with a javascript bookmarklet but it would be nice to have it there in Drupal)

5. I wish there was a way to print monospaced reports of the admin/module settings. For example, in theme configuration, instead of a ticked box next to "Mission Statement", the print page would state "Mission Statement - Enabled". CSS perhaps?

The least it could be done is to the log page. I don't care for the fancy table and cell colors. Wish I could have a boring courier font print out - much easier to read (Well, can be done in SQL but nicer if it was in Drupal).

6. I do realise no. 5 might warrant more than a small adjustment, possibly a major module (but really?), but if somebody is already making one, I would like to add another wish - have all the settings from every module, every taxonomy, every user type, every CCK node and ...., every theme choices, etc. all printed on one page. It would be so much simpler to debug the site.

Finally, I'm supporting any attempt to make weights easier to manage, to menu and everything else. Doesn't have to be AJAXified, just a two-column table with a column of text entry boxes to be filled with any numbers, including negatives and decimals (how to slot between -101 and -100? make it -100.5!) - that would help tremendously.

1. Don't fool individual bloggers into starting collective blogs

   In Drupal, "Blog" should be used when you want a blog where several authors can contribute. If you are the only one blogging on your site, you are supposed to use "Story". This countra-intutive naming is missed by a lot of individual bloggers, who end up having a duplicate My name-blog on their site.

   A change of wording, or a visible warning text should fix this problem.

2. Read more-break

   In order to control what part of a long text that goes to the front page, the user has to enter a html comment into the text. A more user friendly way to control this would be great.

   For example, kan additional text entry field for the part of the text that are only to be shown on the node page.

(I'm using Drupal 4, so these issues maybe alredy are fixed in 5.)

I'm going to be skinned alive for saying this, but can we please get some sort of core asset management in place? This is a real sticky issue for a lot of people, and in terms of adoption rates, I personally think this can be filed (albeit loosely) under "usability".