Session notes: View Modes—the many faces of your content [Drupalcon 2012]

Presenter: Tim Cosgrove, Phase II

View modes:

  • Help you theme faster
  • Write less PHP
  • Create easily reusable layouts
  • Named ways of displaying entities within different context
    • “Full” — the actual node page
    • “Photo Teaser” — photo with title
    • “Dated Teaser” — date on top, summary
    • “Subtitle Teaser” — photo with summary, title
  • View modes are in core
  • View modes are NOT in Views
  • They’re built into all Drupal 7 entities
    • Nodes
    • Users

Bad themer habits:

  • Too many .tpl files/custom templates
  • Too many functions in template.php
  • You use Views to do theming.
  • In D6, we needed these things, but NO MORE! D7 brings us View Modes!

How to use View modes:

  • In Manage Display, “default” and “teaser” are built in by default
    • “Full” — how to display the full page
    • “RSS” — how to display RSS feeds
    • “Search Index”
    • “Search Results” — how to display nodes in search results
  • To activate said view modes, click on custom display settings and activate the new ones you want; otherwise, default and teaser is it.
  • If you go into the view mode to edit, you can deactivate extra fields, or add new fields
    • This happens in code
    • You don’t need to do a new node–type.tpl.php for each type anymore
  • BUT, we need more custom view modes! How?
    • Entity View mode
      • Simple, lightweight
      • does what it says
      • con: keeps EVERYTHING in one variable (this means that Features might get stuck if you use it with this module)
    • Display Suite
      • Has a better way of exporting view modes
      • Extremely powerful way of dealing with this
      • Con: it does A LOT OF THINGS. If you want that, great, but if you just need to add a couple of View modes, it’s a bit much
    • Doing it in code.
      • Just need a little bit of code
        • use hook_entity_info_alter( )
        • change $info[node] and create a new machine name and array with qualities
        • add it to a module and throw it on your site.
        • Now it should show up in your view mode display panel.
  • Exporting view modes
    • Throw them into Features when you export your content types; they’ll come back in when you import the content types into a new site
  • Use cases:
    • Node reference: add a custom view mode to the User Content page
  • Why not use Views for this stuff?
    • it’s messy and complicated
    • takes significant time
    • too many templates, customized for each View
  • View modes actually make using Views much easier!
  • Other ways of using View modes:
    • Customizing search results
    • Customizing search index: offer more information to search index than is generally available to the index.
    • Create custom blocks with related content at the end of an article.
      • Big win: you don’t have to theme, as long as someone sets up the display for that content type’s block with “subtitle teaser.”
  • Changing view modes:
    • make one change and it populates across things
  • Issues
    • Consistent design is key to using view modes
      • Make use of repeating elements
      • Use grid systems
      • The more you can use reusable elements, the better.
        • Save time & money
        • Look for inconsistencies; those will add to the dev time.
    • Also doesn’t work with tables
    • Won’t work with outputting fields from multiple entities at once, e.g. multiple content types or nodes.
    • Theming issues
      • Consistency is good, but boring sometimes
      • You might have to give a bit in order to get a design that the designer will be happy with.
      • Sometimes you might have to make a separate template, or preprocess something.
      • The way we were forced to do things in 5 and 6 forced us to do all these extra things.
        • We don’t need to do this by default anymore; we can save it for when we actually need it.
  • bit.ly/view-modes (http://www.treehouseagency.com/learn/view-modes)
    • Learn more about View modes
    • download the code to make a new View mode module
  • BEANs (custom block entities) BoF (Thursday 2:15; room 506)

Session Notes: UX design for every screen [Drupalcon 2012]

Presenter: Aaron Stanush, Four Kitchens

How 4kitchens has been doing websites for the past decade:

  • Requirements and planning
  • Site maps, user flows, wireframes
  • Comps
  • Implementation

The new way:

  • Requirements/planning
  • Content strategy (mobile first!)
  • Design systems > Comps
    • You can’t spend time doing comps for every single device anymore; it’s not an effective use of your time.
  • Prototyping is KEY
    • You can leverage design systems within prototypes to enhance the mobile experience.
  • Build. Design. Iterate. Design. Build. Iterate.

Major changes:

  • There is no more “page”
    • Layout/template are consistent across devices
  • Comps are no longer golden
    • Don’t need one for every single page/screen
  • Elements are no longer static—they adapt to different devices
  • Prototyping happens much earlier in the process
    • Helps define the vision; helps client get it sooner
  • Designer and developers working closer together
  • Higher level of client communication
    • Some clients are skeptical, think there’s too much risk involved.

THE PLAN:

  • Future-friendly
    • http://futurefriend.ly
    • We don’t know what will be on the market 2–3 years from now;
    • want to provide advice and design that’s going to be sustainable.
  • Mobile-first
    • Luke W’s book: Mobile first (available on A Book Apart)
    • Focus on three things:
      • Growth = opportunity
      • Constraints = focus
        • Screens have different sizes, different needs
      • Capabilities = innovation
        • Tap the capabilities of the phone—GPS, location, etc.
    • “Designing the mobile app first forced us to strip down to the essentials”—Bill DeRouchey, Banksimple
      • Focusing on app first carried the focus of the project into the rest of the experience
  • User-first is content-first; THEN you worry about mobile strategy.

“Mobile Web”

  • Most clients seem to think folks are on mobile devices “on the go”—grocery store, bus stop, etc.
  • But honestly, that’s not true; people are spending more time on their phones, more time on the site through that medium
  • Mark Boulton: “Start designing from the content out, rather than the canvas in.”

Future friendly content

  • What are the types of content and why?
    • Video?
    • Text?
    • How will it be broken up?
  • Make it modular
    • Drupal makes this easy; you can leverage fields, etc.
  • What’s really important?
    • If something goes away, will users care?
    • If something gets smaller, will that change/decrease value?
  • How will the tool you’re using organize this stuff?
    • Drupal gives you flexibility to organize content in multiple ways.
  • Page tables give hierarchies
    • Title
    • Message
    • Secondary Messages
  • Design strategy
    • Workflows aim for best user experience; focus on task/behavior, not layout
      • Responsive is about providing the best experience, particularly when you focus on content.
      • These experiences can differ between devices; desktop may contain more information; mobile can contain more FOCUSED content.
    • Wireframes can help organize layout and convey content flow
      • Still needed
      • Focus on content, flow
    • Design systems save time, create patterns
      • Styletil.es (@samanthatoy)
        • Using texture, fonts, etc. to capture feeling
      • Build style guides/pattern libraries
      • Comps are probably still needed, but not for every page in every viewport.
        • ICANN: Created 3 comps, for 3 different viewports, AFTER creating and iterating style tiles.
      • Goal: get the design to the browser QUICKLY.
    • Prototypes help the team fail faster, to facilitate better solutions.
      • Provide client value; help them “get it” sooner.
      • We’re focused on much more complex problems now.
      • Clients can get really focused on comps; the browser is where the responsive magic really happens.
      • A “living” design allows richer convos between devs and designers.
        • Developers can talk about content flow and other design decisions
        • Designers have to understand more about how things will actually be built.
      • Fail fast. SUCCEED fast.
        • Agile/Lean
        • All about iteration and letting the team direct changes.
  • Best practices = Best experience
    • Not about convention; it’s about creating the best experience for users.
    • mobilewebbestpractices.com—library of best practices for mobile devices
    • Understand how people use their devices and why
    • Content > navigation
      • Users on mobile are generally coming in through a link; they don’t necessarily care about navigation.
    • Best experience doesn’t necessarily mean limiting choices
      • Stripping the experience down to just links/text isn’t the best experience
      • Users spend more time on their phones than you think; particularly reading.
    • Maintain clarity and focus
  • What makes a good experience?
    • Readable (font size, spacing, contrast)
    • Relevant (most valuable content first)
    • Keep forms to a minimum unless you’re dealing with commerce, surveys, etc.
    • Avoid modal overlays (lightbox, ads, etc.)
    • Make it snappy
      • People want to do stuff, and they want to do it fast
      • Performance management (reduce the amount of time for loading)
      • Get people to the content quickly
  • Layout
    • Design for screens, not devices = Breakpoints
      • You really can’t focus just on iPhones anymore; Android, Windows phone, etc. is growing
    • Be fluid, liquid, flexible
      • Think in proportions, NOT pixels
        • aligns with content strategy; focus on hierarchy
        • aids in fluid grid management
      • Think scale in media, text, images
    • Consider device orientation
    • lukew.com/ff/entry.asp?1514: Looked at a bunch of different mobile-to-desktop layouts; identified patterns for responsive layouts
    • Navigation
      • Starbucks changed their navigation; took a risk on an icon-only navigation with drop down box.
      • Don’t try to make drop downs a work of art; the OS takes care of things in their own way.
      • Put fixed toolbars at the top rather than the bottom.
        • The bottom is where the OS puts its hardware buttons; you don’t want users accidentally clicking the hardware buttons.
      • Consider OS and hardware buttons.
    • Responsive Images
      • How do your images scale for various widths and orientations?
      • Reduce the # of images if you can.
        • Not everyone has super-fast phones!
      • Be careful of using HUGE images
    • Mobile text
      • Make it readable
      • Consider text flow; long headlines might not scale well on smaller viewports
      • Be aware of typeface characteristics
        • Tall, skinny?
        • Short, fat?
        • Test performance with mobile devices; make sure that loading fonts isn’t slowing things down
    • Gestures
      • Buttons are a hack: they’re basically styled links.
        • globalmoxie.com/blog/buttons-inspired-ui-hack.shtml
      • Make gestures obvious.
        • Don’t make your users read a manual
        • There’s no such thing as “hover” on a touch site.
      • Do use visual cues like coach marks.
      • There is a need for universal conventions
        • Current conventions: tap and swipe (pull down?)
        • Consider competing OS/Browser gestures
        • Provide alternatives to gestures
          • All devices aren’t yet touch-enabled
      • Design for humans; embrace the physicality of touch
      • Size elements and space them appropriately
        • rule of thumb: size touch elements at about 40px
        • Remember: not every device is touch-enabled
    • Tools
      • Software isn’t necessarily the answer
      • Start with pen and paper
      • Fluid grids
        • Goldengridsystem.com
        • Github.com/davatron5000/Foldy960
        • csswizardry.com/fluid-grids
        • gridsetapp.com (coming soon from Mark Boulton)
      • Wireframing/prototyping
        • Whiteboard!
        • Pen/Paper
        • Axure
        • Balsamiq
        • Boston Globe used InDesign
          • handles both images and text
          • Can create patterns with paragraph/character styles
      • Responsive media
        • Images
        • Slideshows
        • Videos (fitvidjs.com—takes any embedded video and scales proportionately)
        • Text (fittextjs.com)
        • filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing
        • markboulton.co.uk/journal/comments/responsive-advertising
      • Media queries
        • @media screen and (max-device-width: 480px) { .column { float: none; }}
        • Media type: screen (desktop, phone, tablet)
        • Query for media feature: width, height, orientation, pixel density
      • Prototype frameworks
        • foundation.zurb.com
        • twitter.github.com/bootstrap
        • goldilocksapproach.com
        • html5boilerplate.com/mobile
      • Touch frameworks
        • jquerymobile.com: can create something that looks like an iPhone app within a browser
        • sencha.com
      • Test on REAL DEVICES
        • blackberry
        • Windows phone
        • Kindle fire, iPad2
        • Galaxy tab, etc.
      • Adobe Shadow: labs.adobe.com/technologies/shadow
        • Runs in the background, and has an extension on FF/Chrome
        • Make sure your devices are on the same wifi network; then you can browse on desktop and it shows up on all your devices.
      • Browserstack.com
        • will emulate any number of browsers inside one website
        • Just started adding mobile VMs.
          • Won’t get the same fidelity as an actual device, but you can get a general overview
        • Subscription is pretty cheap.
      • Blaze.io/mobile
        • tests mobile performance
        • Gives load time and other factors
      • mattkersley.com/responsive
        • Type in different websites, and it’ll show you how it looks in different browser widths.

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

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
    • quirksmode.org/html5/inputs.html
    • 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
  • CONDITIONAL LOGIC
    • 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 (http://drupal.org/project/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
  • FORM BUILDER INTEGRATION

Tips and Tricks

  • You can clone and export web forms
  • Only fields clone; results don’t copy over
  • Options Element (http://drupal.org/project/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

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

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

Session Notes: Drupal Media [Drupalcon 2012]

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
    • WYSIWYG
    • 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 groups.drupal.org/node/215218
  • 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

Media

  • 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. Youtube.com, Vimeo.com, 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 (http://drupal.org/project/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.