One For All and All For One

All for one and one for all, united we stand divided we fall. Alexandre Dumas, The Three Musketeers 

I've been putting off attempting to write what I might call "What I've learned about accessibility in twenty years" for a while - partly because even though it's based on a presentation and therefore already written (in a sense), copying PowerPoint slides as images is not very satisfying. Mostly, though, it's because it's likely to be a really long post and those often tend to not perform well. Considering what I've seen in the industry recently though, it's maybe past the time I should have done it, either way, here it goes.

Before I seriously dive into this topic, I want to share a little information about myself. Over the past (almost) two decades I've worked with accessibility in both the public sector, where I was bound by Section 508 of the Rehabilitation Act (1973), and in the private sector, where I've worked with guidelines that are now published as the Web Content Accessibility Guidelines (or WCAG). Over that time I've not only built a significant amount of what we might call "product knowledge" about accessibility, but have built quite a bit of passion for the work as well. I'm going to attempt to share that passion and attempt to convince you to become what I call an "Acessibility Ally" (A11y*ally, A11y^2, or "Ally Squared") - someone who is actively supportive of a11y, or web accessibility.

What Is This Accessibility Stuff, Anyway?

A lot of discussions about interface accessibility start with impairment. They talk about permanent, temporary, and situational impairment. They talk about visual, auditory, speech, and motor impairment (and sometimes throw in neurological and cognitive impairment as well). They'll give you the numbers...how in the US, across all ages,

• approximately 8 percent of individuals report significant auditory impairment (about 4 percent are "functionally deaf" and about 4 percent are "hard of hearing", meaning they have difficulty hearing with assistance)
• approximately 4 percent of individuals report low or no vision (which are not the only visual impairments)
• approximately 8 percent of men (and nearly no women) report one of several conditions we refer to as "colorblindness"
• nearly 7 percent of individuals experience a severe motor or dexterity difficulty
• nearly 17 percent of individuals experience a neurological disorder
• nearly 20 percent of individuals experience cognitive difficulties

They might even tell you how all those numbers are really First World numbers and when you go into emerging markets where reliable access to resources is more limited the numbers double. They'll talk about how, in general, those numbers are skewed by age and how about 10 percent of people under the age of 65 report impairment while more than 25 percent of people between the ages of 65 and 74 report impairment (and nearly 50 percent of those 75 and older report impairment).

I don't generally like to start there...though I guess I just did. Accessibility is not about the user's impairment - or at least it shouldn't be - it's about the obstacles we - the product managers, content writers, designers, and engineers - place in the path of people trying to live their lives. Talking about impairment in numbers like this also tends to give the impression that impairment is not "normal" when the data clearly shows otherwise. Even accounting for a degree of comorbidity, the numbers indicate that most people experience some sort of impairment in their daily lives.

The other approach that's often taken is diving directly into accessibility and what I call impairment categories and their respective "solution". The major problem here is a risk similar to what engineers typically refer to as "early optimization". The "solutions" for visual and auditory and even motor impairments are relatively easy from an engineering point of view, even though neurological and cognitive difficulties are far more significant in terms of numbers. Rather than focus on which impairment falls into the four categories that define accessibility - Perceivable, Operable, Understandable, and Robust - we have to, as I like to say, see the forest and the trees. While there is benefit in being familiar with the Success Criteria in each of the Guidelines within the WCAG, using that as a focus will miss a large portion of the experience.

One other reason I have chosen this broader understanding of accessibility is that accessibility in interfaces is holistic. Everything in the interface - everything in a web page and every web page in a process - must be accessible in order to meet the definition of accessible. For example, we can't claim a web page that meets visual guidelines but not auditory guidelines "accessible", and if the form on our page is accessible but the navigation is not then the page is not accessible.

Why is Accessibility Important?

When considering accessibility, I often recall an experience in interviewing a candidate for an engineer position and relate that story to those listening. This candidate, when asked about accessibility, responded something along the lines of "do you mean blind people - they can't see web pages anyway". I've also worked with designers and product managers who have complained about the amount of time spent building accessibility interfaces for such a "small" group of users or flat out said accessibility isn't a priority. I've worked with content writers who are convinced their writing is clear enough for their intended audience and anyone confused by it is not in their intended audience - what I call the Abercrombe and Fitch Content Model.

For those who consider accessibility important, there are a few different approaches we might typically take when trying to sway those who tend be less inclined to consider the importance of accessibility. In my experience, the least frequently made argument for the importance of accessibility is one of a moral imperative - making an interface accessible is the "right thing to do". While I agree, I won't argue that point here, simply because it's the least frequently made argument and this is going to be a post that bounds the too-long length as is.

The approach people most frequently take in attempting to convince others accessibility is important is the anti-litigation approach. Making sure their interface is accessible is promoted as a matter of organizational security - a form of self-protection. In this approach, the typical method is a focus on the Success Criteria of the WCAG Recommendation alongside automated testing to verify that they have achieved A or AA level compliance. The "anti-litigation" approach is a pathway to organizational failure.

Make no mistake, the risk of litigation is significant. In the US, litigation in Federal court has increased approximately 400 percent year-over-year between 2015 and 2017, and at the time of this writing appears to be growing at roughly the same rate in 2018. Even more significant, cases have held third parties accountable and have progressed even when remediation was in progress, indicating the court is at least sometimes willing to consider a wider scope than we might typically think of in relation to these cases. To make matters even more precarious, businesses operating internationally face a range of penalties and enforcement patterns. Nearly all countries have some degree of statutory regulation regarding accessibility, even if enforcement and penalties vary. Thankfully, the international landscape is not nearly as varied as it was, as nearly all regulations follow the WCAG or are a derivative of those guidelines.

So, why, when the threat of litigation both domestically and internationally is so significant, do I say focus on the Success Criteria is a pathway to failure? My experience has repeatedly shown that even if all Success Criteria are met, an interface may not be accessible - an issue I'll go into a little further when I talk about building and testing interfaces - and only truly accessible interfaces allow us to succeed.

What happens when your interface is not accessible - aside from the litigation already discussed? First, it's extremely unlikely that you'll know your interface has accessibility issues, because 9 of 10 individuals who experience an accessibility issue don't report it. Your analytics will not identify those failing to convert due to accessibility issues - they'll be mixed in with any others you're tracking. Second, those abandoned transactions will be costly in the extreme. In the UK, those abandoning transactions because of accessibility issues account for roughly £12 billion (GBP) annually - which is roughly 10 percent of the total market. Let me say that again because it deserves to be emphasized - those abandoning because of accessibility issues represent roughly 10 percent of the total market - not 10 percent of your market share - 10 percent of the total market.

Whether your idea of success is moral superiority, ubiquity, or piles of cash, the only sure way to that end is a pathway of accessibility.

How Do We Become an Accessibility Ally?

Hearing "it's the right thing to do" or "this is how we can get into more homes" or, sometimes the £12 billion (GBP) number - one of those often convinces people to become at least a little interested in creating accessible interfaces, even if they're not quite to the point of wanting to become an Accessibility Evangelist. The good news is that even something as simple as making creating accessible interface a priority can make you an Accessibility Ally.

The question then becomes how to we take that first step - how do we create accessible interfaces. The first rule you have to know about creating an accessible interface is that it takes the entire team. Accessibility exists at every level - the complexity of processes (one of the leading causes of abandonment), the content in the interface, the visual design and interactions, and how all of that is put together in code by the engineers - all of it impacts accessibility.

At this point, I should give fair warning that although I'll try to touch on all the layers of an interface, my strengths are in engineering, so the Building and Testing Interfaces section may seem weighted a little heavier, even though it should not be considered more important.

Designing for Accessibility

If we were building a house we wanted to be accessible, we recognize that we would have to start at the beginning, even before blueprints are drawn, making decisions about how many levels it will have, where it will be located, and how people will approach it. Once those high-level decisions are made, we might start drawing blueprints - laying out the rooms and making sure that doorways and passages have sufficient space. We would alter design elements like cabinet and counter height and perhaps flooring surfaces that pose fewer navigation difficulties. To remodel a house to make it accessible, while not impossible, is often very difficult...and the same concepts apply to building interfaces.

Most projects that strive to be fully accessible start with Information Architecture, or IA (you can find out more about IA at https://www.usability.gov/what-and-why/information-architecture.html). This is generally a good place to begin, unless what you're building is an interface for a process - like buying or selling something or signing up for something. In the case of a process interface, you've basically decided you're building a house with multiple levels and you have accessibility issues related to traversing those levels...to continue our simile, you have to decide if you're going to have an elevator or a device that traverses stairs...but your building will still need a foundation. Information Architecture is like the foundation of your building. Can you build a building without a foundation? Sure. A lot of pioneers built log cabins by laying the first course of logs directly on the ground...but - and this is a very big but - those structures did not last. If you decide to go another route than good IA, the work further on will be more difficult, and much of it will have to be reworked, because IA affects a core aspect of the Accessibility Tree - the accessible name - the most critical piece of information assistive technology can have about an element of an interface.

Once your Information Architecture is complete, designing for accessibility is considerably less complex than most people imagine it to be. Sure there are some technical bits that designers have to keep in mind - like luminance contrast and how everything needs a label - but there are loads of good, reliable resources available...probably more so for design than for the engineering side of things. For example, there are several resources available from the Paciello Group and Deque, organizations who work with web accessibility almost exclusively, as well as both public and private organizations who have made accessibility a priority, like Government Digital Service, eBay, PayPal, and even A List Apart.

With the available resources you can succeed as an Accessibility Ally as long as you keep one thought at the fore of your mind - can someone use this interface the way they want rather than the way I want. What if they search a list of all the links on your site - does the text inside the anchor tell them what's on the other side? What if they're experienced users and want to jump past all the stuff you've crammed into the header but they're not using a scrollbar - is there something that tells them how to do that? Keep in mind that as a designer, you're designing the interface for everyone, not just those who can [insert action here] like you can.

Building and Testing Interfaces

When building accessible interfaces, there is a massive amount to learn about the Accessibility Tree and how and when to modify it as well as the different states a component might have. Much has been made of ARIA roles and states, but frankly, ARIA is one of the worst (or perhaps I might say most dangerous) tools an engineer can use.

We're going to briefly pause the technical stuff here for a short story from my childhood (a story I'll tie to ARIA, but not till the end).

When I was a child - about 8 years old - my family and I visited a gift shop while on vacation in Appalachia. In this particular gift shop they sold something that my 8 year old mind thought was the greatest thing a kid could have - a bullwhip. I begged and pleaded, but my parents would not allow me to purchase this wondrous device that smelled of leather, power, and danger. I was very dismayed...until, as we were leaving, I saw a child about my age flicking one and listening to the distinctive crack...until he snapped it behind his back and stood up ramrod straight as a look of intense pain crossed his face.

ARIA roles and states are like that bullwhip. They look really cool. You're pretty sure you would look like a superhero with them coiled on your belt. They smell of power and danger and when other engineers see you use them, you're pretty sure they think you are a superhero. They're very enticing...until they crack across your back.

Luckily, ARIA roles and states are almost unnecessary. Yes, they can take your interface to the next level, but they are not for the inexperienced or those who lack caution. If you're creating interfaces designed for a browser, the best tool you have to build an accessible interface is Semantic HTML. Yes, it's possible to build an interface totally lacking accessibility in native HTML. Yes, it's possible to build an accessible interface in Semantic HTML and then destroy the accessibility with CSS. Yes, it's possible to build an accessible interface with JavaScript or to destroy an accessible interface with JavaScript. None of the languages we use in front-end engineering build accessibility or destroy accessibility on their own - that takes engineers. The languages themselves are strong enough...if you are new to accessibility, start somewhere other than the bullwhip.

The next topic most people jump to from here is how to test an interface to make sure it is accessible. This is another place where things can get tricky, because there are a number of different tools, they all serve a different purpose, and they may not do what they're expected to do. For instance, there are tools that measure things like luminance contrast, whether or not landmarks are present, or if any required elements or attributes are missing - validating according to the Success Criteria in the WCAG. In this realm, I prefer the aXe Chrome plug-in (by Deque). Nearly all these tools are equally good at what they do, but - and here's one of the places where it can go sideways - tools that validate according to the Success Criteria are a bit like spellcheckers - they can tell you if you spelled the word correctly, but they cannot tell you if you've selected the correct word.

Beyond Success Criteria validation, there are other tools available (or soon to be available) to help verify accessibility, the most common of which are screen readers. Of screen readers available, some are free and some are paid - VoiceOver on Mac and JAWS on Windows are the most popular in the US - JAWS is not free, but there is a demo version you can run for about 40 minutes at a time. NVDA (another Windows tool) and ChromeVox are free, but less popular. In addition to screen readers, in version 61 of Firefox the dev tools should include a tool that gives visibility into the Accessibility Tree (version 61 is the planned release, this version is not available at the time of this writing).

One thing to remember with any of these - just because it works one way for you doesn't mean it will work that way for everyone. Accessibility platforms are multiple tools that share an interface. Each tool is built differently - typically according to the senior engineer's interpretation of the specification. While the results are often very similar, they will not always be the same. For example, some platforms that include VoiceOver don't recognize a dynamically modified Accessibility Tree, meaning if you add an element to the DOM it won't be announced, or it may only be announced if certain steps are taken, and the exact same code running in JAWS will announce the content multiple times. Another thing to remember is that there is no way you will ever known all the edge cases - in the case VoiceOver not recognizing dynamically added elements mentioned previously, it took more effort than it should have to demonstrate conclusively to the stakeholders the issue was in a difference in the platform.

Finally, when you're trying to ensure your interface is accessible, you will have to manually test it - there is simply no other way - and it should be tested at least once every development cycle. Granted, not every user story will affect accessibility, but because have that holistic view of accessibility that acknowledges that accessibility exists at every level, we know that most stories will affect accessibility.

As with design, there are resources available, but good resources are more difficult to find because engineers are opinionated and usually feel like they understand specifications, even though what they understand is their interpretation of the specifications. If you want to become an accessibility expert, it can be done, but the process is neither quick nor easy. If you want to become an A11y^2, well that process is quicker and easier and mostly consists of keeping everything said in this section in mind. Understand accessibility holistically. Make "Semantic HTML" and "ARIA is a last resort" your mantras. Check your work with one of the WCAG verification tools (again, I prefer the aXe Chrome plug-in) and at least one screen reader. Check it manually, and check it frequently.

Being an Accessibility Ally

Being an Accessibility Ally is really not complicated. You don't need to be an accessibility expert (though you certainly can be one if you want)...you just need to see accessibility as a priority and the pathway to success. Being an Accessibility Ally means you're actively supportive of accessibility.

To be actively supportive, one needs to understand accessibility in a more holistic way than we've traditionally thought about it and we need to understand that not only does accessibility accumulate, its opposite accumulates as well. In other words, inaccessibility anywhere is a threat to accessibility everywhere.

To be actively supportive, we need to do more than act the part by designing and building things like stair-ramps with ramps too steep to safely navigate with a wheelchair or Norman doors. We need to make building interfaces that are perceivable, operable, understandable, and robust a priority...and we need to make that priority visible to others.

When we're actively supportive and people see our action, only then will we be the ally we all need...and we all need all the allies we can get.

---

For another take on age and web interfaces, you may want to take a look at "The Danger of an Adult-oriented Internet", a post in this blog from 2013 or A11y Squared, a post from 2017. 

The Party's Over

On the way in to the office today I was listening to the radio. No, not "internet radio", real radio - with a real DJ and everything. There was an interview with Paul McCartney, who was asked, in light of his upcoming appearance at Candlestick Park, why the Beatles stopped performing...his response was "it wasn't fun anymore". Something about the culture of money, fame, and ostensibly doing what they loved changed and it wasn't fun anymore, and that was enough to make them walk away.

I know that the Beatles, individually, were famous and talented enough that they were able to enjoy 'solo' careers, and that even if they never toured or recorded again, they could probably have survived quite comfortably, and that's no small comfort (for them)...but still - walking away from millions of dollars and instant recognition with no guarantees that you will be able to do what you love again...it's nearly mind-blowing.

You might find yourself asking "why is this important, why is he bringing this up" - and with good reason. After all, my most recent posts on this blog have been at least somewhat technical...and there haven't even been any of those for a significant span of time (at least in blog years). So, your curiosity is understandable...and I'll get to the why of the timing eventually.

Back to the original train - "it wasn't fun anymore". When I heard this come over the airwaves, it reminded me of something I'd read in April of this year - Brian Chesky Note 1 relating the advice of Peter Thiel Note 2 when he funded Airbnb.

Don't fuck up the culture.

Peter Thiel, 2012

There have been a lot of people considering Thiel's advice - there are around 31,000 document matches when searching for Thiel's exact words - and now here is my journey down that particular rabbit hole.

When I was at university in the Metaphysics course, a question intended to highlight the division between essentialists and existentialists arose, framed not as a question about people but objects. Consider that we're rebuilding a sailing ship and we tear it down to the keel and replace all of the boards. When our work is complete, is it the same ship? If we think of it in terms of automobiles, it would not fit the definition of being the same car, because the identifier for the car - the VIN Note 3 - no longer accurately represents information about the vehicle. So, is it a question of how much we change something or what we change that makes the determination? Are organization analogous to objects? How does this apply to organisms?

Corporations are not people, but they are organisms, with values and personality that govern their actions, for good or evil. If we go back to the question of 'how much change' or 'what kind of change' makes something no longer identifiable as itself, we can think of situations in which we've thought, even though we may not have formally defined it, that some person we know has changed in some way and now they are not the same person - we may even readily claim this using this exact phrase. We should consider corporations subject to these same rules of behavior and personality. In fact, we can most likely each think of an organization - such as a business or philanthropic organization - that after an unsettling experience left us with the thought "they would have never done that it the past" or "they sure have changed."

Thiel most likely has seen organizations that have damaged their culture time and time again in organizations that have come to him for venture funding. He certainly sees it not only as a possible problem, but one that is likely as well. This, too, stands to reason as the common thinking is that as an organization grows, the culture changes as efficiency of scale is achieved in various areas.

The problem that I imagine Thiel sees - and yes, I am putting words in his mouth to an extent - is that when the culture changes, people leave - a situation that is also accepted as not only survivable, but normal. However, in reality, the turnover caused by culture changes are dangerous for an organization - it's like having an illness that has not yet been diagnosed - one with symptoms that you decide you can live with but that just might kill you. Part of the reasoning here is that culture changes are generally a self-reinforcing loop - the sort of loop that once it's started is not only difficult to stop, but also difficult to control or in some cases to even recognize.

Given the semi-private nature of an organization's culture, the earliest greatest impact of damage to an organization's culture will be to those within the organization. Why is this important? People are generally not motivated by money - culture is what motivates people - and it motivates people to do amazing things - like work 80 hours a week for several weeks at a time even though they're only compensated for 40, meet ridiculous deadlines, or nearly violate the laws of physics to deliver a high-quality, low-cost product quickly - whereas incentive programs generally don't work. Note 4 Because of the tight coupling between culture and other areas - like motivation and productivity, changes to culture can have a dramatic effect on the organization as a whole.

At this point, we might be tempted, after seeing people violate Thiel's advice, to think the culture of the organization is permanently damaged any time that it is changed dramatically. There certainly are people who have departed any number of organizations thinking just this thought. A brief review of companies on a site like glassdoor gives insight into the number of people working for a company who believe "changed" is equivalent to "damaged". However, here we have to stop and notice that Thiel's advice wasn't "don't have a damaged culture", his advice was "don't damage the culture". The linguistic difference between those two messages is less significant than it should be, because they are drastically different concepts.

In one version, culture is in a damaged state and in the other it's different than what it was. We need look no further than our own history of romantic relationships to see the truth of the premise that these are different, regardless of our willingness to admit it in the pain and grief that comes immediately after the recognition of how we, or the other, have changed. Just because someone or something you love - be it a person or an organization - changes and you find they are now intolerable (to you) that does not mean that they are therefore befouled or damaged - they can be a perfectly nice, good person (or organization) and still not be your cup of tea. Changes are significant, however, because once you've changed the culture, people no longer have the company they love, and people not only lose motivation, people start leaving - whether they're customers or employees - and that's seldom a good thing. Note 5

When the people most invested in the success of an organization - like employees - leave because the culture has been damaged, there are likely to be repercussions that ripple out in ever-widening circles, like those created when a pebble is dropped into a pond. If the damage to the organization's culture is significant enough, it's just a matter of time before that trend carries outward as far as customers. Whether the organization can repair the damage and weather depends on a variety of factors that are outside the scope of this brief essay, but in every case, the nature of the business will be profoundly changed. Whether that change is for good or ill is something only time can tell. If your organization survives by knowing their customers (or users), such turbulence can be exceedingly dangerous, and it is unwise to assume that it is not.

Now, to address the question of why this post, now.

Recently there has been a lot of interest in why I left a position I held for nearly a decade. Here is the best brief explanation I can offer - I left for the same reason the Beatles stopped touring - it wasn't fun anymore. Unfortunately, that explanation has frequently proven inadequate and I have developed a longer, but still brief, explanation.

Several years ago, I started what I believed could potentially be my last job in the industry. The work was challenging and interesting, the people were, as they say, "wicked smart" and immensely talented, the product was an economic product geared toward serving under-served populations, and the general corporate culture was based on four basic values that resonated with me. It was, in a lot of ways - very nearly every way in fact - the perfect fit. Over the course of the next several years, things changed - as things do. The work became mundane as my skills were under-utilized, the vast majority of people moved on, and the product and culture changed significantly. The organization was not the same organization with which I had fallen in love, and I finally came to recognize that all the perks and incentive programs were metaphorical chains that bound me in place.

As a result of changes that transformed the organization from something I loved into something that I didn't, I left - and yes, it was before finding another gig - because I'm a firm believer that when you see it's time to go, you put your affairs in order, raise your sails, and go. Now, three months past my departure, I still have a sense of what I've lost, and yet there are times that, like the song says, I'm "too relieved to grieve" Note 6  because, in the end golden chains are still chains (Robert's Rule #33).

Notes and references

Links in the notes and references list open in a new window

1. Brian Chesky is the founder and CEO of Airbnb. You can learn more about him on wikipedia.
2. You can learn more about Peter Thiel, an outspoken entrepreneur and venture capitalist, on wikipedia. 
3. The Vehicle Identification Number is an alphanumeric sequence used to uniquely identify a vehicle.
4. A summary of a journal article in the Harvard Business Review says it clearer than I've seen it said before - "according to numerous studies in laboratories, workplaces, classrooms, and other settings, rewards typically undermine the very processes they are intended to enhance."
5. There are a number of reasons it's not good when people leave an organization - brain drain and the ills associated with turnover - hiring costs, overtime costs, low morale, and low productivity to name just a few - are just two of the big reasons.
6. "Let It Go" (Kristen Anderson-Lopez and Robert Lopez) as performed by Demi Lovato.

What Isn't Said

If you're a follower of this blog, you'll notice that my posts tend to fall into three general categories. There are posts about how do something, like put PayPal on your Facebook page, build a slider toggle, or include reference notes, posts that show a different side to things in technology industry news that catch my eye, and posts that are general career advice from someone who has spent a few years in a very turbulent industry. I'm not sure if this post fits in any of those three categories, or if I'm starting a fourth after reading the blogs written by two men I consider to be, at the very least, something more than acquaintances (http://www.thejourneyismydestination.com/ and http://www.codercowboy.com/). I should point out, I suppose, that neither of these has the reputation in the industry of Eric Meyer (http://meyerweb.com/) or Nicholas Zakas (http://www.nczonline.net/), but I suppose that gives them a little more influence in my estimation because they are writing, not because they need to but because they need to, and I see something of myself in that, and besides, their year-end posts were good.

In addition to the inspiration from other bloggers, this time, as I looked back on the past year and looked forward to a new year (as many of us do at the start of a new year) I came across interviewing tips from recruiters and one in particular caught my eye as I read through the post, asking myself the interview questions as part of my year-end self-reflection. The question caught my eye, in part because as someone who has conducted several interviews and 'phone screens', I find it to be a question that I've been asked, but have never asked - it's simply what is your greatest weakness.

This time, perhaps I found insight that has eluded me in previous years or perhaps I have rediscovered a forgotten truth, but I recognize that there are those who see my greatest weakness only as a weakness, while I see my greatest weakness as a strength as well. This difference in perspective likely comes about because we all expect that other people to not only understand our actions - because they're based on beliefs that spring from rational thought - but to share those rationality-generated beliefs our actions are based upon. However, that universally-held, unspoken belief is false - there are those who do not understand our actions and do not share our beliefs, and likely never will - their perception is fixed and the die is cast.

Here's where I offer a bit of advice. When this happens to you, and it's extremely likely it will, at some point although you will not fully realize what is happening you will attempt to cast what others see as your greatest weakness as a strength. This is a Sisyphian task, and no matter how many times you roll that boulder up the hill, scrabbling for every inch of dirt, it will roll back down, and all the while, none of us acknowledge or challenge our perspective unless we trust each other - really trust each other - and remember that we're human, doing the best we can with any given situation.

As the past year closes and a new one is begun, I am also reminded that good leaders know the strengths of those on their team, and beyond that, great leaders see strength where sometimes even team members see only weakness. As we work together, maybe we should take Peter Drucker's words to heart and listen for what's not said - search for those points of weakness - and talk about why we see them as weakness but to then use our trust of each other to move beyond that to see them - really see them - not only as weakness but as a hidden strength, because whether we're the team captain or just one of the players, we can all benefit from the humanity that comes from trusting each other.

A New Broom

At the end of the year, I look back and think about the auld lang syne1...like many of you, I would suspect. This past year, for a lot of us, saw a jump into yet another technology stack as the newest broom - in this case dustjs - sweeps the UI engineering world (thanks to the powerhouse known as LinkedIn and later, PayPal, who took the ball and ran with it). It was bound to happen sooner or later, of course. As one person commented about learning to code, you must realize that if you choose to become a developer you will learn to code every day for the rest of your life.2

This realization - or remembrance on my part - brings up another point, however. People, especially geeks in my line of work, get über excited about new technology, and a lot of that excitement is misplaced. Let me say at the outset, there are usually legitimate reasons for getting excited about a technology stack, but we are too often subject to more hype than reality.

Long, long ago in a galaxy far, far away...when I started on my career path, I worked for a company that was built on COBOL 74, courses covering C were finally making it into university programs, and RDBMS languages like PROGRESS and PARADOX were making inroads on PCs (which were still fairly new themselves). Those first few years when businesses were setting up token-ring networks and figuring out how to share data across multiple workstations that weren't linked to a mainframe were exciting - primarily because it was a minor revolution. The cost of several PCs, even in those days, was considerably lower than the cost of a mainframe and it became a lot less expensive to do business.

In a few years we were all connecting to a little corner of the Internet called "the World Wide Web" and there was another minor revolution as the online world enabled a globalization of business that previously had been the domain of international businessmen (and let's be honest, there really weren't international businesswomen in those days - so we're slightly less sexist now - not much, but a little). In the almost 20 years since, we've gone from HTML, with its simple styling tags to CSS, JavaScript, and HTML5 in front-end code and gone through (something like six production versions of) ColdFusion, ASP and ASP.Net...and C#.Net...and well...everything Dot Net, Perl (and LAMP), PHP, Stripe, Ruby (and Ruby on Rails), Python...and on and on. Yes, the world has improved...except...it really hasn't.

In my time, I've written software for a number of organizations, and nearly every time I've changed organizations I've changed the language(s) I've used. This realization leads me to two conclusions - both relevant to today's environment. First, I cannot recall the last coding class I took that actually applied to what I was doing or about to do in which I did not know as much, or more, about the topic than the instructor. On the other hand, I easily recall the last time I used what I learned in a number of courses in maths, language, history, and philosophy - so that is what I will make sure I pass along to the next generation.3 Second, the technology used by someone (organizations included) is nearly irrelevant.

Why would I, a geek at my core, say something like the technology is nearly irrelevant? Because I believe it to be true. For evidence, we need only look to the any of a number of organizations, both public and private, functioning quite well on technology that is decades old. We might also consider that while there is no doubt that I am not a fan of complexity, newer technologies are sometimes improvements or even required even though they typically add complexity on any one of the many layers an organization has. To see the truth of this one need simply follow the path of the World Wide Web from document markup and delivery to ecommerce.

In my own career you may be surprised at the number of organizations that I have worked with that have said "we're not responding to <something> fast enough because our technology is out-dated, but we'll be able to respond much more quickly if we start using <your favorite technology>". You might also be surprised at the number of times an organization has been wrong when it has made such a claim. Let's look at this idea from a few points of view.

First, let's consider the learning curve associated with any new technology. If we have, for example, engineers expert in C, they will likely be able to switch to C++ with little effort. If, on the other hand, we switch to Java (which is a much more likely scenario) they are likely not experts and may in fact be novices, not only with the language itself, but with purer object-oriented languages in general. It takes time and effort to become an expert, time and effort that make the claim of being able to respond more quickly if a different technology is used questionable.

Since responding quickly is often a question of productivity, let's look at another activity - developers building productivity tools. Historically, manufacturing operations had a person (or persons) designated as 'tool and die maker'. However, because of the distributed nature of application development that position has been abandoned. There may be productivity teams who look at how productivity can be increased, but typically those groups are too far separated from the process and paint with too broad a brush to be as effective as possible. Further exacerbating the problem - when the underlying technology changes, tools used previously are obsolete, even if the problems those tools solve are not. This alteration of process alone increases the learning curve associated with new technology, and if the underlying problems have not been addressed, new tools must be built to replace the obsolete tools.

These are just two of the myriad issues associated with changing a technology stack. So, if it's not the technology that makes an organization successful, what is it? How the organization functions.

One of our idiomatic expressions is "a new broom sweeps clean", and unfortunately this is true in organizations - sometimes through the diminishing of knowledge capital by significant turnover in human resources but more often simply because the new person has a different way of doing things or is used to a different technology. How new brooms are put to use is a part of how an organization functions, and if each new broom sweeps clean, there is little history from which to learn.4

Another aspect of how an organization functions - where money is budgeted - demonstrates the organization priorities. In short, budgets are power - the larger the budget, the greater the power, and an easy way of securing a larger budget is by making the case that <your least favorite technology> is out-dated and must be replaced. You can claim that you won't be able to compete for better job applicants or that support for <your least favorite technology> is going away or that <some other technology> is faster and more reliable. Some of your claims might even be true, but they need not be verifiable to induce a mild fear response and increase your budget. Of course once you have the budget, you have to spend it to keep it - otherwise you lose your standing of power in the next round.

Of course, the truth of the matter is that there are job applicants who are expert in <your least favorite technology> who are happy to work for well-functioning organizations and most established technology will be continually supported, simply because organizations providing the technology understand the importance of backward compatibility. As for claims of <your favorite technology> being faster and more reliable...sometimes those are true, but typically only after becoming established technologies. Increased complexity rarely produces speed or reliability as offspring; rather, complex systems fail in complex ways and, unfortunately, failure is not an option - it's a certainty built into every system.

For all the hype, the technology should not be the ultimate concern. For instance, LinkedIn could just as easily run their entire site using classic ASP rather than dustjs. I understand their reasons for not doing so and I understand their reasons for getting away from a fragmented stack5 but I also recognize that getting to a point where the stack is fragmented is a function, not of the technology, but the organizational culture and the way in which the organization operates.

There are usually a number of legitimate reasons for changing a technology stack, but let's step away from the hype of how "<my favorite technology> will help us get to market faster" (there are other, better ways to do that - Lean UX6 for example) or the "how <my favorite techonology> is better than <your favorite technology>" arguments that have been known to start something akin to a holy war in engineering departments. We're better than such puerile behavior, and maybe if we're not focused on how great the squirrel scampering by is, we can focus on building from our strengths and making more awesome...because sometimes we do not need a new broom, we need to learn how to sweep.

Notes: links open in a new window

1. Days long past or in American vernacular, the good 'ol days.
2. Dachis, Adam. Don't Learn to Code: Learn to Work with Technology.
3. You can read more of my thoughts about coding classes in "Coding education, coding life".
4. Those who cannot remember the past are condemned to repeat it. [Santayana, George. The Life of Reason; or the Phases of Human Progress. New York: Charles Scribner's Sons, 1905.]
5. Basavaraj, Veena. Leaving JSPs in the Dust: moving LinkedIn to dust.js and client-side templates.
6. Gothelf, Jeff. Lean UX: Getting Out of the Deliverables Business.

Ambition

It's the middle of the year, so that means it's time for semi-annual reviews. Reviews are always a little difficult for me - in part because I was raised to believe that it was morally wrong to, as the saying goes, blow your own trumpet. This belief is so ingrained that in the past I've had difficulty with writing a CV or even effectively answering questions regarding my previous accomplishments during an interview for a position.

There's more here than just my ingrained beliefs, however; more that relates to ambition and how others perceive it. More that we in the corporate world refuse to discuss because we all know what the words and concepts mean. We are so convinced we know the meaning that we really need not think about the words or the concepts they convey. However, I wonder if perhaps it is that we don't really understand ambition, even though we think we know the definition.^[1]

As a case-in-point, I recently received a message from a former coworker - I'll call him Mr. Foo - that I'm going to paraphrase here, removing references that will identify who it was or which employer we shared in common. All edits will be enclosed in *[ and ]* to identify them.

When I was at *[our common employer]*, I was full of ambition and could not for the life of me figure out why you didn't put a ton of effort into sharing your *[tools]* with the *[rest of the employees there]* in a more formal fashion than just have them 755^[2] in your home dir.
... 

*[It]* might sound kind of weird, but in this weird way that chosen inaction on your part really stuck with me and I've always respected and always will respect you as an awesome developer and wise person in general...and time to time I think "well, Robert had this awesome stuff and didn't really share it or align himself with movement x y or z". There's wisdom in your actions, I think, and its taken me a while to come around to understanding that.

Now, I might have shared this message because this person referred to me as "an awesome developer" (and yes, I appreciate "awesome developer" more than "wise person" - it's better geek cred) and it's not really blowing my own trumpet because Mr. Foo has done it for me - that sort of ego stroking always feels good, but that's really not why I share it.

My thought today is this - most of us - and by most I mean nearly all, have become convinced that ambition and self-promotion are inseparable. They are not. Few of us have difficulty with people who are ambitious - at least to a small degree; however, more than a few have difficulty with those eager for self-promotion - people who, as they say in the western US are "all hat and no cattle"^[3]. While ambition is a necessary condition for self-promotion, it is not a sufficient condition.

My experience of the cycle of self-promotion rampant in corporate culture has been one that has shown it to be one of the most emotionally damaging issues confronting humanity. It is a vampiric greed that drains the soul of a person, because just as for the gun-fighter of the old west, there is always someone faster or willing to cheat just a little, and in the end you're just as dead.

In honesty, I created the tools Mr Foo references to make work easier - for me, sure, but for anyone who used them. I promoted the tools (not myself as author) on several occasions as something that could help resolve a problem but if others didn't use them I wasn't offended - I decided to not be bothered by the action of others.

That is not to say there aren't consequences for avoiding self-promotion. There are. It would be nice if the world - or our little part of it - were the meritocracy we teach our children it is - one where management paid less attention to self-promotion than work. Unfortunately, life is not nice - nor is the corporate world. If you're going to avoid self-promotion - the grasping greed of blind ambition - be prepared to get punched in the face, hard. People around you will not understand, and will likely criticize, your lack of ambition. Of course what they really mean is that you don't share their goals, but that will not be how it is put forward - this isn't a cooperative game with a win-win outcome, this is a bare-knuckle fist fight because people don't like what they don't understand, and people don't understand others who refuse to engage in self-promotion.

The good news, however, is that while self-promotion may not keep you from getting punched in the face, without it you're more likely to keep your soul in the exchange.

To Mr. Foo, if you're reading this and recognize your words, thanks for everything.

Notes:

1. Ambition: (a) an ardent desire for rank, fame, or power; (b) desire to achieve a particular end
2. 755 is the numeric representation of permissions for a file that indicates it is readable and executable by users on the network but only modifiable by the owner
3. Full of big talk, but no action; pretentious

What I learned from writing payment interfaces (Part V)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

In Part I and Part II we looked at elements, both foundational and code-related, that affect speed. In Part III we started our exploration of velocity by looking at mitigating risk and in Part IV we looked at expanding our app to other locales. In this entry, we'll look at non-specific cognitive overhead.

Cognitive Overhead

• What can you do that is not checking out while checking out?
• Which of the following affect reaction time?
  • Time spent waiting
  • Day of the week
  • Chronological age of the user
  • Time of day
  • Month of the year
  • Complexity of the interaction
• Which is likely to affect conversion more?
  • Adding a message that notifies you to add your address to a prepaid card
  • Using a tabbed design that separates card types
  • Having concise text labels
  • Forced acquisition

Cognitive overhead is the number of logical connections or 'jumps' your brain has to make in order to understand or contextualize the thing you’re looking at, or to put it another way, it’s what your brain has to go through to assign meaning and purpose to what you see - is a significant risk in developing a risk-aware, global app, and is especially significant for a payment interface.

Paying for something can be a very complex – and therefore slow^[1] – interaction, especially for young or older users^[2]. Non-member users often have to ask themselves "do I apply for credit", "which card should I use", "should I use my bank account", "how do I ship this purchase to my sister for her birthday", and "should I create an account". Member users have even more questions than non-members, questions like "why can’t I just make all this information the default so it doesn’t take as long next time".

There are a number of things that can increase cognitive overhead, like handling risk and globalization, especially when those topics are not fully developed or integrated well. On the other hand, there are things we can do to reduce cognitive overhead – things that a payment interface naturally does, like reducing automation and increasing user input by putting the user in the middle of the process, and things that a payment interface may not naturally do, like giving the user real-time feedback – such as a message to let you know you need to add your address to the card profile when using a prepaid card.

To some, suggesting that reducing automation and increasing user input as a way to maintain or increase velocity may sound counter-intuitive; however, for a number of users, especially those who are unfamiliar with your app - the group with the lowest original velocity, the time it takes to make choices is lessened when clear, concise information is present and the users are allowed to make their choices.

Consider, if you will, the case in which automation routes a user to a feature they didn't intend to use - in that case the user must then backtrack to a point where they understand the context before they move forward. This situation becomes even more vexing if automation repeatedly moves them forward in the same direction. In a payment interface, this type of behavior is typically seen in forced acquisition^[3] - a situation in which the user's frustration becomes palpable and is reflected in lower conversion.

Of course it's not only impossible to remove all automation, it's not advisable either. We must determine how to reduce cognitive overhead through other means. One of the simplest ways to reduce cognitive overhead is to simplify not only the process but the design as well. As da Vinci said, "simplicity is the ultimate sophistication".

How we may simplify the design is often relatively clear. Simplifying the process, on the other hand, is seldom clear. How can you easily accomplish this? Think of your process in terms of a story. Is your story simple, with a single plot-line like The Very Hungry Caterpillar, or is it complex, with multiple plots and sub-plots like Game of Thrones? If users see your process as not only simple but with a clear path, they’ll complete it faster and it will feel more convenient. Another  advantage to this approach is that with a simplified process returning guests are more likely to have greater velocity on each iteration.

Of course there are other benefits to reducing cognitive overhead - benefits the engineers and support personnel will enjoy. Benefits we gain because we know that it is always easier to destroy a complex system than to selectively alter it and that complex systems fail in complex ways. The less complex a system is, the better habitable (form) it is for the engineers who have to modify it and support it, the better we are able to ensure its function, and the better its fitness is likely to be.

Notes:

1. Hick’s Law - an individual's reaction time increases by a constant amount as a function of available choices
2. Age affects the processing speed of the brain (Salthouse, T. A. (2000). "Aging and measures of processing speed". Biological Psychology 54 (1–3): 35–54.
3. Acquisition occurs when a guest user becomes a member - your app has 'acquired' a member. Forced acquisition, then, is when the user is forced to upgrade from a guest to a member account.

What I learned from writing payment interfaces (Part IV)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

In Part I and Part II we looked at elements, both foundational and code-related, that affect speed. In Part III we started our exploration of velocity by looking at mitigating risk. In this entry, we'll look at expanding our app to other locales.

Globalization

• Where do we have to tell users that Flash cookies and browser fingerprinting are used?^[1]
• In comparison to the US, is page load time less than, greater than, or the same in LATAM? APAC?^[2]
• Which credit card does not use the Luhn algorithm?^[3]

It may seem somewhat counter-intuitive, however, the job of mitigating risk becomes even more difficult when we talk about business on a global scale. One of the greatest problems we face when building a product for a global market, however, is not risk, but rather that we are used to thinking only in terms of our own country, and our app appears to be something like a tourist when it’s used outside of its home country.

It’s relatively simple to develop an easy-to-use app for your own country because we know all kinds of things about our country – like you cannot require someone to give their ZIP code for a cash purchase in the US, or that privacy laws for the EU require disclosure about how information – like a Flash cookie or browser fingerprint – is collected and used, or even more simple things like how to collect addresses and phone numbers or what funding methods (e.g. lastschrift or credit cards) are typically used.

Beyond the technical "how" of code development and reuse, issues such as legal restrictions regarding what information can be collected, when it may be collected, and how it may be used as well as cultural issues such as which item a user is likely to select from a list in a given situation affect payment interfaces used globally, but they affect other apps used globally as well.

In developing a global product, we have to consider not only the nuanced issues - like the selection rate of lastschrift versus credit cards in a payment interface - but other, simple things as well. We have to consider something as simple as what we know, or can know, about information like addresses and phone numbers for other countries.

You can easily target a single country and do the necessary research; however, we must either accept the impact of increased complexity that comes with a highly localized product or determine how to generalize the interfaces by answering a host of questions – for example, can we validate phone numbers or postal codes, what are the common elements in an address, what can we determine about different funding instruments, and how do we design for linguistic issues, such as text direction or significant variance in word length, and how does cross-border trade affect any or all of these issues?

Of course one of the greatest dangers in the globalization of our product, is like the danger associated with risk - it can easily impact velocity. Further, the more subtle part of the danger to velocity lies in the way data collection intended to mitigate risk or make a more global-friendly product contributes to cognitive overhead.

Notes:

1. The EU
2. Page load time is greater in LATAM than in the US (AR and BR have load times approximately 2x the US times); however, there is wide variance in APAC (load time in CN is about the same as US, but load time in JP is less than US times, with mobile nearly .5 the US times, and most other countries in APAC are significantly slower than US times). http://analytics.blogspot.com/2012/04/global-site-speed-overview-how-fast-are.html
3. China Union Pay

What I learned from writing payment interfaces (Part III)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

In Part I and Part II we looked at elements, both foundational and code-related, that affect speed. In Part III we'll start our exploration of velocity^[1].

Risk Mitigation

• What do we know about the product that might affect the transaction?
• What do we know about the customer that might affect the transaction?
• What can we learn about the customer while they’re making their payment?

As anyone who has written apps for any length of time can point out, there is more than just raw speed that we must consider. In another post, I've referred to this something similar as completion time, likening it to load time and render time; however, in this series I'll use the term velocity to refer to how quickly the user moves through a process.

One of the major factors affecting velocity in a payment interface is risk. Processor declines, charge backs, and disputes can easily derail an otherwise profitable business; however, the rules defining risk, such as "selling jewelry is riskier than selling shoes" or "new customers are riskier than existing customers" typically exist outside of the payment interface^[2]. Of course there is risk associated with all sorts of transactions, such as legal ramifications brought about by not attending to country-specific restrictions. Ideally, there is a secondary process (hopefully isolated) that tells us whether the customer we think we have is really the customer we have.

In a payment interface, and in an app, we don’t generally need to be concerned at a high level that our risk rules fail to block the right transaction (e.g. a shipment of alcohol to a restricted locale) or alternatively, exclude otherwise valid transactions (e.g. a person preparing for a trip by purchasing electronics such as digital cameras along with prepaid phone cards). In our app our task is to collect enough of the right information in order to make reasonable decisions regarding not only how much risk is associated with a specific transaction but also about how much risk we are willing to allow.

More importantly, of course, we have to be cognizant of whether or not while we are collecting the right information we are negatively impacting velocity. One typical bottleneck we've seen is in the collection of an address. Of course this is in part due to the difficulty of gathering addresses in a global setting (which we'll touch on in Part IV) but also due to difficulties with regard to validation of an address^[3]. Not only is there a significant chance that we will affect user velocity with our risk rules, there is a significant chance our risk rules themselves prove to be a problem. That does not mean we should eliminate the risk rules, simply that those rules should be integrated into app code with the utmost care, and, of course, testing.

Notes:

1. Velocity, unlike speed, is a vector measurement - it's related to movement in a direction.
2. There are risk factors that are especially applicable in developing payment interfaces - things like product type (e.g. prepaid cards, jewelry, electronics) and the country of the buyer and seller; however, there are also more general risk factors we can attend to, such as a mismatch between the originating location of the request and the user-reported location or a user accessing an account that has a negative history (how 'negative history' is defined is less meaningful - it could mean anything from a poor reputation score to chargebacks).
3. For further information, you may want to read my post regarding Address validation.

What I learned from writing payment interfaces (Part II)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

In Part I the focus was on the foundational elements of a web app, and how those foundational elements aren't generally within the domain of the UI engineer, even though they are of significant importance. In this entry, I'd like to consider the aspects of code speed that are generally within the domain of the UI engineer.

Code speed

• Which is faster - Value equivalence (==) or Type/Value equivalence (===)?
• Which is faster – a native JS for loop to iterate through a NodeList or the jQuery "each"?
• Which is faster – an if..else statement or a switch statement?

One of the practices I’ve seen in my years as a UI Engineer is a constant, steady, relentless increase in the amount of code associated with an app. We, as a group, know the importance of keeping page weight low; however, somehow we end up with 86MB pages that win design awards^[1].

Even though such monster pages are rare, common code that I've seen typically includes a little bit of everything from poorly-written HTML that either uses tables for layout or is rampant with div-itis^[2] to bloated and/or low-performance CSS and low-performance JavaScript. All of these have an impact beyond page weight alone.

I have no desire to jump on the JavaScript is bad bandwagon. I firmly believe that HTML and CSS should be subject to many of the same rules as we have for JavaScript and be as simple as possible; however, there is often little we can do to HTML and CSS to increase the speed with which the most basic page renders. We ought to hold fast to the principles of both progressive enhancement and semantic markup, but we ought not stop there. We are no longer - at least in my experience - being paid by the KLOC^[3], so take up the practice of delivering the least amount of code possible. I can promise that this practice will benefit you in a number of ways in the future^[4].

Further, as UIEs, we must take the same ruthless approach with JavaScript. The first question we must ask is "is it necessary" because, based on my observation, we seldom consider the effect seemingly simple things, like DOM manipulation, have on speed. It’s all too easy to look at a block of code and think “it runs in less than 10ms, so it’s fine” without considering how that block of code is actually used - a practice we must abandon. We have to ask ourselves how the code is being used. For example, does the code trigger a repaint? Is the block of code wrapped in a setTimeout or setInterval that may cause a race condition that impacts the interface? Does the block of code do something that impacts user interaction, like disabling a field or repopulating a drop-down list?

Beyond the overarching questions, however, we must get into a practice where every line, every block of code is ruthless written to perform. For example, it is fairly commonly to see a value equivalence check used even though a faster type/value check would return the same result, and I see many more if/else statements than faster switch statements. We must implement design patterns that give speed advantages whenever possible. This simple practice will become increasingly important as we develop more apps that run on mobile devices and we begin to focus on framerate and how our code affects animation.

We must change our thinking. As I said before, speed cannot be considered in isolation but it also must not be an afterthought. We must get out of the mindset that development is about function – the app does the job – or form – the app is habitable, not only for users but for engineers as well – and into the mindset that development must be a balance of function, form, and fitness – the software performs – and that we must develop from the outset for fitness.

Notes:

1. This time it's Oakley's page for the Airbrake MX, which I have every reason to believe is a wonderful product. Details about the Site of the Day award from awwwards, and some discussion about it can be found on the awwwards award page. Documentation about the site can be seen at Oakley's monster page of baubles.
2. Div-itis is the tendency to wrap portions of code inside a div tag, and preferably add an ID attribute in case there will be some DOM manipulation in the future.
3. LOC is "line(s) of code", so KLOC is 1000 lines of code, which was an early measure of productivity for programmers
4. Many of us have heard it said, and can attest to the truth of the matter, that complex systems fail in complex ways. Simple code not only carries a lower risk of failure, but a greater chance of resolution and repair when failure occurs.

What I learned writing payment interfaces (Part I)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

When I think about what I've learned writing payment interfaces, I might have started our quest with a discussion of industry terms and how they’re used, or how we need to use A/B testing to measure user response to changes and monitoring the shift in conversion^[1] in basis points^[2], or the impact that acquisition^[3] has on payment - these are important topics, especially to people who write payment interfaces - however, the most important topic we need to understand is the payment business, and the most important things we need to understand about the payment business is that speed matters and velocity matters. To understand speed, we’ll start our questioning at the beginning.

Foundational Questions

• What’s the average worldwide DNS lookup time? Which is faster IPv4 or IPv6?
• What load balancing device is used for external load balancing?
• Who are NACHA and OFAC?

These questions, at first glance, don’t really appear to be questions User Interface Engineers consider. That first question – DNS lookup time – a UI engineer doesn't control that. It's the same with the load balancing device. Don’t those belong to “operations”? NACHA and OFAC? Those are business groups, right? Why are these important?

As I've already stated, speed is important – in fact, it’s one of the most important considerations during checkout. However, not all site speed issues are directly related to things UIEs have under their control. The reality is that speed cannot be considered in isolation, however, speed cannot be an afterthought either. We must be aware of just how the factors outside of our control affect speed, in part to take steps – like minimizing DNS lookups – lookups that take 400ms on average^[4] – to increase speed, and in part to know what actions will have greater, or more immediate impact. For example, would it be better to keep an IPv4 address or use an IPv6^[5] and change the load balancing algorithm? What impact would a change to from a consortium bring forward, for example, what if the rules OFAC uses to restrict payments changed or if NACHA changed constraints regarding required information? Are any changes to the foundational elements large enough to affect overall speed?

It is without question that these foundational elements affect speed. It is also without question that is largely a balancing act of almost innumerable variables where we're hopefully reducing the cost of some of the variables so that we might offset increases in the cost of others. To maintain this balancing act, we must learn to step outside of our typical domains to understand, and at times to help others understand, the foundation upon which our app is built and specifically how it relates to speed.

Notes:

1. Conversion is the percentage of users who actually pay once the transaction has been started. Think of it as a queue of people waiting to pay - those that actually do "convert" and those who decide they're too busy or have forgotten their wallet "abandon" their transaction, and the rate is abandonment.
2. A basis point is one one-hundredth of one percent (.01%), or one more paying customer out of a queue of 10,000 people.
3. Acquisition is converting a guest user to a member user. Data clearly demonstrates that forced acquisition - forcing a customer to create a username and password to complete a purchase - lowers conversion significantly (which is not to say that the cost incurred by the reduction in conversion would not be offset by benefits of acquiring new members).
4. The 300-400ms speed reported by Google is considerably faster than the 400-800ms speed reported at Velocity 2010, however, it's still significant. For further reading, I'd recommend A Dismal Guide to DNS and the Performance Benefits portion of the Public DNS discussion on Google Developers. If you'd like to run a simple test to see how long a DNS lookup might take for one of your users for your domain, you can check http://www.dnswatch.info/dns/dnslookup?la=en&host=insert-your-host-name-here&type=A&submit=Resolve - just replace the insert-your-host-name-here with the host name you want to check (e.g. cathmhaol.com).
5. You can see Cisco's data regarding IPv4 vs IPv6 at http://www.cisco.com/web/strategy/docs/gov/IPv6perf_wp1f.pdf, of course you'll also want to take a look at An Engineer's Guide to Bandwidth to help make sense of the information presented by Cisco.

Doing the impossible (with Robert's Rule #31 & #32)

This post is not going to be a 'how-to', or an example of critical thought applied to a current topic, but rather a prosaic reflection with career advice mixed in - somewhat like earlier posts.

When I was a young child, we were discussing poetry in primary school and I pulled a book of American poets off the shelf and found It Couldn't Be Done by Edgar A. Guest^[1]. I still recall the note my schoolteacher sent home saying how much the poem reminded her of me, even though I cannot find the note - of course that was quite a number of years ago.

I would not encourage anyone to be excessively optimistic (I would say pollyannaish, but I believe that unfairly associates optimism with feminism), there have been a number of credible studies that demonstrate the benefits of positive thinking^[2]. Yet,  there is something beyond even positive thinking that I feel is crucial to our survival in a corporate environment - an indomitable will. For some, an indomitable will manifests as an "incorruptible patience" or "a destructive pursuit of perfection"^[3]; for others, there are other ways - but they have this in common - they are not skill related and won't be found on the Programmer Competency Matrix^[4] - in fact, it's those times that we're faced with a situation that we know is beyond our bounds that this applies, and it's what made Bert Bell's belief that on any given Sunday any team could beat any other team in the league real. (Robert's Rule #31 - success is about more than skill - is based on that belief.)

A personal story - several years ago I was preparing to fly to California for an in-person interview for a position that I considered a dream job when I found out that my sister, who lived 2000 miles away, was critically ill, and a few hours before I was to leave for my day-long interview, I learned she had died. My grief was beyond anything I had borne before, but I also recognized that the only thing I could do at that point was request PTO and book a flight - and one more day would make little difference in the grief or support that I, or anyone else in my family, could offer.

Even though I knew a rigorous interview process was beyond my bounds in that circumstance, I went and did my best. After I returned home, I contacted my employer and booked a flight, and left the next day. After I secured the job (yes, I did get it), I discovered that some who interviewed me noticed (what they interpreted as) a lack of enthusiasm - several commented to me that interviewing in that situation was something they thought couldn't be done, yet it was done - and well enough to secure the job.

So, here's the lesson I learned that day - if you want something enough and your will is indomitable, you will likely succeed - success is not guaranteed, mind, but very likely.

There was another lesson I learned that day - one that's probably more important
that I carry with me, especially every time I interview a candidate - on any given day we see only a part of a person, and like in jazz, the important bits might be those not heard, so make allowances for what you don't see (Robert's Rule #32).

Or, in the words of Bill (in Bill & Ted's Excellent Adventure), "be excellent to each other".

Notes:

1. If you've never read this poem, do so. I recognize as a (more cynical) adult that it's a bit trite, but it's somewhat uplifting and motivational, and there are times we all need that.
2. The article How the Power of Positive Thinking Won Scientific Credibility is an interesting read regarding the evolution of thought and research in this field, and has links to a number of those studies.
3. These are two traits of a fantastic programmer from Signs that you're a good programmer.
4. http://sijinjoseph.com/programmer-competency-matrix/

The (un)Importance of Design

Quite a lot of importance is placed on design, specifically interface design, but what do we really think about design?

Building end-user software for more than a few years, I've heard my share of complaints, criticisms, and confusion around interface design - the most common being something like "why the **bleep** did they do that". Where's the problem, we think to ourselves, it's not like the solution - the way it should be - isn't right there in front of you. After all, we all know enough about good design that we know it when we see it, right? Besides, we reason with ourselves, don't they know that poor design will kill their product, and how hard can it be to follow the simple steps to good design?¹

Perhaps...or perhaps not.

I recall working for the first time with an Apple product in the mid-90's - a PowerPC. Overall a decent unit, but one where the power button was placed next to the floppy drive bay - in the exact spot a disk eject button would be on a DOS/Windows machine. They could have easily placed the button somewhere else -on the other side of the machine next to the cover for the installed hard disk, for instance. For people used to working with desktop PCs they didn't even have to think about what the button next to the drive door does. However, for those new Apple users it was quite a problem when the power was turned off with a non-boot disk in the drive.

On the flip side, what happens when the interface is rockin' on a bad product (Apple Maps, anyone)? The best interface in the world isn't going to help if you get completely lost.

I shouldn't pick on Apple alone - a person could get a reputation for doing that sort of thing...so I'll just mention a few others who have confused design with quality - products like the Dish Network² or the MyFord Touch³.

The reality is that we should have good design, not just because it's the cool thing, but also because it builds trust. Even though we were (or at least I was) taught to not judge a book by its cover, what people see matters. It's difficult to convince ourselves that an organization that can't deliver on something simple, like button placement, can deliver on something complicated, like an OS. On the flip side, in my experience leads me to believe that design is not nearly as important as it's claimed. People tend to be brand-loyal - in America, extremely so; in some cases, for example automobiles and operating systems, brand loyalty can reach near religious fervor.

We consumers, it seems, maintain our love-hate relationship with poorly-designed quality products and well-designed inferior products and complain, criticize, and vent our confusion...to people who aren't brand-loyal like we are. Therein lies the rub, because it's not those brand-loyal customers we're trying to keep, it's the new customers we're trying to get.

What's the conclusion, then? First, as we philosophers are fond of saying, there are two positions one might take on this issue: design isn't critically important because consumers are brand-loyal or design is critically important because of its effect on potential consumers. Second, think about the design of your product. Design is a piece of a larger whole, and some designs encourage us to create an inferior product,⁴ whether it's because of their complexity or the effort required to build them. Ideally we'll build products that are both quality products and have a rockin' design.

Notes:

1. Yes, there's likely to be an upcoming blog post about that topic.
2. When Good Design => Bad Product
3. A Confusing User Interface And Poor Usability Are Killing Ford’s Quality Ratings
4. Although the moto.oakley.com page won an award (Site of the Day from http://www.awwwards.com/) for its design, it is hardly an example of a superior, or even mediocre web page, weighing in at nearly 86M over its 450+ requests and lllloooonnnngggg loading time. You can read more about it at http://hawksworx.com/blog/oakleys-monster-page-of-baubles/, or try the site - it may still be up.

Mobile First

Mobile first has become the new mantra of technology companies, but as with anything, we must think about what we're doing, not just do it because we can.¹

Any time we're building a new product there are things that must be built into the requirements - especially those items that without which our product would be defective. Security and performance are two good examples of this, and neither can easily be 'tacked on' at the end any more than it would be easy to transform a minivan into a race car.² However, contrary to the assumptions about security and performance, we ought determine, before going down the 'mobile first' road, whether or not it makes sense to travel that path.

What I am going to say next will probably surprise you, but...mobile is not for everyone...at least not in the US market. Now, granted, I'm for creating products that handle globalization well - in fact it's been one of the most forceful lessons I've learned over the last several years - but if we're just looking at the US market we have to evaluate the data. After all, we are getting paid to think.

Data now shows that while there has been a hefty increase in the number of people using their mobile devices for banking, those same people are reluctant to use their devices to pay at retailers and restaurants.³ While many retailers are seeing a trend in which consumers will enter their physical locations to do additional research and subsequently make a (better informed) purchase online, that does not translate into purchases using a mobile device. The global financial services giant, PayPal, announced figures at their recent Analyst's Day that also point to this trend. According to those numbers, 25% of PayPal's users are using their mobile devices (compared to 50% of US cell phone users who accessed online banking services) and mobile devices only account for 10% of their total payment volume (TPV).⁴ While this 10% may in fact be a disproportionate number of transactions, and likely is as people pay for mobile-specific items like ringtones and other digital goods, it still points out, in the best case, that big purchases - the kind typically made at retailers and restaurants - are not being paid for using mobile devices.

Of course the situation could change, and it's clear that eBay, PayPal, and a number of other companies are betting on it. In the meantime, why maintain the mantra "mobile first"? There are valid reasons associated with development costs that basically boil down to why develop two (or more) apps when one responsive app will suffice. That is difficult to argue against - after all, if developed well it's likely that quality assurance cycles can be shortened, time between releases can be decreased, as can the number of engineering staff necessary for maintenance and new product development. Then again, I have yet to see any reliable data that demonstrates any of these advantages, and there is still disagreement in the industry whether a responsive web application or a native mobile solution is best in any given situation. At the very least it behooves us to put more thought into our work than simply repeating a mantra that may or may not be useful.

Notes:

1. Robert's Rule #17 (Too often 'we can' erroneously becomes 'we should' and 'we will')
2. Look at BBC's Top Gear Series 12, Episode 3 to see how that transpires.
3. Consumers using phones to bank, but not to buy, Wall Street Journal, March 27, 2013
4. eBay Inc. expects to enable $300 billion of global commerce by 2015

What kind of engineer, indeed.

Several of my friends and colleagues have tweeted and otherwise commented about a post on the extremely knowledgeable Nick Zakas' blog.

I have a lot of respect for Mr. Zakas, and often enjoy his blog posts, learning something each time I visit, and this post was no exception. Unfortunately, there is also a point with which I don't agree...but it's not really Mr. Zakas' point. He says,

If you stop and think about it, writing code is something that a lot of people do. You can hire someone cheaply out of college to write code and it may not be as good as an experienced software engineer, but if it’s close enough, that’s usually all you need. So if your programming acumen is the only thing that you focus on, you aren't improving your position in the company. What matters far more are the soft skills that you have along the way. Do people enjoy working with you? Do you add something over and above your coding skill?

First, to Mr. Zakas' point, there are a lot of people who can code...but there is a potentially significant difference between "close enough" and "correct". With "close enough" your revenue most likely will not be zero, but it will also likely not be as much as it would with "correct"...and in some situations, "close enough" may be nowhere near close enough. If we're talking about a web page that responds in 8 seconds instead of 4 or 6, that may be one thing (though you might want to see my earlier post about speed in websites, Faster, faster, faster) but if we're talking about real-time or life-critical software, is "good enough" really good enough.

Still, Mr. Zakas is correct in that our reputation is important...but therein lies my problem, and it's demonstrated to a degree by those Peter Hinssen refers to in Will the real CIO please stand up - individuals who associate responses to the phrase 'IT departments' which are "wonderfully colorful comments such as 'arrogant', 'out of touch with reality', 'language of their own' and - increasingly often - 'hopelessly out of date'."

Are there engineers who are reasonably considered "arrogant" or "out of touch"? Certainly, and, I suppose if Mr. Zakas' post were geared toward those engineers alone, we might not have anything to discuss. Note, however, that Mr. Hinssen's post discusses the prevailing attitude. If we see "arrogance" and "hopelessly out of date" as the status quo, then I would posit that Mr. Zakas' advice to adjust our attitude addresses a symptom of the underlying problem without addressing any of the underlying issues.

In part, the prevailing attitude - that we are arrogant and out of touch - is our fault as software engineers. Whether we write software for the World Wide Web, smartphones, or desktops - we have, to some degree, failed to convey our value to the organization. Often we do speak a language of our own, and life would be much easier (from the perspective of those who see us as arrogant and out of touch) if we would just communicate more/better/the right way - if we would stop being so out of touch - if we would stop seeing ourselves as so valuable to the organization - after all, the contribution of an engineer is not that significant because "writing code is something that a lot of people do" (emphasis mine).

As a User Interface Engineer (or web developer, if you'd like), I often hear comments similar to this - comments about how someone's teenage relative can build a good web page. While there are, of course, prodigies, the amount of engineering that is required to create the best web page is significantly greater than the skill level held by general practitioners, as is the amount of engineering required to create the best software for other media. I would posit, therefore, that our challenge is not as much improving our soft skills (though every engineer I've met would benefit from such development), but rather conveying our value to the organization in a meaningful way. To that end, as a counterpoint to Mr. Zakas, I would commend a quote that Baskin-Robbins used to hang in their stores: "there is hardly anything in the world that someone can't make a little worse and sell a little cheaper - and people who consider price alone are this man's lawful prey."¹ 

There are a number of issues that might be discussed when an organization perpetuates a culture similar to Mr. Zakas' comment above (that people who code are a commodity) or similar to those Mr. Hinssen references; however, one of the most significant is that organizations which learn to accept "close enough" when it's less expensive incur technical debt that becomes deadly. Further, the effect such an attitude has on morale within the IT department can be equally as deadly as mounting technical debt.

There is, in my estimation, another side to this story. In the face of significant potential issues, such as creating code that's "good enough" under one estimation and not another, mounting technical debt without having resources to address it, and demotivating personnel, there is also the thought that perhaps the perception of engineers as weak in soft skills, arrogant, and out of touch, is mistaken. Perhaps, just perhaps, those engineers are instead are significantly different than other employees.

Perhaps these engineers are not arrogant and out of touch. Perhaps there are weaknesses related to their soft skills, but if we, instead of operating from the assumption that what these engineers do is something that a lot of people can do, operate from the assumption that what these engineers do is something that few people can do, and that they are therefore in a different realm than others, might we see their "arrogance" as an indication they have a different understanding of their capabilities and the situation? Might the perception that they are "out of touch" be due to the manner in which they, in their different world, relate to those outside  of their area of expertise.

Let us consider then, the possibility that their "arrogance" and being "out of touch" are, at worst, simple weaknesses in their soft skills. What is the best advice? Certainly Mr. Zakas' advice is good, and traditional - work on your weaknesses. However, is that really the best way in which these engineers can contribute? In this consideration, I would offer the following advice that Dr. Donald Clifton gave his son: "your weaknesses will never develop while your strengths will develop infinitely."²

Let me be clear - the best advice the creator of the Clifton StrengthsFinder, Gallup's own online psychological assessment, could offer his son, was to build his life and work around his strengths rather than try to fix his weaknesses. For Dr. Clifton's son, and many engineers, Mr. Zakas' words, and in fact the words of those who brand us as "arrogant" and "out of touch" would have them "fix their weaknesses".

In this, I would posit that rather than engineers spending time fixing their weaknesses, that they spend time using and developing their strengths, and that management (at all levels) spend time seeing and celebrating diversity and the value it brings. I understand this is unconventional wisdom, but perhaps, just perhaps, this is a new age - an age in which each of us can contribute to our fullest.

What kind of engineer do I want to be? One that develops my strengths infinitely.

1. This quote is attributed to John Ruskin, though there is some debate about whether or not that attribution is valid.
2. Reported in a post by his son.