Skip to content

Instantly share code, notes, and snippets.

@mparker17

mparker17/2013-07-13 1000 - Drupalicon's fables.md

Last active December 19, 2015 17:49
Show Gist options
  • Save mparker17/5994409 to your computer and use it in GitHub Desktop.
Save mparker17/5994409 to your computer and use it in GitHub Desktop.
Download ZIP
Notes from DrupalCamp Toronto 2013
Raw
2013-07-13 1000 - Drupalicon's fables.md

2013-07-13 10:00 Andrew Berry Keynote

The Feature and It's Reflection: If you always chase what's hot in the Drupal community, you'll leave your own work behind and end up with nothing.

Ticket Soup: An effective project manage enables positive collaboration by identifying actionable units of work…

The Client in the User's Skin: Don't let your client pretend to be the user. Don't let the user in user stories be "I" or "me"…

The QA Tester and the other Devs: Testers ensure we have to acknowledge reality: QA is our best guard against software decay and run, even when it feels like it impedes progress towards our goes. We had better heed their device.

The Drupal community lets us change the rules. What was impossible becomes possible, probable, and before you know it, done.

http://slideshare.net/deviantintegral https://twitter.com/deviantintegral

Raw
2013-07-13 1115 - Proviso.md

2013-07-13 11:15 — Proviso: a revolution in local development

What is proviso?

  1. A framework — SDK+API to provision platform-independent local VMs for Drupal development.
  2. Accessible — one-click installer control panel
  3. Ecosystem — or boxes with upstream parity

Why?

Because we have too many different answers to the same question…

  • Kalabox
  • Oscar
  • Ariadne
  • Drupal vagrant

Provisio is an attempt at community-building on neutral ground — the Geneva convention of local development.

Multi-vendor approach to provisioners.

  • No need to diverge the conversation and project vision based on tooling
    • Worth the extra effort to write it twice.
  • Common set of infrastructure tests via test-kitchen & Travis CI
  • Test drive provisioners on various platforms (CentOS, Ubuntu, etc.)
  • Working closely with folks outside the Drupal community and exploring shared needs.
  • Abstracting customizations into modular Vagrant plugins.

Timeline and major obstacles

  • One conference cycle-ish to version 1 maybe? @patcon things a couple months?
  • Obstacles:
    • SSH key agent forwarding? — talk to patron.
Raw
2013-07-13 1345 - Accessibility and Inclusive Design.md

2013-07-13 1345 — Do the right thing: Accessibility and inclusive design with Drupal

@cspin

A11y: The degree to which something is accessible to other people.

Inclusive design: a design that is inclusive of the full range of human diversity…

Who are we doing this for?

We are developing for people with…

  • Vision disability
  • Hearing disability
  • Mobility disability
  • Cognitive disability
  • Older people
  • Low literacy or not fluent
  • Low bandwidth connections or older technology
  • New and infrequent users
  • Future generations of connected devices

Example:

When you make your stuff wheelchair accessible, you also make it accessible to people with walkers, strollers, the delivery guy, etc.

Numbers:

About 4.4 million Canadians (14.3%) reported having a disability. This stat goes up when you narrow the sample size to older people.

  • 20% motion disability
  • 5% hearing disability
  • 4.5% learning or memory disability
  • 3% vision disability

(that's 32%)!

Why now?

Accessibilty for Ontarians with Disabilities act

  • By Jan 1, 2014, new public websites with more than 50 people, new public websites and web content must conform to WCAG 2.0 A

Penalties:

  • Corporations can be fined up to $100,000 /day
  • Individuals or unincorporated business can be fined up to $50,000/day

Case study: cost Target corp $10,000,000!

What does it cost to do it right?

  • It depends
  • Estimates:
    • 1%—3% on simple HTML+CSS sites
    • 3%—6% on intermediate site
    • 6%—10% on heavy Javascript sites
  • Don't wait!
    • Retrofitting can cost 2-3x more!

Where do I start?

  1. Determine requirements (audio? video? images?)
  2. Develop some rules (style guides and best practices)
  3. Train staff (including design/dev partners)
  4. Start implementing

Web accessibility initiative

http://w3.org/WAI

WAI-WCAG 2.0

  • Configurable
  • Interoperable
  • Understandable

3 levels of compliance: A, AA and AAA.

Widgets, drag-and-drop, dynamic updates, sortable tables

WAI-ARIA

A way to make rich web content and web apps more accessible.

WAI-ATAG

Web content authoring tools

What about Drupal?

Drupal is accessible! We have a committee!

Mostly this affects the theming level. Look for #D7AX and #DAX hashtag on themes, modules.

There are also a11y-specific modules.

A11y dev tools

Firefox:

  • WAVE toolbar
  • Juicy A11y toolbar

Resources

There are also other validation tools:

  • IDI Web A11y checker
  • WebAIM Color contrast checker
  • Photosensitivity Epilepsy analysis tool (PEAT)
  • ARIA linter (requires grunt.js)
  • A11yLint Brackets Extension (requires brackets and optionally brackets-grunt for grunt.js integration)

GoC has a handy checklist! There's a Drupal group.

  • OpenAjax Alliance
  • Inclusive design institute
  • Inclusive design research centre (OCAD university)

http://www.bv02.com/device-lab

Raw
2013-07-14 1000 - Building a Meaningful Web.md

2013-07-14 10:00 — Building a Meaningful Web

Michael Keara http://tuag.ca/

How usable === meaningful.

There's a lot of excitement around Mobile right now because we have to think of the content first, more than anything else.

Is a book still a book if it doesn't have content?

If you have a blank slate, you need a strategy for putting stuff in it.

Four questions critical to UX design

  1. Who is the user?
  2. What are their objectives? (What are they here for? What are their objectives?)
  3. Who is the "business"? (brand identity)
  4. What is the "business" intent? (purpose of the site)

Think of them in order…

Who is the user? -> What are their objectives? What are their objectives? -> Who is the business and what is the intent of the site?

How do we make user experience meaningful?

Meaning = continuity (of identity) Sustainability Persistance Connection Growth Flow Life

2 worlds

  • Outside:
    • Site owner
    • Site users
  • Inside:
    • Designers
    • Themers
    • Site builders
    • Developers
    • Architects

Are we doing an inside-out process? Or an outside-in process?

Michael believes we are thinking too much about what's inside our websites & Drupal.

We need to embed UX strategy as part of Drupal's design process, and the design process of our sites.

Raw
2013-07-14 1100 - From Interior Decorator to Architect Changing How We Work.md

2013-07-14 11:00 — From Interior Decorator to Architect: Changing How We Work

Emma Jane Westby (nee Hogbin) @emmajanehw

Drupalize.me is changing payment gateways.

Background

Roles and responsibilities: who did what on the project…

  • Product owner = Addi (Director of Education)
  • Developer = Joe
  • Site builder = Kyle
  • Designer = Jared
  • Themer = Pat
  • Project manager = Emma

Terminology:

  • Decorate = make something look a certain way.

Workflow: How we restructured our flow from a build-and-theme to design-pattern-architecture

This team works as a agile-lite team

The greater community is talking about how we shouldn't be decorating anymore, we should be looking at scalable, modular, architectural CSS / Object-oriented CSS… we need to be creating a style guide which is consistently applied, rather than specifying how each block on a site looks.

Problem is, how do we predict how it gets applied to our workflow, which is frustrating. This project was great for learning on, because the client was an internal client.

Interestingly, there is currently a gap between how themers want to act versus how they actually act.

How does this work?

  1. Analyze the design to identify components
    • Jared create style-guide mocks in HTML. There were no static design files.
    • We like working this way, but we don't know how to deal with it because there are no final reference points so we know when it's done.
    • It's very difficult to define done.
  2. Create a style guide of components.
    • Emma spends a lot of time on the phone with Pat.
    • Pat printed out the style guide and wrote class names on it.
  3. Create stubs in (s)CSS files with the style naming conventions.
    • Pat could pull out the class names from the designs.
    • But this approach was problematic because they didn't correspond nicely with Drupal's internal classes.
  4. Then fill in the stubs with style rules.
    • Better communication between themer and designer would have saved time due to clashing grid frameworks.
  5. Apply classes to markup in Drupal (tpl.php, theme_*, template.php).
    • Currently working on this.
    • In this part, you apply styles from the style guide onto elements on the page.
    • Sounds like a trivial shift, but once we get this process down and figure out how to ticket it, Emma feels like it's going to be a lot faster to implement.
  6. Cross-reference against build tickets.
    • Also difficult — there's a lot of bits and pieces that aren't captured in User Stories.
  7. Close user stories.

A walk through sample theming tickets - good bad and ugly

  • Base styles:
    • In the beginning, wrote tickets to "just do it"
    • Wasn't enough detail in ticket for Pat to start coding without having to first start thinking.
    • This was actually a research story (they called it a meta-ticket), not an actionable one.
  • Component styles:
    • They'd start the sprint with a meta-ticket, and write down a steps in the ticket.
    • As they'd get through some of the steps, they'd start filing follow-up tickets to deal with the work that needed to be done.
    • This write-down-the-steps way has been a good way for them to work while they figure out how to work in this manner.
    • Disconnect between writing styles and applying them to components on the site — how do you create a ticketable, estimatable item?

What's hard

  • Naming things
  • Acceptance tests for OOCSS-style tickets.
  • Matching building tickets to style component tickets.
  • Defining the style guide ahead of time is "waterfall". Agile forces a constant refactoring of the style components.

Recommendations

  • Daily checkins are critical when the process isn't perfectly defined.
  • Conduct code reviews "in person"
  • Write meta-tickets describing process and then break into child tickets.
  • Refactor your tickets as needed to reflect the actual process.

Resources

Raw
2013-07-14 1400 - Fast local development with Kalabox and Pantheon.md

2013-07-14 14:00 — FAST local development with Kalabox + Pantheon

@andrew_mallis

Local environments are...

  • Faster
  • Deployment
  • Try new things
  • Fail privately
  • Don't need the internet
  • Get on same page as team
  • Easier to fiddle with files
  • Free!

but…

  • Pain to set up
  • Not native stack
  • Not modern stack
  • Not like a real server
  • Difficult to use
  • Parity with production
  • Can't upgrade / hack around
  • Additional setup costs to make up config difference

Ideal stack would be…

  • Fast
  • Modern - optimized and tuned for PHP dev
  • Native (actually runs on Linux)
  • Easy to set up with sane defaults
  • Accessible for newbies, but control for veterans
  • Parity with production - change environments
  • Great tools
  • Automation for common tasks
  • Easy to deploy

Kalabox

  • Works on top of Vagrant
  • You can upload your Pantheon-generated Drush aliases
  • You can build a site from inside the box
    • It'll download all the things it doesn't have, refresh anything out of date, and uses rsync for the files directory
  • Sets up your hosts file

http://kalabox.kalamuna.com/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment