Skip to main content

Blog Post

DrupalCon Chicago Day 2 Session Notes

Hello again from DrupalCon in Chicago. Today began with some interesting statistics from George DeMet and Tiffany Farriss about the WiFi usage at the event - over 4,000 devices connected to the conference's network yesterday, and now Clay Shirky is delivering a keynote about social media. I'll post updates from sessions again today, beginning with a BOF session at 11 a.m. which I am eagerly awaiting.

Karen Stevenson posted a session for "Multigroup and Nested Fieldgroups" in CCK-6.3. Multigroup is an interesting topic with a rich history, including an issue in the queue that lasted for two years and gathered 358 comments. Multigroup in CCK allows flexibility in setting up fields for a content type - for example having a "Phone Number" group that allows multiple entries so that the content editor can provide descriptors and numbers in paired fields. This prevents the need for setting up distinct, named fields for "Office", "Mobile", "Home", etc. Multigroup was bundled in CCK-6.3, which stood as a Dev release from June 2009 through February 2011 but gathered more than 15,000 users seeking the Multigroup solution. At issue currently is the direction for Multigroup functionality, including a few parallel efforts, and an upgrade path for Drupal 7. I've been working on a specification for a client site that depends upon Multigroup and hope to learn more about the future direction in the BOF session.

Multigroup and Nested Fieldgroups

BOF session led by Karen Stevenson

A group of 15 gathered in the BOF session to discuss CCK-6.3 and Multigroup. Karen provided a status update and overview that answered all of the questions I had hoped for. We reviewed the history and challenges behind the various "fieldable fields" attempts in Drupal 6 and discussed next steps needed for an upgrade path to Drupal 7.

CCK-6.3 has moved to an alpha release, and the expected destination for Multigroup in Drupal 7 will be Field Collection. Requirements from an enterprise site for one of Karen's clients at Lullabot helped fund and drive CCK-6.3 from dev to the release. The items that were holding up the release included testing, a Drupal 7 upgrade path and available time from the contributors.

In Drupal 6, not all fields will work within Multigroup. Most of the common/core CCK field types are fine (e.g. text, nodereference, date). The fields that do not currently work will not be addressed in Drupal 6 (active development targeted for 6 is being closed in favor of work toward the Drupal 7 path). Documentation is needed to specify which fields will not work with Multigroup in 6.

Two additional limitations in Drupal 6 include use of multiple value fields within a Multigroup and the ability to move fields in and out of a Multigroup. Neither is possible, but Drupal 7 will likely make these features possible. "The theory is in Drupal 7 we can do what we wanted to do all along - better," Karen said.

Field Collection in Drupal 7 is where the majority of the separate "fieldable fields" initiatives seem to have converged. It creates an entity that will accept fields.

Alex, the maintainer for the Flexifield module, was also in attendance. Upon learning that Field Collection is the emerging direction for fieldable fields in Drupal 7, he said he will likely target it as the upgrade path for the Flexifield module as well.

In addition to documentation, Karen asked for help in mapping out the Drupal 7 upgrade path. Suggested approach is to create a test in Drupal 6, then duplicate the content in Drupal 7 and compare the underlying data structures in order to map out the upgrade.

Those interested in contributing to the next steps should coordinate efforts in the CCK issue queue by using the content_multigroup.module component. Mrconnerton has taken the first steps by submitting an issue for documentation.

Design Thinking

by Jared Ponchot, Jen Simmons, Samantha Warren and Steve Fisher

From introductory video presentation: "Design is really about problem solving"

The panel pulled a series of Design Thinking definitions from various sources and discussed:

Definition 1: Design Thinking is a discipline that uses the designer's sensibility and methods to match people's needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.

Definition 2: A methodology for practical, creative resolution of problems or issues that looks for an improved future result.

Problem identification is the first step.

Showed a video covering the process and evolution of designing the DrupalCon visual identity and site.

Designer sessions sure do have nicer slides and videos in their presentations than other tracks at DrupalCon.

Now have a 2-day streak going of sitting in on panel discussions that like to make jokes about the Canadian pronunciation of "process".

"Who and Why" are questions one of the panelists likes to ask during exploration.

"There's a craftsmanship to what we are doing here."

Very nice video presentation with inspirational messages such as "trust your gut" and "ideas first" - went too fast to capture them all in notes but worth viewing later.

Q: Clarity is a goal. How do you bring clarity into it?

A: Often spend first part of the project confused, spend time getting to understand it for himself first. "You don't understand something unless you can explain it to a child."

Q: What was it like to work on a project with a specific purpose - e.g. drupalize.me

A: It was an iterative process, which gives freedom to the designer and can keep things simple in the beginning. Example of a very clear definition of purpose: it needs to play videos for people and we need to collect their money.

Social contribution: Neat video where a staircase designed as a piano encouraged its use instead of an adjacent escalator.

Sustainability: Bartik theme a good example (was created by one of the panelists)

Beauty: people often start with this but this is not where design thinking should start.

Phase2 Technology - has a new design studio site that is separate (and elegant) from main site.

Book referenced: "Designing for Interaction" by Dan Saffer

Find reference links at: http://www.delicious.com/hellofisher/designthinking

Summary: Design is important - and everywhere.

Baby Got Backend: Content administrators are users too

by Karen McGrane and Jeff Eaton

This session is about building out sites that someone has to live with.

Example: photo of a kitchen that needs remodeling. Just because you have a new kitchen doesn't mean you are going to be a good cook.

D7UX was remodeling the kitchen of Drupal. But that doesn't solve all of our problems.

We focus on making Drupal easier for site builders. But what about the people who use Drupal every day?

Content administrators are more important to the longterm success of the site. These people might be more important to the future of Drupal than the people at this conference.

Content administrators think about Drupal the way most people think about their cars. e.g. get me to the store. don't care what is under the hood.

Lots of preaching right now. Hope we are going to get to some actual ideas and suggestions soon.

Drupal won a showdown at SXSW against Wordpress and Joomla for ease of use by content administrators. Customizations in Wordpress tailored to blogging UX worked against it when solving for other features such as forums, events, etc.

Better interface widgets don't equal usability.

Better workflow equals usability. (groups, labels, steps, etc)

Drupal presents a data model, not a task model (e.g. here are nodes, here are users, here are fields)

How to do it:

  1. Listen to the content administrators. If your content creators don't have a voice, you're throwing money away. Analyze task completion like it's an ecommerce shopping cart. Get them to roleplay and document both online and offline workflows.
  2. Don't just understand the data, understand what they're doing with it. Content creators invent all kinds of workarounds. Understand how fields are used. Even new sites evolve quickly: "The Day 2 Problem".
  3. Keep asking "why?" and iterate, iterate, iterate. Think like the business. Why do they need to do a certain task? Don't just replicate existing mental models. Fast-and-crappy turns to polished-and-good with the right feedback.
  4. Optimize the workflow, not individual screens. Real content production is a process, not a single screen. Metadata makes flexible sites but complex workflows. Bulk tools: easy turns hard when you have to repeat it 10,000 times.
  5. Use repeating concepts, not just UI elements. Proper categorization and consistent labeling go a long way. Use similar visual cues for workflows across the site. Place similar fields in a consistent place across all screens.
  6. Accept that many good answers will be unique.

The better it fits one team, the harder it is to reuse.

Having a content administrator reference their site as "easy to use" is just as important a community contribution as releasing code back to Drupal.

Summary: great suggestions, but it would have been nice to see actual examples from some of the referenced sites to show the end results of this process being followed.

Drupal Monster

Albert Hughes, star of the new Drupal Monster rap video, just stopped by the Mediacurrent booth! I am now the proud owner of a "Geeked Out Exclusives" CD. If he comes back I aim to seek an autograph.

Jeff Diecks

Meet team member, Jeff Diecks

A veteran of the web publishing and sports media industries, Jeff draws on his extensive project management, business analysis, and site building experience to lead professional services and client delivery...

Learn more about Jeff >