[drupal-devel] A collection of usability problems
I tried to identify a number of usability problems based on the comments in http://drupal.org/node/31896. Creating a static brochure site with Drupal is extremely relevant; not only because some people create static Drupal sites, but mainly because even the most dynamic Drupal site has static content (eg. almost every site has an about page, a contact form, etc). Problem #1: people find it hard to integrate pages in the navigation structure. No one mentioned they were using core's menu module to setup a site's navigation structure. Strange? Maybe. Either way, it begs the question: do we need to improve the menu module? Problem #2: many people use the book.module to create structure. The book.module is a logical choice <strong>if and only if</strong> you know Drupal. If you're new to Drupal, creating structure using the book module is not exactly logical. The underlying problem is that people need a way to link pages and to create structure. Simply renaming the book.module to outline.module or structure.module and dropping the book node type might come a long way for new users, and might help focus development efforts. Problem #3: many people use the menu on the fly module (menu_otf) to add pages to the navigation menu. The good news is that Drupal 4.7 will have menu_otf functionality built in. Problem #4: you have to go to the theme system options, to add a page to the main navigation menu. For new people, this is (i) not logical because creating links has nothing to do with the look and feel of your site, and (ii) the options are nearly impossible to find. The solution is to integrate this with the menu system, so you can link pages in the main navigation menu using the menu on the fly module. I pushed Adrian to work on this, but we never managed to complete that work. I'm convinced this is an important change; we need someone to pick up this work. Problem #5: some people want to disable the author information and submission date. I see two problems with this: (i) you can't disable them on a per-node basis so people are forced to use two different node types, and (ii) the configuration option to disable this information is almost impossible to find. To fix (i), I suggest creating per node options to control some of the visibility settings. The settings would be available in a collapsible form element on the node submission page. Example toggles include (but are not limited to): display author name, display publication date, display taxonomy terms, display user picture, display 'read more'- link, etc. Problem #6: quite some people use the front page module. I've never used the front page module but I'd like to know how it is different from a static page? The key difference I see is that you ca have a different front page for anonymous users. If that is the only key difference, why aren't people using static pages? Something is wrong here, and I'd like to figure out what. Maybe some people volunteer to fix some of these problem? If not, maybe we can incorporate them in the usability task list Ber and Kieran have been creating? -- Dries Buytaert :: http://www.buytaert.net/
Problem #2: many people use the book.module to create structure. The book.module is a logical choice <strong>if and only if</strong> you know Drupal. If you're new to Drupal, creating structure using the book module is not exactly logical. The underlying problem is that people need a way to link pages and to create structure. Simply renaming the book.module to outline.module or structure.module and dropping the book node type might come a long way for new users, and might help focus development efforts.
This was suggested before, and it would be a good improvement IMHO. Outline module is the way to go! Goba
On 23 Sep 2005, at 10:44, Gabor Hojtsy wrote:
Problem #2: many people use the book.module to create structure. The book.module is a logical choice <strong>if and only if</strong> you know Drupal. If you're new to Drupal, creating structure using the book module is not exactly logical. The underlying problem is that people need a way to link pages and to create structure. Simply renaming the book.module to outline.module or structure.module and dropping the book node type might come a long way for new users, and might help focus development efforts.
This was suggested before, and it would be a good improvement IMHO. Outline module is the way to go!
There was consensus but the problem was that it requires the book node type to be dropped. This breaks some people's workflow / permission scheme. -- Dries Buytaert :: http://www.buytaert.net/
On 23-Sep-05, at 4:51 AM, Dries Buytaert wrote:
On 23 Sep 2005, at 10:44, Gabor Hojtsy wrote:
Problem #2: many people use the book.module to create structure. The book.module is a logical choice <strong>if and only if</strong> you know Drupal. If you're new to Drupal, creating structure using the book module is not exactly logical. The underlying problem is that people need a way to link pages and to create structure. Simply renaming the book.module to outline.module or structure.module and dropping the book node type might come a long way for new users, and might help focus development efforts.
This was suggested before, and it would be a good improvement IMHO. Outline module is the way to go!
There was consensus but the problem was that it requires the book node type to be dropped. This breaks some people's workflow / permission scheme.
I don't think there's any reason you'd *have* to drop book.module - it could become another "simple node type" - to maintain backwards compatibility (what? what's that?) ... but breaking out an outline.module still makes sense to me (yes, as we discussed i think first in February?). The thing is the "online handbook" idea has attracted a lot of drupal users... but a generalized outliner would as well (that would still, of course, be used for book organization). -- James Walker :: http://walkah.net/
Hoo, not too fast. Let us not rush too fast and fix usability issues here, yet break them elsewhere. I will deal with this issue in my pres/discussion on drupalCON A'dam, about the relations. The ultimate goal of relations is to get rid of books (harharhar). Nah, the ultimate goal is to allow simple hierarchies and relations out-of-the-box. And to allow contribs to do harder stuff. But this issue goes far further then 'just fix a usability issue'. it really needs a lot of thought, ideas and tests, IMO. not a simple 'yea, rename books to outliner'. That will not solve anything.
On 23 Sep 2005, at 15:05, Bèr Kessels wrote:
But this issue goes far further then 'just fix a usability issue'. it really needs a lot of thought, ideas and tests, IMO. not a simple 'yea, rename books to outliner'. That will not solve anything.
Care to explain why it wouldn't solve anything? IMO, having a more desprective module name does make a difference for new users. -- Dries Buytaert :: http://www.buytaert.net/
But this issue goes far further then 'just fix a usability issue'. it needs a lot of thought, ideas and tests, IMO. not a simple 'yea, to outliner'. That will not solve anything.
Care to explain why it wouldn't solve anything? IMO, having a more desprective module name does make a difference for new users.
For what it's worth, I think "outliner" is an absolutely horrible name. An "outliner" software *means* something, and they'll expect the usage of that name to mean what they expect (which is why "category" was such a horrible choice for "taxonomy") - it'd be like an OPML editor (like Dave Winer's) or OmniOutliner. If you'd like to try out a crossplatform (Java) opensource outliner, that mimicks what people expect an "outliner" will do, check out the screens here: http://outliner.sourceforge.net/. In short, our book.module is absolutely nothing like an outliner. An outliner needs to be *quick*. Our book module requires about 3 million more clicks than an outliner-expectant user is going to put up with. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
For what it's worth, I think "outliner" is an absolutely horrible name. An "outliner" software *means* something, and they'll expect the usage of that name to mean what they expect (which is why "category" was such a horrible choice for "taxonomy") - it'd be like an OPML editor (like Dave Winer's) or OmniOutliner. If you'd like to try out a crossplatform (Java) opensource outliner, that mimicks what people expect an "outliner" will do, check out the screens here: http://outliner.sourceforge.net/.
In short, our book.module is absolutely nothing like an outliner. An outliner needs to be *quick*. Our book module requires about 3 million more clicks than an outliner-expectant user is going to put up with.
Of course the renaming should be companied with reworking of the UI, introducing better outlinging functionality. The potential is in there, but the interaction patterns are not fortunate... It is not suitable now for non-geeks even to author books effectively (I know I have been preparing an S5 slideshow with book module these past days :). Goba
On Friday 23 September 2005 16:21, Gabor Hojtsy wrote:
Of course the renaming should be companied with reworking of the UI, introducing better outlinging functionality. The potential is in there, but the interaction patterns are not fortunate... It is not suitable now for non-geeks even to author books effectively (I know I have been preparing an S5 slideshow with book module these past days :).
Again, lets not hurry this. I plan to get this discussed in the relations system talks. It would really be a pity to see book module being rewritten in Yet Another Hierarchy System (the fourth for core?) while we are preparing to solve this for once and for all. in a general way.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23 Sep 2005, at 3:15 PM, Morbus Iff wrote:
In short, our book.module is absolutely nothing like an outliner. An outliner needs to be *quick*. Our book module requires about 3 million more clicks than an outliner-expectant user is going to put up with.
I agree with this stance. Our book.module is nowhere near an outliner yet. Simply renaming it will not be enough. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDNCaFgegMqdGlkasRAonaAKCrqQVrmth4i3knf46mDwv4o2ccngCgun/8 pruUzW3YRb3ENFphe52m4Rc= =6Wrk -----END PGP SIGNATURE-----
On Friday 23 September 2005 15:07, Dries Buytaert wrote:
Care to explain why it wouldn't solve anything? IMO, having a more desprective module name does make a difference for new users.
Book module does what its name suggests: it allows you to chapterise (is that a word?) a long set of articles. It /can/ be used as outliner. Somehow but it certainly IS not an outliner. And I keep on chanting my mantra: "it is not about the name, it is about what the interface and system communicates to the users" Hell, I as a Dutchy would think funny things are happening at flickr. I would have no idea what delicious is about (cake, recepies, h0t Ch1xx). nor what an orkut is. And what does the name RSS/RDF learn me? Nothing. Yet everyone seems to know what its about. The /name/ is but a small, if not tiny, part of the whole communication. Simply changing the name will make hardly any difference. For example: did we see a decrease in the amout of rants about taxonomy being so hard now that it is called classification? I certainly see no less confused people in this area. Greets, Bèr 'calling your bike a Mercedes does not make it a car' Kessels
Problem #2: many people use the book.module to create structure. The book.module is a logical choice <strong>if and only if</strong> you know Drupal. If you're new to Drupal, creating structure using the book module is not exactly logical. The underlying problem is that people need a way to link pages and to create structure. Simply renaming the book.module to outline.module or structure.module and dropping the book node type might come a long way for new users, and might help focus development efforts.
This was suggested before, and it would be a good improvement IMHO. Outline module is the way to go!
There was consensus but the problem was that it requires the book node type to be dropped. This breaks some people's workflow / permission scheme.
I don't think there's any reason you'd *have* to drop book.module - it could become another "simple node type" - to maintain backwards compatibility (what? what's that?) ... but breaking out an outline.module still makes sense to me (yes, as we discussed i think first in February?).
The thing is the "online handbook" idea has attracted a lot of drupal users... but a generalized outliner would as well (that would still, of course, be used for book organization).
Well, now there are suggestions to let any node type go into forums, let any node type go into books (generalize it as an outliner.module without a node type), the page node is quite irrelevant now, etc. A movement to have different display modules (outline, taxonomy, forum, archive, etc) and different node types (story, page, book page, etc) separately is not new. Since stripping off functionality from book pages and forums, what is left is basically a story type of node (really just a basic node), what we need is a simple interface to replicate this node type under any name desired. I have posted code which does so on a programming level, and as far as I have seen (although I only took some cursory look at that), chx was working on some functionality to provide "multiply and rename story" functionality into Drupal core, which should have an issue on drupal.org, if I am not mistaken. Goba
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23 Sep 2005, at 10:44 AM, Gabor Hojtsy wrote:
This was suggested before, and it would be a good improvement IMHO. Outline module is the way to go!
I would like to see book.module be replaced/reimplemented with the general node relationship API that is in development. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDNCXogegMqdGlkasRAgq8AKCml8R8DQiU2FTpeCe2/Hiv4GVHPwCgxb/g fcvOt9vZo+SAe8Mvabyv0Mo= =QYDS -----END PGP SIGNATURE-----
On Friday 23 September 2005 10:23, Dries Buytaert wrote:
Maybe some people volunteer to fix some of these problem? If not, maybe we can incorporate them in the usability task list Ber and Kieran have been creating?
I am very much for this approach. Some of your issues have simple solutions others not. And some even need discussion and agreement before being coded. I will take care of this and get them online in the todolist. Which raises another issue: dogfood. I now use openusability.org, more as a test. And I am very much impressed by the ease of use (usability, huh?) of its task manager. How can we get this on drupal.org? Should we split these tasks out to openusa bility, instead of keeping them inside drupals issue tracker? Beware that there are like hundreds of isseus that somehow tough usability sitting stale in our issues. We really need to do something about this, for just adding new entries, will not help. I am sure they will drown within no time. Think of that small/silly wrapper thing to get HTML out of core and get more unity in the presented HTML. this was agreed upon on the HIG meetings in antwerp. Yet where is it? it has been in the patch queue for months, yet still nothing there. Ber
On 23-Sep-05, at 4:23 AM, Dries Buytaert wrote:
I tried to identify a number of usability problems based on the comments in http://drupal.org/node/31896.
Creating a static brochure site with Drupal is extremely relevant; not only because some people create static Drupal sites, but mainly because even the most dynamic Drupal site has static content (eg. almost every site has an about page, a contact form, etc).
Problem #1: people find it hard to integrate pages in the navigation structure. No one mentioned they were using core's menu module to setup a site's navigation structure. Strange? Maybe. Either way, it begs the question: do we need to improve the menu module?
I think the menu_otf integration should help - perhaps make menu.module enabled by default? I know I sometimes forget about it...
Problem #2: many people use the book.module to create structure. The book.module is a logical choice <strong>if and only if</strong> you know Drupal. If you're new to Drupal, creating structure using the book module is not exactly logical. The underlying problem is that people need a way to link pages and to create structure. Simply renaming the book.module to outline.module or structure.module and dropping the book node type might come a long way for new users, and might help focus development efforts.
see my previous comments... but +1 for outline.module (that's all OPML enabled by default - just to be fully on that bandwagon)
Problem #3: many people use the menu on the fly module (menu_otf) to add pages to the navigation menu. The good news is that Drupal 4.7 will have menu_otf functionality built in.
ayup.
Problem #4: you have to go to the theme system options, to add a page to the main navigation menu. For new people, this is (i) not logical because creating links has nothing to do with the look and feel of your site, and (ii) the options are nearly impossible to find. The solution is to integrate this with the menu system, so you can link pages in the main navigation menu using the menu on the fly module. I pushed Adrian to work on this, but we never managed to complete that work. I'm convinced this is an important change; we need someone to pick up this work.
yeah - what happened to this? wasn't it Ber? or Adrian? or...
Problem #5: some people want to disable the author information and submission date. I see two problems with this: (i) you can't disable them on a per-node basis so people are forced to use two different node types, and (ii) the configuration option to disable this information is almost impossible to find. To fix (i), I suggest creating per node options to control some of the visibility settings. The settings would be available in a collapsible form element on the node submission page. Example toggles include (but are not limited to): display author name, display publication date, display taxonomy terms, display user picture, display 'read more'- link, etc.
+1 - although - is this gonna be an "administer nodes" only type thing?
Problem #6: quite some people use the front page module. I've never used the front page module but I'd like to know how it is different from a static page? The key difference I see is that you ca have a different front page for anonymous users. If that is the only key difference, why aren't people using static pages? Something is wrong here, and I'd like to figure out what.
dunno.
Maybe some people volunteer to fix some of these problem? If not, maybe we can incorporate them in the usability task list Ber and Kieran have been creating?
well, I'm *sure* someone will beat me to it... but if nobody does - I'll give it a shot in early October :P -- James Walker :: http://walkah.net/
Regarding the outline/book debate, I think there is a related problem which may help to improve Drupal for static sites (and for dinamic ones also). It's a pattern that I always find after showing to Drupal to new admin users: they always ask "where is the backoffice". It's as they seem to need a place where all the content is stored and accesible, separated from the layout of the site. Now we have "content" (admin/node), but it's something that, at least "my" users, don't like very much, or don't pay much attention to, I think because of its usability (or lack of). Maybe admin/node would need to show the contents of they site more visually? (by visually meaning easier to filter certain content type - now you have to do 3 clicks to list the "page" content type, for example, and that means that some basic admin users may never know that they have the abbility to list the content in their sites). So the conclusion would be, from my experience point of view: * identify more clearly when you are in the admin area (as CivicSpace does, and as have been commented here previously) * make it easier for an admin to identify which content is in his site álvaro -- wwww > http://the-cocktail.com blog > http://www.furilo.com
On 23 Sep 2005, at 15:12, Álvaro Ortiz wrote:
* identify more clearly when you are in the admin area (as CivicSpace does, and as have been commented here previously)
This is a theme system issue. In your _page template, simple use: if (arg(0) == 'admin') { // load admin stylesheet } else { // load normal stylesheet } If someone cooks up a patch which changes one or more core themes to introduce some visual distinction between admin and user mode, I'd be happy to commit that. The differences don't have to be disruptive. Just changing the background color would probably be a small but helpful change.
* make it easier for an admin to identify which content is in his site
Could you try to be a little more concrete? How exactly would you like to see admin/content improved? I'm not sure I understood your explanation. -- Dries Buytaert :: http://www.buytaert.net/
On Friday 23 September 2005 16:48, Dries Buytaert wrote:
If someone cooks up a patch which changes one or more core themes to introduce some visual distinction between admin and user mode, I'd be happy to commit that. The differences don't have to be disruptive. Just changing the background color would probably be a small but helpful change.
Theres more admin then admin. this too needs carefull thought, proper testing and proably some discussion too. The closest to a solution we came now, is a sections (-alike) system with copypastable 'profiles'. Think them as advanced regexps like you paste in your blokcs admin. Really, making ONLY admin appear different is just plain horrible. It only confuses people. I have tested this with three clients, all three went like 'WTF is happening? Why is foo different but not bar (node/*/edit), user/*/edit etc'. And all three were not just confused, they were actually very very annoyed that they 'got lost' all the time. Carefully selected profiles help a lot. Thus to make sure that everything a user thinks/feels like it is administrating, looks like an admin theme. Not just a small part of what he/she thinks is administrating. A lot of roles might suddenly find only one or two pages to look different. Ber 'Big changes need more then a few lines of code' Kessels.
Really, making ONLY admin appear different is just plain horrible. It only confuses people.
Ber, this is _exactly_ what CivicSpace does and _many_ people have expressed that they like it better. Don't ignore the facts. For many it will be an improvement, for others it won't. When you say it is 'plain horrible', you're clearly exaggerating. It doesn't help this discussion. -- Dries Buytaert :: http://www.buytaert.net/
On Fri, 23 Sep 2005, Dries Buytaert wrote:
Really, making ONLY admin appear different is just plain horrible. It only confuses people.
Ber, this is _exactly_ what CivicSpace does and _many_ people have expressed that they like it better.
better != good.
Don't ignore the facts. For many it will be an improvement, for others it won't. When you say it is 'plain horrible', you're clearly exaggerating. It doesn't help this discussion.
I think it does help. Extending the regexp to also cover node/*/edit and user/*/edit can't be that hard. Cheers, Gerhard
On 23 Sep 2005, at 22:52, Gerhard Killesreiter wrote:
Really, making ONLY admin appear different is just plain horrible. It only confuses people.
Ber, this is _exactly_ what CivicSpace does and _many_ people have expressed that they like it better.
better != good.
Eum, so better = bad? -- Dries Buytaert :: http://www.buytaert.net/
On Fri, 23 Sep 2005, Dries Buytaert wrote:
On 23 Sep 2005, at 22:52, Gerhard Killesreiter wrote:
Really, making ONLY admin appear different is just plain horrible. It only confuses people.
Ber, this is _exactly_ what CivicSpace does and _many_ people have expressed that they like it better.
better != good.
Eum, so better = bad?
Yes, a half-assed "solution" is probably rather harm- than helpfull. "Everybody" will think "we did somthing about this" and stop worrying. It is really very similar to renaming the taxonomy menu item "categories". it is "user friendly" now. ;-> The underlying code and the UI hasn't changed a bit and that is where the real solution needs to be. When somebody submits a patch you always expect them to be complete, too. Don't lower your standards for UI. Cheers, Gerhard
* Dries Buytaert [2005-09-23 17:04]:
On 23 Sep 2005, at 22:52, Gerhard Killesreiter wrote:
Really, making ONLY admin appear different is just plain horrible. It only confuses people.
Ber, this is _exactly_ what CivicSpace does and _many_ people have expressed that they like it better.
better != good.
Eum, so better = bad?
I think Ber might have meant only catching pages with the simple admin/* regexp. That indeed would be confusing since not all admin functions are caught by that and it would appear random to a user. It pretty clearly needs to be an all or nothing decision I would think. But I shouldn't speak for him, he may be on the "integrated admin functions" side of the (long-running) debate. -- ________________________________ toddgrimason*todd[ at ]slack.net
better != good.
Eum, so better = bad?
I think Ber might have meant only catching pages with the simple admin/* regexp. That indeed would be confusing since not all admin functions are caught by that and it would appear random to a user. It pretty clearly needs to be an all or nothing decision I would think.
So what doe you mean with an 'all or nothing decision'? What exactly does that mean in terms of what pages to theme differently? If I give you 2 months to think about this problem, will you be able to come up with a perfect solution? No, you won't. There is no perfect solution. Due to Drupal's highly dynamic nature, the distinction between user-mode and admin-mode will remain blurry, regardless of the regex you throw at this. That, and it is often a matter of preference. -- Dries Buytaert :: http://www.buytaert.net/
* Dries Buytaert [2005-09-23 17:24]:
better != good.
Eum, so better = bad?
I think Ber might have meant only catching pages with the simple admin/* regexp. That indeed would be confusing since not all admin functions are caught by that and it would appear random to a user. It pretty clearly needs to be an all or nothing decision I would think.
So what doe you mean with an 'all or nothing decision'? What exactly does that mean in terms of what pages to theme differently?
If I give you 2 months to think about this problem, will you be able to come up with a perfect solution? No, you won't. There is no perfect solution. Due to Drupal's highly dynamic nature, the distinction between user-mode and admin-mode will remain blurry, regardless of the regex you throw at this. That, and it is often a matter of preference.
Well of course you're right, there's no perfect solution that will please everyone. I don't use many of the features so I'm probably less aware of things that wouldn't clearly seem like 'admin' features. At one level it's somewhat of an HTML problem, as the biggest issue I've seen with the integrated admin is page designs that don't play well with all the form field machinery used in editing. So looking at it from this angle it's more of a design issue than functional/code one. Another view is that you can't have an optimal editing/admin UI when you're sharing the page with the optimal layout/design for viewing the site. As you rightfully point out, this is an almost infinite spectrum though due to the hazy line between the two in lots of Drupal's functionality. Perhaps that haziness more or less forces the decision to the way it is now (integrated). I've not seen how Civicspace does it so can't comment on that, maybe I'll set it up and take a look. But again, it's not like no other systems out there have a separate 'backend'; in fact that's more common in my experience and Drupal's the exception. Have you not found that? I do think this is one drawback of the swiss army knife approach; clearly it's a workable one for enough people though (including myself by and large). -- ________________________________ toddgrimason*todd[ at ]slack.net
On Friday 23 September 2005 04:18 pm, Dries Buytaert wrote:
I think Ber might have meant only catching pages with the simple admin/* regexp. That indeed would be confusing since not all admin functions are caught by that and it would appear random to a user. It pretty clearly needs to be an all or nothing decision I would think.
So what doe you mean with an 'all or nothing decision'? What exactly does that mean in terms of what pages to theme differently?
If I give you 2 months to think about this problem, will you be able to come up with a perfect solution? No, you won't. There is no perfect solution. Due to Drupal's highly dynamic nature, the distinction between user-mode and admin-mode will remain blurry, regardless of the regex you throw at this. That, and it is often a matter of preference.
Which is why I'm not wild about admin-only themes. As an option perhaps, but definitely not as the only/standard way of doing it. Is editing a node administrative? What if it's your own node? Someone else's? Will the theme sometimes change and sometimes not? How drastically does the theme change? WordPress, for instance, has all of its administrivia physically separate from the user site, so having a dedicated admin theme makes perfect sense. Drupal's functionality is not even split into "admin" and "user" in the first place. We have different roles with varying levels of access and control. There is no clean place to split admin and non-admin, unless we completely reorganize the entire system. Of course, then we'd lose most of the power of Drupal and turn into Mambo. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
definitely not as the only/standard way of doing it. Is editing a node administrative? What if it's your own node? Someone else's? Will the theme sometimes change and sometimes not? How drastically does the theme change?
I would not discuss if editing a node is administrative, but I think we all can agree is that editing a node is something that happens in a not public environment - I think this is the criteria that should guide the decisions: * actions that are private happens in a private environment. This way, the user is not confused in terms like "anyone can edit this?", always knows when he's editing something. Moreover, I would think in making into core something like workplace.module: when I user logs into his account, he has an overview of all ot its "things" in the system (as WordPress or MT or many others "CMSs" do). * actions that are public, like posting comments, keep in the public area. Surely we will find actions that are not clear if they are public or private. Posting a forum topic is private but its comments are public? But its a start an a solid criteria, that, moreover, I think its a pattern that shows in many many other tools.
WordPress, for instance, has all of its administrivia physically separate from the user site, so having a dedicated admin theme makes perfect sense.
What does "physically" mean? An URL change only? Some corporate CMSs have the backend and the frontend in two different IPs in two different network interfaces (so that the backend one can be in an VPN with secure access): that's physically :) If the URL change is the only concern, I would not worry because the user doesn't mind if he's on admin* or *edit*. cheers, álvaro -- wwww > http://www.the-cocktail.com blog > http://www.furilo.com
On Saturday 24 September 2005 03:42 am, Álvaro Ortiz wrote:
WordPress, for instance, has all of its administrivia physically separate from the user site, so having a dedicated admin theme makes perfect sense.
What does "physically" mean? An URL change only? Some corporate CMSs have the backend and the frontend in two different IPs in two different network interfaces (so that the backend one can be in an VPN with secure access): that's physically :)
If the URL change is the only concern, I would not worry because the user doesn't mind if he's on admin* or *edit*.
By "physically", I mean both the URL and structurally. The "admin" portion of the site is completely different than the main area. There are no sidebars or blocks. The footer is different. There are different hooks in the system. It's blisteringly obvious when someone is in the "admin" part of the site in WordPress. An admin theme there reinforces that. There is no clearly binary "You're in admin or not" for Drupal, and frankly I don't think there needs to be or should be. An admin-only theme doesn't really work unless you have clean separation between admin and non-admin. And if we're defining admin based on URL patterns only, then you can do that now. The section module lets you throw an arbitrary theme at admin/*, or node/*/edit already. If someone wants an admin theme, that's the way to do it. There's no need for an extra set of features to support it. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
And if we're defining admin based on URL patterns only, then you can do that now. The section module lets you throw an arbitrary theme at admin/*, or node/*/edit already. If someone wants an admin theme, that's the way to do it. There's no need for an extra set of features to support it.
I think the point being discussed is what default configuration offers the best out-of-the-box experience. Having to de-activate sidebars and every block I add to my site for the admin pages in every site I set up is not a good out-of-the-box experience. álvaro
If you pick up any book on usability it tells you first off how to navigate around opinion based design. I generally stay out of these usability debates because that's all they are. We have a working solution in the Drupal community to endless debate. I think all you have to do is look at what happened on the documentation team. We spent months and hundreds and hundreds of emails debating what should be done. In the end, we did three research exercises and then made some decisions. 1) We conducted in person interviews. 2) We did a broad based survey. 3) We conducted a usability exercise. With research, the debate ended. This lead to the creation of http://drupal.org/handbook/modules and the re-organization of the handbook here: http://drupal.org/handbooks So if you are serious about improving usability, then please help with research. Here are the questions for newbie Drupal administrators: Drupal administration 1)How would you describe yourself as a Drupal administrator? Which version of Drupal do you run? What additional modules/themes do you use? 2) How often do you use Drupal administration? How long do you administer your site? 3) Can you access your Drupal administration menus?(warm up question) 4) What are the most common tasks you do with your site as an administrator? What other tasks do you do less frequently?(Write both answers down as a list in order) 5) Which of the common tasks you mentioned earlier are easy to do? Why are they easy? (Get into detail) 6) Which tasks are hard? Why are those tasks hard?(Go into detail) 7) How about other important tasks you have not mentioned? 8) What is the one thing that would make your job as a Drupal administrator easier? Review your interpretations. Cheers, Kieran
On Friday 23 September 2005 22:50, Dries Buytaert wrote:
Really, making ONLY admin appear different is just plain horrible. It only confuses people.
Ber, this is _exactly_ what CivicSpace does and _many_ people have expressed that they like it better. Don't ignore the facts. For many it will be an improvement, for others it won't. When you say it is 'plain horrible', you're clearly exaggerating. It doesn't help this discussion.
Allright. Sorry for my too strong language. Anyway. I feel that we must go for a proper solution. Just putting /admin to an admin theme is a half arsed attempt. Adding /node/*/edit is even a haf arseder attempt, for alll the forum implementation (edit your own site) handbook systems (edit your own handbook) will break. Why i used suc strong language is that wqe must think this over better. Not go for a solution that will help a few ppl. But leaves all the others on the cold. PLease, I beg alll people to think about the implication of such a choice. Ber
Additionally, since I designed and implemented this feature, you can extend it however you want -- to include or exclude any pages you want, simply by changing one or two lines of code. If your customers are confused by the admin section looking different from the node editing pages, all you have to do is change the test that looks for /admin in the directory name or also include /node/*/edit. And yes, I agree with Dries -- hyperbole doesn't help. There are people who will come down on both sides of the issue; if you don't like it, don't use it! For those who want to use it and appreciate the separation between site-level admin tasks and community-centric tasks, it is a huge benefit, not the least of which helps themers focus on the front end of the site knowing that the admin area will be consistent (and able to be documented) between sites. Chris On 9/23/05, Dries Buytaert <dries.buytaert@gmail.com> wrote:
Really, making ONLY admin appear different is just plain horrible. It only confuses people.
Ber, this is _exactly_ what CivicSpace does and _many_ people have expressed that they like it better. Don't ignore the facts. For many it will be an improvement, for others it won't. When you say it is 'plain horrible', you're clearly exaggerating. It doesn't help this discussion.
-- Dries Buytaert :: http://www.buytaert.net/
On Monday 26 September 2005 22:37, Chris Messina wrote:
If your customers are confused by the admin section looking different from the node editing pages, all you have to do is change the test that looks for /admin in the directory name or also include /node/*/edit.
So, you are saying: if you don't like foo, open up your texteditor and change the sourcecode? Weren't you the one that was so extrmely against enforcing any kind of programming on users? Bèr
On Tuesday 27 September 2005 03:40 am, Bèr Kessels wrote:
On Monday 26 September 2005 22:37, Chris Messina wrote:
If your customers are confused by the admin section looking different from the node editing pages, all you have to do is change the test that looks for /admin in the directory name or also include /node/*/edit.
So, you are saying: if you don't like foo, open up your texteditor and change the sourcecode?
Weren't you the one that was so extrmely against enforcing any kind of programming on users?
Heavens no. An admin theme that requires code editing to remove would be insanely bad. :-) If we're dead-set on shipping an admin theme (something I still oppose), then the easiest and most "correct" way would be to move section.module into core (I'll try to get my patch posted tonight, really!) and ship with two sections defined: admin/* and node/*/edit, both of which use some alternate theme but default to OFF. Then in the instructions somewhere say "If you want to use the default admin theme, go to the sections page and enable those two. Or change them to suit your fancy." We still maintain the default behavior of not confusing people with a "randomly" changing theme, but those who want a standard admin theme have it a few clicks away and those who want to customize the admin theme definition can do so without leaving the admin section. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 9/27/05, Larry Garfield <larry@garfieldtech.com> wrote:
On Tuesday 27 September 2005 03:40 am, Bèr Kessels wrote:
On Monday 26 September 2005 22:37, Chris Messina wrote:
If your customers are confused by the admin section looking different from the node editing pages, all you have to do is change the test that looks for /admin in the directory name or also include /node/*/edit.
So, you are saying: if you don't like foo, open up your texteditor and change the sourcecode?
Weren't you the one that was so extrmely against enforcing any kind of programming on users?
Heavens no. An admin theme that requires code editing to remove would be insanely bad. :-)
The point is not to force people to edit code. What I was saying was that you can edit the code *for now* until a UI is developed to determine which sections of *your site* belong inside or outside of the admin area. This has been my proposal all along and I'm rather tired of rehashing this discussion. We decided last March to separate out the admin section of Drupal to use a consistent theme (http://lists.drupal.org/archives/drupal-devel/2005-03/msg01249.html). Little action has happened to get this into core. I'm not advocating that Drupal dictate what is or isn't admin -- only that there exist a UI that allows you to determine what functionality should be part of the site "control panel" that looks consistent between Drupal sites (or can be overriden at the theme level). I wrote code for CivicSpace to do this because in the CivicSpace distro, it always made sense to have an admin section that didn't include the node edit pages (since that was decided to be a community function instead of an admin function). I noticed that there is another thread on the mailing list about this topic, so I'm going to go check that out, but I would appreciate it if you would characterize my proposals in view of the history of my advocacy -- not in view of one simple email written quickly. Obviously I don't advocate for UIs that exist only in the code. But as it is, Drupal is still far too code-centric. Consider the fact that there is still not a decent built-in theme editor in Drupal. If you want to pick on code-centric UI issue, tackle that one. Chris
If someone cooks up a patch which changes one or more core themes to introduce some visual distinction between admin and user mode, I'd be happy to commit that. The differences don't have to be disruptive. Just changing the background color would probably be a small but helpful change.
For one of my Drupal sites I use a different stylesheet with slight changes: * fixed column width to a liquid design, so large tables (ecommerce ones, ie) fit without overlapping the columns. * a simplified header
Could you try to be a little more concrete? How exactly would you like to see admin/content improved? I'm not sure I understood your explanation.
Here's a sketch: http://furilo.com/drupal/DRU-HCI-admin-content-01-out.png (a continiustic approach, as I mean not to propose big changes) Comments: * Quick stats (or call it whatever you like, its a quick sketch, haven't entered into much detaill): the total number of nodes and comments (I know comments don't belong here, but a shorcut well thought its not bad), the # of nodes/comments needing action, and some insight as what happenned in your site recently (this could make it into the new admin control panel?) * Content by type: so you get an idea of what your site is composed of, and shortcut to filter any content type. Another debate would be separating "page" content type, or letting an admin change the name of a content type... * Content by status: not sure of this one, as many of the indicators are not of frequent use, but good to know at first glance that you have content waiting moderation (but it's repeated) * Filter: I find the actual filter widget difficult to use, which I think ends up in reducing its use. I find the radio buttons irrelevant; you can go without them as it can be seen with the same functionality and reducing the number of clicks. * Table of results: I would add a date column. álvaro -- Álvaro Ortiz Travado alvaro.ortiz@the-cocktail.com The Cocktail Avda. General Perón 6 28020 Madrid +34 91 567 06 05 wwww > http://www.the-cocktail.com blog > http://www.furilo.com
* Filter: I find the actual filter widget difficult to use, which I think ends up in reducing its use. I find the radio buttons irrelevant; you can go without them as it can be seen with the same functionality and reducing the number of clicks.
Moreover, its more powerful than the actual method as it lets you select "blog" content that is promoted and in category X. Talking about categories: imagine, as I do, that you have 9 vocabularies with +5.000 terms in total. Its almost useless for me... Although for other sites with not so many categories is fine. álvaro
* Quick stats (or call it whatever you like, its a quick sketch, haven't entered into much detaill): the total number of nodes and comments (I know comments don't belong here, but a shorcut well thought its not bad), the # of nodes/comments needing action, and some insight as what happenned in your site recently (this could make it into the new admin control panel?)
Quick stats are a must. We have a custom control panel on weblabor.hu to look for recently submitted (approval pending) content, and we often forget to look after such stuff on drupal.hu, because we have no such facility there. Having some default solution would greatly simplify administration :) Goba
On Sunday 25 September 2005 14:25, Gabor Hojtsy wrote:
* Quick stats (or call it whatever you like, its a quick sketch, haven't entered into much detaill): the total number of nodes and comments (I know comments don't belong here, but a shorcut well thought its not bad), the # of nodes/comments needing action, and some insight as what happenned in your site recently (this could make it into the new admin control panel?)
Quick stats are a must. We have a custom control panel on weblabor.hu to look for recently submitted (approval pending) content, and we often forget to look after such stuff on drupal.hu, because we have no such facility there. Having some default solution would greatly simplify administration :)
this is exactly what xstatistics module does. Ber
On Fri, Sep 23, 2005 at 07:45:42PM +0200, ?lvaro Ortiz wrote:
Here's a sketch:
http://furilo.com/drupal/DRU-HCI-admin-content-01-out.png
(a continiustic approach, as I mean not to propose big changes)
Comments:
* Quick stats (or call it whatever you like, its a quick sketch, haven't entered into much detaill): the total number of nodes and comments (I know comments don't belong here, but a shorcut well thought its not bad), the # of nodes/comments needing action, and some insight as what happenned in your site recently (this could make it into the new admin control panel?)
I like this idea. You say this is a quick sketch, I'd like to see a more finished version.
* Content by type: so you get an idea of what your site is composed of, and shortcut to filter any content type.
Another debate would be separating "page" content type, or letting an admin change the name of a content type...
Making story and page part of a system with user-defineable content types would be nice. But that is a different discussion.
* Content by status: not sure of this one, as many of the indicators are not of frequent use, but good to know at first glance that you have content waiting moderation (but it's repeated)
Yep, I don't find much use in these. I'd be interested to know if anyone has interesting uses of these.
* Filter: I find the actual filter widget difficult to use, which I think ends up in reducing its use. I find the radio buttons irrelevant; you can go without them as it can be seen with the same functionality and reducing the number of clicks.
I like this, but it seems redundant with the Content by type and status sections. I think the Filter section may be removed. To get the multiple-filtering functionality out of the Content by type and status sections we could add a link beside 'view' which narrows down what is currently shown. An example of this is the 'related tags' column of http://del.icio.us/drumm/drupal. I don't think '+' is the best link to use for narrowing down since it hard to click.
* Table of results: I would add a date column.
This table is quite wide. Maybe type or status could be represented with color? -Neil
* Content by status: not sure of this one, as many of the indicators are not of frequent use, but good to know at first glance that you have content waiting moderation (but it's repeated)
Yep, I don't find much use in these. I'd be interested to know if anyone has interesting uses of these.
If you have workflow module on, then different workflow stages might just be important for you. Goba
On Friday 23 September 2005 14:20, James Walker wrote:
Problem #4: you have to go to the theme system options, to add a page to the main navigation menu. For new people, this is (i) not logical because creating links has nothing to do with the look and feel of your site, and (ii) the options are nearly impossible to find. The solution is to integrate this with the menu system, so you can link pages in the main navigation menu using the menu on the fly module. I pushed Adrian to work on this, but we never managed to complete that work. I'm convinced this is an important change; we need someone to pick up this work.
yeah - what happened to this? wasn't it Ber? or Adrian? or...
It was me. After hours and hours ofblood sweat tears and beers, I couldt cope. Menu Array Iterations is just over my head. I gave up, sent a mail to the ML with a desparate request for help (well....) but heard nothing back. So I gave up.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23 Sep 2005, at 4:47 PM, Bèr Kessels wrote:
It was me. After hours and hours ofblood sweat tears and beers, I couldt cope. Menu Array Iterations is just over my head. I gave up, sent a mail to the ML with a desparate request for help (well....) but heard nothing back. So I gave up.
I spent a week and a half trying to do it. It took me three days to comprehend the menu system, but even after I got it mostly working .. i got lost, and ended up sending the last version of the patch to Dries (in portland) Since then i've been too busy with the forms api to actually work on the menu system. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDNCcEgegMqdGlkasRAhxNAKDJ2b0y0FhdPS/+NGt2g4DUiF2fCgCgzerF 4YfTByAyTBIhY8klov7Rh64= =RhNX -----END PGP SIGNATURE-----
I wrote this up earlier today, and although Dries has already identified most of the areas I have problems with, I'll post it here anyway in the hope that it offers some insight into the way someone new to Drupal approaches the task of learning and working with it. I'm a web site developer and I'm trying to set up a system where instead of building and maintaining a static HTML site, I build the site in Drupal and then hand it over to the site's owner to manage. The "manager" would be a CEO, sales manager, marketing manager or receptionist depending on the size and type of the company. I must admit, I'm finding Drupal's admin interface and usability to be a real problem. I myself can work out how to do everything, but I am not at all confident that the manager would be able to maintain the site in the long run. In the thread http://drupal.org/node/31896 gpdinoz offered the suggestion of setting up a manager role and making custom blocks to hide much of the Drupal interface. While this may solve my immediate problem and allow me to roll out a Drupal-based solution, I really do stop and wonder whether I should really adopt a system which needs to have much of its interface hidden from the user. Here's a run-down of my system requirements, sorted by priority: * Easy for the site owner to maintain the site * Search Engine Friendly URLs (URL rewriting) * Placement of images on the page with nice formatting * Site navigation is automatically updated as new content is added * Some sort of wysiwyg formatter, ideally cut/paste from Word * Contact form to email and database * Allow file downloads from pages (e.g. catalog.pdf) * Automatic syndication (RSS) for news items only * Bread crumbs with the option to hide them. * Minimal additional features (to keep it simple) * Additional modules which can be enabled if needed After installing Drupal, the first thing I did was to try to base my site structure around the Taxonomy system. This looked ideal for managing the menu and breadcrumbs. Unfortunately Taxonomy in its standard state is lacking some features and even after installing the patches and additional modules discussed on the GreenAsh site I decided that the process of creating vocabularies and terms and then having to create the content and then link it all together would be completely impossible for a CEO to cope with. At this point my experience with the Admin interface had been so frustrating that I actually dismissed Drupal as a candidate for my project and went and installed and tested a bunch of other CMS systems... but eventually the promise of the power and flexibility of Drupal lured me back. This time I used only the page and story modules. Page to be used for the static pages in the site and with attachments enabled and "post information" disabled. Stories to be used for News and have the date and author "post information" enabled. Ideally, as Dries has identified, the Create Content page for each node would have the option of hiding the post information in the same way that User Comments can be disabled. But there needs to be a way of setting the default values by content type. Currently the "display post information on" option is hidden away on the theme configuration page, but this probably belongs on the content>configure>content_types>configure page (settings>content_types in HEAD). While we're on the issue of Theme Settings... this area of the admin interface is in dire need of attention. Hardly any (none?) of the options in there are relevant to a theme. Logo... should be moved to the ?q=admin/settings page. Name, Slogan, Logo. They all belong together. And favicon in HEAD belongs there too. Toggle Display... likewise, this all belongs on the Site Settings page. Primary and Secondary links... where do I start? Almost everything about this feature cries out that it is still alpha: - The settings page where these are configured contains a warning and talk about incompatibilities. - I don't want to see a textarea full of HTML code (addressed in HEAD but now I have less control over the layout). - The "I need more primary links" checkbox is a kludge. The rest of the Drupal interface has "add" and "delete" and yet this feature has a "more" checkbox! - "primary" and "secondary". Straight away it seems that this needs refactoring. What if I only need one links section? What if I need three? What if I want to give them more meaningful names? There should be a way of adding and deleting these link sections as blocks. - The content of the link "blocks" should be managed through the create content page like menu_otf. - The link blocks should be positioned on the page through the Blocks admin interface. So now I've moved all the options out of the Theme configuration, what would I actually expect to see when I clicked on "themes" in the admin menu? - the ability install new themes - a way to enable/disable themes - and to set a theme as the default for the site I would also like some way of customising the colors of a theme through an admin interface and that would belong here too. As Dries has indicated, the menu_otf module has been merged into the menu module. This is great as it will allow my site owners to manage their navigation panel(s) through the same interface they manage the content. I would like to see the settings panel and the jjeff patch also included in this module to make it so much more useful. Allowing the user to control the order of their menu through the Content interface is essential. The built-in upload module does not allow comments and titles to be added to files. This is included in the attachment module (which requires one of the file management modules) but I think this is should be a core feature. I include this "feature request" in a usability discussion because without this functionality in the core module I need to install the attachment and filesystem modules, increasing the complexity of my sites and therefore reducing the usability. There is a good deal of confusion with terminology used in the path module. On the Create Content page the heading is "path alias". You then specify an "alternative URL" but are then warned about the "URL alias" not working. It took me a good while to work out that this was all talking about the same thing and that the "url alias" admin menu option was managing the path module. I'd be happy to see this all changed to "friendly URL" throughout (including the module name) because the only reason to use this module is to make your URLs friendly to both humans and search engines. ...Richard.
Hi Richard, I think you nailed it, and I encourage everybody to read your e- mail ... twice. :-)
I must admit, I'm finding Drupal's admin interface and usability to be a real problem. I myself can work out how to do everything, but I am not at all confident that the manager would be able to maintain the site in the long run.
I think our short-term priorities should be to: 1. Integrate the primary/secondary navigation system. 2. Simplify the theme settings pages. 3. Rename 'path alias' to 'custom URL' (patch pending). It would come a long way improving the out-of-the-box user experience, and is absolutely necessary if we want to make Drupal more accessible. Anyone?
As Dries has indicated, the menu_otf module has been merged into the menu module. This is great as it will allow my site owners to manage their navigation panel(s) through the same interface they manage the content. I would like to see the settings panel and the jjeff patch also included in this module to make it so much more useful. Allowing the user to control the order of their menu through the Content interface is essential.
I'm not familiar with jjeff's patch. Can you provide me a link so I can check it out?
The built-in upload module does not allow comments and titles to be added to files. This is included in the attachment module (which requires one of the file management modules) but I think this is should be a core feature. I include this "feature request" in a usability discussion because without this functionality in the core module I need to install the attachment and filesystem modules, increasing the complexity of my sites and therefore reducing the usability.
There is a patch in the patch queue that lets you add titles to uploaded files. It doesn't add comments though. Maybe 'title' should simly be renamed 'description'?
There is a good deal of confusion with terminology used in the path module. On the Create Content page the heading is "path alias". You then specify an "alternative URL" but are then warned about the "URL alias" not working. It took me a good while to work out that this was all talking about the same thing and that the "url alias" admin menu option was managing the path module. I'd be happy to see this all changed to "friendly URL" throughout (including the module name) because the only reason to use this module is to make your URLs friendly to both humans and search engines.
There is a patch for this in the patch queue; it needs some additional love before it can be included. I wrote an e-mail about that earlier today. -- Dries Buytaert :: http://www.buytaert.net/
On Friday 23 September 2005 18:46, Dries Buytaert wrote:
There is a patch in the patch queue that lets you add titles to uploaded files. It doesn't add comments though. Maybe 'title' should simly be renamed 'description'?
there WAS a patch in the queue that was meant to trick that part "* Placement of images on the page with nice formatting" ...... Ber
At 6:46 PM +0200 23/9/05, Dries Buytaert wrote:
I'm not familiar with jjeff's patch. Can you provide me a link so I can check it out?
http://drupal.org/node/22076 The really important features are: User selectable weight - i see being able to fully manage the menu from the create content page as being critical. and Show only submenus of default - so the admin menus are not available as a parent of content. For example, I have set up my test site with the following menu structure: Navigation Menu item Expanded Site Content (disabled) Yes - Home - About Us - Products No - Product 1 - Product 2 ... Administer - access control ... The Site Content item is the default and menu_otf is restricted to adding content in this submenu.
There is a patch in the patch queue that lets you add titles to uploaded files. It doesn't add comments though. Maybe 'title' should simly be renamed 'description'?
Sounds good to me... I would just like to see each attachment being able to have some text next to it so users know what it is. ...Richard.
People, On Friday 23 September 2005 15:07, Richard Archer wrote:
* Easy for the site owner to maintain the site * Search Engine Friendly URLs (URL rewriting) * Placement of images on the page with nice formatting * Site navigation is automatically updated as new content is added * Some sort of wysiwyg formatter, ideally cut/paste from Word * Contact form to email and database * Allow file downloads from pages (e.g. catalog.pdf) * Automatic syndication (RSS) for news items only * Bread crumbs with the option to hide them. * Minimal additional features (to keep it simple) * Additional modules which can be enabled if needed
This is what I needed often, too. But this really is merely ONE of the areas Drupal could be deployed. My (now on hold) project called DrupalCOM was meant for exactly (yes EXACTLY) these 11 items. Well, not really, I had 12: * allow english and dutch on one site. (ie super easy i18n) So, please let us not forget that this is just one possible area for Drupal. That this should ideally be dealt with in a distro, not in core drupal. Unless we move from the all-purpose Drupal to a CorporateCMS! Ber
* B?r Kessels [2005-09-23 13:52]:
So, please let us not forget that this is just one possible area for Drupal. That this should ideally be dealt with in a distro, not in core drupal. Unless we move from the all-purpose Drupal to a CorporateCMS!
I'm actually feeling a bit uncomfortable as of late because of this, the "all-things-to-everybody" approach. I suppose such projects do cater to certain niches, but more commonly targeted applications seem to do a much better job, with their (if done well) vastly reduced complexity. As the codebase is constantly (pretty significantly) changing all over, it feels like I'm walking on a layer of marbles or something -- so many pieces, so many interconnections, and yes so many possibilities, but all at the cost of complexity. What to do? I wish I knew. Maybe it's just me. In my dreams a severe refactoring, almost to the point of new branch seems perhaps appropriate, but yeah I know all about the perils of such endeavors and the value of working code *now* vs. theoretical future improvements. I guess other than griping I'd +1 on Ber's suggestion to think long and hard about lots of this rather than adding in a million little ingenious clever solutions to get the incremental improvements on the way to some goal. </whining> -- ________________________________ toddgrimason*todd[ at ]slack.net
On Friday 23 September 2005 20:43, Todd Grimason wrote:
on the way to some goal. I'd say that that word "some" is both the success and the biggest threat for Drupal. By wanting to do "anything" you will always have to ignore "everyone".
Hence I really very much plead (and want to participate in) the installation profiles et al. We should really get personalised settings going ver fast, or else the negative side (not being able to server anyone) will soon draw back on us. That is also the reason why I am replying so strong in this thread. I very strongly feel that the (seemingly simple) choices in this thread will push us in one direction, which, I fear, will take away our biggest pro: being able to do anything. Ber
That is also the reason why I am replying so strong in this thread. I very strongly feel that the (seemingly simple) choices in this thread will push us in one direction, which, I fear, will take away our biggest pro: being able to do anything.
Maybe it is me, but I'm totally missing your points today. What are we taking away by implementing the proposed changes? -- Dries Buytaert :: http://www.buytaert.net/
At 9:10 PM +0200 23/9/05, Bèr Kessels wrote:
That is also the reason why I am replying so strong in this thread. I very strongly feel that the (seemingly simple) choices in this thread will push us in one direction, which, I fear, will take away our biggest pro: being able to do anything.
Aah, but at the moment (IMHO) the admin interface is so confusing that Drupal is almost at the point of not being able to do anything. I probably wouldn't adopt Drupal in its current state for my needs, which I think are really very simple. The problems identified in this thread are glaringly obvious examples poor usability and there is really no reason not to make some improvements in these areas. While these improvements might not result in the perfect solution, that doesn't matter. As long as they make Drupal easier to use and don't break the API they are worth while. There's a window of opportunity of... what, 2-4 weeks?... to make some incremental improvements in the 4.7.0 release. Ber's comments in this thread have expressed a desire to research and design the optimal solution to usability problems. But there is no reason why the base for the research into the 4.8.0 interface can't be based on an improved 4.7.0 interface rather than the existing, confusing 4.6.3 interface. I think it's very telling that the OpenUsability project Ber has created is labelled "Drupal 4.8.0", and that's where his focus is. ...Richard.
On 24 Sep 2005, at 00:47, Richard Archer wrote:
The problems identified in this thread are glaringly obvious examples poor usability and there is really no reason not to make some improvements in these areas. While these improvements might not result in the perfect solution, that doesn't matter. As long as they make Drupal easier to use and don't break the API they are worth while.
Right on. At this point in time, we should focus on improvements for 4.7, not on those for 4.8. Everything that is meant to be for 4.8 should be put aside. Remember that Drupal 4.7 will be the de facto release for the next 6-9 months. That is a _long_ time and thus a _lot_ of new users (and potential customers) that will be exposed to Drupal 4.7. It is in everybody's interest to improve Drupal 4.7's usability in the few weeks that we've left. -- Dries Buytaert :: http://www.buytaert.net/
Correct. And my concerns all boil to one thing: rushing in usability improvements without proper thought about it is a no-go IMO. We are not talking about some nodapi improvment, or wheter a cancel button should be a link. We are making decisions that form what Drupal IS. Some of the choices will have a great impact on what drupal can, is or serves. that is why I am so very reluctant about rushing such huge choices in. Ber$ On Saturday 24 September 2005 01:06, Dries Buytaert wrote:
On 24 Sep 2005, at 00:47, Richard Archer wrote:
The problems identified in this thread are glaringly obvious examples poor usability and there is really no reason not to make some improvements in these areas. While these improvements might not result in the perfect solution, that doesn't matter. As long as they make Drupal easier to use and don't break the API they are worth while.
Right on. At this point in time, we should focus on improvements for 4.7, not on those for 4.8. Everything that is meant to be for 4.8 should be put aside. Remember that Drupal 4.7 will be the de facto release for the next 6-9 months. That is a _long_ time and thus a _lot_ of new users (and potential customers) that will be exposed to Drupal 4.7. It is in everybody's interest to improve Drupal 4.7's usability in the few weeks that we've left.
-- Dries Buytaert :: http://www.buytaert.net/
participants (15)
-
Adrian Rossouw -
Bèr Kessels -
Chris Messina -
Dries Buytaert -
Dries Buytaert -
Gabor Hojtsy -
Gerhard Killesreiter -
James Walker -
Kieran Lal -
Larry Garfield -
Morbus Iff -
neil＠civicspacelabs.org -
Richard Archer -
Todd Grimason -
Álvaro Ortiz