Drupal 6 usability suggestions?
The Drupal 6 status update has spawned a very long thread with suggestions on how to improve the usability of Drupal. I figured I'd open up the discussion and let people post their favorite suggestions for usability improvements and aggregate them in a new thread. (Crazy strategy, I know.)
Personally, I'm mostly interested in the kind of suggestions that can still make it into Drupal 6 with the help of an aspiring developer. Many of our expert developers are already super-busy working on other improvements so let's try to come up with "simple" improvements that might inspire new developers to get their hands dirty and contribute to core.
So let's focus on smaller improvements rather than legendary tasks such as improved image handling or a full-blown WYSIWYG editor. Yes, we've heard you but it might not be the best strategy to focus on these big tasks now. Let's involve more people, and coach them to become experts that can help take on bigger tasks in future. And at the same time, let's aim to get some additional usability improvements into Drupal 6. (That doesn't imply that the bigger improvements can't make it into Drupal 6.)
And me? I'll promise to review and test your patches!
Here are some of my own suggestions that fall in the "small and simple" category. Hopefully it sets the right tone for this thread, and hopefully it avoids the obvious WYSIWYG comments ...
- Streamlined installation procedure. Remove the Drupal welcome page, and replace it by additional installation steps in the installer. The additional installation steps should query the user for basic site settings (i.e. site name, site slogan), and should provide a dedicated and simpler user interface to create the administrative user account (i.e. user #1).
- 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.
- Hierarchical page structuring. Remove the "book page" node type, and turn the book module into a module that is specialized at creating hierarchical content trees. This module will be the de facto standard to structure pages and to create hierarchical navigation schemes in Drupal.
- "Save as draft" feature. Better support for saving posts as draft. Ideal for the Drupal-bloggers amongst us.
- Module update notifications. Let Drupal tell me when a new version of a module became available. Oh, wait, dww is working on that already, but he could use some help to get it implemented in time for Drupal 6!
- 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.
- Remember anonymous comment posters. When someone leaves a comment as an anonymous user, his name, e-mail address and URL are not remembered. If we'd store that information in the user's session, he or she wouldn't have to re-enter that information every single time. A subtle but important improvement.
- 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.
- All small bits that help flatten the Drupal learning curve.
Any small annoyances left? Any subtle but important improvements that can be implemented for Drupal 6? Let's tackle some.
Remember anonymous comment posters
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
Yes, please
I think it's worth including, yes. It should be straightforward to implement -- 10 or 15 lines of code maybe? I'd think we can use sessions for both cached and non-cache pages, but let's discuss that in the issue tracker. Post a patch and share the issue number! Thanks Matt. :)
Here is the issue
Issue filed at http://drupal.org/node/141131. I am looking for feedback for cached situations and not using jQuery.
--
Matt
http://www.mattfarina.com
Auto registration
It's not just comments! The real issue is one-step registration & posting for every node type.
Here is a full spec I've prepared for the auto registration workflow - I would love if someone can implement it.
Amnon
-
Professional: Drupal Search | Drupal Israel | Web Hosting Strategies
Personal: Hitech Dolphin: Regain Simple Joy :)
+1 to auto registration
Have my own thoughts on that, some possibly even practical, but mostly this is the most important improvement for Drupal for any site that actually wants people to get hooked by the content and register when posting or replying. Note that there's a bit of a bounty for implementing this, as patch or contributed module.
benjamin, Agaric Design Collective
....
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 Topjavascript: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
...
1. Ability to have "read more" "comments" links below or *above* the teaser
The "read more" link is often hidden between other links (like taxonomy terms) but it's far more important. If we could make it easier to theme the position of the "read more" link, or if we could provide a (per-theme) configuration setting to change the position, that could make for a great core patch. I believe there is (or was) a module that attempts to do some of this. Someone should have a look at that, and try to make a core patch out of it. Ideal task to get started with Drupal development.
6. Track my posts as "My new nodes", "Nodes I commented", "My nodes that got comment"
This would make for a good tracker module improvement too. I'd support these suggestions (or a subset of them).
6. Track my posts as "My new
This would be non-trivial to implement, but it be amazing if it was possible on user/uid/track to get links to the actual comments the user made (otherwise it can be a link to an 800 comment thread they posted on). But that's really a views feature request I guess.
This is one I've wanted for
This is one I've wanted for Drupal's forum for quite a while. A common forum feature is to 'dot' topics that you've posted in. Basically, the topic icon to the left of each thread in the topic list is changed to indicate you've posted there. Typically, this is done by putting a simple dot in the middle of the icon. It's a little thing, but a nice improvement to usability.
Dot
The idea of using a dot is new to me -- but it sounds like a cool little improvement!
This works quite well!
This works quite well! http://drupal.org/project/ed_readmore
Might be good starting point!
Needs work
If you look at that module's code, you can see that it could be simplified. It's rather messy, and it's not the module's fault. So if there are ways we can make this more elegant (and less code), that would be much appreciated.
Some good ideas but...
I strongly disagree: #1 and #3 are handled by the user agent already and just add noise (even worse, *JavaScript* noise) to the page while #2 doesn't need JavaScript at all, just plain HTML (and even then doesn't belong in the core code.)
Again, should this really be done server-side? In core? Although #5 may have a use for folks who need to switch PCs a lot, it's still just a possible use of a hypothetical "web bookmarking" module.
EM
....
Not agreeing with point 3 above
The book page node acts as a good wiki ..... I wish it stays there.
Best regards
Hierarchical page structuring
I strongly believe that a hierarchical page structuring capability is a very important thing for a website, still nowaday with all that social-web tools available everywhere.
So my suggestion is to modify book module to be more customizable, so if one wants to can use it to structuring pages hierarchically.
That won't be a small
That won't be a small task.
category.module is an example of that.
I also use the book pages as
I also use the book pages as books. If extending them to accommodate hierarchial navigation means I can still use them as books then no dramas. I'll be sad if that functionality is scrapped though :P
Conversion
Dries, I know that, and largely agree with, Drupal has a policy of not carrying baggage forward. But this is one that will open a HUGE can of worms unless a full upgrade conversion is available.
There are many people whose entire website is designed around books. Just changing books will destroy their sites.
Perhaps one way to approach this possibility is to "demote" book to a contributed module and put in your new functionality. That would allow people to convert their books as they have time and energy to do so.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
I agree, keeping the
I agree, keeping the original book.module will leave books intact.
Besides, it lets people keep category.module as well.
Forward compatibility from
Forward compatibility from books should not be an issue.
Look at category_legacy. It converts books and taxonomy into its category structure.
Basically, I think a webpage.module could replace books, category, taxonomy, outline, etc.
It should provide a parent/child hierarchy of webpages that would be automatically reflected in menus
It should also allow for any other node of any type to be "embedded" or "assigned to" any webpage node (kind of like assigning nodes to terms)
i.e. merge books/outline/menu/page/taxonomy/category module functionality into a webpage module
to avoid duplication of these structures in the database
At the end, users can make "webpages" to structure their site and these webpages can "contain" anything, like views, or a bunch of stories, or images, and events, etc.
PS
There are of course WAY better ways to handle the structure problem,
but those solutions (Relationship API; making everything a node) might fall under the "legendary task category"
Also, some people have
Also, some people have suggested using an "entity" type so that nodes, categories, menu items and everything work in the same way and benefit from the same hierachy tools.
I hope it doesn't turn too complex, like the Gallery entities (gallery.menalto.com), because in G2.2 there's that situation where database crashes make random bits dissapear, which causes the need of integrity checks and repair modules.
Book purpose
Disclaimer: I am a newcomer (I don't like the word newbie). Thank you Dries for this much-needed thread.
It seems to me that Book has two purposes:
This appears to me a completely unrelated and should not be put together. I am a proponent of completely discarding Book (with a Book-to-Page/else converter in the process) and spllitting its features into three different modules:
Any input appreciated.
Outlining, collaborative
Outlining, collaborative writing, and wiki syntax are already handled by separate modules. Collaborative writing is supported through the node module, in that content can be broken into separate nodes that can be edited independently. Wiki syntax is handled through filtering, e.g. with the PEAR wiki filter module.
The book module provides outlining, which assists with collaboration by encouraging users to break content into smaller pieces. Note that this is not real-time collaboration, where authors are chatting with each other as they work. Instead it is a slower process using comments and such, more suitable for situations where authors are not all online at the same time.
So the description of book pages is a bit misleading - the primary purpose of the book module is outlining, which inherently makes collaboration more feasible, but does not do anything else to directly support collaboration.
Replacing the book module with a more general outlining module would not mean that sites using book pages would be broken - just as the story module was replaced by the CCK framework in Drupal 5, the book module can be replaced by a well-designed outlining module without compromising the book content type. Did anybody even notice that the story module disappeared in Drupal 5? Some of the issues that need to be addressed by the outlining module design are listed in the Page+Outline post: problems like rendering previous and next links onto arbitrary node pages.
One big advantage of having a de-facto standard for hierarchical outlining is node access control. It is often useful to group sites into sections that have different access rights, regardless of node type, but there is currently no good standard way to do this. Using taxonomy is confusing because a node can appear many places in the taxonomy. In Drupal 4.7, PACS was good, and even integrated with the book module for book pages, but it had to invent its own hierarchy mechanism and synchronize with the book module to make it work. If Drupal has a good outlining framework for all content types, something like PACS can be created that would be much easier to use.
What you say is exactly
What you say is exactly right. The key issue (and ultimately the only issue) regarding outlining is the idea of unified access control to different branches of the site. Taxonomy based AC is not sufficient and makes for very user unfriendly sites.
______________________
Dominik Lukes
http://www.dominiklukes.net
http://www.hermeneuticheretic.net
http://www.czechupdate.com
http://www.techwillow.com
Priorities for Drupal 6
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]
....
Excellent suggestions.
At one point of time in the recent history of web, cms-es were something "new" and showed new or breaking paths ..... but then with advent of orkut, myspace etc there has recently been nothing "new" contributed by the opensource php comm.
I fully agree with points 2 and 3 of Geddon - extremely good feedbacks.
There are OG module but it has problems unanswered for 4.7 as well as 5x versions of Drupal. And probably far more cpu resource-friendiless is needed for mass runs of this module.
Though all these are not small suggestions :-(
Best regards
Using existing modules..
My hopes were to look at the current modules (which are downloaded practically by default) and compare them to the "evolution" of the "social web" in order to determine a potential road map for future Drupal development.
This said, while they may not entirely be "small suggestions," they do currently "largely exist" as a module -- with the exception of No. 2, which should begin to be solved after the SoC '07. Still, I appreciate the feedback!
(cR)
Is it just me
or were there no actual suggestions or ideas in there?
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
Simple one
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.
solved
Um, that problem has already been solved. There is a module for 5.1 and back to deal with the issue. Future releases will have this multiple posting problem solved. See http://drupal.org/node/107358
--
Matt
http://www.mattfarina.com
But.... maybe not
The pending FAPI 3 patch from eaton and chx takes this out again (with the intention of adding it later, I think), so it is an issue worth tracking.
- Robert Douglass
-----
Lullabot | my Drupal book
Not convinced
I'm not a fan of this feature. If you clicked 'submit' you can see your browser's throbber spin or rotate. That or the browser has a progress bar to indicate that you have to wait. If every button would change to display 'please wait', the experience would become really annoying real quick, IMO.
If you watch less experience
If you watch less experience web users they tend to double click on everything because thats what they do in windows. So i think that the double submission is indeed an issue do we agree there?
As to the solution, if you think that changing the text is annoying (i tend to agree) what about just triggering the submit button to disabled onSubmit? It is much more subtle and serves the same purpose no? Alternatively we could leave the UI the same and handle the duplication on the backend by unsetting a SESSION var i think.
Agree with Dries
I feel that disabling buttons is good in theory, but bad in practice; I've occasionally had my browser (Safari) choke during the HTTP request in apps that implement this feature. It might not be very often, but it is annoying not being able to resubmit the request in that case. Just dealing with duplicate requests is a better way, in my opinion.
How about a toggle that
How about a toggle that locks the submit button to "please wait" (or alternative) and at the same time unlocks a "retry" button.
It'd be best of both worlds and might have configurable settings.
Please wait... ajax only
I do agree with Dries.
All those "Please wait" and "Loading animation" were created to give user feedback when the browser throbber stays still. So, if the page load or reloads, there is no need to add a redundant throbber in the form of a "please wait".
All these animation and "please wait" messages are most welcome for Ajax and the likes.
How about:- * don't change
How about:-
* don't change the submit button text to anything.
* disable button on submit click
* add a timer upon submit click, if timeout occurs, re-enable the submit button
This should solve the concern about browsers borking and having to re-submit a page sometimes, whilst stopping the happy double clickers.
User testing
Unfortunately I do not agree with Dries (sorry Dries) and let me first say that I am not a developer but do specialise in usability, working in this field for over 10 years. Having said, that doesn't mean what I am suggesting would be the best way to go. I could be completely off the mark. What we should all do is do some proper usability tests by getting in users of your websites and set-up the appropriate scenarios ie we should not use developers or people like myself but the actual people using the sites.
Collating this information will then give us a clear picture of what to do.
In addition, we can refer to the US based 'Researched Based Usability Guidelines 2006 section 2 - Optimizing the user experience' where it states "Users should not be required to wait for more than a few seconds for a page to load, and while waiting, users should be supplied with appropriate feedback." Furthermore, section 2-10 provides further research stating "Provide users with appropriate feedback while they are waiting.....If processing will take less than 10 seconds, use an hourglass to indicate status. If processing will take up to sixty seconds or longer, use a process indicator that shows progress toward completion. If computer processing will take over one minute, indicate this to the user and provide an auditory signal when the processing is complete."
http://usability.gov/pdfs/guidelines.html
The point that I was trying to make is that when a user clicks that submit button there is usually an element of doubt on whether they clicked that button or not and the 'processing time' can be lengthy depending on the request and the bandwidth. But using some sort of 'instant' feedback to the user will give them some level of comfort. At the moment, there is none and hence we do have duplications of posts.
also,
also,
13:11 - anticipate typical user errors
13:20 - ensure double-clicking will not cause problems
Users are impatient
Dries,
Users are, as a whole, impatient. If a computer hesitates for more than say, three seconds, they begin quadruple-clicking everything in sight in a vain attempt to get it to respond again. I have witnessed this strange behavior numerous times, and I can't fathom why it happens, but it does happen.
It's our job to protect the newb user against themselves. Education of the user cannot happen within a web app. It has to happen over time, and from people in their lives that they trust. Simple Drupal core effects like disabling the submit button once its been clicked will prohibit negative effects within the application itself, and will provide the user with a visual cluebat. After all, they're not looking at the spinning beach ball. Nor are they aware of the status progress bar. All they can see is that huge 'Submit' button that hasn't turned into a 'Your content has been created' message.
[/Senpai]
While it'd be nice to assume
While it'd be nice to assume all users actually pay attention to the throbber or progress bar, there are a few browser that, I know, don't even have a throbber by default (Safari being one of them). Though a lot of browsers do have them, taking care of the user experience by providing proper feedback is something that should be handled by the website and not the browser.
In the case of the progress bar, impatient users or inexperienced users who double-click anything that's not nailed down may actually end up clicking again before the progress bar has moved enough to get their attention; often there's a delay before the bar begins to move.
The best place, IMO, to put feedback regarding a button action is in the button itself, where we already have the user's full attention. As for exactly what to do with the button... that might take some trail and error to see what sort of thing doesn't slip by the user.
Suggestions for "small"
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
What you ask in your point 2
What you ask in your point 2 can already be done. The person submitting the node simple has to change the authorship (if they have have node admin privileges). So the change could be in adding this as a separate privilege.
Your point 6 can be fixed through admin/by-module in Drupal 5.
______________________
Dominik Lukes
http://www.dominiklukes.net
http://www.hermeneuticheretic.net
http://www.czechupdate.com
http://www.techwillow.com
With regard to 2 : yes, of
With regard to 2 : yes, of course you can change the "Contributor", but as you say, it would be best to be able to distinguish between contributor and author.
With regard to 6 : well, actually, admin-by-module doesn't influence my point. What I'd like to see, is a kind of "map" or a list of "locations" where a certain module will show its presence. Sometimes (or often if you play around with modules quite a lot) you have something called "list" or "edit" or who knows what showing up, and there is no way of knowing where that particular thing is coming from, at least not without such a map (or an elaborate readme.txt).
Ludo
More specifically about
More specifically about point 6, the admin page item for the Taxonomy module has a confusing name. 'Categories' is clear, but then the module itself should have been called 'category'.
Changing the description text so it includes the word 'taxonomy' would help.
(It actually seems to me that the designers of the taxonomy module swallowed a thesaurus -- there are far too many complex terms for what amounts to a tagging system.)
Taxonomy is more than tagging
The use of the term taxonomy is correct, just not the most familiar. From the wikipedia article:
Tagging implies a flat classification scheme, whereas taxonomies can encompass complex hierarchical relationships. However, I agree that Drupal should be more consistent now that they've changed the reference over to category.
aigeanta
remember, this is a discussion about usability
I agree,
The use of the term "taxonomy" (or "node" for that matter) is not correct from a usability perspective. From the wikipedia article:
People understand tagging/labeling and they understand categorizing, but they need to look up "taxonomy" in Wikipedia!!!
Just because Drupal "categories" work more like a "taxonomy", does not mean that we should call the categories taxonomies, anywhere, ever! (not even in the URL bar)
Simply put, when a person whants to emply the tool "Drupal" to make a website, working with "content" and "categories" is easier for them than googling for "taxonomy", "vocabulary", "term", "node", etc.
The terminology used has a lot to do with the ease by which things get done
lrstudio: From my
lrstudio: From my perspective, being someone who's studied and studies cognitive science, behavioral sciences, linguistics and usability, and works with it, I don't think that's an important issue at all. Both terms are appropriate, and since many versions, the Drupal admin pages say "categories" instead of "taxonomy". The internal name of the module is still taxonomy and it is an appropriately selected term.
What can be improved is the handbook or the help files, preferably both. They should be better at explaining each of these concepts. It's like popularizing science, it's usually a bad idea, what you gain in easing the spreading of the ideas you lose in the simplification, even the trivializing, of them. I don't want Drupal to be trivial, but powerful, and taking things down to a "simpler" level is not the way to go.
I've written an introduction to Drupal and its basic concepts (see link below), it's something I've been planning to extend into a set of tutorials. It's a kind of guide covering things that are not covered in the handbooks. People who are new to Drupal are often scared off by the concepts behind it, things like nodes and vocabularies, powerful concepts all but not properly explained in the handbooks. This is a gap in understanding, a gap I've attempted to bridge and judging from the feedback I have received many people who are new to Drupal find the tutorial useful.
http://www.jakob-persson.com/myblog/drupal_for_solid_lifeforms
--
Jakob Persson
Drupal developer, web designer and usability consultant
http://www.jakob-persson.com
People who are new to Drupal
I am thinking that you have hit the nail on the head with respect to what I am trying to get at
BUT
Simply improving documentation does NOTHING to improve usability!
It merely explains the less than "usable" state to the users ... so they can get their work done in a utilitarian manner
You may disagree, but to improve usability, the gap in understanding NEEDS to be eliminated altogether ... not bridged
I think you're confusing
I think you're confusing apples with pears, and I think your understanding of "usability" is not entirely correct.
Usability is not about simplification or making complex tools simple, look at Microsoft Windows as a server OS to see where that takes you when it comes to scalability and security. Windows as a server OS is not usable, Linux is, even though handling an application like vi takes time and reading man pages to grasp even the basic commands. A steep threshold doesn't mean that vim offers poor usability, the application is highly usable for someone who knows it well.
Would you argue that an accounting application is not usable because it requires an understanding of accounting? Should we make accounting simple or trivial by basing the application on a less powerful way of organizing a business' finances just to make it "easy to use"?
The idea that a powerful tool can be learnt intuitively or without reading any kind of manual is seductive, and attractive, but not always realistic. An application can support user learning and reveal powerful features as the user gains understanding. This is used effectively in complex applications like 3D modellering and rendering software, although crudely in that they offer beginner and expert modes. Doing it effectively requires a lot of research and planning, and an entirely new interface for managing Drupal, allowing the communicated metaphors of function to work consistently regardless of their accuracy to their actual workings.
An application can be considered an expression of how its creator/programmer envisioned it to work, as such as the interface of an application is a message in itself. The message embeds ideas and metaphors, and these may correlate to how the application works, or they may be based on a less accurate model that requires less effort on the user's part to grasp. A sliding level of fidelity in regards to how the application seems and how it works requires that the concepts work regardless of how accurate the user's understanding. In effect, a "simple" understanding must not impede the user from applying the metaphors and concepts, and doing so together, in a meaningful, powerful and useful way.
I think this can be done, it would be interesting and challenging to achieve but it is not within the scope of this forum topic.
--
Jakob Persson
Drupal developer, web designer and usability consultant
http://www.jakob-persson.com
sigh
The apples to oranges argument applies to your example
As someone who has successfully used both in Enterprise areas your statement is not applicable nor accurate. Just because someone can 'use' Windows (as in XP, etc) does not mean they can actually use, size, understand or configure Windows Server in various roles and deployments. We have a joke at work, 'everyone thinks they are a windows expert just because they can click start.'
The reality is, to use Windows or Linux in an Enterprise takes skill, knowledge and understanding of your goals.
I would now argue that your understanding of the usability of Windows is limited either the lack of your going through the steep learning curve to use the product properly. Much like my ability to use vim is limited by my disinterest in using it for more then the vary basic tasks.
Now see, this isn't what you were arguing was it? If you are going to use an example you need to pick an example that illustrates your point a little more clearly and is not based on bias or preference.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Steven, you echo my
Steven, you echo my opinion:
Exactly! This is the point I am trying to make! Just because something is simple to do doesn't mean you possess the cognitive tools to do it, it takes learning and understanding. Perhaps I didn't express it as well as I could have. My reason for using Windows Server was the kind of thinking you illustrate above, just because it's "point and click", many people draw the conclusion "it's easy". Same goes for accounting applications, without an understanding of corporate finance, it's useless, regardless of how neat it looks or how good you are at using Windows or Mac. Point is, it doesn't matter how "user friendly" your user interface is, you still need to know what you're doing - which is why I think making Drupal "simpler" and turning to a terminology that is "easier" to grasp is not the way to go.
More accessible? Yes!
Clearer? Yes!
More intuitive? Yes!
Simpler? No!
Also, speaking of terms, is there a better word for "node"? Considering there's a move towards further abstraction, users and comments becoming nodes in Drupal, finding a less abstract term gets even harder. It is, after all, the abstraction that makes Drupal shine!
There's also the aspect of support and how users think about support. I've been supporting open source software for a long time and I've noticed that some users don't get far simply because they have the wrong attitude. In order to get somewhere with Drupal you need to be inquisitive, you need to have an appetite for learning and actually sitting down and understanding how it works, otherwise you will be dependent on others for your development.
The users who don't get far, or give up quickly, are those who do not think it's worth doing some work and learning on their own, expecting to have everything served to them on a silver plate. Catering to the needs, whims and wishes of this latter group of users is not in the interest of the project - but turning them into the former group may be a worthwhile enterprise. By bridging the existing gaps in the handbooks in regards to Drupal's conceptual framework, more people would considering it worthwhile to learn and probably not be so quick to throw in the towel.
--
Jakob Persson
Drupal developer, web designer and usability consultant
http://www.jakob-persson.com
I advocate verbacious simplification
In the interests of promoting a fuller recognition of serviceability unto incidental patrons , I provide this conceptualization of distilling variegated terminology into transparent commentary. Can we please dispense with words that have pervasive meaning to twelve propellorheads in a dank cellar somewhere, and use a few surrogates that the entire world grasps within 500 milliseconds?
I'd offer to build you a six-orieled, quadruplicated pneumatic-belt circumferential support transporter with an aluminum alloy exterior skeleton, but you probably already have a car, don't you?
[/Senpai]
lol
i agree why use vague or complicated words to describe thing? I think using these types of words just shuts out or intimidates to many people and that is not the point of opensource. i believe if an apple is an apple and thats what everyone knows it by why would you try to change it besides to give yourself a personal feeling that your more advanced. Everyone knows that drupal has a learning curve a part of that is the language/ descriptions used. and as far as to what is another word for a node someone else asked above,,, well... ask yourself what is a node ? and you should have your answer ;-)
(not even in the URL
Well, in the URL bar, yes (if not for the rest too - I don't have definitive position there), because, who look at the URL? The technically-minded. And it would help increasing the use of the Right Word. Look at what happends with websites giving away free space? Publicity for their domain name. Same could go for the taxonomy word.
Re: Point 100...
... a big +1 from me!
Hear, Hear
Agreed in principle, though apart from education attempts there is not much that is practical to do.
Also some of the entries in the module listings are uninformative, along the lines of:-
"Xaybzc
Impliments the Xaybzc interface system on Drupal."
Leaving you wondering what the ! is "Xaybzc". Is it something invaluable to my website or will it be a complete and utter waste of my time trawling the net to find that "Xaybzc" is an obscure mathematical syntax evaluator for calculating impact of water preasure.
John Bryan
www.ALT2.com
Application Integration Specialists
Tel: UK 08700 3456-31
...
If a contrib modules description is unclear, please file an issue with that projects issue queue.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Caching and performance
3. ... caching and performance ...
We almost always accept patches that improve performance. I particularly enjoy reviewing patches that implement performance improvements. They jump straight to the top of my list. :)
Category module replaces the
Category module replaces the taxonomy link.
I can't recall if this is done automatically but that'd be the end result.
For point 1) you should
For point 1) you should never change any other CSS files than your THEMES style.css!
CSS is made to override previous definitions. Just find the class/id you want to change and add it to your theme stylesheet.
You never need to know about the 17+ other style sheets being used by your modules.
Also in Drupal 5 active the caching of CSS in to a single CSS file to make your site load quicker.
I would like to see some way
I would like to see some way to add theme- and module-independent css. It can be messy, I know, but it is not unmotivated.
For instance, all my pages (content!) have a particular structure, such as, let's say, a color-system for a diagram. No matter what theme I am using, the colours will be always the same.
Would be good to have a style.css valid for every page in a single site?
Not a very big deal, though.
Regards,
José San Martin
Performance for logged-in users
Regarding #4, yes, registered users don't get much benefit from caching. It's not the page generation time that kills performance but fully loading Drupal itself. I'm working on a patch to improve that: http://drupal.org/node/140218 Feedback and testing is needed! Even if you can't code, we'll need people who can review and test it. If we can get it implemented for Drupal 6 the performance benefits should be huge.
--
Larry Garfield
http://www.garfieldtech.com/blog
http://www.palantir.net
Agree with #2...kind-of
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.
I agree that there should be a way to add multiple authors more and possibly to categorize them.
More to allow better restrictions on who can edit what, or allow multiple users with the "edit own page content" restriction to edit the content.
100
Ludo, I heartily agree with #100, but doubt we'll ever see anything like that. But I have definitely seen modules that just don't tell you what they do or how.
Let's add:
101) Make it mandatory to include an Uninstall function in all modules, even if it does nothing but log a message. However, I haven't seen a module yet that shouldn't at least delete its system variables and clear the cache on uninstall.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
#6 code in Pro Drupal Development
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).
- Robert Douglass
-----
Lullabot | my Drupal book
Please look at the find_path module
See http://drupal.org/project/find_path
Works quite well for me.
Let's integrate it in core
As I said elsewhere in this thread -- most of that module, if not all of that module, should be part of core. People should not have to download and install such a module. Let's take that module, extract the good parts, clean it up a little, and add it to core.
I'm tempted to say: this module should never been created in first place, and should have been submitted as a patch for path.module to begin with ...
Path search
Here's a patch for it: http://drupal.org/node/141526 (URL aliases search form) :-D
Excellent
I just reviewed the patch. Let's work on this some more and fix this once and for all. Thanks Gurpartap. :)
Hierarchical page structuring and mass editing
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
Just go for it?
I cannot agree more with point 3. If Drupal could improve its handling of outlines, its usability would go through the roof.
Well, Dominik, just go for it. ;-)
For Informational Sites Only ?
There are are some very good points in your post, but I'm not sure if I understand all of them. For instance, I didn't understnad your comment that neither the Category module nor Outline modules would be sufficiently safe to use without core support. Without core support ?
Also, I didn't understand, "assign one taxonomy term to multiple nodes" ? Is that just a matter of integrating the Taxonomy module into the core ? The Taxonomy module is so useful that I can't imagine someone not installing it on their site.
I visited your links and we both seem to have the informational, "text" sites, as opposed to community, multimedia or commerical sites. Each type of site probably has its own set of needs and operating considerations. For informational sites, I think that the most important point is improving page structuring, which would vastly expand Drupal's usefulness for presenting information in a book-like form.
In Drupal 5, the combination of books, categories and weblinks has worked very well for me. The pages of a book pop out of the hierarchy as items in a category listing, providing something like a associative, network view of the content as well as the hierarchical view of the the book structuring. The weblinks get included in the category listing, which relieves me of the effort to creating links within the pages.
A nice feature of weblinks is that I can include them into a book hierarchy "outline". It also works with blog entries and static pages. One inconvenience is that the user has to create the content first and then assign it to an "book outline" from the list content page.
So I'm not sure, but maybe your comment about outlines was to extract the outline functions from the book and give it the status of a new node type, without the necessity of a main book page ( ? ).
I think the smooth blending of hierarchical with associative views within a consistent presentation schema is a central requirement for text sites. I think text sites also tend to wind up with several hundred nodes. I think anything to make the maintenance functions more powerful and managable is a good thing.
One difficulty I've had is with ordering items in a list for a category. To work around the lack of control per-page, I fiddle with the creation date until the item shows up in approximately the right order across several category pages. In fact, it seems to work out pretty well, as if the importance of a given item is largely independent of its importance within a particular category. Interesting, conceptually speaking ?
I would also like to see a friendlier UI for weighting in general, preferably some sort of "move up/move down" capability and let Drupal figure out what weight numbers should be.
I think in the long run it would make sense to steer toward document model standards such as DocBook, using more powerful XML document technology. There are many considerations involved in wholesale transition to XML documents, not least of which is performanace. So I'm really talking about Drupal version 7 or later.
In the meantime, maybe some sort of template manager/generator would rev up the RPMs for page structuring. It seems like their should be some simple way to integrate Smarty templates, without having to create separate theme. Is there ?
Also, I think that the eCommerce module is reaching a critical threshhold of featues and usability. As some point, maybe version 7, it will probably need enhanced 'commerce-aware' functions inside the core, particularly transaction integrity, security, the usual list of suspects.
My thoughts on the subject ... and many thanks again to all the Drupal developers for such a great CMS.
- Bill
http://www.billbreitmayer.com/home
What I meant by my comment
What I meant by my comment about Category and Outline not being safe to use because of lack of core support is more about the level of support when upgrading a site and how other modules interact with them (not anything negative about their quality as a stand-alone modules). Particularly Category has to replace some core files which is always a potential problem. I think outlining and a simple way of creating a basic hierarchical site with access rights for specific trees should be a great addition to the Drupal toolkit and would make it much more userfriendly out of the box.
______________________
Dominik Lukes
http://www.dominiklukes.net
http://www.hermeneuticheretic.net
http://www.czechupdate.com
http://www.techwillow.com
Menu module?
For my outlining needs so far, honestly, all of the "brouchureware" sites I've done I've simply added a menu item to the Primary Links menu for the node. There's a fieldset to do so right on the node add/edit page (if you have the appropriate permissions). Primary Links then becomes your page tree. If you want a sitemap view of it, then you can use the menutree module I wrote.
I'm definitely in favor of a non-menu outline module for hierarchies, but for the main site hierarchy don't short-change the existing menu module. It's quite flexible in that regard.
--
Larry Garfield
http://www.garfieldtech.com/blog
http://www.palantir.net
for 3
http://drupal.org/node/138721
http://drupal.org/node/138718
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
I'm not sure I understand
I'm not sure I understand this post but I guess it means: "here are some related issues that need to be solved as well".
...
more related in that some people are working on something there. It was in the way of additional information for those interested.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Mass editing....
I had an idea for this after I saw that actions is likely to be in core in Drupal 6. I've thought of this previously, but it required some custom code and themeing to get close.
How about a module that exposes actions within views the same way a field is exposed? Configure a table view, and then expose an action such as promote, publish, delete, or send email, change workflow, etc, etc as a field to be placed within that view?
It may require alot of configuration options, such as multiple selects for some things, or checkboxes and a submit handler for others, but I think the module could be coded in such a way that it would be possible to build a configurable mass editor without writing any code just using views and actions.
I really think this is a good approach because roughly half the work or more even, of coding the editor would be done, since it would leverage all the filtering, arguements, fields and configuration options of views.
Any thoughts? I'd love to work on it, but I'd need a full time mentor ;)
-Mike
Drop me a line.
This is, in fact, implementable using a custom 'view style' -- you could add checkboxes to each field and a submit button at the bottom/top of the list, and otherwise copy the normal 'table' style display code. The results would be a very customizable "build your own node admin screen" system.
I've got some ideas on how this could be done, and experience with both views and actions, but haven't had time to work on it myself. If you're interested, drop me a line.
--
Lullabot! | Eaton's blog | VotingAPI discussion
I am interested
I've bumped into a situation where this kind of solution could be suitable. I need to create a view where to settle the privacy status of certain nodes. It would be great to have nodes listed with checkboxes and then submit modifications. I would really like to know which is the correct approach in this case. Any ideas? Thank you.
Offer weight and location as
This issue should indeed be adressed. Making custom blocks requires just too much clicks...
tracker, checkboxes, and view nodetype controls
As a non-coder, I don't know how easy these suggestions are to implement:
-----
Charlie Lowe | cyberdash
Tips for posting to the Drupal forums
Tracker page filterable by
You can do that with the views module very easily. You could also submit a feature request to infrastructure if you want it on drupal.org itself.
views module not in core
Certainly, that can be done with the views module. I would suspect it won't happen on drupal.org any time soon given the performance overhead of the views module. But it is a usability feature that would benefit many large sites with multiple node types.
-----
Charlie Lowe | cyberdash
Tips for posting to the Drupal forums
I have to agree. It's all
I have to agree. It's all to easy to say "views module can do that very easily". We're trying to improve the out-of-the-box experience here ... in other words, don't hesitate to submit patches for the tracker module.
Check all
Is already in Drupal 5: look at the column header for the checkboxes -- checking that checkbox selects all. And highlights them, even.
--
The future is Bryght.
ahhh . . .location of checkbox
I never noticed the checkbox up there. I wonder if the normal user expectation is to find that at the bottom. That's where I would have anticipated finding it, but maybe that's because I tend to use that sort of option most in phpmyadmin, and that's where it is located. Typically, don't those checkboxes have something like "check all" beside them?
-----
Charlie Lowe | cyberdash
Tips for posting to the Drupal forums
gmail and yahoo
If you look at the gmail and yahoo mail interfaces they have one at the top.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
good point
Good point. Perhaps the way to address this in terms of usability is to make that checkbox appear above with a "select all" note beside it. Maybe put it right above the table headings.
-----
Charlie Lowe | cyberdash
Tips for posting to the Drupal forums
from memory...
I believe that was discussed and the end answer was... 'where?' and 'translating it could be very long'
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Hierarchical Structure
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
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.
couple thoughts
Your first part about suffixes and prefixes can be done with pathauto. Should it be moved to core? I think that an issue needs to be opened, a case needs to be made, someone write a patch, and see where it goes. This is a scratch your own itch environment. Someone want to scratch that itch?
jQuery won't be optional in 6. There is a lot of javascript in core such as expanding text boxes, auto complete fields, and more that are all directly tied to jQuery. Can you add something else on top? Sure can. But, if you can do it in prototype you can do it in jQuery.
There was good thought put into jQuery compared to the rest. To have a system of swappable javascript frameworks means your core work would have to be independant. It, also, removes commonality among module development. Can you imagine setting up a site with a bunch of contributed modules and they use 3 different javascript frameworks? That would be a pain. Commonality makes it a lot easier for the mass majority of users and developers.
--
Matt
http://www.mattfarina.com
Path auto in core
About point 6: Is it possible to move the Pathauto module (or add something similar) to the core?
I'd have to have another look at the pathauto module -- it's been a while since I looked at the code. Either way, there are path alias improvements that we can implement that everyone benefits from -- including pathauto module users. Not everyone will want to use the pathauto module, so it's not a good substitute for all path alias challenges. (I, for one, prefer to manually choose the path aliases on my blog entries.)
The #new links in
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
+1 Not tried them yet but: http://drupal.org/project/find_path looks like a start
Yes, please!
About that module you referenced at the bottom of your comment -- I haven't looked at it yet so I can't comment on the quality of the code, but this should be integrated in core's path.module. I'd be happy to commit such a patch. Looks like an ideal task for an aspiring core developer. :)
Patch for Drupal 6
Here's a patch for it: http://drupal.org/node/141526 (URL aliases search form)
Notification for several new comments
Does it fix the problem with being notified of all the new comments (the #new thing may only show you one new comment—although this is OK in linear mode, this is definitely in threaded mode).
Along with path aliases - a
Along with path aliases - a similar system for taxonomy terms - or alpha paging like views_alpha_pager would be a big help for free-tagging vocabularies.
Also multiple select check boxes on those pages (both before and after some kind of filtering) for bulk deletion.
I'll try to stop posting on this thread for the rest of the day now, sorry.
Suggestion for admin side
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
admin menu
I'd like to expand on this. There should be a developer menu (ie current version) and an administrator (or perhaps "editor") menu. The administrator menu would have drastically fewer options available, ie exclude anything that requires a modicum of thought or knowledge of Drupal (themes and modules for example). Content and comment administration would be good examples of items on the adminstrator menu.
Ideally someone would create an admin theme that would present the administrator's menu as friendly icons, ala Joomla (only better of course ;-) ).
At the same time, the default install would have 3 user roles: anonymous, developer (= current "authenticated"), and a third in-between one, called administrator or editor.
This makes sense to me since I suspect most Drupal sites are now developed on behalf of a client, who needs simple access to the more basic administration activities.
Small suggestion
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.
Menu Permissions
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.
+1 for menu permissions
Just thought I'd add my +1 for menu permission limits. For a project I'm working on for a non-profit, the volunteers will be entering much of the content(diff CCK content types) and I would like them to be able to add the pages to the menu structure. But I also want to make sure they don't put it in the totally wrong place.
Another possibility(or in my case a diff solution to the same problem) would be a dynamic menu entry. What I mean is a pointer to a CCK node type, and all nodes of that type would be listed. In my case we would be adding/dropping projects every once in a while. It would be great if as we go along the menu structure would also reflect these updates as we add new project nodes.
Of course, I'd be happy to hear that the menu rewrite already done for Ver 6 already includes both ideas :-)
-------------------
http://www.PrivacyDigest.com/ News from the Privacy Front
http://www.SunflowerChildren.org/ Helping children around the world
+2 for menu permissions
I use drupal as a cms for corporate clients to whom I provide limited access.
I would like them to be able to provide them with the ability to create pages and allocate them to a menu stream, but as above, this also gives them access to the menu settings page, which is more control than they would need to have and could possibly have bad repercussions should they mess around with these settings.
Greater flexibility in Menu permissions would be a great step forward for the Drupal CMS, and I imagine rather straight forward to implement.
Thanks!
Interesting idea
I think this is part of the larger "make it easier to structure your site" discussion. It's far too difficult to setup a Drupal website with some hierarchical pages and a simple permission scheme to protect some of these pages. It's possible to do all that with the help of contributed modules, but it takes too many steps, research and fighting with contributed modules. So, yes, you nailed it. We have to make this a lot easier. Frankly, it's at the basis of what they call "content management" ... go figure.
In fact, it's exactly why I suggested to massage the book module into a module that let you build hierarchical navigation trees. A permission scheme could be a straightforward but popular extension. Either way, I think that step #1 would be to work on the proposed book module improvements as that is going to (re-)define how you organize pages in menus. Then, in step #2, we can worry about permission schemes.