#WCORL – Designing a process that gets things done

Speaker: Karena Kreger
Twitter: @karenalenore
Speaker’s notes: www.openskywebstudio.com/design-process (has slides!)

Process

If it’s something you’re repeating, find a system for it.

  • You will know what to expect, it will help making things predictable, more efficient.
  • Helps you be an expert and manage expectations
  • History is less daunting, less scary, because you know what to expect
  • Gives room for growth. Conventions that are being followed in the organisation helps keep control and allows everyone to pick up where others left off

Curate

Be a curator of your process, maintain best practices that work for you.

Continue evaluating the process, there’s no setting and forgetting. Things around us keep changing.

You have to assess with your client whether being an early-adopter/cutting-edge is worth the cost. What if it fails? Can they afford starting over?

Also judge if your client is ready for it. Some of them say they are, but really aren’t.

Foundations

Sandbox

Have somewhere you can play around with. There are a lot of things that leave unwanted things behind. Make sure you have a backup so you can easily nuke all the things and revert back.

Template site

A starting point with all the settings, plugins, and users you know are going to be installed on every website.

Use a framework (like Genesis)

Help with providing otherwise repeated code out of the box. Use a child theme to make your changes, don’t hack into an existing theme to make it do what you want.

Alternatively: Use a starter theme (underscores, roots.io).

Good plugins, bad plugins

Things to look for: Compatibility details, updated date, number of downloads, ratings, reading reviews.

Tools

Communication: Trello
File Sharing: Dropbox, Google Drive
Ex. process documents
Updates: InfiniteWP, ManageWP
Tech docs: Track links, passwords per client (requires protocols and naming conventions)

Inspiration

Find a starting point, avoid the curse of the blank slate. Learn how to spot and save cool stuff and apply it to clients.

Example: colourlovers.com for colour palettes.

#WCORL – Write Better Documentation

Speaker: Jeff Matson
Twitter: @TheJeffMatson
Website: jeffmatson.net

Why write documentation?

  • Support ticket reduction
  • Customer satisfaction
  • Increase Traffic
  • Converts to sales

Good documentation shows you care. Helps the support reps. No more need to repeatedly write the same solutions, a link to the docs suffices.

How to get the most from it

  • Use Visuals
    More likely to get a support customer to go through the process of fixing it themselves. Helps reduce support rep phone time.
  • Write it in the simplest way you can, write like you’re explaining to 5 year olds.
  • Make sure you to keep it up to date
  • Target search engines (leads to more traffic)
  • Allow for comments
    this can drive (voluntary!) community support, further reducing load for your support reps
  • User-Submitted Documentation
    Helps all the people. Exposure for the submitter, additional traffic for your website.
  • Overlapping keywords
    People searching for support with competing plugins can come across your documentation. Leads to the impression that your plugin is better and sale conversion as a result.

How do you get people to submit documentation?
– Give them an incentive to do so. For example, Inmotion may offer perks like swag, hosting, etc.

#WCORL – Designing for development, the value of collaborative design

Speaker: Michelle Schulp
Twitter: @marktimemedia
Website: marktimemedia.com

What is collaborative design?

To help understand how collaborative design can help, we must look at the waterfall method first.

Waterfall

Linear, ie., content -> design -> development

Downsides:

  • Project scoping assumptions
    Whoever’s first in line needs to assume scope for the rest of the process.
  • Inefficient communication
    Game of telephone and very likely to have miscommunication
  • Hard to adapt to changing requirements
  • Decisions made outside of expertise
    Designer quoting development work, or vice versa, because of change requests in their phase.

Collaborative Workflow

Non-linear, stuff happens at the same time. Ie, Content <=> Design <=> Development <=> Content

  • Leads to more accurate scoping, because everyone’s involved in the process of scoping and estimating
  • More direct communication
  • Quickly adapt to changing requirements, no more need to wait for communication to go through the chain
  • Results in efficiency/time saved

Example workflow

Recommended Book: Strategic Web Designer (Christopher Butler)

Designer
  • Design elements, rather than literal mockups. Style tiles.
  • Communicates interpretation of brand at a high level, rather than specifics of the design
  • Design wireframes (static or dynamic)
  • Design system assets (Typography)
  • Mockup styleguide, CSS Styleguide for reusable elements
Developer

Involved early. Allows for catching of budget/time issues with functionality.

  • Know the design system
  • Prototyping, iterating, and testing
    Prototype functions, but doesn’t look like much. Stuff is in place, but not styled. Allows functional/flow tests
Project Management
  • Bridge between goals
  • Understand communication styles (how do people work/communicate best)
Client
  • Leave good feedback!
  • Design specific feedback: Focus on look and feel, evaluate clarity, keep in mind that it’s for your visitors (not for you!), be specific.
  • Dev specific feedback: Focus on function, evaluate consistency across platforms, explain what you expect vs what happened (specificity!).
For all the peoples:
  • Understand vocabulary (within reason, know enough to be able to understand and communicate the basics)
  • Ask all the things
  • Define goals

#WCORL – WordPress JSON REST API

Speaker: Ivan Lopez
Twitter: @ivandevelop
Website: www.ivanlopezdeveloper.com/

Slides were verbose, so notes are a bit lacking here. Will link to slides when I can.

The API brings platform independency. Use WordPress as a backend for many different front-end platforms, regardless of their language (Ruby, Python, JS, whatever).

Authentication

  • Cookie (in core)
  • HTTP Basic Auth (requires Basic Auth plugin)
  • OAUTH ( requires OAUTH plugin)

Basic auth is fine for dev, but not secure enough for production.

How does it work?

A plugin is currently required to make this work. Goal is to get this in core with 4.1.

root request URL: /wp-json/

  • /posts/
  • /taxonomies/
  • /media/

A Backbone client exists for making communicating with the API easier.
See: client-js

For more information about the API, find the documentation here: wp-api.org.