Bryan Braun (@bryanebraun) gave a refreshingly opinionated talk Empowering Content Creators with Drupal.  Coming directly from the Ruby and Rails communities where a core value is to articulate best practices, it is great to see this kind of guidance from a member of the Drupal community.  (slides here)

Bryan referred to a blog post by Dilbert creator Scott Adams on the Botched Interface Market, where sites like Orbit and Travelocity had such poor user experiences that they inadvertently created a market opportunity for new sites like Hipmunk.  Bryan’s goal is that Drupal should not become a botched interface market.

He organized his advice into two categories:

  1. More Control: Power Tools, Reducing Risk
  2. Less Confusion: Better Interface, Streamline Workflow

Bryan highlights borrowed techniqes from other platforms (mostly WordPress), and points out lots of “low-hanging fruit” techniques.

Example: the default layout for a node has a lot of labels and whitespace which doesn’t contribute to understanding the page.  The default UI for a file attachment is not concise.  Compare Gmail’s message compose interface vs. what it would be in Drupal (~1/3 of your screen vs. a page that is two screens high!)  Having a very long page can contribute to confusion, since you have to scroll to get to some of the functionality.

Larry Garfiled’s blog post Drupal is not a CMS points out that Drupal is something you use to build a CMS.  Perhaps we should think of it as a CMF, a Content Management Framework.  In this case, we are designing the workflow and user experience of a new custom CMS that we build with Drupal.

Myth: I am not a designer
Fact: um.. you actually are. Whether you identify as a designer or not. The decision you make when you are building a site has an effect on the end user — these are design decisions!

Myth: it will take a long time and effort
Fact: it could but it doesn’t have to

More Control

We can make our content creators more productive by giving them “power tools” while at the same time, reducing risk that they will make mistakes will give them confidence to move faster.

WYSIWYG

It’s not really an option anymore to tell people to edit HTML. [My personal perspective is that even though I am perfectly capable of HTML markup, why should you make me type extra characters? why should I have to learn the markup that works with your stylesheet? Though I do like the option of editing HTML when the rich text editors fail me.]

The following modules are good for WYSIWYG and File Upload:

  • wysiwyg or ckeditor which both appear to be rich text, WYSIWYG editors
  • media or imce for uploading and managing file (also seems to be an either/or choice

Node Editing Power

Always check “Add to Menu” on the Node Edit page — for most content creators, if a menu isn’t there, the feature doesn’t exist.

With context, use a module with Context Node which can pull out just a few context options and put it on the Node Edit page.

As a themer, you can make a bunch of templates and the content creator can pick with template -picker module.

Use Short Codes

Short code are a best practice from WordPress and can accelerate content creation:

[video:url]
[[nid:123]]

Drupal Modules:

  • Caption Filter
  • Video Filter works with the wysiwyg module or with TinyMCE or CKEditor (not sure why those are in a different category).
  • Insert View lets content editors add views without editing PHP
  • Make your own

In Drupal we tend to expose this kind of functionality as a block, but that gives the power to the site builder, rather than the content creator. In Drupal, the modules that do this tend to be called filters.

Reduce Risk

Always put description text when you are creating new fields (you probably won’t come back later). If you are going to come back later, you can improve it then — at least put something in.

  • Autosave
  • Revisions: just enable it by default
  • Preview — poor experiences with the preview button, not always what you expext
  • Turn off preview button on content types page, use use view_unpublished module instead

Granting Appropriate Access is not an easy fix.  You need to understand how your organization works, know the users, watch them work, etc. Once you do know those things, you can set up good workflows for them with clear options for the different roles in the organization.

Less Confusion

Admin Themes can help

  • Rubik is less cluttered: 2-column node-edit page, description text on
  • Ember is responsive

Logical Grouping

Group things according to how your content creators think about them, not how you built them. Consider grouping admin menu items into safe vs. risky like WordPress does. Bury advanced and less-frequently used functionality.

  • Fields into fieldsets & field collections
  • Admin Menus for content creators
  • Permissions into Roles
  • WYSIWYG Icons

Default to expanded for highly recommended options, collapse for optional, and hide anything that is unnecessary.

  • Use conditional fields (never show someone an option that does nothing
  • Simplify hides fields
  • Jammer hide many other things)
  • Hide Submit Button avoids double submissions and just an importantly communicates to the creator or editor that the site is actually doing something
  • Preview Button (see above)

Streamline Workflows

  • Use Chosen instead of the default multi-select
  • Add Another is great for repetitive node creation.

Dashboard

There are lots of great dashboard modules.  Consider what your creator or editor wants to see the most — make that their default homepage.

“the best tool of them all… …is the one that works best for your users”

It looks like I’ll still have to do quite a bit of experimentation, since Bryan often points to multiple modules to solve the same challenge — still a great reference to address common concerns and highlight best practices.

Emeline Glynn and Anthony Glynn gave a helpful talk called “How to teach anyone Drupal in 7 months.” The timeline was based on their experience where Anthony, an experience Drupal developer, taught Emeline remotely over a period of 7 months, to the point that she is now working professionally as a Drupal developer. Slides posted here.

Emeline notes that you need a passionate & dedicated student. It can be very frustrating, especially as someone new to development, especially learning command line tools, git and debugging, but she was excited about it and found it very rewarding even when she was very new. She usually spent 4-6 hours a day. Anthony noted that if someone has experience with another framework, you can expect the timeline to be 2-3x faster.

I liked this breakdown of stages in learning:

  1. Learn the Language
  2. Get the Skills
  3. Cross the Chasm
  4. Leave Footprints

For me, as a developer with 20+ years of experience, I pick this stuff up fairly quickly.  I spent a few solid days on getting my dev env setup, understanding the major components and making small changes to a module.  As important as the code, is understanding its patterns and jargon.  The immersive experience of CapitalCamp with its enthusiastic community and these references to key learning resources has significantly accelerated the learning curve.

This learning path focuses on the non-programmer; however, Anthony suggested (and I agree) that the experienced developer would take a similar path.

  1. Register at drupal.org
    drupal.org/planet should be your home page, with news feeds of all the best blogs online
  2. drupal.org/security – the Drupal security team meets once a week and issues security advisories less frequently — they also have a mailing list.
  3. Meetups — Anthony learned by reading Pro Drupal Development & going to meetups. (He noted that the community is a bit less friendly on line.) Meetups provide inspiration and the landscape of what to learn.
  4. Setup your dev env
    Recommended: Linux, git, Drush, PhPMyAdmin, Firebug or Chrome Developer Tools
    (Linux much easier than Windows)
    On Mac OSX  it is pretty easy too, but finding good setup instructions was hard.  I posted the steps I the I use and have since added apache vhost config so I can run multiple drupal sites easily.
  5. Embrace the command line! students may be freaked out at first, but it makes you very productive. If the student is non-technical, there are a lot of skills that are not Drupal that you still need to learn (e.g. command line, git)

Consider starting with a distribution profile

  • Drupal Commons: if you want to manage communities
  • Drupal Commerce: e-commerce
  • OpenPublic: government site

Terms & Landmarks

  • API api.drupal.org
  • node: a piece of content
  • module: a Drupal extension written in PHP

Helpful modules

  • administration menu: allows you to hover on Drupal menu items and shows submenus (drill down)
  • coffee: type in the page you want to go to and link pops up (also for the admin UI)
  • module filter: allows your module page to look clearer
  • devel: key helper module, allows you to access those variables,
  • develthemer – helps you develop themes
  • views – pretty much on every site
  • features – export your config (config + content is in the database)
  • panels & context: each puts you don’t a certain path
  • context – if you are in this part of the site, show this
  • panels – let you pick

Learn about themes – Omega, Adaptive theme and something else.  Also, subthemes.

Build

Debugging tips

  • “Calm down and clear the cache”
  • become fmiliar with the apache logs and drupal watchdog logs

Make students feel adventurous! Db backup + git makes it safe

More tips

  • codecademy – good for PHP
  • make sure you understand the hook system
  • look & use other people’s code
  • write patches
  • write your own blog
  • PHP function: debug_backtrace

litmus test / goal is to write your own modules

A Response-Able Process to Responsive Design talk by Mal Jones (@skeletonjones), Brian Verhoeven (@beverhoeven) and Corey Lafferty (@coreylafferty) introduced their agile process and a new open source prototyping tool that they built.

In 2011, they made responsive default for advocacy sites and content sites. We’re no longer building cars, we’re building transformers. How did they change their process?

Start with mobile story boards, then page description diagram. Pick three things on each page that are important, then three more, then the rest. Involve client in that prioritization — force them to choose.

Agile process. Prototype the unknowns — in the browser. They needed to be able to experiment. They need to be able to see how it looked and felt like on a phone. They looked at a lot of tools, but nothing really met their needs:

  • fast sketching of ideas
  • how elements respond in an actual environment (the web)
  • A/B testing
  • supports iteration

They ended up creating Proty, which can be used by coders and non-coders. If you are a coder, you can edit the HTML, but that isn’t required. Mobile first, breakpoints second (from sass). Each of the responsive sized gets its own file, but they aren’t mutually exclusive.

  • Small gets loaded first
  • Medium only what you need for the medium size that is not in the small (just the diffs)
  • Large, same thing, just what you need in the desktop, that is not in medium + small.

How do we use Proty? we use it first for creating wireframes that are live and responsive to different sizes. You can add notes to the page, for clients or other team members.

We also use Proty for:

  • technical tests / proof of concepts.
  • style guides

This process helped us transition designers to learning HTML and CSS.  Also helps with the agile process where there is overlap between dev and design roles.

Note: prototyping is not a magic way to create a web site once the design is complete.  You still have to build a web site.  If parts can be reused, great!  but that’s not expected.

Responsive design cannot be an afterthought.  It not a feature — it is how you build every feature.  Identify what works on mobile and what doesn’t.  Be able to recognize challenges early with embedded content, such as large document files, large tables of numbers, video, etc.

Brad Frost has a great list of responsive design patterns for navigation.  They like the “hamburger” menu (love that name for the icon with three little lines that typically triggers the main screen to reveal a side menu — see Path, Facebook, and many others now).

Don’t do the “hide & cry” — just because someone is on a mobile phone, they still deserve to see all of your content!

Notes from the audience:

  • checkout style_guide module.
  • Canvas will be hosting a devicelab in DC in the next few months.

For more info follow: @forumone and @protytype