We need to come up with a good name for a CSS class, but I don't want this discussion to clutter up the issue queue. (Let's reserve the queue for presenting and discussing patches that fix functional or programmatic problems.) So I'm posting this item to see if we can develop an idea that is better than the ones we've already come up with.

An important feature request for Drupal 7, Skip Navigation' should be in all core themes, provides one way to ensure that Drupal-based sites can comply with WCAG 2.0 Guideline 2.4.1, Bypass Blocks:

A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

Part of this patch involves naming a class for the links that perform this function. The working name for this class, "skip-nav," is bad because:

• The abbreviation "nav" raises problems.
• This function can actually be used to let people skip any part of the Web page, not just a navigation menu. (So "skip-navigation" doesn't work, either.

So, we're wondering: What would be a better name for this class? Following the name of the WCAG Guideline we are addressing would give us "bypass-block." But, because "block" has a more specialized meaning in Drupal, that doesn't quite work.

How about simply "bypass"? Or "bypass-for-accessibility"?

Or a better idea of your own?

Fellow Media Moguls,

We're shaking off the dust from the Media module, which was sadly neglected during the heady Summer of Code, where we got Stream Wrappers into core! I'm excited to meet now with my fellow Drupalistas, and get the module presentable for Drupal 7 (and Drupal 6, if anyone is interested in helping on that front).

Come to the Mansueto offices in NYC on October 23-24 for a Monster Media Sprint! Let's bring the #D7UX Media Microproject to life!

I'll concentrate the next few weeks on working out a game plan, so that we can start the day off running. All levels of expertise are welcome! We'll have tasks and coffee for everyone...

Important note: You must pre-register, and you must have your Full Name in your profile, or you won't be admitted into the building.

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.

He was using Drupal a little while back, when a lot of modules hadn't been upgraded to Drupal 6. This was a source of some frustration to him, as it has been to other users. What also frustrated him, however, was the lack of compatability between modules written for Drupal 5 and Drupal 6 core.

My reaction was to explain why this isn't possible: changes to the API in core necessitate a complete rewrite of modules. His point was that this is different to how other systems work: he was familiar with operating systems like Windows which usually support programs written for earlier versions. Think of Drupal core as the operating system and contrib modules as the programs and you get a good picture of what my friend expected should happen.

So, my question is: would it be possible to write some kind of compatability layer that allowed modules for D5 work in D6, and modules for D6 to work in D7?

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.

There are several events coming up, camps & meet-ups where participants would be able to sit down and run several user tests.

We want to make it easier for people to participate.

Problem:

• New contributors to the Drupal Usability effort may not know "where the action is"
• An install of Drupal 7 won't have appropriate patches applied to it
• Errors with only one user do not display a pattern; we need multiple occurrences of the same error
• Patches which need to be tested might already be out of date (the drop is always moving)

Solution:

• To identify patches which represent changes since the last d7UX tests done in Baltimore.
• These patches can then be applied to a demo site which incorporate changes and can be crowd-source tested.
• Hot patches need to be tested an updated.

How to:

• Run latest Drupal 7, apply these HOT patches listed below
• Conduct Crowdsourced Usability testing as proposed by Leisa, and described in detail here: http://rufzeichen-online.de/category/news/planet-drupal-english
• Bojhan and Yoroy are working on an updated test-plan and script to follow. Coming Soon!

Hot Patches!

Shortcut bar (Admin header/Overlay)
http://drupal.org/node/517688
isn't this the overlay?

D7UX: Implement customizable shortcuts for the toolbar
http://drupal.org/node/511286

Edit links everywhere
http://drupal.org/node/473268 => D7UX: Put edit links on everything => Drupal, theme system, critical, needs review, 89 comments, 19 IRC mentions

Textfield to slider behavior
http://drupal.org/node/565312

Usability: Improve help text in block.module
http://drupal.org/node/340535

"Show on all pages" - block specific settings
http://drupal.org/node/514256

Submit & Save buttons light grey, not noticeable
http://drupal.org/node/573138

D7UX toolbar: Usability in narrow viewports
http://drupal.org/node/515334
Other patches

Menu name = node title upon node edit through user interface
http://drupal.org/node/410464
Video of latest patch for this: http://vimeo.com/6557401

New field type for profile: taxonomy
http://drupal.org/node/19014

Dashboard Module
http://drupal.org/node/544360#comment-2024234

"Save draft" Button
http://drupal.org/node/282122
This does not even have a patch - but is to be watched closely, since it changes publishing workflow quite a bit.

Use Seven theme for installation/upgrade
http://drupal.org/node/547068
Made a video of this difference: http://vimeo.com/6561926
If you want to test installation with someone, the reactions to the changed looks would be interesting. This is in the google repository version.

Add colouring and description to password checker
http://drupal.org/node/331893#comment-2024938
See video of the current patch: http://vimeo.com/6546877

Config and modules page
http://drupal.org/node/508458

Add UI text to make date format choices less ambiguous
http://drupal.org/node/279570
- this is being mooted by a major change to date localisation.

Committed

Wow, the drop really is always moving. Since this list was made a few patches have already gotten committed. But we may want to pay attention to usability issues arising out of their inclusion.

Position of teaser field above main text field in Node form.
http://drupal.org/node/513414
User-Test Position of Teaser field above main text field in node form
[This patch has been committed as of 11 Sept]

Improve taxonomy help text for vocabularies (duplicate)
http://drupal.org/node/31394 (this was turned into duplicate issue after 'remove wall of text' http://drupal.org/node/570440 )

Join!

Add hot patches to this list, run tests on the patches or sign up to take part in this effort. You need a minimum of 15 minutes with a user, screen recording software, a good mic, and some time to write up your findings.

There is currently an open issue in the d.o issue queue Add colouring (and description) to password checker (#331893). The issue hasn't received much attention lately and I am curious what thoughts there are from usability and accessibility folks on the proposed patch in comment #36.

This patch essentially tests the password strength and displays a growing colored bar which changes colors depending on password strength. The patch also displays text to represent the strength of the password.

From an accessibility perspective I believe that it is critical to display the textual representation of the password strength.

I also think that it is important to define a method through which themers can override the default colors used to indicate weak, fair and strong password strengths.

Mike Gifford (mgifford) and Everett Zufelt are addressing a major accessibility issue for the administration interface of Drupal 7. If they had help from someone with JQuery skills, they could make significant progress. If you think you can help, check out http://drupal.org/node/467296.

Code freeze for improvements to accessibility and usability is November 15, so your help now can make a drastic improvement in the Drupal experience for people with disabilities. Also, by improving the accessibility of Drupal, you will be making it possible for more governmental agencies and local governments to adopt Drupal as their CMS of choice.

This module implements major features of Slashdot moderation and comment system. I made a few attempts previously with various hacks/modules, but this module is very mature and fully compatible with latest VotingAPI. I have not encountered any issues using this module.

What it does:
Transforms comment controls to Slasdot type (thresholding).
Displays each comment slashdot-type.
Hides comments below threshold. Hidden comments can be uncollapsed by a click.
Provides slashdot moderation system (troll, interesting, insightful, funny, etc).
Own comments stand out.

TODO:

• Ajax comment moderation
• Integration with Karma/Userpoints
• Meta-moderation
• Limited modpoints

You can download the module from my website: http://www.mukhsim.com/blog/slashdot-style-comment-moderation-drupal
Please take a look at the module and let me know what you think.

Also, should I be releasing it into Contrib?

Max.

This module adds a "delete" MENU_LOCAL_TASK to all nodes and removes "delete" button from all node forms. While this module is very simple and may not seem important for a developer, it does provide a significant improvement for content publishers/maintainers, especially to those who are new to Drupal.

Please leave your feedback.

Also, can I submit it as a contributed module?

deletetab.info:

deletetab.module:

There has been a lot of informal talk about Drupal’s issue queue. For designers and non-technical people, it can be a confusing place. And while there has also been some talk about creating a separate place to discuss design-related issues (for example), the simple fact is: the issue queue is where developers get informed about problems and requests and that’s the place where they organize the work that they do. If non-developers want to improve the code, they have to use the issue queue.

However, there is a lot that could be done to Drupal’s issue queue to make it much easier to use and to navigate. It’s simply a matter of identifying the UX and IA problems and finding solutions for them. So let’s start talking!

And, of course, after we brainstorm, we’ll need to move individual solutions into the issue queue so we can get them fixed! :-D

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:
http://drupal.org/files/issues/find-content-proposed.gif

For reference, here is the current form:
http://drupal.org/files/issues/find-content-current.gif

Does anyone see disadvantages to this design? The proposed form is simpler with no radio buttons and allows multiple filters to be applied in a single submission.

Next Conference Call (Skype)

Monday July 27th,
2pm Eastern Time

If you want to participate please email everett@openconcept.ca

Agenda

• Theme Changes
• Form Changes
• jQuery Changes

Participants

• Mike Gifford
• Everett Zufelt
• Katherine Lynch
• Brandon Bowersox
• William Lawrence
• Kathy Kahl
• Ann McMeekin
• Jeff Burns

Links

• Outstanding Accessibility Issues http://drupal.org/node/364629
• WCAG & ATAG Checklists - http://groups.drupal.org/node/18595

The thought came up a couple days ago, during the conversation with Robert Castelo.

We could use our office space in Holborn, Central London. We can have 2 days on Saturday 22nd and Sunday 23rd of August.

Let's focus on improving the user experience on Drupal.

There's no agenda yet.

Your thoughts are welcome!

This Wiki page summarizes the UI needs for the D7 Field API, to get the ball rolling on design discussions.
Discussion currently takes place in the comments here - or is there any other place more in line with D7UX habits ?

Introduction

A good UI for D7 Field API remains to be invented - esp. when considering a couple new features compared to CCK D6.
To be extra clear: I personally (yched) will not have the time to lead a Field UI brainstorm and the ensuing implementation work, but I do have a couple ideas / intuitions, and will happily participate and feedback if such a community effort happens.
I also did not closely follow the ongoing D7UX work, and might easily miss some UI concepts raising there which could reformulate Field UI issues.
Bojhan and yoroy have expressed their intention to bump this during the forthcoming UX sprint, which is IMO the best thing that can happen :-)

Core or contrib ?

From back in DC Barcelona (sep 07), the 'Fields in Core' roadmap was "API first, UI can remain in contrib for a release cycle" - main reason was to reduce the amount of code to make 'core worthy'. Another good reason is: UI in core means it's frozen until D8.
OTOH,
- the ultimate goal is still to have the UI in core at some point - earlier is better, of course
- it is now obvious that the Field API will remain under-used (and thus under-tested and fine-tuned) unless it ships with a native UI in core. The UI itself will get more eyes in core.
- the D7UX movement is a great opportunity to try to get this right.
The design and coding work done with core in mind will be profitable anyway.

CCK HEAD (tarball, or from CVS HEAD) currently provides a "working" Field UI.
- 'direct' port of the CCK D6 UI - general agreement is that D7 should aim at much better.
- some features are not addressed (formatter settings, storage indexes, per-context order and grouping)
- the organization of subforms for field settings is sub-optimal
- generally still rough on the edges
Participants are nonetheless highly encouraged to install and play with it, to see where we start from.
A couple screenshots are included in the various sections below.

So, here we go:

Fieldable entities, bundles ("= node types") and pre-existing UI

Fields are not tied to just nodes: taxonomy terms, users, other contrib stuff that core doesn't even know about (fictional, possibly irrelevant examples: webforms, panels...).
Each fieldable entity choses what are its 'bundles', i.e what defines which set of fields a given object has: node type for nodes, vocabulary for terms... If it helps taking the leap from CCK D6, think 'node type' whenever you read 'bundle' below.

Each fieldable entity will have its own UI for managing those bundles: create/edit node types, create/edit vocabularies... Field UI has no control on this.

-> Requirement: the Field UI will need to tie itself easily to any existing UI for core or contrib entity types and their bundles (and/or define a set of reasonable UI patterns that fieldable entities need to follow). But: even though "create a node type or a vocabulary" and "set up its fields" are different UIs handled by different modules, users will most likely see this as part of the same "task", so we might need to think of ways to make this the most fluent we can.

Current UI screenshots: Access field UI pages,
- for nodes (+ links on node type overview)
- for taxonomy terms (not integrated to the 'vocabularies overview' page yet)

Fields, field instances

Field API internally deals with two separate structures:
field: roughly, the definition of a storage 'bucket' (think: a set of columns in a db table)
field instance: the attachment of a given field to a bundle ('node type').
Example: all node types have an instance of the same 'body' field.
This is what lets Views or custom code query a given field across node types: "Select all 'Person' and 'Business' nodes where 'City' is 'Paris'."

Current UI merges the two notions - can be debated, but is OK IMO.
"add new field to a bundle" = create field + create instance,
"add existing field to a bundle (shared fields)" = create instance.
"remove field from a bundle" = delete instance, delete field no more instances
The UI has no way to create a field with no actual instances.
Current UI screenshots:
- 'Manage fields' tab: add fields to a bundle, reorder them, change their settings, remove them
- Overview of existing fields at admin/build/fields (not tied to any bundle admin page) - with links to the 'Manage fields' page for each bundle

Widgets, formatters

Pluggable handlers that define how fields appear in edit forms (widgets) and in displayed objects (formatters).
Available widgets and formatters depend on the field type. Contrib modules can add new widgets and formatters for existing field types.

Settings

Here's a list of what users can set up in a field:

• field properties: things that will be the same in every bundle where the field appears.
  • type (text, number, image...), name, cardinality (single value, multiple values), db columns to index
  • settings specific to the field type: maximum length of text fields, precision of decimal fields...
    Most of those settings directly impact the storage thus and cannot be changed after creation.
• instance properties: can be different in each bundle where the field appears.
  • weight (order) label, description, required, default value
  • settings specific to the field type: min and max value for number fields, formatted text / plain text...
  • widget used in forms, with settings specific to the widget type: number of rows in textarea...
  • display settings: for each display context ('build mode', see below)
    • label display options : above the value, inline with the value, hidden.
    • formatter used to display the values: link to img, imagecache derivative... - or 'hidden'
      with settings specific to the formatter (new in D7, not handled in current UI): number of decimals, imagecache preset, autostart for media player...

-> UI workflow dependencies, some of which are challenging:
- pick a field type -> pick a widget, pick formatters
- pick a widget -> define the widget settings; change widget -> the settings form changes
- pick a formatter -> define the formatter settings; change formatter -> the settings form changes
This requires forms to be split into independent subforms (or intelligent AHAH form update, which might be tricky).
IMO, only Views or Panels UI and their AHAH subforms/modals made good UI translations of those patterns so far. Heavy supporting code.
The ongoing work on 'Harmonicas' might be precious here.

Current UI screenshots:
Field settings subforms. Probably not the best we can imagine.

Build modes and display settings:

Build modes are the contexts in which the objects can be displayed (for nodes: full node, teaser, rss, search index, search result...)
Each build mode has its own set of fields visibility and display settings.
Each fieldable type declares what build modes it uses - extensible by contrib modules according to their own features: Print.module adds 'print' mode for nodes; an easy module would provide a UI to let admins define custom build modes, and thus define 'display styles' (fields display settings + matching .tpl's and CSS), to be easily reused in several places (Views, custom code...).

-> Requirement: the UI needs to scale for 10+ build modes for an entity type.
(sounds like a use case for vertical tabs ?)
Maybe a good use of vertical tabs might allow us to merge both 'Manage fields' and 'Display fields' screens to a single page.

Note:
"fine tune formatter settings for 'rss' mode" could be argued to be an 'advanced' task
but "define which fields are visible in teasers" is a pretty basic task.

Current UI screenshots:
'Display fields' tab: define fields display settings for the various build modes (note: forget the 'Exclude' column, it's on the way out). Currently does not provide access to formatter settings.

Ideally: field order per context

One order for forms, a different order for node pages, yet another one for teasers...
Would also be cool for fieldgroups: different groupings on forms, full nodes, teasers...
Not done yet in code (easy), but more complex as a UI.

Problem: Combine this with "10+ build modes" and it easily turns in config hell:
"How many things do I need to configure just because I added a new field, or enabled a module that silently adds a new build mode ?"
I proposed a possible approach in http://drupal.org/node/367498#comment-1232096, but it could very well be far-fetched or ill-designed.

Fieldgroups / combofield

TODO
- different notions of 'grouping' in D7: (HTML) fieldsets, sets of vertical tabs, D7UX's 'meta' section
- how can different 'grouping' notions be plugged from contrib ?

Module-defined fields

How does Field UI treat module-defined fields ?
Current scenario: all instance settings (order, label, widget, display) can be changed by admins in the UI.
Field / instance deletion: A module defining fields and instances might break if they get deleted.
-> Field UI should forbid the removal of module-defined fields and instances.
But : an admin can add a new instance of a module-defined field. It should then be able to remove that instance.

Form_builder

Quicksketch's Form_builder is a spectacular piece of work in itself. I'm personally not sure it can be the basis of a Field UI - but would be happily proven wrong.

• Fields are much more than widgets, as the list in the 'settings' section above clearly shows. How can form_builder account for field settings, instance settings, display settings ?
• Usability: do we want to be working on a (massive) 'form edit' form whenever we're adjusting field properties ? For day-to-day work, the CCK D6 'manage fields' tab is IMO much more usable.
• Manipulate different object:
  Form_builder: "pick a widget and fine-tune its settings". Field API: "pick a field type first, available widgets (+ other things) ensue".
  Seamlessly tying those reversed API logics could be tricky.

More conceptually, what is the user's mental target when he defines or adjusts fields ?
I'd personally tend to think "a list of information bits" more than "an input form".
Input forms are merely a way to fill in actual data on your site. But you target your data and how you want them displayed to your users, more than the input form seen by content authors.
Different use case than webform.module, in which you actually design a form.

Also: content (nodes or other fieldable content) can be created programmatically, imported, aggregated... For those cases (which will only get more frequent IMO), primarily designing an input form is counter-intuitive.

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.

As for most of our sites we want to turn revisions on for all content types, a module (or D7 core patch) to do this from somewhere with a single switch (or checkboxes for all content types in one place) would be nice.

Questions:
* Is there already a module that does this, hiding from my searches?
* Should other per-content-type workflow settings also be centralized?
* Where should centralized settings like this live in the administration menu?

^{benjamin, Agaric}

Excuse the hyperbole, but...
I really think the biggest problem from a designer/developer/admin's perspective is:
Not enough module specificity. By which I meant that module's are not specific (ie small) enough.

I'll illustrate by way of example:
I built an online classified web site (www.bandbswapshop.com), and had some difficulties with one particular aspect. I wanted the admin to be able to create a user and a Classified Ad at the same time.
In order to make this happen, I had to contract someone to program the php in the ed_classifieds module to create that form and hook it into the user signup module.

In and of itself, not that big a problem. But it made me realize that what Drupal needs is a bunch of very small modules that do one very specific thing. I mean, I can think of lots of other people who might want to create content and a user at the same time. Unfortunately, that bit of code is not stuck in ed_classified, not in a separate module. That is just one example.
I can think of several other examples where this happens. Where there is one aspect of a module that i'd like to plug into some other content in Drupal.

What I'd like to see is a concerted effort to keep things small. Keep things fine-grained.
The ship may have set sail on Drupal as a CMS to be fine-grained, but modules are certainly still being developed and still able to be influenced.

FWIW I am a usability specialist (MS in Human Factors Psych) who fell into Drupal development. I have now developed a dozen or so sites completely. So, I've been on all sides of this issue.

Thanks
JR

I have trouble finding icons sometimes for my designs. Thought this might be of help...

http://www.smashingmagazine.com/2009/06/07/50-fresh-useful-icon-sets-for...

Welcome, how nice of you to drop by! Post a comment, say hi, see who else is about. Let us know what you'd like to do here so we can help you do it!

Get started with Drupal 7 UX

• D7UX microprojects! It's the new thing especially for you to get involved in Drupal 7 UX design.
• D7 UX project framework
• UX issue queue proposed changes to Drupal that need your review
• Say hi in IRC, #drupal-usability on freenode.net

There is quite a lot of work that needs doing and many ways you can contribute. It's challenging, fun and not as scary as you might think! Also, it will give you valuable experience in working the open source process and maybe even that warm fuzzy feeling of getting your contribution committed to the actual Drupal software.

People to look for and where to find them

bojhan, yoroy and webchick are some of the names you want to look for if you have questions about all of this. The team is certainly bigger than that but these folks generally know what's up. Feel free to contact them. The easiest way to find us is to join the Drupal group chats on IRC. We're in #drupal-usability on irc.freenode.net, here's the info on how to get on there and here's even more

But yeah, start with saying hi in the comments! :-)

This might be a Zen-theme specific issue, so forgive me if that is the case.

If I want to make the Primary Links block not appear, then I do so from the "Blocks" page. But to make the items in "Primary Links" not appear as tabs at the top of the page, then I do so from the in "Toggle Display" section of the the Administer-->Site Building-->Themes-->Configure page.

I wanted to recommend that the wording be changed from "Primary Links" to "Display 'Primary Links' menu items as tabs", in the "Toggle Display" section, since I am actually choosing whether or not to display them as tabs, rather than whether to display the "Primary Links" block.

Is there a reason that this would not be a good idea?

Thanks,
jrtayloriv