[Drupalcon 2012] Session Notes: Webform—the survey tool for Drupal

Presenter: Nathan Haug

Nifty stuff in Webform 3:

  • Webform-enable any content type
  • Download web form results as CSV, Excel
  • Multi-page forms
  • User-editable email templates
  • Save as Draft and Resume (only works for logged in users)
  • Save automatically between pages
  • Total and per-user submission limits (you can only submit X number of things total tracked by IP and cookies)
  • Tons of APIs for hacking; APIs like whoa
    • Means many additional modules that integrate
    • Rules integration is good
    • Panels integration also

NEW features:

  • added HTML5-friendly field elements (email, phone, etc.)
    • Important advantages for mobile devices
    • Also offers browser validation on latest versions of Chrome, Firefox
    • Backwards-compatible: any browser that doesn't get it treats it like a normal text field
  • Number component
    • Force users to input integers or decimals
    • Also an HTML5 element
    • Gives you a new keyboard on mobile
    • Can show pages, fields, etc. based on the value of another field in the form
    • UI isn't great, but it is functional
    • Logic is currently limited to multipage forms
    • Webform Conditional ( offers functionality for single-page forms
  • Download range options
    • Can download a subset of results instead of all results
    • Remembers how many submissions you've downloaded since last time; only downloads the submissions you haven't downloaded yet

Tips and Tricks

  • You can clone and export web forms
  • Only fields clone; results don't copy over
  • Options Element ( helps make it easier to create select boxes
  • Use hidden fields to display information that only administrators can see
    • e.g. track page they're on when they send the form
  • Use %get tokens to set default values—can get information from the URL and set it as the default value of the field
  • Use MIME mail to send attachments and HTML emails with Webform

[Drupalcon 2012] Session Notes: Drupal Media

Presenters: Dave Reid, Palintir & Aaron Winborn, Advomatic

Goals of the media project:

  • Unified media/file management within Drupal
    • We've been looking for a way to treat all media and files the same way in the Drupal database; this has been difficult.
  • Media/files as fieldable entities
    • Can tag and add taxonomy terms directly to files
    • Can include start and end dates on files to ensure limited access
  • Use a Single browser for editorial control
    • Makes things easier for content editors
    • Don't have to worry about different fields for files vs. video?
    • Thumbnails for all images, video, etc. right in the browser
  • WYSIWYG and Views integration
    • Lets editors embed media directly into a text area
    • Allows you to modify the browser with Views
    • Can organize files by tag/title/etc.
    • Can use exposed filters, etc.

Media in Drupal 6

  • Attached to nodes via upload file
  • Upload module has been retired for Drupal 7
  • Or media was created as a node through specific modules, which created baggage
    • Image
    • Video
    • Audio
  • OR media was created as a field within a node via CCK, which required a different type of field for each media type, and doesn't give the opportunity to separate the media file from the node
    • Imagefield
    • Filefield
    • Embedded Media Field
    • VideoField
    • AudioField
  • Every module had its own strategy for file management, which led to confusion
  • Inline media became possible via
    • IMCE
    • Node Embed
    • Embedded Inline Media
    • Node Reference/Embed Media Browser
  • Before Drupal 7, there were MANY different modules offering media/file management, but each offered different stuff, and it wasn't very extendible (multiple modules for new media requirements)

History of the Drupal Media Ecosystem

  • 2008: Proposal for Rich Media GUI
    • Create extensible browser for rich media editors
    • Create API to better connect developers with extension modules
    • Called the module Media
  • Original proposal went out to 5-6 developers; 2 dozen folks by the end of the year.
  • Ongoing Media sprint
  • 2009: added some patches to Drupal core
  • Now there are lots of maintainers, and an unofficial Media Initiative

The new NEW Media module for D7

  • Pushed 1.0 out of beta and into release/stable status in September
  • Now there's TWO versions
    • Wanted to add new features, but didn't want to break it before stable release
    • 2.x is unstable (we're working with crazy sauce/hot sauce
    • Wiki link
  • 1.x is feature locked; only fixing bugs right now
  • Views integration/UI changes will go only into 2.x
  • Palintir is already up to 2.x
  • Choose 1.x if you need something absolutely stable right now; BUT it won't get any of the new stuff.
  • If you have the resources to fix what breaks, go with 2.x; it will be getting ALL the new features/updates.
  • In the sprint, they changed the Media browser so it was powered by Views
    • gives more flexibility for site builders to filter, present data
    • makes good use of code that ALREADY WORKS WELL

Media stack

  • Modules that integrate with Media
  • Media Module:
    • Widget for fields
    • Media browser
    • more UI
  • Views module: backend for Media browser (2.x)
  • File entity: Fields on files, file display and view modes, Admin UI
  • Drupal 7 core

File entity provides and API/UI for

  • Viewing/editing/deleting files
  • Managing fields and their display on file types
  • Allows file to be easily extended via
    • Translation
    • Rules
  • Does NOT
    • allow file types to be edited, or how they're defined to be changed
    • Provide an API for file access
    • provide the greatest performance
    • exist currently in D7 core


  • provides a unified UI for managing Drupal files
  • allows upload of new files
  • allows you to mass import from a directory
  • integrates with WYSIWYG
  • provide an API for other modules to provide
    • Media browser plugins
    • integration with media_internet for external sources
  • DOES NOT (yet)
    • natively display audio and video
      • Use oEmbed, MediaElement, etc. for display
    • embed non-media with WYSIWYG
      • works great for images, though
    • make it easy to configure
    • allow more control over WYSIWYG integration
    • have the greatest usability

Adding media files to content type

  • Add file field
  • Choose "Media file selector" as Widget
  • Choose in file settings WHICH browser plugins to show
  • Update allowed file extensions
  • Update "Allowed Remote Media types"
  • Update "Allowed URL schemes" - i.e.,, etc.
  • In Manage Display tab, choose "Rendered File" - and then update the "View Mode" for that file.
  • Media will provide a new field in your node/edit screen which allows you to "add media."

Adding remote videos to a content type

  • In the browser, choose "Web" instead of "Upload" or "Image Gallery"
  • Copy and paste URL.
  • Works the same way as image upload.
  • Displays multiple images at once.

Setting it up:

  • Configure WYSIWYG to accommodate new media content types
    • Make sure that "Convert media files to tags" is checked.
    • Update your various text input filters
    • Make sure the "Media Module" button is checked.
    • You should then see the "Media" button in your WYSIWYG editor, and pressing it will open the Media browser.
  • Configure Fields on a file
    • Structure > File types (2.x)
      • Allows you to add new fields to file types, e.g. tags, availability date, caption, image credit
    • Configuration > Media (1.x)
  • New "Edit Media" feature in 2.x allows you to update media fields without leaving the node.
    • Want to use fields for information that's going to be the same everywhere you see it (currently, if you change fields on one image, it'll show up everywhere that image is used).
    • Can't edit the file itself (e.g. upload a new one); you can only update the FIELDS on it.
    • What if you want to upload a new version?
  • Multiform ( allows you to include several forms in one <form>
  • New "Add file" section allows you to upload files in one go for later; nice touch for editors
  • You can also update the media browser in 2.x with Views, add new ways to filter, etc.

What other people are working on in Media

  • Plupload
    • Multiple upload
    • not integrated in Media browser (yet)
    • Does work from the Add file page
    • d.o/project/plupload
  • oEmbed
    • Easy workflow for embedding from multiple various content providers
    • integrates with Media: Internet
    • Used in Gardens
    • Works with both 1.x and 2.x
    • d.o/project/oembed
  • Remote stream wrapper
    • Easily ref files from CDNs and external sources
    • Can generate image style derivatives
    • Integrates with media browser
    • Works with 1.x and 2.x
    • d.o/project/remote_media_browser
  • Derivitaives API
    • Use rules to create derivatives and process media files
  • Media update/translation
    • Only works with 1.x
    • Replace and translate files
  • Media crop
    • Used in Gardens
    • Crop, rotate, and edit images via WYSIWYG
    • d.o/project/media_crop
  • Media front
    • Open standard media player
    • HTML5 with Flash fallback
  • MediaElement
    • External Lib.

[Drupalcon 2012] Session Notes: Native Mobile Application Development on Drupal

Presenter: Kyle Browning, Workhabit

Why NOT native?

  • Options like Titanium/Appcelerator support multiple devices
  • Rapid prototyping: it's easier to write JS than to do a bunch of memory management stuff
  • Native is not easy for development.

WHY native

  • Faster performance on the device
  • supported by the OS maker (can make support requests on iOS/Android forums)
  • Manage errors on the side of the stack
  • No waiting on API updates, release schedule
  • Game development
  • Personal prefs

Dev process

  • Start with getting your idea on paper.
    • Getting the idea on paper helps the entire process go more smoothly
  • Build wireframes/prototype
    • It's easier to fail in wireframes and prototyping
    • Gather all the types of content you'll be using
    • Lay out the app in a workflow (user flows, task maps)
    • Use tools like Briefs, Omnigraffle, Axure
    • Save time on development by failing early and learning as you go
  • Design (visual, UI)
    • WIll it need to support multiple devices?
    • What are the key tasks and how will those be called out
    • Attempt to create an experience users are familiar with: colors, taxonomy menu, etc.
  • Development
    • Figure out what features are pre-reqs for others
      • Will content come in as feeds? First build content, then feeds or vice versa
    • Build API communication file
    • If things are constantly changing, write unit tests
    • Tackle the larger, harder problems FIRST

Mobile stack

  • Mobile App
  • Services
    • Standardized solution to integrate external apps with Drupal
    • Service callbacks can be used with multiple interfaces like REST, XMLRPC, JSON, JSONP, JSON-RPC, SOAP, AMF, etc.
    • Gives you your connection into Drupal
    • Much time is spent messing around with Services
    • Servers
      • Defines Accept and Response types
      • Call Authentication Methods
      • Executes the actual function call
    • Authentication
      • Session based
      • OAuth both 2-legged and 3-legged
      • Singletons: You'll have a user object that exists through the entire app; you want to make sure that only that object exists. Singletons help with that.
      • No need to re-login to the app when it opens.
    • Endpoints
      • A URL that a mobile app will hit
      • The bread and butter of Services
      • It's a configuration object that has all the resources and servers/auth methods, etc. that you need to make Services work.
      • You can also work with versioning, access controls for new developers, etc.
    • Versioning
      • Helps keep things consistent
      • Won't break apps when you build new features or functionality
    • Things to note:
      • Services Views is a bit wonky, but it works
      • There is potential to break if you change Views
      • Features allows you to take the View and put it into code so that it can't be messed with.
      • Adding images inline within content
        • Services will insert unnecessary HTML tags instead of images
        • Working on a module that will strip out images and attach them as a file to the node
        • Use Imagecache to deal with image handling (it's already in D7 Core)
    • Tools
      • Drupal iOS SDK and Dandy
        • Sits between Services and the mobile app so you can communicate with Drupal natively
        • Helps do user/session management
      • Services Log
        • hooks into services and logs everything that Services is doing.
        • You can see when you're getting a 403, etc.—what is messing up and why?
    • Drupal
      • Holds and organizes content
      • Can be sent to mobile app through Services

Book Review: Influence

Some books you read because you are obligated to—they are required reading in a class, or they are considered the “gold standard” of knowledge in a particular subject. Others you read because they’re interesting, or they bring new light to a subject that the reader has found mystifying in the past. For those whose jobs ever require getting another person to say “yes,” Influence, by Dr. Robert Cialdini, fulfills both roles exceptionally well. Weighing in at around 250 pages, Cialdini describes six “weapons of influence” that are so adept at guiding our behavior that most of us don’t realize we’ve fallen prey to them until the smoke clears and we realize that we’ve been had. In brief, Cialdini’s primary weapons of influence are:

  • Reciprocation: the idea that people give back to you what you give to them. Evidence for this rule abounds in human culture; Cialdini cites several sources that suggest it exists in cultures around the world.
  • Commitment and Consistency: our almost obsessive need to appear consistent with what we’ve already decided to do, particularly commitments made in public. Our need for consistency, while often a good and valued part of being human, also seems to get us into the most trouble; for example, the smoker who knows full well the risks of smoking, but still manages to minimize his vulnerability to those risks (Gibbons et al, 1997).⁠
  • Social Proof: the idea that we look at what those around us are doing to guide our own behavior. This is another key area where, when we are mistaken in our search for the right action in a given situation, the impact can be dangerous. The so-called “bystander effect,” in which an increase in witnesses to an event actually decreases the likelihood that the person in distress will receive help, is well demonstrated in the chilling example of Catherine Genovese, a young woman murdered in 1964 New York City while 38 of her neighbors watched, each believing that someone else must have called for help (Influence, pp. 112–118).
  • Authority: the way that we often defer to people who are perceived to have authority or knowledge on a topic. Note here the use of the word “perceived;” the most interesting facet of this principle is that simply having the appearance of authority—for example, a uniform—can have the same effect on our behavior as a legitimate authority figure. Con artists, Cialdini notes, make use of this principle often.
  • Scarcity: the idea that the more limited the availability of a given opportunity, the more we want that opportunity. This is often seen in retail sales, where customers are warned that stock of a particular item is “going fast!”
  • Liking: this principle states, quite simply, that we tend to want to help people that we like and trust. This one seems almost a no-brainer; what’s interesting about it, however, is the many ways that influence practitioners can facilitate the liking process, or use our relationship with friends to get something from us. Cialdini opens the chapter with the example of home Tupperware parties, where the attendees are driven to buy more often on the basis of their friendship with the host than a genuine need for the product (Influence, pp. 141–142).

The thing to remember, Cialdini argues, is that in most cases these tendencies are actually good for us; they help us make sense of an increasingly complex world, and prevent us from spending each day in a state of analysis paralysis. The problem lies in the ways that these otherwise adaptive strategies can be used against us by forces who want to get something from us; those that Cialdini describes, in an interview about the book with business blogger Guy Kawasaki, as “Smugglers:”

Smugglers, on the other hand, do know—quite well—what the principles are and how they work. But they import these principles into situations where they don’t naturally exist. An example would be a salesperson who pretended to be an authority on a particular computer system in order to get a customer to buy it. Although the smuggler’s approach often works in the short run, it’s deadly in the long run. Because only one person—the smuggler—wins. The customer, who gets fooled into buying the wrong system, will be unhappy with it and will be unlikely to ever return to that salesperson or dealer for future business.

Cialdini identifies a variety of influence smugglers throughout the book. These range from advertising agencies who use actors to pose as “regular customers” of their products in order to make others think people just like them love the product (demonstrating the principle of social proof), to Hare Krishnas, whose recruitment tactic of giving a small gift to pedestrians plays into the reciprocation principle so effectively that people go out of their way to avoid coming into contact with them. Each chapter cites a wealth of examples, both anecdotal and academic, describing how these principles can impact our behavior; each chapter ends with a reader anecdote on the chapter’s subject. Another key feature of Cialdini’s book is a section in each chapter called “How to Say No.” In this section, he not only shows readers how to recognize influence principles at work, but he also offers ways to counteract them. It is here that Influence is most useful, but it’s also where Cialdini tends to lapse into a cranky long-windedness that hurts his message more than it helps. In his chapter on the theory of social proof, Cialdini calls for a mass boycott of products advertised with actors representing customers—what he calls “phony ‘unrehearsed interview’ commercials.” But far beyond simply suggesting the reader stop buying these products, he recommends launching an aggressive counter-attack of the company’s “bad social proof:”

“Moreover, each manufacturer of the items should receive a letter explaining our response and recommending that they discontinue use of the advertising agency that produced so deceptive a representation of their product.”

In most cases, the advice given in each “How to Say No” section is useful—particularly in the context of putting these theories to practical use. However, in this case, as well as in his imagined response to the “stunning young woman” who duped him into buying an overpriced entertainment package by playing on his desire to impress her (Influence, p. 94), the advice Cialdini gives seems reactionary, and overblown for the issues that he’s describing. Despite these flaws, Influence remains a valuable work, particularly for those who work in industries—such as sales, marketing and design—that depend on the ability to use the principles Cialdini outlines in an effective, yet ethical, manner.


Kawasaki, G. (2006, April 26). “Book Review: Influence—Science and Practice.” How to Change the World: a practical blog for impractical people. Retrieved from:

Cialdini, R. (2009). Influence: the Psychology of Persuasion, Adobe Digital Edition. New York, NY: Harper Collins E-books. Gibbons, F., Eggleston, T. & Benthin, A. (1997).

Cognitive Reactions to Smoking Relapse: The Reciprocal Relation Between Dissonance and Self-Esteem. Journal of Personality and Social Psychology, Vol. 72 No. 1, 184–195.

[AgileUX Summit] Session Notes: Code Literacy for Lean Teams

Jonathan Berger, Code Literacy for Lean Teams

  • Coding as literacy
    • gets rid of the binary nature of "you can code or you can't"
    • If you work in technology, the medium is power
    • "I can get this code to work or not" can be frustrating to those just learning
    • Just because you can code doesn't mean you'll be good at it
    • Getting technical doesn't have to be a full time commitment
    • Many resources available (books, sites, tutorials, etc.) are geared towards people who want to be full timers
  • More and more shops won't hire designers who can't code.
  • How does code literacy help lean teams?
    • More literacy leads to more sustainable projects and more successful outcomes
    • Fine details are important, but often get shoved to the wayside by devs moving on quickly to the next feature
    • There's a whole class of things that are easier/less time consuming to do than to explain
    • Being able to fix details yourself saves the developers time,
    • Gives team more hands on deck, fewer bottlenecks
    • Builds camaraderie
  • How does it hurt?
    • Time/cost in learning curve
    • Potential for overstepping bounds (humility is important)
    • Harder to look at things with an "innocent" eye (i.e. without thinking about how it can be made)
    • Tunnel vision in devs can skew priorities towards problems that are "easy" to fix
  • Ways to become literate
    • Use in browser mockups (HTML/CSS/JQuery)
    • Use Inspector (Chrome) or Firebug (Firefox) to inspect and change elements, then import changes into code mockups
    • Align product/development/design
    • Set up a local dev environment (e.g. MAMP, Rails)
    • Get started with Git
      • Designers can contribute small changes, e.g. copy or CSS, and push to production without interrupting the developers' workflow
      • You can make the fixes that matter to you but aren't crucial to the developers
      • Watch out for breaking tests (e.g. when copy is changed)
    • Learn JQuery & the DOM
      • Make better mockups—directly in the browser
      • Make more changes for the team
    • Learn the language your team is developing in—PHP, Rails, Drupal, etc.


Subscribe to Blog