Mike Fowler

Links for 2013-01-09 [del.icio.us]

2013-01-10T00:00:00-08:00

Simplify Responsive Design by Embracing the Flexible Nature of the Web | Webmonkey | Wired.com

Links for 2013-01-02 [del.icio.us]

2013-01-03T00:00:00-08:00

Regexper
Visualizes RegEx expressions. Damn cool.

A New Frontier in 2013

2013-01-01T12:39:00-08:00

It’s been a time since I last blogged, and during that time much has happened. Within the last two months, I moved my life across the country; started working at Findery; stumbled upon another vegan developer, Jim Whimpey, on the internet and found an apartment with him; joined a new rock gym, Mission Cliffs; survived the apocalypse; and became an everyday commuter on The Wiggle. And in the midst of all this happening, I still managed to dip my toes into the ocean of things to explore that a new city provides.

And so begins my first year on the western frontier. Surrounded by thousands upon thousands of people who do what I do, where creativity and innovation seeps from manholes and rains from the sky. And while this may be a hyperbole, it is so only by a little. I’ve come away from networking and industry events having met a dozen people at a time who are working on their version of the Next Big Thing, having either quit their jobs entirely to dedicate themselves to their dream or simply continued their normal work and elected to spend each other waking moment on their project.

The immediate reaction of a young creative in this city: how can you possibly distinguish yourself in an environment like this, so saturated with smart, hard-working people? But it truly is only that, an immediate reaction, for the overwhelming sense is one of being energized by the collective drive of a city whose veins pulse with innovation and creativity. I must remind myself that, after all, this is why I moved here. This culture and community will push me, as much as I will push myself, to do better work.

Let’s Make People Smile

Looking back at my beginning-of-the-year post from 2012, my goals were different because many were driven by being in a smaller developer community in Burlington. Speaking at events is certainly going to carry over, but my goals for 2013 are mostly different, and more focused on personal growth. In lieu of leaving a bulleted list in this post to potentially stare me in the face for the remainder of my career, I will deliver my goals for 2013 as a concept:

I want to create things that elicit an emotional response. At my new job, I get to help build just such a thing every day. Therefore, I will do similar in my side projects. By “eliciting an emotional response”, what I actually refer to here might mean anything from inspiring somebody, to making somebody smile, to actually helping create lasting value for a person.

Last month myself and the rest of our team at Findery got to sit down and chat with Evan Williams for a bit. One of the concepts he mentioned while talking with us was that of internet “snack food”: products that don’t creating lasting value, but satisfy our need for instant gratification and positive reinforcement. That was my takeaway, at least. But the more I’ve thought about it, the more I realize how spot-on that analogy is. And more than ever it has inspired me to distance myself from creating things that aren’t going to create real value.

TL;DR

In 2013, I will not be creating snack foods.

Links for 2012-12-21 [del.icio.us]

2012-12-22T00:00:00-08:00

Understanding the Git Workflow
For somebody like myself, whose understanding of Git is fairly basic, this is a good outline of a workflow that leads to cleaner commit histories in master branches. Useful for teams doing a lot of one-off feature branches.
My Workflow: Never having to leave DevTools
Editing files in browser and saving changes to the local source... pretty neat for small tweaking, but I can't imagine not having a fully functional editor for major development.

Links for 2012-10-22 [del.icio.us]

2012-10-23T00:00:00-07:00

Unix Toolbox

Links for 2012-10-18 [del.icio.us]

2012-10-19T00:00:00-07:00

Patterns For Large-Scale JavaScript Application Architecture
A solid overview of a possible architecture for large-scale JavaScript applications with code examples and design pattern descriptions.

Links for 2012-10-16 [del.icio.us]

2012-10-17T00:00:00-07:00

ls, colors, and Terminal.app
Solid documentation of how to customize 'ls' output colors in Terminal.

Onward. Westward.

2012-10-15T03:09:00-07:00

In only four weeks I will be both living and working in a new place. Sure, I’ve made these changes before: new job, new apartment. But this is different, because both of these new places are further than across town. They’re further than across the border into another familiar New England state and further even than a long drive to Philadelphia or a short plane ride to Chicago.

In four weeks I will be living and working in San Francisco.

I don’t mean to be dramatic in my writing when I say this, but this is the most radical thing I’ve ever done in my life. And yet… I feel oddly at ease. My excitement has been repressed in a sense because of the myriad of details that must be attended to: wrap up things at work, get rid of things I don’t need to bring across the country, find somebody to sublet my room, and so on and so forth. But beyond that I still sense it… an unexpected calmness that says: “You need this. And you will be great”.

Findery, here I come!

Today I can officially annouce that I will be accepting a position to join the team at Findery and start working on a product that, while I’ve only been using it for a week or two now, I adore. Findery (for me, anyhow) is all about sharing experiences we’ve had at specific places, or as the tagline explains, “Findery makes places come alive”. But that’s what is really great, don’t you think? That’s what Findery is about for me. Having chatted with the team (and some actual users) at the Findery open house last week, I can tell that the ways people will use Findery are going to be vast and varied.

To the West

Of course, the other half of this story is the move across the country to a brand new city, and it should not go understated. “Why San Francisco?”, I’ve already been asked. Sure, it has really nice weather, and a decent vegan culture, and a TON of cool things happening, but the initial decision transcended those aspects. The reason I can’t wait to be in San Francisco is that I long to be surrounded by people working tirelessly to make incredible things with technology. Things that will change lives. Things that will influence others. Things that will bring a smile to the face of millions, or even just one, person.

It goes without saying that the developer culture in San Francisco is strong, and the prospect of continually meeting and working with people who are as passionate about work and creation as I am is extremely attractive to me. Whether it’s code meetups, conferences or casual encounters, I’m ready to expand my network of influential human beings.

Stay Weird, Vermont

Vermont isn’t going anywhere. Nor is the New England I was raised in and all of its eccentricities. If or when I decide to venture back to the East Coast, I expect I’ll find the culture of people much the same, and there is something mildly comforting in that. The culture of Vermont has truly molded me over the past six years, both spiritually and philosophically (and maybe physically, Mike thinks as he trims his beard and dons flannel).

But, for now at least, that isn’t quite enough for me. I need fast-paced and influential and inspiring and transformative and informative! I need life! Making this move puts me out of my comfort zone in so many aspects and I love that. For better or for worse (with a much stronger sense of “better”), I dive into the unknown.

Make way for magic! Make way for objective mysteries! Make way for love!

The photo in the header was taken by Flickr user photographerglen.

Links for 2012-10-02 [del.icio.us]

2012-10-03T00:00:00-07:00

A List Apart: Articles: Mo’ Pixels Mo’ Problems
Dave Rupert gives a great overview of a (currently) ideal set of rules for progressively enhancing images and reminds us, above all, to use our heads when working with this stuff.

Crafting Scalable Stylesheets

2012-09-22T16:13:00-07:00

Linked below is my slide deck from the talk I gave today at VTCodeCamp. I spoke on some ways that Sass and Compass can help create more maintainable and scalable systems. I had a great time presenting and for everybody that made it to my talk: thanks for swinging by.

“Crafting Scalable Stylesheets” on Speaker Deck

An Early Look at CSS3 Conditional Rules

2012-08-21T08:38:00-07:00

In a recent episode of Shop Talk Show, Tab Atkins briefly mentioned a draft of a spec that includes feature querying in CSS. The feature, @supports, is part of the ”CSS Conditional Rules” module, and while the working draft has existed since September of 2011, it was my first time hearing about this proposal. Bear in mind, nothing about this spec is even close to final, and the editors draft specifically mentions that the @supports rule is at risk.

The @supports rule will allow us to test whether a user’s browser supports a given CSS ‘property: value’ pair. The use of @supports is similar to the way that we currently pass a block of content into the @media rule to be executed only if the proper conditions are met. In addition to being able to test for a positive result (the browser DOES support the given “property:value” pair), we will also be able to test if a given “property: value” pair is NOT supported by the browser.

Current State of Feature Detection

Presently, a lot of us are using Modernizr to handle any CSS feature detection we may need to do. The amount of functionality covered in the Modernizr test suite is now so comprehensive that, for me at least, it has become the de facto library if I need to test for a feature. The production build tool they provide makes it painless to create your library initially and then add additional tests later. To facilitate using feature detects in stylesheets, Modernizr adds classes to the root html tag indicating support (like class="touch") or the lack thereof (such as class="no-touch").

A major difference here is that Modernizr also adds test results to an object in the global JS namespace. While there isn’t much practical use for executing JavaScript based on the support of a CSS property, this functionality is crucial if you want to load JS-based polyfill libraries based on the lack of support for a CSS property. I don’t know enough about spec writing to know if a spec like this one implies a JavaScript counterpart (document.supports?), but obviously we would not be able to load polyfills with CSS-based feature detecting alone, and sometimes fallback rules just aren’t enough.

At-Supports Rule in Action (Theoretically)

Before reading these examples, note again that this spec is in flux, and furthermore no browsers have implemented this. These examples are pulled from the current version of the editor’s draft, linked above. In our example, let us say we are testing support for flexbox. We want to specify some rules to apply if the browser supports the property, but we also want to be able to specify fallbacks in case the user agent does not support flexbox.

/**
 * Set our main sections to use flexbox
 * if the browser supports it.
 */

@supports ( display: flexbox ) {

  body,
  #navigation,
  #content {
    display: flexbox;
  }

}

/**
 * Fall back to a compatible layout if
 * the user agent does not support flexbox.
 */

@supports not ( display: flexbox ) {

  body {
    width: 100%;
    height: 100%;
  }

  #navigation {
    width: 25%;
  }

  #article {
    width: 75%;
  }

}

Pretty straightforward. We would also (theoretically) be able to chain tests like we can with the @media rule using the and and or keywords:

@supports ( box-shadow: 2px 2px 2px black ) or
          ( -moz-box-shadow: 2px 2px 2px black ) or
          ( -webkit-box-shadow: 2px 2px 2px black ) or
          ( -o-box-shadow: 2px 2px 2px black ) {

  .shadowbox {
    -webkit-box-shadow: 0 0 5px -2px black;
       -moz-box-shadow: 0 0 5px -2px black;
         -o-box-shadow: 0 0 5px -2px black;
            box-shadow: 0 0 5px -2px black;

  }

}

Preprocessor Implementation

I couldn’t write this post without mentioning how elegant this functionality might be implemented in Sass or Compass. The box-shadow example above is illustrative, but as a developer who has been writing nothing but Sass and Compass for the past year, it feels exceptionally repetitive.

How about something like this?

/**
 * This would compile to the code in
 * the previous example.
 */

@include supports( box-shadow ) {

  .shadowbox {
    @include box-shadow(0 0 5px -2px black);
  }

}

Lovely. That’s what I thought. The practicality of adding @supports (or something very similar to it) to browsers is obvious, so let us hope that this draft continues to be developed and we see an implementation somewhere down the line.

Efficient Theming with Sass

2012-08-14T14:17:00-07:00

Even after a full year of writing stylesheets almost exclusively with Sass and Compass, I continue to find solutions to common problems that further convince me that I will never write vanilla CSS again. Creating theme sets is something I’ve worked heavily on in the past three to four months, and it’s there that I’ve honed my Sass-fu and started to establish some of the material I present here. None of this is what I would consider “best practice”, but rather possible solutions that I find rather elegant. Some of this may be useful for others, and some of it may not be.

Variable Semantics

Let’s demonstrate a problem. Say you’re developing a base stylesheet, and eventually you’re going to create child themes that inherit from your base, overriding variables to change colors, dimensions, etcetera.

_base.scss

$grey: #ccc !default;
$blue: #4169ff !default;

body {
  background-color: $grey;
  color: $blue;
}

Great. Everything looks good. Now say we get a request in to make a child theme that has green body copy. Sure, no problem. We defined our variables with !default flags so we can easily override them.

theme01.scss

$blue: #299126;

@import 'base';

You’ve no doubt caught on by now that we’ve essentially just destroyed the semantic value of our variable name. Sure, the above file will compile just fine, and even look correct in browser, but we have a variable that has essentially been decoupled from its actual assigned value.

Don’t give your variables vague names assuming you’ll be able to reuse them in multiple places. If you plan this out carefully, it could work. But in many cases, in my experience, you will eventually find yourself renaming variables or creating new variables anyways. Create variables with purposeful, semantic names:

_base.scss

$body-width: 960px;
$body-background-color: #eee;
$body-copy-color: #222;

body {
  background-color: $body-background-color;
  color: $body-copy-color;
  margin: 0 auto;
  width: $body-width;
}

Seem like overkill? I promise you it’s not, and you’ll thank yourself later, as will any other developer trying to work with your themes.

Standalone Config File

We all know that one of the best parts of precompiling our stylesheets is the ability to use variables. As the ones developing and maintaining code, effective use of variables can shave hours off the time it takes to make changes or implement new features on a platform. That being said, large systems using Sass will undoubtedly end up with a considerable number of variables. All of these variables should (hopefully) be kept in a single well-documented file. For every large system I maintain stylesheets for, this file is my _config.scss partial.

The official Compass website does a decent job explaining this concept, but does not explicitly state something crucial to this concept: your configuration partial should never define or import any actual CSS. Importing anything into the configuration partial that would result in actual compiled CSS ruins the ability to then import that configuration file into multiple files without duplicating code.

“Smart” Variables

Say you’re developing a theme, and you have a header bar that has a background gradient. You could define the two colors of the gradient as two variables:

$header-gradient-1: #000;
$header-gradient-2: #fff;

However, I find it much cleaner to store these as a list, since the naming of these two variables implies they will always be used together (and if not… rethink the semantics of your variable names):

$header-gradient: (#000, #fff);

This reads much cleaner, and then you can use the native Sass nth function like such:

@include background(
    linear-gradient(
        nth($header-gradient, 1),
        nth($header-gradient, 2)));

However… this poses an issue. What happens when you have a theme to develop that SHOULDN’T use a gradient, but rather a solid color? This is when you can make good use of the built-in type-of function and some conditionals:

@if type-of($header-gradient) == "list" {
    // Code here for a gradient background
}
@else {
    // Code here for using a solid background color
}

Implementing this where appropriate will result in a more flexible theming environment.

Inline Your Media Queries

This concept has been written about before, but it’s worth mentioning here and expanding upon a bit. First, an example. Below we have the beginnings of a file structure for a responsive design. Simplified, yes, but bare with me. Individual sections are defined for different areas of the page, segmented by docblock-style comments. We’re using a custom mixin for our responsive queries, passing content in via @content blocks. Everything looks great.

main.scss

/**
 * Base Styles
 */

// Header
[role="banner"] { }

// Body
[role="main"] { }

// Footer
[role="contentinfo"] { }

/**
 * Media Queries
 */

// Tablet
@include respond-to('tablet') { // etc... }

// Desktop
@include respond-to('desktop') { // etc... }

Now imagine something else: imagine that for each of the three main sections, header, [role="main"] and [role="contentinfo"], we have anywhere between 500 and 1000 lines of code. Suddenly our structure seems a bit more unwieldy. When you get into the tedium of adjusting styles at multiple screen resolutions, the act of scrolling up and down through thousands of lines of code, several times each minute, becomes a chore. Luckily, the solution here is easy.

Write your media queries inline with the base styles. Seriously, do it. Keeping media queries in proximity to the base styles does two things: it reduces the obnoxious amount of scrolling between sections while writing styles for different breakpoints, and, maybe most importantly, contextualizes the content being passed into the media queries. Often times the styles being set at specific breakpoints are there to override or set properties not present at other resolutions. In other words… most of the styles we write in media queries are meaningless without seeing the base styles to compare.

main.scss

/**
 * Header
 */

[role="banner"] {

  // Base styles...

  @include respond-to('tablet') {
    // Tablet styles...
  }

  @include respond-to('desktop') {
    // Desktop styles...
  }

}

Are there implications of writing your media queries inline like this? Yes, there are. Namely, you’re going to end up with a compiled CSS file with a bunch of duplicate @media queries. Whether or not this is a dealbreaker is something each developer needs to decide on his or her own. My opinion is that writing media queries in this manner is more than well justified by the time saved and frustration avoided.

Font Face Syntax in Compass

2012-07-23T11:50:00-07:00

Since the documentation on the Compass website is a tad confusing I thought I’d clarify the basic usage of the @font-face mixin included in Compass.

If you’re using Font Squirrel or any other web font creation tools, you should have a stack of font files with different file types for each font you need to load: .woff, .ttf, .svg and .eot. Drop these into the fonts directory for your Compass project (by default it’s a folder called ‘fonts’ inside the compiled CSS directory, like ‘/css/fonts’). Once these files are in the correct place, the syntax is as follows:

// Import the Compass Font Face module
@import "compass/css3/font-face";

// Define our font
@include font-face('My Font Name', 
  font-files(
    'fontName.woff', woff,
    'fontName.ttf', ttf,
    'fontName.svg', svg),
    'fontName.eot');

After importing the Compass module, the first thing we do is name our font. The string value can be set to your liking, and will be used in your font stack declarations. The font-files() array then defines the names of the included files, with an unquoted indication of its file type. Note that the *.eot file is a standalone string outside the font-files() array and is used only by IE.

Our custom ‘My Font Name’ font is now available to use just like any other in a font stack declaration. However, since we’re using Sass and Compass, we should go ahead and make this DRY and create an @extend-able selector. If you’re using Sass 3.2.x you can use a @extend placeholder, or just use a regular class to extend if you’re still using the stable version.

%myfont {
  font-family: 'My Font Name', sans-serif;
}

h1 {
  @extend %myfont;
}

NN/G Usability Week

2012-06-25T09:56:00-07:00

Here are my unedited notes from the Nielsen/Norman Group Usability Week conference I was at last week. Extract as much or as little from this as you can, as I will be doing the same over the next few days. The session on ‘Creating Credible and Persuasive Websites’ was especially enlightening, so I expect some of what you see here to influence a post or two in the coming months.

Designing Complex Apps & Websites

Complex applications need to provide the user with an exploratory path rather than a cut and dry “Point A to Point B” workflow of simpler applications.
In complex situations, user-centered design can fall short
- Tech and development has evolved fast/often whereas tools for UCD have not involved very much
How do you align the conceptual model of a designer and the end-user when the end-user may have 20+ years of experience in the domain versus a two-week sprint?
Challenge: how do you quickly ramp up on decades of domain experience? (Becoming a “pseudo-expert”)
Usefulness VS usability (value of functionality VERSUS how easy is it to use?)
A successful user experience depends on so much more than visuals:
- Design
- Content
- Interaction/UI
- Navigation
- Functionality/Usefulness
- Audience/Needs/Goals
Applications fall into a triangular space where the corners are (1) Useful, (2) Appealing and (3) Usable
Prohibiting Usefulness
- Too much focus on the technology
- Talking only with clients rather than end-users
- Self-fulfilling user research
- Overuse of focus groups: great for understanding requirements but not for testing design
- Talking to users before you understand the domain
Understanding usefulness up front:
- Minimizing risk
- Better understanding of whether you should integrate with other services or whether your tech can replace/displace other processes and technologies
- Identifying ways to put your own software ahead of existing competitors
Design Research to expose usefulness
- Results in clearer personas and earlier/better wireframes
Applying user-centered design earlier in the process:
- Removes assumptions earlier in the process to align the models of designers and stakeholders
- Provides more time to become pseudo domain experts
The “Design Research” focus
1. Learning about the domain
2. Creating hypotheses about end-users
3. Test with potential actual users
4. Test hypotheses through observations/interviews and usefulness tests
5. Get to the root of what you ACTUALLY found, not what you HOPED to find
6. Seek out emerging patterns in the Usability
Stakeholder Data Collection
- Identify key stakeholders and interview/survey on an individual level to determine goals, core UX metrics to gather, personas to target, use cases, tech requirements (or things to avoid)
- Analyze/summarize this data and present back to the entire group of stakeholders to help align everybody
- Aligning the views of stakeholders up front BEFORE gather product req’s will speed up time to a focused, solid MVP.
User Recruiting
- Identifying personas
- Weed out bad matches for your user studies
- Find good sources to find users based on your personas
- Loosen participant requirements if you can’t get the right people
- Avoid user testing with “professional” user testing participants: they are not “normal” users b/c they frequently test.
Primary differences between “usefulness” testing and “usability” testing
- Earlier in process to figure out if application elements are “useful”
- Testing materials are not always prototypes, and if so they are rough and conceptual
Utilizing a range of user research methods throughout the lifecycle of a product will help blur out the cons of certain methods.
Test domain-specific language in your usefulness and usability testing: are users able to understand the domain-specific terminology used in the app? If not, this is a problem.
Artifacts
1. Personas
2. Personas should not be perceived as a “deliverable”. They are living documents. Keep them updated. Reference them often. Put them in a visible place in your workspace.
3. Personas for domain experts can help to disseminate ways to help them trust the application more (“technology trust indicators”)
4. Driven by data… based on USERS not CUSTOMERS
5. Use Cases / Epic Stories
6. Domain experts need: confidence indicators, domain-relevant terms, exploratory workflows
7. Use cases may fall short because: 1 Too much reliance: ultimately they are theoretical… get some actual data 2 UI detail provides too much “solution” (button colors, for instance) 3
8. Enhancing use cases:
  - Theme, related personas, similar features, lengthy descriptive story, domain-specific terms, interaction pattern candidates
Patterns
- Abstract and draw upon known solutions to comprehend challenges
- Shared knowledge across organization
- Helps expedite prototyping
- Common design language
- Global consistency
- Easier learning curve for users: feel more safe/familiar
- CONS: laziness (no testing), patterns become stale, company culture shift may be required (YUP)
- Integrating patterns into your development cycle:
  1. Identify candidates for patterns via personas and use cases
  2. Apply patterns and test them through early prototyping
  3. Manage/maintain patterns during development. Integrate them into your organization
- Major benefits
  - Development efficiency boost
  - More code recycling (DRY)
  - Faster prototyping
  - Consistency between releases
  - Plays well with rapid development (agile/scrum)
- “Many organizations estimate an upward of 20% loss in design quality moving from prototypes to production, prior to utilizing patterns”
THOUGHT: Shouldn’t forms be a “conversation” rather than a questionnaire thrown into the users lap? Let’s start GUIDING users through forms better.

Creating Credible and Persuasive Websites

Question: What are the things that drive trust and persuasion in web design?
Believability and persuasion: you must be believable to be persuasive.
Designers must attempt to understand what their potential users are susceptible to.
Credibility + benevolence = trust
A user’s disposition to TRUST your site will depend on your audience: their experiences, cultural background, personality…
- Are any of these factors things that YOU can do something about as a designer?
Untrusting users do not make for good user cases.
Users do not fixate on banners, regardless of content (peripheral disregard)
Globally, stats show that a general sense of “trust” is decreasing
Often the mistrust felt by users is NOT the fault of designers/developers
Giving additional control to users can go a long way for helping them trust your site
Trusting a website is a two-step process
1. Initial (spontaneous)
2. Safe? Meet expectations?
3. FIVE SECOND TESTS – DO THESE
4. Experiential
5. Good for me? My best interests at heart?
“Dont ask for too much, too early”
How do you gauge credibility?
- “Which site would you choose?”: top factors were looks, navigation, focus, motives, usefulness
- “Prominence interpretation”
  - Things are only change credibility as much as they are noticeable.
  - Prominence X Interpretation = Credibility Impact
Guided studies lead people to rate certain factors higher
DO
- Observe users
- Add to perform specific tasks
- Watch/listen/ask to unveil credibility issues WITHOUT mentioning it
DONT
- Conduct surveys
- Ask to select attributes that affect credibility
- Ask to just credibility of your site
Cognitive Ease VS Cognitive Strain
- Untrusting users fall into a pattern of cognitive strain
- Increase believability by reducing the strain: vigilant, suspicious, increased effort
- Factors:
  1. Legibility (bold, larger, etc)
  2. Avoid complex language
  3. Memorable messages (prose/verse)
  4. Quote sources with easy to pronounce names
  5. Optimization testing (A/B or split)
The Mind
- “Automatic” (System 1) vs “Effortful” (System 2) Systems
  - Fast vs slow
  - Automatic/low effort vs effortful mental activities
  - Simple decisions/relations vs deliberate choices
  - While we identify with effortful systems, automatic systems more often “run the show”
  - System 1 feeds System 2: endorsing the intuitions, intentions or feelings of 1 in 2 leads to these becoming beliefs
- http://trust.edelman.com/trust-download/global-results/
- Human Automaticity (this is system 1 working)
  - “Human automaticity is the ability to do things without occupying the mind.” – Robert Cialdini
- Will users be using your site under positive or negative circumstances?
- Judgment errors common with system 1
- People will default to speed and convenience over accuracy
- “People judge competence by combining two dimensions: strength and trustworthiness.”
- Cognitive Biases
  - Priming: “Priming is an implicit memory effect in which exposure to a stimulus influences a response to a later stimulus.”
  - Anchoring
  - Framing
  - Reciprocation
    - A perceived obligation to repay what another has provided
  - Commitment and Consistency
    - Users feel committed to a choice they’ve made (they have to)
  - Social Proof
    - People seek validation through the reviews/opinions of others
    - Many will deny using reviews or caring about what others think to seem logical and intelligent
  - Liking
    - People seek out similarity, familiarity, cooperation, association.
    - the “Halo Effect”: one good trait favorably affects overall opinion
  - Authority
    - “Obedience constitutes correct conduct”
    - People react to symbols of authority
  - Scarcity
    - Things more difficult to obtain are perceived as more valuable
- HOW DO YOU DESIGN FOR DESIRABLE ACTIONS?
- Applying Persuasion and Trust
  - The Kano Model
    - Basic vs Performance vs Excitement features
  - The Credibility Model
    - Basic, Befriend, Believe
- Persuading people to visit websites
  - rank within top half of first page of search results
  - brand familiarity
  - quick loading pages
  - how people search
    1. look at results above fold
    2. skim results for familiar names in results
    3. skim URLs
    4. skim descriptions
    5. pick up details like dates
- Persuading to STAY on your site
  - Personal referrers create more forgiving new visitors
  - Talking heads = FAILBOTs
  - “Visual first impression impacts perception of experience”
  - Users assessment of websites:
    1. Page load speed
    2. Judge visual appearance
    3. Fixate on specific pieces of information
    4. Click on “scent” of information
  - Utilizing associative imagery will prime the user
  - Users shopping on price actually react NEGATIVELY to more professional designs - surprising.
  - Use larger images (rather than more content) on listing pages
  - Any sort of overview pages should include images to guide the user to their destination
  - Local providers need to indicate service area PROMINENTLY and PERSISTENTLY
  - Specific & persistent taglines
  - Take care of your localized content: credible, up-to-date and (if applicable) accurately translated
  - Prices should be visible by default
  - Being able to sort products can alleviate mistrust (give the user control)
  - Two equally attractive product choices can paralyze users and delay purchase decisions… three carefully chosen options can often convert better
- Persuade people to BELIEVE your site
  - cognitive ease: consistency, clear descriptions
  - user stories / testimonials NEED to be believable or relatable
  - show CONTEXTUAL images of your products
  - use face photos for personal transactions
- Persuade people to ACT on your site
  - Remove obstacles: lead to decisions and desirable actions
  - Behavioral economics states that people are irrational yet predictable and systematic
  - Logical VS persuasive design
    - persuasive design says that many of our (the users) decisions are driven by the gut, not the head
    - through persuasive design we can encourage people to make certain decisions (“Decision Architecture”)
      - determine complexity and impact of decisions
      - it is up to US as designers to determine things like defaults, number of and difference between options, ordering, and wording
      - “opt-in” is more effective than “opt-out”
- The Eight Guidelines
  1. Build brand awareness
  2. Create a visual language that speaks to your target users
  3. Address common objections through testimonials (for example)
  4. Cut choices
  5. Remove obstacles
  6. Apply the Influence Principles
  7. Test, Test, etc
  8. Read a lot!
“Thinking Fast and Slow” book

Fundamental Guidelines for Web Usability

Consider: in your market/industry, what other sites are your users seeing? What comes before you in Google search rankings that you can compare/contrast with?
Huge majority of people start at search engines and rarely hitting the front page of the site (75% of results hit interior page)
Most of peoples tasks online are goal-oriented
How do we balance the business goals of a site or application with the goals of our users?
Truths: users can’t understand things that YOU don’t understand (how do we overcome poor leadership, business models or strategy?)
Stop imposing joy on users… instead let’s focus on content and let the site speak for itself.
We need to back away from the idea that complex business rules == complex interfaces. Users will love you more for SIMPLIFYING.
Stop imposing joy on users… instead let’s focus on content and let the site speak for itself.
Stand up for your content: question or test the motives of executives through split testing and key metrics.
Designers, stand up for your content: question whims of execs w/ split tests & analytics. Do execs represent target audience?
Be aware: an estimated 43% of users are “low-literacy” users. They won’t read or even scan, but “plow” or skip text content entirely.
Patterns of reading/scanning:
- The ‘F’ pattern
- The ‘Spotted’ pattern
- ‘Layer Cake’ pattern (what turns into the ‘Commitment’ pattern)
  - Headings help users quickly scan to relevant content
Copywriters: even highly literate users appreciate succinct copy and clear, readable product or service descriptions.
Only 5% of people view links on page two or higher of web searches, and 78% will only click one link (or not at all) per search.
Aesthetics DO make sites seem more usable
- How people feel about sites strongly correlates to how much they feel they can get done on the site.

User Experience Basic Training

Products should be designed around people, rather than creating products we need to teach people how to use
SOFTWARE can make products more complex
Usability: smooth interactions between computers and people
1. Learn-ability
2. Efficiency
3. Memorability
4. Errors
5. Satisfaction
Users shouldn’t have to stop and think about things. Things should be simple and clear, and OBVIOUS.
Usability heuristics are not guidelines, but things we SHOULD DO when designing a user experience
1. Visibility of system status
2. What is happening on the site? Provide feedback to the user so they know what’s going on.
3. Match language between system and real life
4. Don’t abstract things that don’t need to be. Examples: buying tickets for flights, using the same terminology
5. User control and freedom
6. Give users some control over the information they’re seeing
7. Consistency and standards
8. This goes for links, colors, navigation, headers, footers, etc
9. Error Prevention
10. Try and help the user to prevent errors (auto-complete, for instance)
11. Recognition rather than recall
12. Avoid forcing the user to remember things between screens or sections of your site
13. Flexibility efficiency of use
14. Aesthetic and minimal design
15. Help users recognize, diagnose and recover from errors
16. Help and documentation
“People like things they are good at”
Three different levels of processing in user experience
1. Reflect
2. Behavioral
3. Visceral
“UX isn’t just about creating high quality products, but focusing on high quality experiences these products create.”
UX form design question: do we need this information right now? what do we REALLY need to know? is this form even needed?

File Cloning in Sublime Text

2012-06-10T12:58:00-07:00

One of the handiest pieces of functionality that many code editors implement is the ability to split, or clone, files into a new tab or window. As one might expect, Sublime Text has this functionality built in, albeit somewhat hidden. The wording of the menu item isn’t immediately clear, resulting in my not knowing the feature even existed until I did some digging around.

Basic Cloning

To clone a file into a new view using Sublime Text 2’s default functionality, find New View into File in the File menu. The result is a new tab in your current group with a second version of the file open. Changes made to the view of either of these files will update the other as well, and saving in one view will save the other. The file has effectively been “cloned”.

Unfortunately, I found using this menu item frustrating. Even if you set a keyboard shortcut (there isn’t one assigned by default), the file is just cloned into the existing group. Given that the point of cloning a file is to look at two copies side by side, it’s a downright pain to break your flow in order to select the menu item (or keyboard shortcut) and then split your layout and drag the file over.

Making Cloning… Better

So I wrote a plugin. My first Sublime Text plugin, in fact. I had been looking for an excuse to look over the plugin API anyways, so this seemed like an easy enough utility to get my hands dirty with. SimpleClone makes it much easier to clone files. Effortless, really. The first version of the plugin provides the ability to clone a file to the right (vertical split) and down (horizontal split) with lightning fast keyboard shortcuts.

To clone a file to the right, hit Apple-Shift-Right*
To clone a file down, hit Apple-Shift-Down*

For those using Package Control, you’ll find it under ‘SimpleClone’, or you can clone the plugin from the Github repo. Browse to your ‘Packages’ directory in Terminal and run:

git clone https://github.com/mikefowler/simple-clone.git

*(Windows and Linux users: use Ctrl instead of Apple)

Use Cases for Cloning

So, why is file cloning useful anyways? There are obviously a lot of use cases, many of which will be specific to the language or environment you work in, but in my day-to-day tasks, I find it incredibly useful for working with Sass. For smaller sites that do not necessitate their own _config.scss partial, I’ll keep my section of variables at the top of the file. If you make heavy use of variables as I do, scrolling back and forth to the top of the file to reference variable names can be frustrating. Solution? Clone the file off to the right and keep the section of variables in view while you continue working on the left.

I think this case holds true outside of Sass as well. Cloning is great when you need to quickly reference another part of the file and want to avoid losing your current place in the file.

Feedback on the plugin are welcome in the comments below or via Github.

Semantic Widget Pattern

2012-05-21T11:41:00-07:00

This is a pattern I’ve been using a lot recently for marking up and styling generic widgets. This has gone through several iterations, the goal each time being semantic markup, as free of presentation-only tags as possible, a full-width header and a padded content area. The goal here is to achieve something that looks like this:

Take 1

My initial pass had been fairly straightforward: a sectioning element (aside, in my case) with a top-level header. Following the header was a div element to handle the padding around the content. Something like this:

Take 1: Markup

<aside class="widget">

  <h1>Widget Title</h1>

  <div class="widget-content">

    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>

  </div>

</aside>

Take 1: Stylesheet

.widget h1 {
  background: #eee;
  width: 100%;
  padding: 10px 0;
}

.widget .widget-content {
  padding: 10px;
}

This is pretty simple and to the point, but I like to eliminate excessive divs wherever I can, so after a while I revisited the problem.

Take 2

My first attempt at eliminating the extraneous div element was to just globally apply padding to every element inside a .widget with the exception of the top-level header.

Take 2: Markup

<aside class="widget">

  <h1>Widget Title</h1>

  <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>

  <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>

</aside>

Take 2: Stylesheet

.widget {
  padding: 10px 0;
}

.widget > * {
  padding: 0 10px;
}

.widget > h1 {
  padding: 10px 0;
}

This seemed to work alright, but there’s still some part of me that feels dirty using global selectors like that.

Take 3

The last revision is the pattern I’ve been using. I was frustrated that it took me so long to see the simplicity of it in the first place, but now it seems like a no-brainer. As I commonly do, I’d overlooked the usefulness of negative margins. Using negative left and right margins on the top-level header we’re able to apply the padding to the .widget itself and not deal with global selectors.

Take 3: Markup

<aside class="widget">

  <h1>Widget Title</h1>

  <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>

  <img src="http://placehold.it/400x400" alt="" />

</aside>

Take 3: Stylesheet

.widget {
  padding: 0 10px;
}

.widget h1 {
  margin: 0 -10px;
  padding: 15px 10px;
}

Demo

View Demo

Thoughts and suggested improvements welcome in the comments.

Using a Local Domain to Serve Scripts for Development

2012-03-16T10:49:00-07:00

I wanted to share something I started doing recently that has sped up my process for quickly mocking up sites. See if the following sounds at all familiar to you…

You’re working… you’re in the flow… you feel good. Suddenly: A WILD IDEA APPEARS! Adrenaline is released and you scramble to open your code editor of choice to mock up the idea before it escapes. Your fingers move across the keys with the elegance of a lithe dancer. You trigger your default HTML page snippet. TAB!

You attach a stylesheet and open it. Some quick markup and a few blocks of styles and your idea starts to take form. You see the user interaction taking shape in your head. Quickly! Include your DOM-manipulation library of choice and… and suddenly you stall. I realized lately how much of a drag it is in circumstances like this to interrupt a stream of great ideation, even for 30 seconds, and go grab the latest version of a script from the website or Github. So this is what I did:

Create a Virtual Host Specifically for Utilities

I created a virtual host on my local LAMP stack that has a straightforward URL of http://utility/. I started populating the root of that domain with scipts I frequently use: jQuery, CSSRefresh, a Modernizr production build, etc. Then I started creating snippets in Sublime Text so that I can insert a production build of the latest version of jQuery painlessly by typing ‘jquery’ and hitting tab. In less than two seconds I have the script imported and I can keep working without worrying about even leaving my code editor to grab a script.

The only maintenance involved here is keeping the scripts up to date in your utility directory. That being said, I could certainly improve this process by checking out all of the scripts in that folder from their respective repositories and creating a simple script that would run once per week (or whenever) to pull any changes from remote.

Sublime Text: Pretty Great

2012-03-01T16:07:00-08:00

I’ve recently changed my development environment across all platforms after finally taking the time to try Sublime Text 2.

As any other developer will agree, this is a momentous occasion. Ones development environment is like a close friend, guiding you through the darkness on the occasionally lonely and dark road to enlightenment. Its softly flitting cursor moves elegantly across the screen even as you spew out poetry that will bring an idea to life. The subtle highlighting of the code…

Fine. Maybe I’m exaggerating. But in all honesty, it’s a great feeling when you find a tool that just seems to fit you, not unlike a great pair of jeans. That has been my experience thus far with Sublime Text (specifically Sublime Text 2, in beta form).

Things I Like

Command Palette

One of the most frustrating things about programming can be the need to continually switch between the keyboard and mouse to perform various operations. Most code editors attempt to solve this issue by providing customizable keyboard shortcuts for performing nearly any operation, and this solution works fine. That is… until you’ve experienced a better way. A quick keyboard shortcut in ST2 brings up their “command palette”, a simple overlay with a scrollable list of all the possible commands. Once that appears, you can begin typing the command you want to run and the list will filter based on your query. The arrow keys allow you to select the command once you identify the one you’re looking for, and Enter executes it. All without moving your hands off of the home row.

Project Switching

Projects in ST2 are defined by including folders which then appear in the sidebar for easy access. Pretty standard functionality in this case except for that you’re provided with an interface similar to the Command Palette pictured above that allows you to switch between projects with a couple of keystrokes. Projects maintain which files are open so switching back and forth from project to project isn’t a hassle at all.

Multi-Select

I’d be remiss to write a review of Sublime Text without mentioning this, because this is another example of “you didn’t know you needed it until you had it”. There are two ways of using this:

Highlight a text or expression
Press Ctrl-D. With each press, ST2 will select the next instance of the selected text
Once you’ve selected all the instances you wish to change, just type. The text you enter will replace each instance you highlighted.

OR:

Use your mouse to select a block of text
Hold Ctrl and select some more text, in another location
Type. You will replace the highlighted text in each location selected.

It’s like magic. I would almost urge somebody to try Sublime JUST for this feature.

Add-On Packages

You can install community plugins within seconds from the command palette, and there are a LOT of community plugins. Want to be able to fire off a Stack Overflow search from your editor? You can do that. Triggering JS Lint with a keyboard shortcut. Yup. Automatic Docblock formatting. You bet. SVN or Git integration. Uh huh.

I could continue, but the number of things to like about this application are too numerous to list here and ultimately must be experienced.

Things I Don’t Like (As Much)

I’m not even sure “don’t like” is the proper title for this section. It might be more appropriate to state the things that would make Sublime Text 2 PERFECT.

Remote file editing (a la Coda)
Syntax support for MVC3 Razor Views (would be helpful at work, not as much in personal work)
Projects could certainly allow for finer control of what is included in the sidebar (allowing single file includes rather than only folders, for instance)

The above being said, it’s important to note that Sublime Text 2 is still in beta, and the past several releases have seen an incredible number of new features.

The Skimmer’s Summary

Try Sublime Text. You won’t regret it.

Is Device-Friendly Development a Responsibility?

2012-02-15T10:38:00-08:00

I got to thinking the other day: is developing device-friendly websites a responsibility of the developer? If it’s not now, will it ever be?

This is an issue that I think is worth talking about. I’d like to hear some other opinions as I think through this myself. I’ll start with some thinking points and then wrap it together at the end.

In The Beginning…

…there were tables. For the simple reason that tables made it easy to align content in a grid-like fashion, tables become the de-facto method for creating visual layout. Layout via CSS become possible in the late 1990’s, but with browser support shoddy at best, it was certainly not the tried and true method that table layout was. And so things were, until the community began more closely considering things like semantics, accessibility and search optimization. As it turned out, the markup you used to create your layout could adversely affect these things.

Gradually, CSS became more powerful and saw better browser implementation. Fundamentally, this was one of the first large-scale transitions for web developers. Moving to CSS-based layouts meant learning a new scripting language. Thus, we arrive at our first question:

During this transition period, did we, as developers, consider it our duty, our responsibility, to inform clients of this transition and push them in the direction of a table-less layout?

Poor Browser Implementation Abound

Let’s jump five to ten years down the road. Microsoft has won the war against Netscape, and Internet Explorer dominates the browser market. Dominate might even be too lenient a description. Check out this 2003 press release from OneStat. This release came near the height of Microsoft’s browser dominance and shows Internet Explorer 6 with an astonishing 97.34% of the market share.

While these stats serve to illustrate just how much the market has changed since 2003, I’ve included them here rather to point out the importance of another massive shift in the industry. The initial release of Mozilla Firefox in 2004 put into motion a shift away from the proprietary browsers released by Microsoft to browsers built on community-developed open source engines, namely Gecko and Webkit.

So, a second rhetorical: In the past five to six years, have developers made it their responsibility to sway clients away from lingering old versions of browsers with poor implementations of CSS and towards modern browsers that provide the user with a richer, immersive experience?

Get to the Point, Already

Ok, ok. Let’s pull this back around. First some opinions.

While I was only getting started with web development at the tail end of the transition from table layout to CSS layout, I can say with certainty that I would have encouraged clients to go for a table-less layout. On the matter of pushing clients towards modern browsers and encouraging the abandonment of old implementations, I think it’s safe to say that I (and the rest of the community) have actively been doing that, even garnering support from Microsoft itself.

Looking back at these two major transitions in the history of web development, I am pointing a huge finger at how our job as developers relates to the technology we promote. Ultimately, our job as developers and designers is create rich, meaningful ways to deliver content that reaches our target audience and can create the best possible experience. For this to happen, we work as a community to push through new specifications and in turn encourage browser vendors to make those specifications a reality.

Over the past two years, developing for mobile devices has moved from an ideal to a requirement, especially for highly visible websites. While initially this requirement took the form of a native application, now more than ever there is a growing number of companies ditching the native application and developing mobile-friendly, browser-based solutions. Some of the more notable companies to achieve this in the past year are the Boston Globe (check out Zeldman’s article for more on that) and Smashing Magazine. There is no doubt that this trend will continue and we will start to see more and more larger companies launching redesigns comfortably viewable on a vast array of devices.

That being said, where do small companies fall in this trend? Should we expect the owner of a local restaurant to be aware of and request that their site be responsive and mobile-friendly? Would we have expected similar from clients in the late 1990’s when we began moving away from table-based designs? Or even two years ago when the push began to kill off the remaining IE6 user-base?

It seems to me that as the developers, the people engineering ways to experience content, a certain amount of this responsibility falls to us. If our job, as I feel is the case, is about delivering content in the most efficient and effective manner, then I think we absolutely have a responsibility to encourage clients to move towards mobile-friendly designs.

In Practice

Is anybody doing this yet? I’d love to hear from developers who have already made responsive development a part of their standard client packages, or have at least begun to have that conversation with some of the smaller companies you do work for. Like I said earlier, I think this is a conversation worth having, so please feel free to voice your opinion and get this discussion going.

The Role of Humility in Community Contribution

2012-02-03T16:39:00-08:00

Developers, designers, artists, musicians… to you I speak. Many of us followed a similar path into our respective creative fields. We spent years as a sponge. We sat quietly on the sidelines, reading as much as we could about our industries. As a result, many of us can proudly say that our livelihoods are the result of long hours of self-teaching and, above all else, an unquenchable passion for the subject.

Eventually we all come to a crossroads. It’s not that our desire to learn begins to wane. No, for most of us that will never happen. Our jobs are our lives. Rather, we begin to desire greater community involvement. For me, this desire brings about a struggle: feeling strongly enough about my own contributions to present them to the community.

This post is not about self-esteem. What I am suggesting here has little to do with self-esteem and much more to do with humility. I’ve strived for humility all of my learning life. I find much greater satisfaction in personal achievement than in public recognition. Unfortunately, this character trait doesn’t mesh very well with pushing opinions out to the public.

Here’s the thing: after you spend a great deal of time reading and learning from the work of community leaders and people doing exceptional work, they become mentors. You show great respect for their work and look up to them for helping teach you so much of what you know. Putting yourself on the same level as them and presenting your work and opinions for anybody and everybody to judge can be exceptionally intimidating.

Embracing Community

Thankfully, there are other reasons to push yourself to contribute back to the community that should (hopefully) trump even the most humble among us. Namely I am referring to feedback. The thing I’ve always loved most about the web development community is the cooperation. People speaking ill of each other or sabotaging others work or progress happens so infrequently that it may as well be nonexistant. Chances are, when you finally take the step to show the community something you’ve worked on (or currently are working on), you’ll find others who are both excited about it and eager to give their opinion, whether it’s suggestions, ideas, feedback or praise.

Granted, I should be following my own advice here and contributing to the community more than I do. That being said, you are reading this blog post, so I suppose I am doing my part and at least embodying what I preach here.

Balancing Act

Let me finish by summarizing the thought that led to me writing this in the first place. Community contribution can be intimidating for those of us humble by nature. For me personally I recognize that community contribution must strike a happy medium between humility and valuing your own opinions enough to share with others. In this way we share and collaborate with others while continuing to learn from those around us. And in this way, our community continues to prosper.

Professional Goals for 2012

2012-01-09T23:42:00-08:00

I don’t make New Years resolutions. I’ve always felt like the changing of a year is a lame excuse to decide to make a change in ones life. When I decide to do something (resolve to, if you will) I just do it. That being said, I’ve decided that this year, for my own benefit, I wanted to write out a list of things that I want to accomplish professionally in the next year.

This year in particular is one that I feel truly marks my entrance into my professional field. As evidenced by you reading this, I’ve finally gotten a website up that represents me as a web developer rather than an artist, which is what I spent my four years of college being. I’ve recently moved into a new job that I’m incredibly happy with where I can flex my brain and work on some really exciting things. I’m ready and poised to start contributing and being an active part of this community that I have become very much addicted to.

Events

The comfort of being in what I feel is a more long-term position takes a big weight off my mind and allows me to turn my sights to something that has been on my mind for quite some time now: helping build and foster the creative and development community here in Burlington. There are a couple of events already, namely Web Analytics Wednesday and Social Media Breakfasts, as well as some yearly events like the Vermont Code Camp, the Tech Jam and the South End Art Hop, that are helping bring various sectors of our creative community together on occasion, but there isn’t much in the way of events bringing together all the different professions. Just in the past couple of months a new group has started up called the Native Creative Consortium. The group was founded by several heads of businesses and education leaders in the area, including Michael Jager of JDK and Jeff Rutenbeck of Champlain College. Quoted from their homepage, their mission is “To unify the energy of Vermont’s creative community, amplify its potential to create positive change and build awareness of Vermont’s creative distinction”. This is truly exciting for our city (and our state). Important people in our creative community banding together to start something like this is EXACTLY what we need right now. I won’t say much more for now regarding my own plans, but I am very excited for the next couple of months.

Harnessing our Young Population

If you’re not familiar with Burlington, know this: we have over 20,000 students living and learning in a, relatively speaking, small city. When you include the 20-something population in that figure, we’re talking about a veritable force of young minds living in this beautiful city. Although this runs somewhat parallel with what I mention above, another project of mine for 2012 drills down specifically on trying to get the young population connected with one another to create amazing things. Again… more on that when the time is right.

Building the Design Side

Although I am most certainly a very visually-oriented front-end developer, if I had to place myself in a category of developer versus designer, it would be the former. Many might recommend that I let that be as it is and focus on building my developer repertoire, but that school of thinking has never really appealed much to me. I always have been and will always pride myself on having an uncommonly widespread skill set, even if that means not being an “expert” in any subject. This year I’m going to focus much of my personal time on my design skills, specifically layout, type and lettering. These have always been subjects of great interest to me, but I’ve never focused any significant amount of time on them, and certainly never received any sort of formal education regarding them.

Public Speaking

I will openly admit my desire for some public recognition as I’m planning these things I’m talking about here. Not in an egotistical sort of way, but more in the sense that I want to position myself as somebody who is influential and helpful in my geographic area because community building and bringing people together is something from which I derive great pleasure. Part of that is certainly public speaking. A definite goal for myself will be to do a presentation at next years Vermont Code Camp. On what subject? That remains to be seen…

Bring It, Year

I must say… I am more excited for the year ahead than I have been in past several. Excited for what I will build, excited for what the web community will build, and excited for the ways in which I can help bring members of my own geographic community together. So let’s do this.

You can read more about the Native Creative Consortium in this Seven Days article.

Our Obligation as Developers

2011-12-20T10:11:00-08:00

There’s no doubt that semantics are an oft-spoken about topic, especially recently. But let’s address a different issue.

As the HTML5 spec continues to introduce new elements, the debate rages about the value, or lack thereof, of implementation in our own code. In Divya Manian’s recent article on Smashing (first link above), she encourages developers to stop worrying about the minute details of the semantic meaning in elements, and I fully agree with her. However, as I read through the comments on Divya’s article, and many others like it since then, where developers are discussing semantic value, I began to notice a particular sentiment cropping up a bit too frequently for my liking. Paraphrased, these comments would read something like this:

Semantic value or not, it seems like a lot of unnecessary effort as a developer to learn what all these new elements and attributes mean when we should be focusing on creating work.

Or, even more alarming:

The whole HTML5 spec seems bloated and unnecessary to me.

The more I continue to read statements similar to this, the more it gets under my skin. We work and play in an industry that is built on progression and personal learning. A List Apart has not released their 2011 Survey results yet, but we can see a trend for the past four years (2010, 2009, 2008, 2007 (pdf)) that many people (at least half of the respondents, in most cases) say that their education mattered “a little” or “not at all”. For those respondents, a group I include myself in, what that means is that we’ve built our careers on personal learning: scouring the internet for comprehensive examples, following the work of key players, and keeping up with best practices.

To then read fellow developers inferring that we shouldn’t be dedicating at least a portion of ourselves to reading about semantics and applying the concepts to our own work is, frankly, disheartening.

To address the title of this post: Many of us got into this field by our own hard work and self-perserverance. If we want to continue working in a rapidly evolving medium, it’s not just our responsibility but our obligation to stay on the bleeding edge, and that includes keeping in touch with specs and emerging concepts. It is one thing to raise concerns about the inherent value of semantics and quite another thing to disavow learning about them altogether.

We as developers earned the privilege to work in such a dynamic and exciting medium. Let’s do our part to continue moving it forward.

phpDate

2011-12-16T17:24:00-08:00

phpDate is a tool for generating strings for PHP’s date() function. It was completed as a weekend project and uses actual magic. The tool allows you to assemble components of a date and then generate a string to be used with PHP’s built-in date() function.

phpDate was created primarily for the sake of my own sanity during a time when I was using date() frequently for a project.

Sound like something you could make use of? Try it out.

Settling on a Content System

2011-12-14T00:56:00-08:00

Around the time that I started developing this site I had started reading more about content systems that would generate static sites (as opposed to a database driven CMS). After a couple days of research I settled on Stacey, a brilliantly simple PHP-based system that builds pages on the fly using markdown-parsed source files. After familiarizing myself with the templating language I got to work creating my theme and finished that a week or so later. I was fairly happy with the ease of it and how I could exercise my obsessive need for file structure organization. It was easy to include additional stylesheets or javascript on any given page, which I knew I would need for any code demos I wanted to post.

Despite these things I was irked that there was no good way to categorize posts. I wanted to be able to separate my blog posts from my code experiments and projects. I wanted to be able to have an RSS feed that would only contain two of those three categories. Without a good deal of additional coding, Stacey wasn’t going to be able to offer me that. Retrospectively, I see that I should have defined some of those things for myself ahead of time so that I didn’t essentially finish building my site and then realize it wasn’t quite what I needed.

In any case, something else came along at just the right time. Octopress! The fantastic piece of work by Brandon Mathis walks the perfect line between being easy to use with a lot of features out of the box and maintaining a high level of customizability. I was able to maintain everything I loved about Stacey and gain those few extra additional features, and that made it worth learning another theme framework literally days before I was going to put the site up.

This is Why It’s Hot

Github Hosting: It’s extremely easy to set this up with Octopress, and built in
A certain amount of automation for creating posts is handled by a Rakefile
Supports Compass for compiling stylesheets (and why wouldn’t it)
Easy Rake command for compiling site in realtime for development (love this)
Jekyll + Liquid for templating is gorgeous and dead simple
Customizable to no end - I basically started a theme from nothing and cherry-picked features from the stock theme

Check out Octopress on its official site or fork it on Github. For some more thoughts on Octopress, check out this post over at Divya Manian’s site (she also just recently launched a redesign running on Octopress).

Passing Content to Mixins in Sass

2011-12-08T14:39:00-08:00

Version 3.2 of SASS adds this incredibly helpful piece of functionality: the ability to pass @content blocks to a mixin. ~~In order to check this out you’ll need to install the pre-release build of Sass since the 3.2 stable is not out yet. Open up your shell and run the following:~~

gem install sass --pre

~~This should install an alpha version of Sass 3.2 (alpha 35 at the time of writing). With that installed we can now try out the new feature.~~

UPDATE: Sass 3.2.0 has been released, so if you’re running the stable version of the gem, you’re all set.

So what do I mean by passing content to a mixin? We can already pass in parameters, isn’t that the same thing? Not quite. Consider the following example, as elegantly illustrated by Chris Eppstein in a Gist from several months ago.

What if we could easily keep our responsive media style rules grouped with the content it defines rules for, but not clutter our file with @media rules? Say, by doing something like this:

#content {

  width:960px;

  @include media(tablet) {
      width:720px;
  }

  @include media(mobile) {
      width:90%;
  }

}

Pretty nice, right? It makes much more sense to keep our media rules inline like this, rather than grouping them into a separate file or section of the document. For small sites it’s not too big of a deal, but when you’re dealing with stylesheets for larger sites, it’s a pain to locate the associated @media rules and make changes in potentially 4 different locations (default, tablet, mobile, wide mobile).

This is exactly what we can do with this new release of Sass. Here’s what the mixin looks like on the other end:

@mixin media($type) {

  @if $type == tablet {

      @media only screen and (min-width:768px) and (max-width:991px) {
          @content;
      }

  }
  @else if $type == mobile {

      @media only screen and (max-width:767px) {
          @content;
      }

  }

}

Everything looks pretty standard here except for the addition of our new keyword “@content”, which is equal to whatever content you pass into the mixin inside of the curly braces.

Check out the link above for some more examples of how this might be used. I’m especially excited for being able to use this for defining animation keyframes. Unfortunately, for now, Compass doesn’t seem to parse this correctly.