Charles Fahey

We all love Chrome. The statistics prove that it has grown to be the most popular browser in the world (roughly 64.8% of all internet visits are on Chrome). But it’s got a dirty secret: it’s devastating to your laptop battery life.

I previously described creating a brand-driven product vision, which is an invaluable guide for keeping your product inline with your brand idea. But a product vision is just that—a vision; something general.

For the 4040baseball project, it became apparent that we needed more than a vision to measure our coding and design patterns against. Especially, since we wanted our brand to permeate every level of our product.

Hello. I am your software. I represent you. You are powerless to stop me.

The 4040baseball product should be the personification of our brand. And I mean that in a very real way. In software, the product is the primary representative of your brand--it’s the first point of contact through which your clients will interact with your company. And since your brand is inexorably an extension of who you are, we thought we’d put in place a set of practical rules to remind us who we are and what we strive for.

4040baseball's PDP

What follows are the 4040baseball product development principals:

1) If a task does not add real value to our product, we won't do it. Questions we ask: Does this task clearly increase effectiveness? Does this task clearly increase simplicity? Does this task clearly increase ease-of-use? 2) Code loss is greatness! The more code we're rewriting, the greater the value-add we must have discovered. 3) Build for the now. We do not architect for future use until the future is upon us. In the agile world, priorities must change on a daily basis. We code for what we need today. We will convert today's code into reusable code at the moment when we know we need to reuse it. 4) Abstraction is not our friend. Our code must remain simple. We must never abstract our code beyond what we need right now. When abstracting code, remember our first principal, and keep it effective, simple and easy to use. 5) Our design patterns must be identifiable and predictable. When solving problems, we must repeat the use of established design patterns where possible. 6) Servers are finite, clients are infinite. For every 100 visitors there are an equal number of web browsers waiting to be put into service. Where possible, we will hand off processing responsibilities to the browser and use MVVM and ajax to lower demand on servers and bandwidth. 7) No shims or polyfills. We use HTML5, CSS3 and responsive design. We will not use custom code or frameworks to make our software compatible with older, lesser browsers. If it works with current Apple Safari, Google Chrome and Mozilla Firefox, our job is done. 8) Bugs are urgent, fixes are not. We will quickly get bug fixes in progress, but we will not rush their solutions. Quality and thoughtfulness are the only objectives of a bug fix. It's better to let one bug persist than to create an additional bug, or degrade user experience, on its heels. 9) Poor comments mean poor code. Comments must be thorough, but efficient. We should be able to read only the comments to understand the code.

Unique to each product

Product development principals are unique to each product. The list above works great for 4040baseball, but wouldn’t be so great for a lot of other products I work on.

You can see that our brand idea of simplicity and elegance has influenced the decisions we make as a development team. This is intentional. It stands to reason that all aspects of our software should point in the same direction of simple effectiveness. And, if you’re familiar with the Kano model, it further stands to reason that the quickest path to customer delight is a high-concentration of problem solving (innovation) and the least required amount of effort. Paramount to that success is a deliberate focus on adding value as efficiently as possible.

Summary

If your team is working on a new entry into an existing market, you’ve been sizing up the competition. Let's take a look at how the Kano Model can help Product Owners use market research to prioritize needs and features and to delight customers.

The Kano Model provides a great framework for understanding when users will and will not be highly satisfied by your product. Kano is broken into two axis: 1) Customer Satisfaction and, 2) Level of Investment (the amount of resources you commit to the product).

Using Market Research to Avoid Low Customer Satisfaction

The poorest level of customer satisfaction occurs when your product prevents users from accomplishing tasks. It frustrates them. This can be caused by bugs, but it can also be the result of lacking basic functionality (aka "missing critical features").

In an existing market, basic functionality is already well established. Kano tells us that mastering basic functionality creates a Neutral level of Customer Satisfaction. And as a Product Owner the worst you ever want someone to feel about your product is neutral.

Example: For 4040baseball the simulation baseball market showed that users expect to be able to create their own team names as a basic feature. If we didn't provide this feature users would have been frustrated. On the other hand, after providing this feature, all we've done is met minimum expectations. This feature doesn't distinguish our product from the competition, and it doesn’t excite users. It’s expected functionality.

As the following Kano chart illustrates, a Product Owner should only devote enough resources ("Level of Investment") to satisfy basic feature requirements (green). Overproducing basic features (red) won't get you any closer to delighting customers. Overproduction includes things like adding nonessential options or, "reinventing the wheel."

Using Market Research to Create High Customer Satisfaction

An oft-forgotten fact about basic features is that many of them started as innovations. In fact, many of them once delighted customers. Then, as these innovations were broadly adopted across the competition, they became de facto standards--no longer delightful, but expected.

Kano shows us that delighting customers means exceeding expectations (or "generating excitement"). Earlier, I mentioned how overproducing a basic feature can drain resources without improving customer satisfaction.

Market research not only identifies basic features. It also exposes weaknesses in those features. Rather than overproducing a basic feature, improving a basic feature—solving a known problem—can help generate user excitement. It can also help distinguish your product from the competition.

Example: For 4040baseball we delivered the basic feature of allowing users to create their own team names. What we noticed from the market research was that this feature is traditionally designed for a user who already has a team name in mind. We realized a user would have to stop and think of a name, or possibly leave and come back later and start the process over. So we looked for a way to improve on the traditional implementation of this feature. What we delivered was a basic feature with improvements designed to make it more satisfying to our customers.

As the Kano chart below illustrates, using market research to focus resources on improving a basic feature can efficiently raise customer satisfaction. The same amount of energy that can be spent on overproducing a basic feature (red) can instead be spent on improving a basic feature (green).

Summary

In software, it’s all about product vision.

Software exists first in the abstract as a set of concepts and whispers of function, form and experience. How those all come together into something cogent—how they first begin to take shape—that’s the result of vision.

Likewise, your brand exists first as an idea—an idea of how you want your company or product to be received. Once people begin experiencing your company and/or product, your brand enters the brand loop, where it is shaped by feedback and adjustments.

To give people a product experience that supports your brand idea, your product vision and your brand idea must be in agreement.

As a ridiculous example, imagine a company that makes construction nails, and they want their brand to be, “the strongest construction nails in the world.” Only, the production team has been making really exceptional toothpicks. The brand idea and the product vision are not aligned. Obviously, toothpicks make for lousy nails. And the company brand would quickly become, “the lousiest nails."

For the 4040baseball project, our team’s core is simplicity, accessibility and effectiveness. These are the things that are important to us, and the brand needed to reflect this. The 4040baseball brand, simply put, is: “Elegant and sophisticated simulation baseball for serious and casual fans.”

Next we defined a product vision to match.

Your product vision needs to be driven by your brand, so I’ve annotated the 4040baseball product vision to illustrate.

“We provide the most elegant and sophisticated simulation baseball league available [reasserting the brand]. Our core is simplicity, accessibility and effectiveness [the soul of our brand]. Every feature we offer our users must be thoroughly effective and easy-to-use [sophisticated simplicity], providing users the greatest return for the time and effort spent [serious and casual fans alike]. This is a statistically-driven system, so accuracy is essential [effectiveness]. This is not a product which will burden our users with a multitude of options [elegance]. We make the best assumptions possible for our clients, and then give them the power to customize those assumptions to their own unique preferences [effective, sophisticated, for serious and casual fans alike].”

As you can see, developing a product vision that is driven by your brand really isn’t that difficult. But it is essential for Product Managers, Product Owners and Developers alike. It gives them a clear linkage between brand and what they are doing on a daily basis.

Since last summer, a small group of fellow curve jumpers and I have been lending spare time to 4040baseball. Hailing from a variety of industries and contributing a variety of skill sets and perspectives, the team is passionate about baseball, good software and pushing ourselves to do new things.

This project brings us an exciting set of challenges. Among them: organizing work around an all-part-time and all-telecommuting team; exceptionally high production standards, and; entering an existing market. Equally as exciting have been the answers to those challenges: a tailored Kanban-based process; creation of Product Development Principals to help ensure consistency throughout the product; and, the use of the Kano model to identify requirements, feature opportunities and priorities--based on market research.

Ever discover a popunder window hanging around on your Mac?

Every now and then I discover a MacKeeper (no link for them) popunder window after reading a local news site. 

It's sleazy to be sure, and I'm sure they aren't the only ones (although I can't think of any other company that does it). If you find that happening on your Mac when using Safari, use this extenstion: https://extensions.apple.com/details/?id=com.mindfulbrowsing.safariextension-XWDSDPD7GS

The problem(s) As any ColdFusion dev can tell you, working with JSON in ColdFusion is like feeding yourself soup with a razor blade. Blood everywhere.

The problem is exemplified by the fact that ColdFusion's isJSON() function doesn't protect the deserializeJSON() function from erroring out.

This code should be bullet-proof, but it isn't:

<!--- if this is a valid JSON string ---> <cfif isJSON( your_string )> <!--- deserialize the JSON string (since it's valid) ---> <cfset your_new_object = deserializeJSON( your_string )> </cfif>

Problem 1 In ColdFusion, if you try to deserialize a string that is not valid JSON you will receive a hard error. Ideally, deserialization should fail gracefully.

Problem 2 Furthermore, the isJSON() method should only return true for strings that can actually be deserialized.

The Solution(s) For these reasons, I created a ColdFusion CFC (safeJSON.cfc) which has two methods--one for better JSON validation, and one for more graceful deserialization.

I hope this helps some of you as much as it's helped me.

Requires ColdFusion 10+

I've recently been running up against different types of encoding issues with extended character sets and html. You probably won't need this very often, but if you do, here it is.

This jQuery plugin works just like jQuery's $.val() function, except that it html-encodes extended characters in the values it's working with. I've also added an inline-conversion method, so you can html-encode the value of a form field before submitting the form. There is also an option to protect html from being converted, so that "<br>" doesn't turn into "<br>".

Everything you need is available here (GitHub), including a fully-functional example.

The Captcha: bane of user experience, plague of cyberkind, mangler of type faces, molester of elegance.

If you must protect your forms from bot submissions, some sort of validation is required. In this tutorial we'll make an image-captcha. They aren't new, but they're easy to build and very effective.

Success Criteria: -- Must prevent bot-submissions of a form -- Must be easy for a human to use -- Must be ready for production in 15 minutes

Here's what you'll create: An image-picker captcha with 4 images to pick from. It's easy for humans and tough for bots.

You'll need these skills: -- Proficiency in a web-programming language -- Proficiency with jQuery or some flavor of javascript -- The ability to crop, size and save images -- Some familiarity with CSS to make it prettier

NOTE: I'm going to jump between ColdFusion and PHP in the examples below, but don't worry, you can get the full code in each language.

Download Source Code

Let's do this!

CodeKit 2 came out earlier this month and it's pretty fantastic.

If you aren't familiar, CodeKit syntax checks (jslint or jshint), compiles and minifies (uglify.js) javascript and css (sass, less, etc.).

Like Coda 2, CodeKit detects changes to files. In Coda, files are, "Marked for Publishing," when they are changed, and they are listed in the Publish view. In CodeKit, files are processed when they are changed and their new minified versions are generated.

Buuuuut... Coda doesn't notice when a file gets added or updated by CodeKit. And that means it never gets marked for publishing. And that means it doesn't show up in your Publish view.

There is a solution (of sorts):

When CodeKit creates a minified/compiled file for the first time, you're still out of luck--you'll  have to manually track it down and mark it for publishing.

If you already have the file that CodeKit will update, you can make Coda detect the changes like this:

1) In Coda, right-click on your CodeKit generated file and select Open With > Coda 2 (yes, that's right, we're telling Coda to open bootstrap.min.js with itself);

2) Go ahead and close the file you just told Coda to open;

The word prejudice usually raises unpleasant connotations. But the meaning of the word itself is less provocative:

"A preconceived opinion that is not based on reason or actual experience." [1]

Positive Prejudice

Back in 1964 a team of Psychologists ran an experiment. They gave grade-school teachers a list of students they labeled, "Academic Bloomers." In reality, the students on the list were randomly selected--there was nothing intellectually known about the group. A year later the "Academic Bloomers" were outperforming their peers academically and on IQ tests.

So what happened? How could labeling a random selection of students cause such dramatic academic and intellectual improvement? Well, here's what happened: The teachers were, "primed to see academic progress," in the "Academic Bloomers." Correct answers by these students were seen as early signs of success. Incorrect answers were seen as anomalies--part of the "blooming" process. Teachers praised these students when they were successful and overlooked their failures. And more importantly, teachers devoted time and energy to ensuring the academic success of these "promising" students. [2]

In other words, the teachers were prejudiced for success.

Prejudice for Failure

Prejudice more often works against us. When building a great team we want diversity of thought but we also need unity of goals and agreement on a definition of success. We want each team member to stretch and grow but we also want each to possess a core set of competencies and fill a specific role. We want A-players who think outside the box but we're quick to dismiss ideas that don't immediately make sense to us. These are contradictions, and contradictions create an aspect of unfamiliarity (a lack of experience), which is the root of negative prejudice. We are skeptical of people, ideas and concepts unfamiliar to us, and we are inclined to work against their success.

In other words, we can become prejudiced for failure.

Prejudice for Success

Great teams and successful leaders aren't allowed the poverty of negative prejudices. As team members (leaders or subordinates) we need to be sure we are working for the greatness of one another, and that our teammates are never hampered by our prejudices. And this means more than just a "positive attitude." We need to establish procedures and resources through which team members can identify and overcome weaknesses and attain goals, and through which they have opportunities to discover and develop new talents. Such procedures and resources (mentoring, education, professional development, goal achievement, growth planning, etc.) demonstrate a "blind" commitment to individual success.

In other words, leadership with a prejudice for success.

---

Calvin Coolidge

Steve Ballmer (cnet article)

This is the third part in a series by Scott Anthony, author of The Little Black Book Of Innovation.It sounds so seductive: a “culture of innovation.” The three words immediately conjure up images of innovation savants like 3M, Pixar, Apple, and Google--the sorts of places where innovation isn’t an unnatural act, but part of the very fabric of a company. It seems a panacea to many companies that struggle with innovation.

If you've been there, you've experienced these challenges. Hopefully you've handled them well.