core-ui

We would like a "quick" way to change a user's "Status" from "Blocked" to "Active." Right now it takes about 3-4 clicks, and then save the User edit form after selecting the "Active" radio button.

When there are dozens of users, this can be tedious. The website client doesn't want users to be "Active" until after careful review...

I've transferred this discussion from the forums at http://drupal.org/node/572734, where it had died a death. Here's what I wrote there. Any thoughts?

Following all of the stuff at Drupalcon Paris about Drupal moving from a service to a product that is friendly for end users, I was having a discussion with a friend of mine who has used Drupal in the past. He isn't a developer or coder but he's not non-technical, either.

This is a HOT page, hot topics. Please edit and add topics.

Eigentor & I prepared this after chatting with Bojhan and Yoroy. All are invited to submit suggestions.

Drupal 7 is at a critical stage and requires user testing. This page is to help prepare a demo-site to make it easy for new user-testers to join in, and make a significant contribution to Drupal development. This will ensure that pivotal patches get the user testing they need, and that we don't trod old ground and waste time.

The 'Find Content' form has a prominent place in Drupal 7. However, the form poses accessibility challenges. The filter form is composed of radio buttons and dropdowns that visually correspond for sighted users but there is no indication they correspond for screen-reader users.

I've proposed a change to the Find Content filter form. I'm seeking feedback here and in issue #551034. I believe the change is a win-win for accessibility and usability.

Here is a screenshot of the proposed form:

Hi folks,

Currently in Administer>>User Settings you can customize various aspects of user registration, but not, as far as I can see, what the user sees when editing their account information. This would be helpful. Also, depending on the site configuration, there can be a lot of stuff between the top of the page and the "Save" button. Might be nice to have reminders for the user to click "save" when making changes.

Many Drupal sites run by non-profits also use CiviCRM. Many of those have memberships in the organizations managed by CiviCRM. When a user visits a site of a membership organization that uses CiviCRM and goes to the "My Account" page, s/he will see "Member for x years and x months".

I think Drupal should not use the word "member" on this page. This "membership" will likely bear no relation to the user's membership in the organization and is confusing.

I think future Drupal releases should replace the word "member for" with "registered website user for" to be as clear as possible.

There are many Drupal 7 core issues that are tagged as "Needs usability review". It would be awesome to try and keep an eye on this list and review UI changes that are going in to core/7, with the aim of trying not to degrade Drupal usability further with un-monitored changes, as we usually do in Drupal core. The most important ones to review are the ones that are in the review process, marked RTBC or recently committed.

Vertical tabs are finally in Drupal core!

Screenshot of vertical tabs on an 'Article Edit' page in Drupal 7.

A week ago Angie "webchick" Byron committed a large patch from #323112 Vertical Tabs to Drupal 7 core. This change is quite possibly the most significant usability enhancement to Drupal 7 to date. Two of the three formal usability tests did usability testing with vertical tabs and reported positively.

Screenshot of a 'Story Edit' page in Drupal 6, before vertical tabs.

UPDATE: Rob Loach has created a patch to implement vertical tabs on the node-type form.

UPDATE: See other issues about vertical tabs in Drupal core .

What is more interesting about this however, is the process, time and effort that it took to get this change into Drupal core. It all started over a year ago, well before DrupalCon Boston 2008 even before Drupal 6 had a stable release. The discussion around part of that patch goes back as far as November 2007! Along the way countless people have been involved in many discussions, worked on heaps of mockups, lots of prototypes, and loads of code.

Read more

I have run into a limitation with the processing of menu items. If I enter a URL into the link, such as "about" (where I have a page with URL "about"), then the system replaces this with something like "node/8". That is problematic because I entered a logical reference and ended up with a physical reference (which is always inflexible design). So if I replace my about page later with a fresh one that has a different node number, then I have to go through all the menus looking for items that referenced about, and re-entering "about" or entering the new node number.