[drupal-devel] two minor usability issues, introduced recently

neil at civicspacelabs.org neil at civicspacelabs.org
Mon Sep 26 21:46:54 UTC 2005

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

> 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.


More information about the drupal-devel mailing list