[drupal-devel] two minor usability issues, introduced recently
I just upgrded to HEAD and very much suprised to find two rather unfortunate usability iissues introduced: MBstring support? This seems to Just Work, why do I need a collapsed form element telling me it works? Joe user (and I) should not be bothered with form options that are no options. RSS in the global settings is a bit an unfortonate choice. first of all, the amount of items set gloabally: 1) why cant this simply respect the amount-of-nodes global setting? 2) RSS without nodes (in core) is non existing. Thus this is no common setting. Therefore I think this RSS setting should live under settings >> RSS settings, so that contribs can add LOCAL_TASKS or so. The current placement requires any other RSS setting (by a contrib) to be placed elsewhere. Scattered settings are one of the mayor usability issues in Drupal. I really think we must get such changes past at least some usability test before they hit core. PAtches are tested and tweaked on comma, tab and spaces level, yet usability is often simply ignored. Herein lies a great opportunity for the community, IMO. Ber
On 25 Sep 2005, at 11:01, Bèr Kessels wrote:
2) RSS without nodes (in core) is non existing. Thus this is no common setting.
The aggregator module has RSS feeds too.
Therefore I think this RSS setting should live under settings >> RSS settings, so that contribs can add LOCAL_TASKS or so. The current placement requires any other RSS setting (by a contrib) to be placed elsewhere. Scattered settings are one of the mayor usability issues in Drupal.
What other settings did you have in mind?
I really think we must get such changes past at least some usability test before they hit core. PAtches are tested and tweaked on comma, tab and spaces level, yet usability is often simply ignored. Herein lies a great opportunity for the community, IMO.
No, this change was a good thing (and tweaked to the comma). If this change needs to evolve, it can. Drupal evolves by means of incremental improvements and refactoring. We don't have usability tests -- how do you envision this to be done? -- Dries Buytaert :: http://www.buytaert.net/
On Sunday 25 September 2005 11:28, Dries Buytaert wrote:
We don't have usability tests -- how do you envision this to be done?
I know that adding the feature itself is a huge improvement! And I did know it has been tweaked over and over and over. What I am concerned about, is that in all that tweaking, usability sometimes is forgotten. And frankly, I have no idea what and how to include usability reviews in our workflow. Though they are very much needed. I hope we can add this to the agenda of the meetings in Amsterdam? Ber
On 25 Sep 2005, at 12:25, Bèr Kessels wrote:
I know that adding the feature itself is a huge improvement! And I did know it has been tweaked over and over and over. What I am concerned about, is that in all that tweaking, usability sometimes is forgotten.
Not at all. I've been advocating usability improvements for 2+ years now, and we've rejected plenty of patches because of poor usability. We've also successfully refactored parts of Drupal to improve usability. Of course, there has been the occasional regression -- typically in exchange for improved flexibility. I'd like to believe that, overall, usability is improving.
And frankly, I have no idea what and how to include usability reviews in our workflow. Though they are very much needed.
The short answer is that it is not feasible on a per-patch basis, unless someone throws a lot of resources (time, money, usability experts) at this. Let's focus on "global" usability reviews like the ones Kieran is conducting. Kieran is doing the grunt work, so we'll let him talk and guide. -- Dries Buytaert :: http://www.buytaert.net/
At 11:01 AM +0200 25/9/05, Bèr Kessels wrote:
MBstring support? This seems to Just Work, why do I need a collapsed form element telling me it works? Joe user (and I) should not be bothered with form options that are no options.
I get a message: "String handling method: Standard PHP: operations on Unicode strings are emulated on a best-effort basis. Install the PHP mbstring extension for improved Unicode support." This is information I need to know. And if I was having trouble with string handling, this is where I would look for something to tweak.
Therefore I think this RSS setting should live under settings >> RSS settings, so that contribs can add LOCAL_TASKS or so. The current placement requires any other RSS setting (by a contrib) to be placed elsewhere.
As a new Drupal admin it seems to me that if a module has settings then it creates a new settings pane like: ?q=admin/settings/pathauto I think I would be confused if modules started adding extra setting options into existing settings panes. Are there existing examples of this sort of behaviour?
Scattered settings are one of the mayor usability issues in Drupal.
That sure is the truth! ...R.
On Sunday 25 September 2005 12:06, Richard Archer wrote:
I get a message:
Well /i/ get a message that it is all fine. I dont want to know what went wrong, nor what went correct. I have my watchdog for that mainly. I we are going to display all settings that were correctly set, we'd have a huge amount of information.
This is information I need to know. And if I was having trouble with string handling, this is where I would look for something to tweak.
So, if it went wrong, you could have gotten an error. That would have helped you a lot, yet would not have left me going 'why the .. do i want to know that mbstring is correct'.
As a new Drupal admin it seems to me that if a module has settings then it creates a new settings pane like: ?q=admin/settings/pathauto I think I would be confused if modules started adding extra setting options into existing settings panes. Are there existing examples of this sort of behaviour?
Scattered settings are one of the mayor usability issues in Drupal.
That sure is the truth!
Case: node aggregator has some settings for this: how many feed entries to show etc. Now the current thing would enforce me to make a second page for RSS settings. Users should not have to visit two pages in different places to set their RSS settings. Users should definately not have to think about the diff. between modules and core, and then find out where modules have settins and where core has its settings. Ber
At 12:32 PM +0200 25/9/05, Bèr Kessels wrote:
Case: node aggregator has some settings for this: how many feed entries to show etc. Now the current thing would enforce me to make a second page for RSS settings. Users should not have to visit two pages in different places to set their RSS settings.
This is perhaps a terminology issue and one that has confused the heck out of me. On several occasions while I've been learning Drupal I have enabled the aggregator module in order to activate an RSS feed of MY news. When what I really needed to do was turn on the RSS block. A visible "RSS Settings" admin option would have helped. Except it would need to be called "Syndicate" because that's what the block is called :)
Users should definately not have to think about the diff. between modules and core, and then find out where modules have settins and where core has its settings.
Out of interest, why is it that module settings show up under the Settings admin menu option and not in a pane within the module's own menu option? For example... using HEAD, I go to administer >> contact form. Up near the top of the window I see: [list] [add category] Why isn't there a [settings] option up there. I'm already in the section of the site for adminstering the contact form. Why can't I alter the settings from there? Or is this the "scattered settings" mis-feature you're talking about? It happens with a few different modules (aggregator is another). ...R.
I fully agree that the split and un-standardized configuration screens are a major usability pain. Also along the same lines is that I routinely go to settings when I should be going to modules, and vice versa. I'm not sure which I do more often but I think it's going to modules first when I want to get to "a module's settings" (as opposed to "the settings for a module"). Currently it's possible to put the extra config screens for a module under the settings/modulename location, as a LOCAL_TASK. It's not documented as such, but I believe it's a good idea in many cases. They don't get the settings form magic, but who cares? It makes more sense than having some configuration under admin/settings/mymodule/ and some under admin/mymodule and some under admin/content/content_types/mymodule o_O. Random thought that I've not done any proper usability testing on yet: What about renaming "settings" to "system settings", and moving the various module settings pages under the "modules" menu, with the recommendation that extra pages go there as well as LOCAL_TASKs? That way the naming structure maps better onto "a module's settings". Thoughts? Flames? Reasons why it's dumb? :-) On Sunday 25 September 2005 05:53 am, Richard Archer wrote:
Users should definately not have to think about the diff. between modules and core, and then find out where modules have settins and where core has its settings.
Out of interest, why is it that module settings show up under the Settings admin menu option and not in a pane within the module's own menu option?
For example... using HEAD, I go to administer >> contact form. Up near the top of the window I see:
[list] [add category]
Why isn't there a [settings] option up there. I'm already in the section of the site for adminstering the contact form. Why can't I alter the settings from there?
Or is this the "scattered settings" mis-feature you're talking about? It happens with a few different modules (aggregator is another).
...R.
-- 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 Sun, 25 Sep 2005, Larry Garfield wrote:
I fully agree that the split and un-standardized configuration screens are a major usability pain. Also along the same lines is that I routinely go to settings when I should be going to modules, and vice versa. I'm not sure which I do more often but I think it's going to modules first when I want to get to "a module's settings" (as opposed to "the settings for a module").
Currently it's possible to put the extra config screens for a module under the settings/modulename location, as a LOCAL_TASK. It's not documented as such, but I believe it's a good idea in many cases. They don't get the settings form magic, but who cares?
As I developer I usually decide where I put my config screen by a simple rule of thumb: - if it is only a simple setting which the settings form magic can cope with, I use the settings hook. - anything more complicated gets its own screen. No, I am not defending this, just stating my current practice. I am pretty sure that other developers handle it similarly. Cheers, Gerhard
On 25 Sep 2005, at 12:53, Richard Archer wrote:
Case: node aggregator has some settings for this: how many feed entries to show etc. Now the current thing would enforce me to make a second page for RSS settings. Users should not have to visit two pages in different places to set their RSS settings.
This is perhaps a terminology issue and one that has confused the heck out of me. On several occasions while I've been learning Drupal I have enabled the aggregator module in order to activate an RSS feed of MY news. When what I really needed to do was turn on the RSS block.
This issue is new to me; I don't know about other people being confused about this. Interesting nonetheless. Maybe the module description (shown on the 'administer > modules' page) needs to be improved upon. Feel free to make concrete suggestions (or better yet, a patch against Drupal CVS). You know better than anyone else what could have avoided the confusion.
Out of interest, why is it that module settings show up under the Settings admin menu option and not in a pane within the module's own menu option?
It's a hard problem, but one we have to solve. I think we all agree that the current situation is a bit of a mess. An important part of the problem boils down to the question: "What exactly makes a setting?". For example, adding profile fields is an uncommon yet reasonably complex task. Is it a setting or not? Does it belong under: 1. administer > settings 2. adminster > profiles 3. administer > users > profiles 4. <something else> I believe Kieran's usability study will help us reorganize the administration section, however, maybe not at this level of detail. We'd have to ask Kieran. What would be really useful for us, is for you to compile a list of situations where you expectation did not match the actual location of a setting/task/function. If we had a dozen such lists from different people, we might see a pattern or two. -- Dries Buytaert :: http://www.buytaert.net/
It's a hard problem, but one we have to solve. I think we all agree that the current situation is a bit of a mess. An important part of the problem boils down to the question: "What exactly makes a setting?". For example, adding profile fields is an uncommon yet reasonably complex task. Is it a setting or not? Does it belong under:
I think the criteria should be: "it's a set-up task or an everyday task?". Moderating comments, editing entries, adding categories, managing users, are every-day tasks. Adding profile fields is a set-up task, because you rarely add a profile field. In my opinion it would help if every setting went into admin > settings, so you know clearly where to head to when you need to change the configuration of any module. And the average admin user would spend very few time in this pages. Reviewing this should not be too hard. álvaro
At 11:02 PM +0200 26/9/05, Dries Buytaert wrote:
This is perhaps a terminology issue and one that has confused the heck out of me. On several occasions while I've been learning Drupal I have enabled the aggregator module in order to activate an RSS feed of MY news. When what I really needed to do was turn on the RSS block.
This issue is new to me; I don't know about other people being confused about this. Interesting nonetheless. Maybe the module description (shown on the 'administer > modules' page) needs to be improved upon. Feel free to make concrete suggestions (or better yet, a patch against Drupal CVS). You know better than anyone else what could have avoided the confusion.
If there had been an item which mentioned RSS or syndication in the administer menu I would have clicked on that instead of looking around for a module to enable RSS feeds. Concrete suggestion: Create a administer > syndicate menu item which contains the RSS Settings content from the current global settings page. Add some help text to this page informing the user that they need to enable the Syndicate block to publish a link to their feed. Attached is a first cut of a patch that does this.
Out of interest, why is it that module settings show up under the Settings admin menu option and not in a pane within the module's own menu option?
It's a hard problem, but one we have to solve. I think we all agree that the current situation is a bit of a mess. An important part of the problem boils down to the question: "What exactly makes a setting?". For example, adding profile fields is an uncommon yet reasonably complex task. Is it a setting or not? Does it belong under:
1. administer > settings 2. adminster > profiles 3. administer > users > profiles 4. <something else>
I believe Kieran's usability study will help us reorganize the administration section, however, maybe not at this level of detail. We'd have to ask Kieran.
What would be really useful for us, is for you to compile a list of situations where you expectation did not match the actual location of a setting/task/function. If we had a dozen such lists from different people, we might see a pattern or two.
My goal at present with Drupal is to set up a very simple Drupal installation which I can hand over to non-technical people to manage. So I have disabled as many modules as I can but I'll offer some feedback on the modules I have used. contact.module I expect to go to administer > contact form and have all the configuration options for the contact module available with an extra "settings" tab for the options currently found on the page: administer > settings > contact form. users.module Once again, I expect to go to administer > users and have all the configuration options for users available with a settings tab containing the options from current administer > settings > users. aggregator.module Same again. I would expect to find the content from administer > settings > aggregator in a settings tab on the page administer > aggregator I have attached patches for these three modules so you can try this system out and see how it handles. Patches are against HEAD. I also noticed that comment.module is structured in this way already. You go to administer > comments and you have list and configure tabs. This could just as easily be set up with the "new comments" and "approval queue" as the tabs and the contents of the configure tab on an administer > settings > comments page. As for profiles... that's a tricky one. I think I would have it as administer > profiles for a couple of reasons. 1. It's a module which can be disabled and enabled. And from a usability standpoint it would be best to have a new admin menu appear once the module has been enabled so the user knows where to go to configure the module. 2. I notice that the profile module does not adhere to the Drupal user interface "standard" of having a "list", "add category" and "add field" tabs. Instead it has the clunky "add new field" section. And once the user is in there they need to key in the name of the category... I hope they remembered it! This needs to be refactored. 3. This module is crying out for some reporting to be added and if that gets done it makes more sense to have an administer > profiles section which contains the settings and reporting rather than have it all hiding in a tab on the administer > users page or a settings page. ...Richard.
On Monday 26 September 2005 23:02, Dries Buytaert wrote:
This issue is new to me; I don't know about other people being confused about this. Interesting nonetheless. Maybe the module description (shown on the 'administer > modules' page) needs to be improved upon. Feel free to make concrete suggestions (or better yet, a patch against Drupal CVS). You know better than anyone else what could have avoided the confusion.
My €0.02 I used locales to differentiate this as follows: * syndication = outgoing: we provide these feeds. * aggregation = incoming: we read/import these feeds. This unity made it clear enough for a complete n00b client to grok the concept. She had never heard of RSS/XML before and was completely confused about what was what. I just removed the words RSS/XML everywhere (in locale) because they do not communicate whether they provide of import. And used the abovementioned words only. Bèr
Op 25-sep-2005, om 11:01 heeft Bèr Kessels het volgende geschreven:
I just upgrded to HEAD and very much suprised to find two rather unfortunate usability iissues introduced:
MBstring support? This seems to Just Work, why do I need a collapsed form element telling me it works? Joe user (and I) should not be bothered with form options that are no options. This is there for a long time.. We already did this or the first time when the image handling kicked in.. I already fought against that and then nobody seems to care, now it looks like it's logical to everyone to not display these messages. (See my reviewing about walkah's image api -> core)
I did comment on that after the image-api hit the trunk.. Why do we want to know when something does succeed?? That does not matter! Everybody who uses software does think everything _will_ work well, and only needs to knowhen therre is something wrong, not which settings are right... Though, something else I learned some time ago is why we use radio buttons for option to enable/disable them.. Isn't a checkbox ment to do that? checkbox checked is 'enabled', checkbox unchecked is 'disabled'.. Checkbox class => 'disabled' is not supported.. There is a lot to improve and it needs a lot of time and love.. I would love to do some tweaking here and there, make notes, etc, ec, and share/discuss then with you all.. Looking forward to some other ideas and suggestions... Stefan
On Sun, Sep 25, 2005 at 11:01:26AM +0200, B?r Kessels wrote:
I just upgrded to HEAD and very much suprised to find two rather unfortunate usability iissues introduced:
MBstring support? This seems to Just Work, why do I need a collapsed form element telling me it works? Joe user (and I) should not be bothered with form options that are no options.
There are a few of these checks: - Is the image library working? - Is the files directory working? - How updates is the search index? - Is string handling working? And a couple I would like to see added: - Is cron working (has it run recently)? - Is the site throttled? These could all be grouped into one screen. Perhaps using some valuable real-estate on the admin front page if only non-working things are shown.
RSS in the global settings is a bit an unfortonate choice. first of all, the amount of items set gloabally: 1) why cant this simply respect the amount-of-nodes global setting?
I think we should just stick to one hard coded global number of items. There is no need to set this since 10 or 15 should be good for all aggregators. RSS is a different view whose number of items doesn't have much to do with the web view.
2) RSS without nodes (in core) is non existing. Thus this is no common setting. Therefore I think this RSS setting should live under settings >> RSS settings, so that contribs can add LOCAL_TASKS or so. The current placement requires any other RSS setting (by a contrib) to be placed elsewhere. Scattered settings are one of the mayor usability issues in Drupal.
I really think we must get such changes past at least some usability test before they hit core. PAtches are tested and tweaked on comma, tab and spaces level, yet usability is often simply ignored. Herein lies a great opportunity for the community, IMO.
I'd avoid adding rules. Comitted patches can always be refactored for UI later. This happens with code too. I think the best thing would be some way of making UI changes more findable for review. I think this would allow for time UI people give to Drupal more well-spent. -Neil
On Monday 26 September 2005 23:30, neil@civicspacelabs.org wrote:
I'd avoid adding rules. Comitted patches can always be refactored for UI later. This happens with code too. I think the best thing would be some way of making UI changes more findable for review. I think this would allow for time UI people give to Drupal more well-spent.
the big problem with this is that refactoring a UI requires coding too. Most Usability experts care not/cannot/will not code. Thus usabiltity 'feature' request will stick as issues in the queue forever. They will because they do already. Somehow developers do not pick up these features from the queue, when they do not have a patch. (and I know why....) So if we want to cater these experts we need to help and include them in our process. Not bolt some usability review on top. And optionally (never) fix issues afterwards. Cateering them would mean: screenshots, example or test sites, etc. I found that when a screenshot is submitted the UI oftne comes out much nicer then when it was not. Because -i assume- usability reviewers find it far too much hassle to maintain local devel sites where they can apply patches. Usability, code style(ity), security, feasability, flexibility are all of equal importance in Drupal. That is quite unique, but a very good thing. Developers often care about only a few of these -itys. Making it go trough more people ensures that most of the itys are touched and reviewed. And to allow different people to look at this in differen ways we need to cater these. Ber
participants (9)
-
Bèr Kessels -
Dries Buytaert -
Dries Buytaert -
Gerhard Killesreiter -
Larry Garfield -
neil＠civicspacelabs.org -
Richard Archer -
Stefan -
Álvaro Ortiz