A few weeks ago I started capturing some notes about areas of Drupal where I think we can make some usability improvements. You can see the notes I've captured so far on my wiki. I've been focussing on issues I encounter as I use Drupal, with the idea in the back of my mind that I should look for problems mainly with the core Drupal installation based on heuristics. However, I've also found that there are other modules not included in the core installation that I think should be addressed, so where I've found it reasonable, I've made notes about those areas as well.
I'd be interested in seeing comments about other core areas I've missed or comments on the ones I've written about.
UPDATE:
The 4.4.1 system usability report is more or less complete on the wiki. Installation usability and non-core module usability is still under development.
As we come up with redesign proposals, please post them in the new Design and usability forum under Designs, mockups and specifications.
Comments
similarly
I've been working on an educational distribution for Drupal based on 4.4.1 which attempts to address some of the usability concerns you have mentioned by providing some examples and simple documentation using the collaborative book. It's still in progress, but close enough now I don't mind sharing it. It's essentially what I imagine as a profile for a writing classroom site. I have a demo site at drupaled.cyberdash.net. The link to the documentation is in the sample post on the front page. Once I formerly announce it in the next few weeks (have to present at a conference on it in June), I'll clean things up, package it, and make it available for download.
Know that I'll be refreshing the db periodically (I have a separate test site for working on it), so feel free to login as root and poke around: username = admin, password = english .
Oh, and I would welcome any feedback :)
-----
Charlie Lowe | cyberdash
Tips for posting to the Drupal forums
NIce
I like the idea of perhaps including a more complete manual as a book for the version you've installed. For the default Drupal installation, I think the right approach might be to slim down the instructtion as much as possible, which is why I suggest a single page "Getting started" guide that gives the bare-bones instructions for post-installation configuration. To write the guide and decide what should get turned on by default, a good hard consideration of the type of persona we're targetting is required. See the back/forth comments between Boris and me about power user vs. casual user on my Wiki page.
slim guide
Right. ultimately, the best would be to have a general guide to accompany a base install, one that could also be adapted and appended to for specific site profiles. Each profile will be aimed at a particular audience which has a specific user ability level. For example, I knew with this that the teachers who might try this would want some heavy hand holding for basic configuration to get things started (comes from experience doing training sessions on using Blackboard).
But I still think that there needs to be some basic, simple instructions for any profile group, something that is well-organized to separate out novice and advanced user needs. After all, any novice becomes an advanced user with more exposure to administering and using a Drupal site. So ultimately, a quick getting started guide, a newbie site config guide, and an advanced power user guide (which in many ways, is what the Drupal handbook serves as in a generic way).
BTW: Did read the wiki. And wanted to let you know that I don't like the archive module. It is extremely frustrating to have to rely on that on an MT site since it is so slow, instead of just having paging such as with Drupal :)
-----
Charlie Lowe | cyberdash
Tips for posting to the Drupal forums
Archive
Yes, I completely agree. Because it's a wiki, anyone can edit the page. Boris added Archive, which is why I commented below that I didn't find Archive to be a useful module to have turned on by default.
Oh sure, go pointing fingers!
Oh sure, go pointing fingers! :p
Depends on what the goal is: if the goal is to make single-user, MT refugees feel at home, then Archive should get included.
But wander over to the wiki and we can all have a go and hacking it together.
:)
:) It's just harder on the Wiki to associate changes with a person, but you kind of need to in order to find out why you think the Archive block should be there. There's nothing wrong with accountability and pointing fingers ;)
But seriously, we all rely on each others eyes and expertise to make things move. I'm just not convinced that the archive/calendar block is useful or that it gives any more context than the date shown below each entry. And more than that, I don't think we should make improvements that make MT users happy, I think above all we should make improvements that improve the user experience.
is it the only way?
to display links to old content? I can't figure out how to do it except with archive... and I'd really rather just have a list.
WEB: www.eleganthack.com YIM: christina_wodtke
Depends on type of lists
Depends on type of lists of links to old content that you are looking for. For instance, the taxonomy module provides lists of nodes by taxonomy term. I use article.module to display the list of terms (e.g. my topics list).
If you are looking for a way to generate a search of nodes and completely configure the display of that list, you can do that by using a module that generates the list, e.g. my hack of article.module, but you then have to use PHP in your module or your .theme file to modify the list appearance. Check for instance my modified list of recent weblink entries, which shows URLs below each title.
If you are looking for a method that is similar to what you can do with MT's index templates, I suggested in my Usability wiki page a sort of "Drupal Node Query Language" for this purpose. However, I'm not sure that this is a good idea or not.
image module
I've installed and played with image module, and it has the biggest potential, yet has a ton of rather ugly problems.
1. Why is uploading images in two different places? I upload single in create content, but to upload a collection of images, i have to dig through admin.
2. I can't find image administration. Sometimes the admin is on individual images, sometimes it's not. So if I want ot delete, turn or caption a photo, first I must begin a grad adventure to find the tools. Once I've found them and I'm ready to do a second, the breadcrumb has changed and I can't find my way to it a second time.
3. Multi-image tools are really needed: including multi-delete (with image so you know what you are killing. btw, is unpublish the same as delete?), multi-caption and multi-turn. If you want to see a slick implementation, take a look at snapfish.
4. I can't change spec based on taxonomy-- sometimes you want big thumbnails, sometimes you want smaller. if I have a dedicated image taxonomy, why can't i spec it out? (this is the least important)
i fear making galleries with a tool like photoshop and uploading them is still more straightforward, which is too bad.
if anyone is interested in making changes, I'd be happy to redesign the interaction.
WEB: www.eleganthack.com YIM: christina_wodtke
please do
drupal has lots of dvelopers, but few interaction designers. please do contribute your skills. i'm sure an engineer will take an interest.
is there a process?
If I do it, how does it work? I mean, what kind of specs are needed? And there is a place where I put it for folks to take a crack?
WEB: www.eleganthack.com YIM: christina_wodtke
having not read the thread in
having not read the thread in one sitting...
make a mockup
How to give developers specs
Christina, In the past, I've just created wireframes and flow diagrams and posted them in a directory on my web server and then linked to the files from a forum discussion like this one or in the developer mailing list. That way people comment on the diagrams in the forum. The developer mailing list is pretty high volume, so you may want to just create a new forum thread and post your specs there.
process for Christina
I usually do following:
Component: User interfaceCategory: task
See my some of my suggestions:
http://drupal.org/node/view/6749
seems a bit random
What if somebody in power makes a new forum for design, and offers up subtopics like interaction design and template designs, so that there is a non-code respository for those who can code to easily find things to make?
A vocabulary like:
Design
-interaction design
-visual/interface design
WEB: www.eleganthack.com YIM: christina_wodtke
Bug, feature issue tracker is for those things
Cristina,
The forum is fine for helping people who encounter difficulties, people who wish to post articles or want to whine aout drupal.
The issue tracker is tehre for the developers.
We (I cannot speak for all of the developers, but this is the way I use things) Run trought the forums on regular basis to help answer questiojns and point people in the right drirection.
But we use the the devel malinglist, sometimes IRC and mostly the tracker to discuss issues for drupal.
The issue tracker is great for all thos that want to keep track of stuff, get organised and see what is happening, if projects are finished, waiting etc.
So the section in tracker called "user interface" is created for exactly those things you discuss here. Please feel free to open feature request or tasks if you made a mockup (PDF, HTML, PNG, etc) for better interaction design. Most of us are coders and would love to learn UI design from more interface designers with experience!
Hope to hear from you on the mailinglist or in the projects soon ;)
Ber
---
Professional | Personal | Wizzlern Drupal training
sounds like
Sounds like michael and I should take our commetns/designs/issues there, then?
WEB: www.eleganthack.com YIM: christina_wodtke
Flow
One problem I have is that Drupal doesn't (always) remember the page I'm coming from - or that there are multiple 'exit points'.
For example, when editing a post in the post queue at 'administer > content', I'm directed to the node's page (i.e.
node/view/$nid) after saving my changes. To edit the next post in the queue, I have to navigate back to queue, page through it (or filter it) and click the next 'edit post'-link. Clearly, this can be tedious.Drupal has similar 'workflow problems' elsewhere. Maybe you could include a list of this and other workflow related problems on your wiki?
workflow & co. for users & admins
concerning workflow...
for users:
for admins:
that's my list, for the time being...:)
yep
...if I add a comment to a node, after I submit it, I'm taken to the comment/reply/nid page, presumably to add another comment. I think this is confusing.
Sure is. much better is the return to article commented, anchoring to your brand new comment.
...and I had a hard time locating all those admin interfaces.
no lie. We need a card sort and re-architecture of those menus, stat!
WEB: www.eleganthack.com YIM: christina_wodtke
Amen about the commenting thing
The current interface is completely counter-intuitive. This should be done exactly as Christina explained. My users have been complaining about being confused by this.
ProvoPulse.com | See - Hear - Know - Discuss - Inform
patch was submitted
I submitted a patch for this a long time ago. The alternative patch that was committed was not as good IMO. See http://drupal.org/node/view/5642.
One Simple Thing
One small thing that would radically improve usability: seperate admin naviation. Right now I've got all the navigation mixed in with my admin stuff, and it's nightmarishly hard to figure out what is for my end-users and what is for me. Seperate them into their sections within the block, at the minimum.
WEB: www.eleganthack.com YIM: christina_wodtke
I agree
I agree. At some point I stopped following Drupal development and was surprised to find that one of the releases changed administration so that it become a part of the main user menu. It used to be altogether separate in an earlier release of version 4.
Now that administration is not a separate view -- i.e. it's navigation is embedded in the normal user block -- I'm not quite sure where the administration menu should go. I found it easier before, when admin was not integrated with the site skin/theme. What I would almost consider is that when you click the "Administer" link, all of the other blocks are hidden. This way, focus can be given to the administration tasks/menu. The menu gets quite long.
agreed
i was considering making a suggestion along the line of a show/hide admin or a set of views based on user type. one of the big diffeences between drupal and MT is how dang hard it is in drupal to see things from your end user's point of view-- you have to log in, log out... ouch!
(p.s. in preview mode, the actions on the preview should be grayed out or not shown... one is oddly tempted to click "reply" to ones preview...)
WEB: www.eleganthack.com YIM: christina_wodtke
Chunking the user block and adding vertical space
I'm beginning to think that perhaps the way to separate the admin menu visually from the rest of the user block is to simply add some vertical space above the administer link. In fact, it would be nice if we could chunk the user block a bit better, but I realize that the weights given to each user block link will vary from system to system. But for the drupal.org site, for instance, maybe this spacing and chunking would serve:
* create content
* cvs messages
* projects
* recent posts
* news aggregator
* my account
* log out
* administer
I simply put "my account" and "log out" together. I moved administer to the bottom and created vertical space between each of these blocks. SO the order of blocks above is 1) content 2) account 3) site administration.
simplest solution
it's what i had suggested to MT after doing usability testing-- chuck functionality and add labels.
i think there may be a bit too many clicks required-- almost everything is one layer down.
what about something like
read:
>blogs
>feeds
>forum
create content:
>image gallery
>blog entry
>book page
>more
Administer
>modules
>blocks
>other(not sure what is most common yet)
my account
log out
Syndicate
WEB: www.eleganthack.com YIM: christina_wodtke
small IRRITATING thing
I just went to my site logged out... why oh why does a post say&link to "read more" where there isn't anything more to read? As a user, I feel misled.
read more should only show up when there is something not shown on the front page. heavens.
WEB: www.eleganthack.com YIM: christina_wodtke
Which theme are you using, Ch
Which theme are you using, Christina? I don't see this on my site.
Shouldn't happen
That shouldn't happen and is probably a bug. Can you point us to the offending post so we can investigate this further?
marvin, widget
my testbed is widget.eleganthack.com
the theme is intact, it's marvin, and the first post on the front page displays the issue. and I haven't messed with it yet, so it's out of the box.
good to hear it's a bug not a feature. ;)
WEB: www.eleganthack.com YIM: christina_wodtke
Do you mean this one? http:/
Do you mean this one?
http://widget.eleganthack.com/node/view/168
It's the only one with a "read more" link. And the following sentence appears in the full version, but not on the front page:
"i hope they do another go at this module, as it could be a real differentiator."
Sorry to hear about disappearing blog items. Perhaps you "unpublished" them? Try going to http://widget.eleganthack.com/admin/node -- you can view "unpublished" as well as "unpromoted" items. Items that are unpublished are in the system, but only display through the admin interface. Unpromoted items don't show on the front page.
Read More
One thing along this same thought, how to change the color on the read more button so it stands out a bit (when there is more to read). Also, this should be the same for the comments link...IF in fact, there are comments, it should turn red or orange or whatever... No comments, then it should not stand out... Is this possible?
Yes, it is possible
All this can be modified in your theme and/or CSS. Some of the read more links (like marvin_2k in phptemplate) already highlight this link.
Needs task specific guides and image module in core
I posted a response in the MT thread (http://drupal.org/node/view/7862) and Dries requested I refine it and post the relevant opinions here.
I looked through the Wiki notes and I have to disagree with a change to the default install settings suggestion. Drupal is really close to a basic tool kit. When installed, you have a near blank canvas. What you build from that point on is up to you. Enabling more modules is making assumptions about Drupal’s initial use may constrain people (example virtually every nuke site looks like virtually every other nuke site). Besides, now is the time for people to learn How to enable/disable and add modules. If it’s not there or on, it can’t be configured incorrectly. *see exception to this…
Rather then enabling more modules to begin with, why not write a few focused guides on setting up very specific sites. The existing documentation is very module specific and sometimes the use in combination is not obvious.
Here are some initial ideas for stereo typical sites.
From a fresh install these are the steps to build …
1. A single user Blogging site with a picture album.
1a. A multi-user Blogging site
2. Slashdot type site with stories and user community comments
3. A news publishing site like wired, no user comments with news feeds in blocks.
I am sure that we can come up with a few more. These can cover setting up roles for this type of site, suggested minor theme modification and setting up a basic menu with a menu module. For instance, this is the clearest example of setting up an Image Gallery I found http://drupal.org/node/view/7872 this can be included.
Here’s my analogy, Drupal is a canvas with a painters palette of colors and some brushes. If you don’t have the color you want, you can mix up your own color or buy new ones. The documentation tells you how to paint a tree, a bush, some grass and a house. It also mentions that you can have a lake if you want. It is not clear how to paint the tree next to the house surrounded by bushes at the edge of a lake while remaining in the context of the picture.
The developers have been using this product for so long that the architecture of the product is second nature. Even the admin section is not a problem for me, just an exploration of where something is located. The problem is that people new to the Drupal framework itself are lost. Should I use stories, blogs, forum comments, voting on comments? What are the advantage/disadvantage of each, should I setup roles …… Even if the suggested single purpose guides do not answer someone’s needs, going through them can help you get a feel for putting together a site and how some of the features interact with each other.
As an example, I have some aspects of these requirements figured out and am still figuring out others.
1. Personal site with a technical knowledge base and a ‘personal’ section devoted to my hobbies. Taxonomy is the biggest lure here. News feeds looks handy too. Current beta site http://beta.blkmtn.org The image module was the biggest hurdle, still playing with the File Handler module.
2. Sister-in-law's business site. Current example http://beta.ancientpathways.net
---hmmmm, events and scheduler for her classes.
---she doesn't want 'submitted by' to be displayed, must learn...
---she is considering a blog (she does knitting) and my want to build a community of her email list ..... Theme and menu currently the learning avenues here....
3. Dog rescue group.(still in feature anmd purpose discussions) They just need a site that they can have an event calendar and some articles and pics that don't change much. Content managed by one or two volunteers. Nice to have submits through web page. Really waiting on what I learn on the above two sites to put together and I had some inspiration from this site which is really well done.. http://ntiwc.offlead.com/
One more idea. A step by step example of how to perform a basic modification of a theme. phpTemplate perhaps as being the easiest with straight css. Perhaps on the order of http://www.stopdesign.com/log/2003/05/27/in_the_garden.html
To contribute, I just wrote a very rough how to install Drupal on a Windows XP system to practice with. How would I go about submitting this for review?
* The exception is the image module. Graphics, even in limited use, are a very much a part of a huge portion of today’s websites. Whether it is pictures or art, it really needs to be included in the core Drupal releases. This is entirely selfish of me too. . My brother-in-law, upon looking at the beta site said it looked like her store was in a corporate office. Of course, right now we're just playing with the product, but he does have a point.
Also, being able to install modules without having to use a command line interface to import sql scripts would be nice. In reality, I don’t know how much trouble it would cause.
With respect and thanks for a great product,
Steven
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
I don't understand...
The user-based approach to documenting and suggesting what modules should be turned on is a nice suggestion. But, I don't understand what you are suggesting specifically. Are you suggesting that we ship Drupal with no default settings? We already do turn some modules on by default. Note that the usability suggestions are for first time installations. It would be rather useless to install Drupal for the first time and not have "blog" turned on for instance. I would guess that more than 80% of installations of Drupal use the blog node type. The idea to modify first time installation this way is to get a primary user type's needs addressed upon installation. The assumption is that users with greater needs will want to customize their installation, so they will be expecting to spend time exploring their options. But the basic blogger user type will be able to simple install and start blogging immediately.
What I hear is that you are opposed to turning on certain modules by default for the base installation of Drupal. Which are you opposed to? I need better justification for why search be off for instance. Why should we have comments off by default? Are you opposed to shipping some modules with the core that are not included presently by default or is it only the "turning on" aspect? I see that you want image.module to be shipped for instance. Part of the question is also how to set permissions by default. E.g. I believe Comments should be on, but permissions should be set to allow only authenticated user comments. People can adjust permissions to allow anonymous or MT style comments after the fact.
Deciding what to turn on is based on assumptions of user archetypes, e.g. individual/community bloggers, which is why the base installation suggestion I made was:
* Blog
* Comments
* Search
* Trackback
* Tracker
What issues do you have with shipping these in the core (e.g. Tracker and Trackback are not included in core) and turning these on by default? These are rather basic functionalities.
polls for this?
Hi,
Should we create a poll for this on drupal.org? To find out peoples opinion on this?
I am not a fan of polls, but i think the "default installation settings" should be basd on how most people use drupal. e.g
What do you use drupal for?
[ ] Blog
[ ] Portal
[ ] Knowledge management (intranet-alike)
[ ] Forum
[ ] General communication platform
[ ] Other
Maybe some other will come up with a better list for this?
Regards, Bèr
---
Professional | Personal | Wizzlern Drupal training
This is a good idea, I think.
This is a good idea, I think. But the question mainly addresses current users. In the end, we will want the question to address prospective/target first time users. The idea is to ease their first time installation. It's not really a big deal to those of us who already know what we're doing.
"Default Configs"
The list above might be the good start of config wizards of sorts. Basically areas that allow you to with the click of a button and answering of a few dialogs to configure the site including activating modules, setting up blocks, ect.
Basically allow someone that doesn't have a clue to quickly add the functionality they would like in a reasonable default fashion.
default on -ick
I don't have a problem with shipping more in the core, I suggest however, that Drupal continue to have a very small amount of items turned on by default continue.
Your assumption of the user architype may not be valid (or it may very well be). For instance, I don't need the blogging function for 4 of the 5 sites I am setting up (ok, it's 3 short term and if all goes well 5). So in my case, only 20% of the targeted installs need blogging :).
If a feature is on by default, I would have to turn it off. I am hoping to use Drupal for it's ability to organize and clasify information. I posted 3 of the examples I hope to have up in 2 months in my first post, if all goes well, I will probably have 2 more to do this fall. Only one of those is interested in the blogging ability. the other likes the Taxonomy feature, the file store and image modules. I have several friends who are waiting to see how my sites turn out, they run a variety of sites, forums, tech support, personal for family pics, etc. Only one has something that approaches blogging.
What I suggested as an alternative to default on, is the user archetype simplified 'how to'. Define 3-5 user architypes and have short (1-3 pages) focused directions for setting them up. This would include configuration\module\ click to enable, etc. People setting up Drupal should at least be acquainted with this information in any case, and the use of short tutorials would assist with the familiarization process.
For instance, if I wanted to do Blogging and a Slashdot style forum, I could look at the 'Basic Blogging how to' and the 'Community Forum' how to. If I wanted to setup a document retrival site, here is the 'Taxonomy and file store how to'.
When I first set up Drupal, I was surprised at how few modules were active. As a systems admin, I like the things off by default settings. A person has to make a concious decisian to use a feature and turn it on. Not find and disable everything they don't want to use. This provides for a more secure setup out of the box. Microsoft is hammered constantly by system admins for shipping 'the world turned on' out of the box. Let's not have that issue with Drupal.
So to be specific on your list:
* Blog -see above, I don't need it on 3 of 5 sites.
* Comments -I don't currently need comments on any of the sites I am setting up (3 inital, 5 posible) but that may change on one of them later so the ability is nice to be able to add)
* Search -no objection.
* Trackback -don't know what this is (I currently don't blog and am only now learning some of the terminolgy so, should I turn this off?)
* Tracker (Boris added this) -don't know what this is (I currently don't blog and am only now learning some of the terminolgy, should I turn this off?)
So I suspose, I don't fit your user architype. I am more interested in Drupal's CMS ability than it's blogging ability, and while I don't object to it having a reputation as a blogging platform, I would prefer not to see it's 'community plumbing' tag dilluted in that focus.
(apologies that my first post was a little unfocused, I was under a bit of time pressur last week and did't take the time to distill and clarify properly)
-steven
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Maybe a wizard is needed for installations?
Perhaps the right approach to new installs is to use a wizard. The new installation could present a set of questions to the administrator installing the system, and from there, determine which modules will be turned on. For instance,
1) Do you plan to use this Drupal system for weblogging?
[ ] Yes [ ] No
2) Do you want to allow people to post comments on this site?
[ ] I don't want to allow comments
[ ] Allow only registered users can post comments
[ ] Allow anyone to post comments, unregistered users must supply email address.
3) Do you want to allow people to trackback to your site?
[ ] Yes [ ] No
4) Enter the time zone for this site:
...
You get the idea. Maybe what one could see upon installing a new system is the option to:
* Use the wizard to set up your Drupal system. (This is the best choice for new users.)
* Set up your system manually
wizards
I have no objection to that. I also have no ability to write such a wizard, though web based 'wizard' installs of modules and the table updates would be a 'good thing'(tm). At this point I have figured out how to do them without the wizard.
If you did the wizard, then partial definition or suggestions with the choices would be necessary. As I don't Blog, I had to go and look up what the term was. Note: I am thinking of using the Blogging capability on my personal site now that I have begun to see the diverse ways that people are using it.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
a combination
that sounds great. users could be given a choice at the very beginning of (a) preconfigured site profiles (individual blog, slashdot-community site, etc.), to include the current blank setup or (b) step by step configuration wizard. sort of similar to redhat's installation options: let redhat decide on the apps to include or user-selected rpms. like redhat, it would also be good if drupal could save the step by step configuration to a drupal site profile so that an admin who might be setting up multiple sites over time could have the same starting point without going through the wizard again.
-----
Charlie Lowe | cyberdash
Tips for posting to the Drupal forums
(nitpick) Tracker is in core.
(nitpick) Tracker is in core.
I think we should have two separate discussions:
1) modules that currently aren't in core but should be
(image, weblink, syndication are three I can think of off the top of my head)
2) modules that are in core and enabled by default
And yes, this does depend on type of user (for both discussions), so I would say the default default should highlight Drupal's strengths.
And I would be against including Trackback, mainly because it is not an open standard. But if Drupal were to develop a referrer module (or turn it on from statistics)…
Sorry, Boris. You're right, T
Sorry, Boris. You're right, Tracker is in core, but I wasn't sure if it was on by default. And yes, we should be having those 2 discussions you mention. Maybe this particular discussion should be moved to a separate forum topic?
Trackback has sort of become a bloggers' de facto standard for creating linkage across blog entries. I added it to appeal to our new emigre community of MT users. I just find the process of adding modules might be a deterrent to getting new users. But see my comments to Christina's package comment below.
tracker
I don't care if it's in core. I just need to know what it is and should it be on. I have since looked it up and IIRC it is on by default. As it tracks recent posts, I suspect that it helps with admin stuff in content management.
I do not object to more being in core, I just object to the assumption that Blogging is the focus of Drupal. There appears to be a wide diversity of sites that use Drupal, from blog, to news, to magazine, political, content management (Bers just posted an article on Drupals content management capabailities). I don't think that 'Bloggin on' benefits anyone. I think that how to setup a bloggin site instructions do.
-steven
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
two discussions
You are right, these are two discussions. Who gets to start the new thread? I am still learning this stuff.
-steven
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
a simpler solution might be
packages.
Why not make package with the right things turned on and the right modules already in it?
blog package
photolog package
small zine package
etc? maybe 5 packages, and everything elese requires grown-ups to set it up.
WEB: www.eleganthack.com YIM: christina_wodtke
This package concept might wo
This package concept might work for new users. It's basically what I heard Steven alluding to above. Sounds like a good idea.
I'd like to hear what the developers, esp. Dries and Natrak, have to say about this. It should cause a little more work for the, esp. with regard to how a "getting started" document might be prepared for each package.
back to core stuff
I don't like the multiple 'pre-packaged installs' method. This now means that multiple configurations (branches) must be maintained, updated and documented. This is why I advocate the 'architype' how to documentation route on how to configure the standard install to accomplish a specific purpose.
This accomplishes several things;
1. Users download the standard package and by following the specific 'how-to', they configure their install and are up and running using the default install.
2. they learn to turn on regular modules and do the basic configuration.
3. By using the standard package this avoids the enevitable, I need to do x but my download doesn't have it.....The blog package, why?.... ah, you need the forums module.... what's a module? How do I get that.
4. Adds to the number of people who are now familiar with the 'Drupal method' using the core install and may stick around to answer basic questions on the forums for other newbie's.
The purpose based 'how to' will have exposed the end users to basic configuration and options and after following a 'how to', they can proceed to the forum setup how to (or whatever).
I mean, Deanspace is a semi-customized version of Drupal. What if they had not prepackaged 'their' version of Drupal, but instead provided detailed instructions using the standard version of Drupal? Concentrated their support site on how to use Drupal with a few additional custom modules in an political campaign.
Now they have a complete site, document, support structure wandering off in their own direction. This is perfectly all right, but represents a branching of resources that might be better used to drive contribution, streamlining and refinement of Drupal core instead of maintining another version of Drupal that will enevitably. I forsee DeanPal, druWebsite, postDrupal, afterDrupal.... etc.
Drupal seems flexible enough to solve your interest in Blogging technology and my interest in Content Management. I mean, your interest in Blogging has caused me to do some reading and I may actually try my hand at it sometime. Between work, school and my new son, if I can get my sites done, I plan on doing such a write up which just may peak your interest in a content management site. :)
From seeing your site, you certainly do understand web development more than I do. My job is more about implementing solutions and providing long term support. I try to generate and implement IT solutions that will be stable, accessable to the end users and repeatable by someone else.
-steven
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Packages is not forking
The terminology is an "install profile". It has been discussed on the developer list, and is definitely coming. It would definitely be useful to spec out some base packages.
Here's my list of profiles:
* individual power blogger
* group blog (== zine?)
* community/organization site
* brochure-ware business site
jibbajabba -- your wiki is now password protected? Lets make individual pages and "usability" folks can go there and quickly get some rough consensus on what should be in/out in terms of modules.
Actually, we need these pages:
* what modules should be in core?
* (for each profile) which core modules should be turned on and how should they be configured?
Hmmm...install profiles will necessarily include non-core modules, methinks. Which means extra instructions about downloading those modules as well as core. Either that, or we really pare down and only look at core, which is probably where we should start.
boris,
boris,
Sorry. I protected it because some spam robot or something kept replacing the contents of pages with their crap. I re-opened them. I'm hoping to get these solidified soon and to repost the entire thing as a report on drupal.org.
-m
sounds good then
Ahh...
Then I misunderstood the context that the term 'packaged' was being used in. In that case, sounds great. I thought that what was being suggested was mulitple pre packaged drupal installs that would be pre-configured out of the box. If there isn't some upfront configuration then people will not necessarily learn the product. The balance is where to put that configuration need.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Permalinks for comments
I just implemented permalinks for comments (an item on jibbajabbaboy's usability list) and committed that to HEAD. I updated all themes in core as well as the default
theme_comment()function. If you maintain a theme in the contributions repository that implements the_commenthook, you can add permalinks just like I did:<?php- $output .= " <h3 class=\"title\">". $comment->subject ."</h3>\n";
+ $output .= " <h3 class=\"title\">". l($comment->subject, $_GET['q'], NULL, NULL, "comment-$comment->cid") ."</h3>\n";
?>
gui?
is there/will there be a gui to this, say under adminstration of the module or theme?
WEB: www.eleganthack.com YIM: christina_wodtke
Not planned
We haven't planned adding a GUI for this. (It would be nice to get a priotized list of your suggestions -- I'm starting to lose track ;-).)
I know
I'm running user testing right now, so I have these funny little 20 minute breaks in between sessions... not enough to gather my thoughts, but enough to discover trouble.
here is a quick pass:
Small things to fix, in order:
1. the bug on "read me"-- very bad user experience
2. interaction on submit: should be user previews, edits, submits and then *is returned* to node where they begin with clear
3. separate admin navigation from "reading" navigation (eventually a full card sort should be done for the navigation-- I'm going to try to set up WebCat to do it)
messaging "your comment has been submitted"
4. Views to allow admin to see what end user sees
5. gui access for permalinks (a simple checkbox on the blog management/set-up page would be enough)
WEB: www.eleganthack.com YIM: christina_wodtke
I will synthesize all these comments
I will synthesize all these comments into the wiki page I started, organizing them by module with status flags for priority. Will do it next week, by Tuesday hopefully.
#1 is not a bug as far as I c
#1 is not a bug as far as I can see -- I checked out your site, and there is a one sentence paragraph that is on the "read more" page. My comment on this is in this thread, here.
#4 - I open up a second browser (i.e. Safari as my main, Firefox as secondary). In my second browser, I'm either not logged in or logged in as a test account. Doesn't make sense to me to add this functionality into the system.
Everything else is good. I have always just added in permalinks to my template as one of my "default actions" (digs around looking for feature request from 2 years ago). I don't think it should be a feature request -- permalinks should always be on.
Group Configuration UI Revamp
I thought of ways that the user group configuration could be cleaned up. Here's what I came up with:
Clicky
It's largely just a framework, but I think something like that (with categorized options, so that they don't look so forbidding) would work well if implemented right.
Some things to remember:
- I've only been using drupal 4.4.1 for a couple days now, so I may have left out some configuration options. I haven't looked at CVS at all, so if there's already something like this in there, my apologies :). Feel free to mention anything that I should add/edit.
- As you may notice, I've added in a few features that might or might not actually exist in drupal at the moment. I guess you could consider those mini-feature requests. However, most of it is just a reshuffling of the configuration that's already there.
- The notes at the top explain some of the syntax (brackets and such) that I have in there.
This is an excellent chunking
This is an excellent chunking and reorganization, beoba. I have added your suggestions to the Wiki.
Book usability
I've already posted on this subject, but I think it would be useful.
I'm working on a site which will essentially use the Book structure to hold issues of magazines, in three levels:
The Magazine (eg "World Cooking")
--The issue (eg, "June 2004")
---The articles (eg "this month's recipe")
Now, if I have multiple magazines (imagine a "lifestyle" type site), all with multiple issues and articles, it is unbelievably irritating to have an enormous drop-down list with all the articles published in all the Magazines (books) to choose from, when I have to "place" a new article (ie book page). Ideally, I would like to see the selection of the placing of a new article in two steps:
1) choose which book to put it in (only the different Books at top level are displayed.
2) Each book has a "leaf level" setting, so that (in my example), the articles are not displayed in the hierarchy (they are considered as "leaves", and you can't put another section under a leaf)
Does this make sense to anybody else?
The problem you present is ex
The problem you present is excessively clear to me as well. I wonder, however, how you determine that something is a leaf that you will not want to turn into another branch? Your example is rather finite, but if someone were authoring a book based on the idea of chapters and chapter sections (with each section being a leaf), what happens when a sub-section needs to be added to a section? It is difficult because I can't imagine all the uses for this module.
Other option: Seperate types
Another option for books is two types: "book" and "book page".
The project module does this too, projects and issues. I beleive a book is something different than a page. The permissions are different, its useage even more.
This way the above-mentioned options will be easier: Creating a book does not present you with the hierarchy, but creating a book page does.
If you create a page you will see an select-option forthe available books fisrt. After selecting [preview] you will see a structure of all the pages in a book.
Ber
---
Professional | Personal | Wizzlern Drupal training
Thanks, Ber. You're providing
Thanks, Ber. I think you've provided me a way to turn this into a high level statement of the Book problem and possible suggestion for improvement. Will add to the wiki later.
Book usability
Well clearly, there is an issue here... it seems to me that there are two different use cases:
1) I just want to add pages to a book, without changing the overall structure. In this case, my suggestion of a "leaf level" setting for the book works fine.
2) As in the comment above, I want to change the structure (ie in this case allow more levels of leaves). The obvious way round is to start by changing the leaf level for the book (from 3 to 4), to allow a subsection below the section. This would be very simple. But perhaps you need to be able to do this in the "edit book outline" function (which by the way I can't find!!!).
I've added some more comments here: http://drupal.org/node/view/8878
Form usability
FYI I am starting a big overall task "Improve the user experience of Drupal forms" and I try to complete it by small subtask-basis.
The first step, "Analyze form accessibility" is here:
http://drupal.org/node/view/8082
Poor Content Managment Interface
Maybe this is being addressed?
My biggest beef with Drupal is with maintaining many, many bits of content. Let's say I have 200 images in a gallery (it's not important as to what they are, get your mind out of the gutter). Now, I want to remove 150 of them. What do I do?
I go to /administer/content. Now what? I have to dig through pages of entries looking for the images I want to remove (or articles for that matter) and do a delete/confirm/back for each image. It was such a drag, I went right into MySQL and removed them there.
What's needed? Filtering for one thing: "Show all [type] posts only". Some others would include: "Display 10/20/40/100 per page", and a "Check all" so I (the user) don't have to check all of the boxes on my screen.
This is just a small handful of problems with the 'Content' page. I'm not beating up on the interface, I'm simply saying it's very poor from a usability standpoint and needs to be addressed.
Yes, we sort of allude to the
Yes, we sort of allude to the need to perform tasks on multiples in Christina's suggestions for image.module. I will add your issue to the wiki.
Usability list is more or less done
I have synthesized most of the usability issues discovered in this thread and re-stated them in the Usability Wiki. Thank you everyone for your contribution to this discussion. Dries will be coordinating an effort to evaluate and address these issues.
-Michael (jibbajabba / jibbajabbaboy)
Taxonomy for multiple vocabularies
I really think the taxonomy feature is one of the most important parts of Drupal. However, if you set up multiple vocabularies per node, you'll quickly find that the standard screen for adding new nodes becomes pretty cluttered with these vocabulary options. Additionally, if you enter a lot of nodes at once (something I find myself often doing for flexinodes, for example), you end up having to make the same set of menu picks for taxonomy settings over and over. For existing nodes, this is also somewhat messy since the lists which display existing vocabulary terms do not scroll to the selected term, so it often appears that something has no selection when indeed it does. Here are my proposals:
1. Establish a 'default taxonomy setting' option for new nodes (established by node type and user).
2. Build the taxonomy selection for a node in a separate window, which pops up upon selecting a link. The user would only need to select that link if his 'default' setting was not appropriate for that node.
3. Provide a way of changing the taxonomy for groups of nodes; I'm envisioning this as consisting of the traditional 'pager' display of node titles, with a check box in front of each, and a set of options (add category, delete category, ...) at the bottom.
I'd be glad to update your Wiki directly, but thought I should post here to solicit feedback on this proposal beforehand.
A Simple Acceleator
I just uploaded a hundred images via directory upload. It makes me really realize one needs multi-edit, simpliar to movabletype's power edit mode (screenshot)
If this page was simply editable fields, it would take one a long way (though i'd beg for tiny thumbnails when content was images and a category dropdown as well for true power)
WEB: www.eleganthack.com YIM: christina_wodtke
Analysis of the functionalities
Seems the functions that are missing in our "Admin > Content" form are:
* Multi-delete using checkbox -> We need to add this
* Multi-modify title -> This is nice. I wonder how often used.
* Multi-modify date -> ditto above
* Multi-modify author -> ditto again
* Multi-modify category ->
The MT-style form would work best for small, strict hierarchies. I don't think the form select with only one item showing will work with Drupal unless it is a form select with multiple items allowed. Drupal supports multiple taxonomies for different node types and multiple terms per taxonomy. So you can imagine how variable this screen would be.
I'm also not sure how this would perform if form select elements are used. Imagine that each drop down menu contained the entire taxonomy (mine would contain like 75 terms or something each). Perhaps we can redesign the interaction and UI for this. Would be difficult. One thought I had was that for each node, we display a link to "re-classify or recategorize" that pops up a small window showing the list of taxonomy terms with checkboxes. You apply and return to the original window. I have no idea if that works with forms though. It would certainly be possible if there was a separate page to handle batch re-classifying multiples.
What we do provide:
* Multi-modify status: approve, publish, unpublish promote, demote
Overall, I think our implementation may be a bit more confusing. Simply removing the heading "View posts that are new or updated" might make it a bit clearer. that heading is just unnecessary on this page, I think.
some thoughts
"* Multi-modify category ->
The MT-style form would work best for small, strict hierarchies. I don't think the form select with only one item showing will work with Drupal unless... "
What about a dhtml flyout menu? or a small pop-up? I agree the design is more complex. It might we worth having a dedicated page for multi-categorize more like snapfish.
multi-author is useful where the author and the user are not the same such as in a zine, for example on B&A Erin uses this function to get the Author names right.
multi-title is good for people who can't spell (like me) or if you change your naming schema suddenly.
Multi-date again, more useful for zines where you want to reset a bunch of articles to a published date
Finally one thing neither implementation does if offer any kind of preview. I think this would be one of the most useful, but one of the most tricky.
Another model is trying to handle multi-actions each on their own page, like snapfish does (I have screenshots on your blog)
Content Type: it seems to me (I could be wrong, since I don't know all the usecases) that type is not useful unless it is editable.
Also: regarding the "view recent" dropdown. I noticed content I havent' touched yet (say, the images mass-uploaded) have a red star next to them. that suggests to me it would be possible to have that as a sort by method...
WEB: www.eleganthack.com YIM: christina_wodtke
Some reactions
What about a dhtml flyout menu?
This is kind of like I was suggesting with "small pop up window", but in a DHTML menu, the interaction remains on this page, rather than on a separate page. DHTML might be feasible if it is accessible and tested across all browsers commonly in use. The small pop-up might be more accessible.
Multi-author, multi-title, multi-date
Thanks for clarifying for me what these are used for. I now aggree that they should be editable.
Preview
Can you clarify for me what we are providing a preview of in this screen?
Multi-actions each on their own page
This might make some functions simpler. I too find Snapfish incredibly easy to use for these types of interactions.
Content type; What about sorting?
In some cases, content types are directly tied to the type of module handling the node authoring, e.g. with image nodes, some data goes into the image table, page nodes into the page table. So you probably don't want this editable, since it's not possible, for instance, to move an image node to blog node, because much of the data is held in the image table. Someone can correct me if my understanding is off, but it's more of an indicator to make it clear what you're looking at. That said, it certainly seems of value to make the headings in the Content management screen sortable: title, type, author, status.
clarification
preview by this I mean the title is not always enough to know what one is talking about; many of my image are named IMG3456, my blog entry might have a name like "good idea". So I'm toying with some ideas about how to preview each item so you can handle multiple content editing. I have a sketch I'm working on where a tiny thumbnail is shown for an image, and a tiny 15 word excerpt for blog etc. I'd suggest as well a rollover that gives you more, maybe 100 words. This gives you sufficient context to multiedit. The whole point is to avoid the pain for a refresh/page call, so previewing seems extremely useful. It's just a spacehog, esp. in a three-col layout. one way to get around this is what MT does, and that's use a dedicated page for it.
I'm growing increasing more fond of a dedicated page a la snapfish for category editing. pop-ups are growing less viable with the adoption of pop-up blockers (we can chat offline about this: from what I've seen lately at Y, I'm guessing the pop-up will be close to dead as a interface object by 2005)
So the model I'm proposing is a three page one:
page 1: multiedit metadata
Page 2: multiedit vocabularies
-- This would be a page with previews and vocabulary Fields left to right, one row per node
page 3: workflow management (multiapprovales) (this could be part of page one, theoretically. i wonder if there are some cognitive overload issues with that, though)I'm restraining myself from making design suggestions here, as I haven't used this much.
later
I've uploaded a very raw sketch (PDF). Michael (and others) love to hear input. most sticky section is the multi-buttons (save, delete, categorize, approve). I feel it will work, but might be confusing. But can't think of a good solution without seperating out the functionality.
WEB: www.eleganthack.com YIM: christina_wodtke
one more thing....
I have not touched the filtering functionality in the sketch. It needs attention as well. Sorting takes you only part of the way. It would be worth having the ability to filter on author, category and well as published/unpublished (currently only unpublished--why?)approved/queued, recently updated, static/dynamic, approved/needs approval. I'll see if i can update the diagram sometime today.
WEB: www.eleganthack.com YIM: christina_wodtke
WEB: www.eleganthack.com YIM: christina_wodtke
added filtering
I've updated the PDF document to include filtering. it's quite a powerful little tool now, IMO. I'd like a sanity chaeck on it's complexity, tho.
it's a very rough draft, without elegant visual design, but I feel liek the interaction is pretty solid.
BTW, the more I deal with Drupal, the more I'm convinced this functionality is critical. Esp post MT-import.
WEB: www.eleganthack.com YIM: christina_wodtke
Design for multiple node modification
Wow. Nice work, Christina. I'd say the design is nearly done, then. :) But seriously, there are issues. Responses and some questions that will probably need clarification by developers ...
Page 1: multiedit metadata; Page 3: workflow management
I really like the power editing page. I love the preview concept as you've illustrated it.
The multi-author functionality is one that I'm intrigued by. I'd like to see how that would be impleemented. On iaslash, for instance, we have over 1,100 users. How would that work with a drop down menu?
I actually think the numerous buttons on the bottom are a big improvement over the hidden functionality of the drop-down menus provided now, but it does seem complex the first time you look at it. I admit to not using those workflow features much myself, but as I understand it, this captures the functionality presently provided.
I wonder if the "save" button would be clearer if it read "save changes"? I almost want a horizontal separator between the Save buttons and the buttons below to show that they're separate groups of functions. What do you think?
The filtering drow down menus are almost perfect. There is the problem of the number of items in taxonomy and author lists. Will it be a bit unusable with large lists? How will multiple vocabularies be supported when doing category drop down menus?
Page 2: multidit vocabularies
This one is a bit tricky.
The vocab headings may not be as neat to align as indicated because different node types can require different vocabularies. This may be a minor problem, but wondering how this can be indicated differently if, using your image and blog types for example, the image uses an image vocabulary and the blog entry uses subject and people vocabularies. How will those headings and the alignment of columns be affected, esp. if you use many facets? Clearly this won't affect most people -- most people will use only 1 or 2 vocabs.
The "Add vocab" link seems to imply that you can add a vocabulary for modifying the node. As it works now, vocabularies are assigned to node types globally. I see the option of allowing this modification on the multi-edit screen to be an OK thing to pursue, but it may not be done very frequently. Is that OK?
I like the idea that clicking "Add term" opens a new window. I assume that window lets the user view all terms from one vocab and they can select one or more terms there, submit, and the original page is updated with the selected terms. We should add a status message, once the terms are added from the popup reminding user to save the changes.
Excellent
Excellent. Your sketch comes a long way explaining what you want, and how it should work. I'll revisit it as soon I have time to work on this (after the menu changes).
I had a long conversation
with my developer who is using drupal for a intranet at yahoo, and got a ton of excelletn advice on some of the problem areas. i'll be refining it and reposting shortly.
I almost want a horizontal separator between the Save buttons and the buttons below to disambiguate the separateness. What do you think? there is essentially NO visual design on this. I should warn you on that. Do you want to tidy up the designs? I'll admit I'm not the world's greatest graphic desinger.
c
WEB: www.eleganthack.com YIM: christina_wodtke
Maybe when these screens are finalized
Yes, I realize that these are wireframes. If a developer eventually wants to start coding this, maybe I or someone else can assist with the design. I'd be happy to, but also give the caveat that I'm only passable as a graphic designer.
that would be great.
Michael, from your site and your lovable tiny icons, I'm sure you are more than passable.
Bad news: I just crashed my laptop computer utterly. I may be delayed in updating the specs while I deal.
If people want to get going, here is a list of changes I suggest based on conversations I've had in the last day.
whew.
so for now I suggest "authors" be a sort-only field for now, like type. I did come up with a design where authors works.. the dropdown displays the author names until it hits 25, then shows a-e, f-j, k-o, p-z and shows a second dropdown with the authors names. and continues to subdivide as it hits numerical limits. What's nice about that is if it is applied to all fields, it will fix categories as well if categories gets humungeous.
But I have an hunch this should be be drawn to be understood).
thanks, and love feedback.
Move this to its own forum topic
Maybe we should summarize and move this feature specification to the new "Designs, mockups and specifications" forum as a separate thread. Your making some great progress with the spec.
another reason for multi-dele
another reason for multi-delete, edit, etc: importing from MT. the author tends to be anonymous, and categories of course are flat in MT, and *I* in my genius accidently imported the first 100 twice-- meaning I have duplicate nodes. sigh.
WEB: www.eleganthack.com YIM: christina_wodtke
WEB: www.eleganthack.com YIM: christina_wodtke
Access control...
I know this has been addressed elsewhere but its the #1 issue that makes drupal less than perfect for my needs.
I really want the ability to control read access by node/taxonomy by user/group. The groups module addresses this but it requires so many patches that it seems that there needs to be a core change in drupal to handle this. I've written up a diagram of the relationships I'd like to see regarding read access of nodes here: http://www.malfunct.net/files/diagram.jpg
As far as write access goes, there needs to be the existing content type restrictions per group and also if it were possible per user. There also needs to be a filter on available taxonomy to post in based on user and group (role in drupal terminology I guess). That would allow you for example to let people post stories and images in the public taxonomy but not in the private taxonomy.
Archived
These files are archived here: http://www.urlgreyhot.com/files/drupaldev/4.4-usability-report/.