Experience Continuity Design®

For nearly two years, I've been working at an awesome little shop that builds nearly everything on WordPress. And for over two years, I've had some strong opinions about web design. Do you see all of the irony here? My blog is on Blogger and I have no credentials whatsoever for web design. That doesn't keep me from opening my mouth though. Ha! Anyway, this seems like the perfect opportunity to put big mouth to the test.

For over a year, I've been contemplating porting my blog to WordPress because it just makes sense. I work with WordPress every single day. I like WordPress. It seems like the right thing to do. And of course, I don't want just a regular old boring WordPress theme that looks like a million other blogs out there so I started coming up with my own design.

I came up with something that I call, Experience Continuity Design®. I'd like to think that this is nothing new but I wouldn't be surprised if no one has ever thought about web design in this way.

So the old school method of web design seems is what I call "The Least Common Denominator" method. Basically, the lowest resolution screen on which someone will view a website on is 1024 pixels wide. So to ensure that everyone can see your website, make a template that 960 pixels wide and just don't do anything wider than that. This really, really, really sucks on full HD widescreen monitors.

With the advent of the smartphone, that method has evolved, but only ever so slightly. With responsive design, you focus on what's most important, display that at the top of your narrowest resolution (~320 pixels) and then let everything flow out as you get larger. It seems like things still max out at a width of about 1200 pixels and really isn't all that different than it was, just slightly less wasteful.

The problem is that design hasn't adapted to the fact that users, in a "desktop" environment (so not on a phone or perhaps a tablet) almost universally have wide screen monitors. That's why there's always wasted space on the edges of most websites. Figuring out how to use that extra space necessitated a different approach.

Instead of finding the least common denominator in screen size, I latched onto the fact that desktop users' view port is essentially the same rectangle. Some are a little wider than others but basically everyone views web content through a rectangular frame. With that in mind, I mocked up my design so that all users would see the same content and layout regardless of the size of their rectangle, thus creating a continuity of experience. So whether you're on a 1280x800 Macbook Pro or have a WQHD monster, you will have the exact same experience.

Full screen @ 1920 pixels wide

1366

And then at 1024 where I felt it was time to respond to a 4:3 layout.

All of this was accomplished using some magical CSS by incorporating lots of percentages, vw's, and vh's. A year ago when I started this mockup, which has collected dust since then, browsers weren't all that happy with the vw and the vh but I think they might just be ready. And I'm hoping that by me actually publishing this, I will be motivated to make something happen. Of course, I don't have the PHP skills to execute but that's just a minor detail, right?

Does this not make amazing sense? Let me know what you think, please, in the comments.

The Dog Age Paradigm

It's a well-known fact that I am the proud parent of the world's handsomest dog. Diego and I have our birthdays a mere 10 days apart which inevitably leads to the "dog years" discussion. While I'm chronologically ten times older than he, in "dog years" I'm only about 1/2 older -- that is, if you subscribe to the notion of "dog years".

The average lifespan of dogs varies from breed to breed but it's somewhere in the neighborhood of 12 years. Since humans live on average about 80 years, we can say that dogs age about seven times faster than humans. Thus, while Diego has now completed three trips around the sun, he's actually 21 in dog years.

I think this model is silly and here are just a few examples of why:

1. Dogs can walk within weeks of birth (not even three months in dog years)
2. They reach adolescence well before a year (not even seven in dog years)
3. They're full grown well before being two (not even fourteen in dog years)

I do have a point in all of this, actually several:

1. Are there things in your project and/or testing that you just blindly accept as true even though they make no sense if you actually think about them?
2. One can prove anything with numbers.
3. Do you have processes that are overly simplified [or complicated] such that the intent gets lost?

I'd like to emphasize point one a little bit more. It's very easy for us to get stuck in a certain line of thinking about anything. Perhaps there's a developer that was plagued with delivering a series of bad code and now you think he's a terrible developer. Maybe some requirements weren't very clear and now the client wants something different than what was constructed but you think your solution is the best. Context-driven testing is God's gift to software testers. Test automation is the bane of mankind.

I'm not trying to suggest in any of those scenarios that opinion was formed haphazardly. Rather, I'm suggesting to not ever stop questioning anything, including your own conclusions. Things change as time goes on and context changes. I suppose the dog years "formula" came about as a way of explaining to children why pets don't live as long as humans. What might be acceptable in explaining a concept to a 5-year-old doesn't work for a 30-year-old.

Alternatively, the death of a family pet could be the "right time" to start teaching kids algebra. If we have to have a formula, I think this one works much better:

x equals the age in dog years and y equals the age in human years.

Your Website Is a Rubik's Cube

My coworker, @jakedowns, has a Rubik's Cube sitting on his desk. It seems to serve as a physical manifestation of the gears turning in his brain as he's working on solving a development problem. He's actually  pretty good at solving them and can usually do it in less than a minute.

On occasion, I've happened past his desk and noticed that it has been arranged in a checkerboard pattern. Last Friday I decided that he needed a challenge so I designed a pattern and told him to replicate it.

And he did! However, the pattern I provided was for only one face and his solution was for only one face. At the time, I made a joke that "the requirements were met but the purpose was not fulfilled" because I wanted the pattern to be displayed on all six faces.

At this, I set to work plotting out all six faces. It took me hours, literally, to figure out a valid solution extending the original pattern to all six sides. It was a great exercise for me. I learned that the pattern does not work when using the colors of opposing faces for the pattern (e.g. blue and green). I also learned that not only do I have to account for all eight corners, I also need to account that the thee colors on each corner are in the correct position relative to the other two. I also exercised my spacial reasoning skills quite a bit.

In the midst of all of this, I was thinking about how websites are like Rubik's Cubes. Designing and building a website isn't as simple as solving a Rubik's Cube where each side is a solid color. Rather, every website is unique, perhaps similar to others, but still has it's own individual requirements, much the same way that I created a new requirement for what it meant for Jake to solve the puzzle.

Upon doing a little internet research, it seems that there are some 43,252,003,274,489,856,000 (that's forty-three quintillion) valid combinations for a Rubik's Cube. When solving one for the traditional pattern, there is a well-established method to do so. However, when trying to solve for a custom design, most, if not all of that goes out the window. You still twist and turn but the algorithms have to be all new.

The thing about websites is that you don't just twist 'em and turn 'em until you feel like stopping and saying "Solved!" You have a goal in mind. Sometimes it takes a lot of work to get it figured out exactly what that goal is. Then you twist and turn until what you have matches that goal. It's a complex process because no two solutions are the same.

Here are some practical takeaways to keep in mind:

• Your customer, no matter what they say, has a very specific result in mind for you building their website.
• It is worth every minute to take the time up front to do design and business analysis.
• Changes made once development (twisting and turning) has begun is going to affect the deadline and is likely going to mean that some things are going to have to be done over.
• Testers are happy to look at your design before development begins and look to see if the corners match up the way they should.

The next time someone says to you the words "simple website" or "simple change", hand them two Rubik's Cubes that have been thoroughly discombobulated and tell them to change one of them to match the other.

Splitting Definitions

There are two words that we use interchangeably and even the dictionary considers them synonyms but I'd like to challenge us to be more judicious about when we use the word "normal" and when we use the word "average." For both words when we say that x is normal or average we're trying to convey a baseline against which to judge y. However normal and average imply completely different, I might argue opposite, methods of establishing the baseline.

Normal establishes the baseline through a rule. It's objective. Anything that doesn't follow the rule is abnormal.

Average establishes the baseline based on the collection of results. It's subjective. The baseline changes as the results change. Result x could be above or below average but it becomes part of the average when evaluating result y. If we wish to exclude x from the average then we're establishing a rule.

When it comes to software, functionality is generally normal and usage is average. In most cases we define [set rules] about how the software is supposed to work but we never know exactly who will be using it or how. It is quite impossible to set a rule as to who will be using the system. Instead we observe and look for trends and patterns. Be careful though because there is no such thing as an average user and when we create rules based on some composite, mythical person, we are sure to disenfranchise real people.

Normal = Objective. Average = Subjective.

Random Ponderings on Various Pay Structures

Recently, I was thinking about the various pros and cons of the various pay structures that we use: hourly, salary, and commission. Being an ardent subscriber of the context-driven testing school, I question everything -- even when I'm not testing.

Thought 1: Link to Productivity
Hourly payment is often applied where productivity can be closely tied to time.

Examples:
Manufacturing - parts per hour
Retail - number of associates needed to handle customer load
Custodial - how much can be cleaned in a given shift

Salary payment is often applied where productivity is linked to accomplishing a task that can require varying time.

Examples:
Software testing - make sure the system works
Teaching - in addition to classroom time, prep for lessons and evaluate student work
Business executive - run the company

Commission payment is often applied where productivity is connected with sales.

Examples:
Car salesman - sell more cars, earn more money
Real Estate Agent - sell more homes, earn more money
Mortgage broker - close more loans, earn more money

Thought 2: Productivity ≠ Working Hard
For any given task with a set amount of time, Person A could exude a great deal of personal effort and not complete the task whereas Person B could exude very little personal effort and finish the task with time to spare.

Thought 3: Time = Money
Hourly: The more hours you work, the more you're paid
Salary: The fewer hours you work, the higher your effective hourly rate
Commission: The more sales you make, which in theory means, the more time you use pursuing sales leads, the more you're paid

Thought 4: Salary is a bit of an odd duck
Unlike hourly and commission, the salary payment structure does not have a built in mechanism to actually get paid more than your base rate. A salary employee gets paid the same no matter how many hours he works or how many "tasks" are completed. Salary has other perks though. Generally it has more flexible hours and sometimes you may even get to leave work a little early or take off a few hours without using paid time off. And in comparison to commission, you're still guaranteed to make money. If a salesperson can't close any sales, he won't get paid. And I don't have any data to support this but with all things being equal, I think salary employees generally have a higher base pay than hourly.

Thought 5: Salary systems require integrity to work
In salary situations it is generally stipulated that hours worked in excess of 40 are not paid overtime. Moreover, employers generally require an accounting of time spent which should add up to about 40 hours. But in order for all of this to work, employees have to actually put in their 40 hours and employers have to keep overtime as the exception. In other words, employees shouldn't try to cheat the system and employers shouldn't try take advantage of their workers.

Thought 6: So why would anyone pick one over the other?
Really, that depends on a variety of circumstances. Generally the "choice" is in the choosing of the career. You don't say, I want to do FOO and be paid with structure BAR. Personality has a lot to do with it too. In the past, I've worked a number of hourly jobs. I liked being able to say, "my shift is over, time to go home." I think the pressure of a commission setting would would weigh heavily on me and I wouldn't enjoy it. But now I've been salary for my entire professional career and it's worked out really well because of the cerebral work that I do. Some days I finish a little early and then I don't have to wait for the clock to strike a certain time before heading out. Other days, I get in a thread and I don't even notice that the time is well beyond the average end of the day.

Counting My M&M's

Like millions of other Americans, I keep a stash of munchies in my desk drawer at work. I find that a little treat in the afternoon is a highly effective way to keep me focused on my work. One of my snacks, interestingly (or oddly), has evolved into a bit of a ritual.

It all started back in 2010. I was at my local Dominick's before work picking up a donut, something for lunch, and stock for the stash. I happened down the candy aisle and saw that they had the jumbo bags of M&M's on sale. I'm always a sucker for the lowest price per unit so I couldn't resist. Fast forward to the afternoon-snack time-and a funny little thought popped into my head: "Are there the same number of each color of M&M's in the package?" I decided to find out, just for the heck of it.

The jumbo sack of M&M's is 42 ounces so there are two things to keep in mind. 1. I do not eat the entire thing in one helping. 2. I was not about to dump out the whole sack and count them right then and there. Instead, I started a spreadsheet. Whenever I decided to have a handful of M&M's, I would first sort them by color, count them, and then record the stats in my spreadsheet. It didn't take too long for multiple passersby to notice and remark upon my method for eating M&M's. Suddenly I had a reputation that needed to be maintained! Never again could I reach into a sack of M&M's and NOT count each color.

Two years later, I'm now on my fourth sack of M&M's. I don't eat them every day and I don't always have them in my stash. But when I do, I keep statistics. Today, I am pleased to announce the public sharing of this information on my M&M Counter page!

The M&M Counter page has several fun features:

• The graph at the top shows the combined stats for all of the M&M's that I have consumed over the years.
• Then, I provide a graph and chart that are updated in real time that show the stats for the sack that I'm currently in the process of devouring.
• Finally, I have provided a form, for what I think is the most exciting feature of all, to allow YOU to join in the fun. You are welcomed and encouraged to contribute your own counts. Currently, the form only supports the regularly colored candies. Pick the closest option when selecting the size of the package. Soon, I will include a graph or two to display the user submitted data.

So yeah, it's a little weird. There's nothing scientific about this. There's no ploy to identify certain colors as subject of discrimination. It's just for fun. Enjoy!

Go to the M&M Counter Now