Stupid Javascript Object Tricks

Dec 30, 2015

I usually write something meaty for my posts, but sometimes it’s worthwhile to just see some of the strange stuff you can do with a language because it’s informative. I remember one of the most enlightening things I experienced while I was working on my degree was taking a class on Assembly. I don’t use Assembly at all in my day to day, but there was a lot of good knowledge I gained just from taking the class.

Probably the most profound item I experienced in that class was creating a struct in C and watching it take up real memory in the debugger. It’s one thing to say “such and such takes a double word” but to actually see it happen in real time is something completely different.

Today we are going to play with a feature of Javascript that is earmarked for deprecation in ES-next, however, it is so valuable to gaining greater insight into how the language works, I hope its never actually removed. The feature I am talking about is hand-instantiation of base objects.

Before we dive in, let’s back up a little and take a look at some code which should be familiar for people who have written any OO Javascript. This is just a basic object setup, so don’t get too excited.

function Greeter (greeting, name) {
	this.defaultGreeting = this.cleanString('Hi', greeting);
	this.defaultName = this.cleanString('person', name);
}

Greeter.prototype = {
	cleanString: function (defaultValue, value) {
		return typeof value === 'undefined' ? defaultValue : value;
	},
	
	greet: function (greeting, name) {
		var cleanGreeting = this.cleanString(this.defaultGreeting, greeting),
			cleanName = this.cleanString(this.defaultName, name);
		
		return cleanGreeting + ', ' + cleanName + '.';
	}
};

var myGreeter = new Greeter('Hi', 'Chris');

myGreeter.greet(); // Hi, Chris.
myGreeter.greet('Hello'); // Hello, Chris.
myGreeter.greet('Dammit', 'Jim'); // Dammit, Jim.

Tell Jim, I’m a programmer, not a magician.

Anyway, this is essentially intro to Javascript object creation for OO programming. The interesting thing is, we can actually look up the chain and see the same kind of code repeated at the language definition level. Let’s dig in and have a look at the Object object. (Yes, I just said that.)

typeof Object; // function
typeof Object.prototype; // object
Object.prototype.toString(Object.prototype); // [object Object]

The reason this is interesting is this, we can actually do some strange stuff with our base object. Normally if we wanted an object, we could just create an object literal. There are actually two other ways we can create an object as well. Behold!

// Common object creation:
var myNormalObj = {};

// Object instantiation:
var myObjectInstance = new Object();

// Object creation through function calling:
var myFirstObjCall = Object();

Okay, here’s where it starts to get weird. You can do this, not only, with Object, but also with Function. Let’s create a Function without using the function keyword. Like Samuel L. Jackson said in Jurassic Park, “hold on to your butts.”

var firstAdd = new Function(['a', 'b'], 'return a + b;');
var secondAdd = Function(['a', 'b'], 'return a + b;');

firstAdd(1, 2); // 3
secondAdd(4, 5); // 9

These are actually just creating anonymous functions with a global scope, but the fact that you can do this at all is kind of amazing. It gets even weirder, though. Let’s actually dig into the inheritance hierarchy of the Javascript language a little bit and see what lives underneath it all.

function identity (value) {
	return value;
}

typeof identity; // function
identity instanceof Function; // true

So far, so good. We know that identity is a simple function and that any function should be an instance of the parent object Function. This all strings together nicely. It also means we get all of the standard function-related behaviors like call and apply as we would expect. This makes things reasonably predictable and sane. If we dig a little deeper, though, we discover something surprising.

identity.valueOf() === identity; // true

Function.prototype.hasOwnProperty('valueOf'); // false
Object.prototype.hasOwnProperty('valueOf'); // true (!!!)

Function instanceof Object; // true

// Testing because of the transitive property of equality
identity instanceof Object; // true

Translating from abstract weirdness to English, what this means is Function inherits from Object. More to the point, functions are not only data, they are actually objects!

Let that soak for a moment.

This helps the idea we could attach properties to functions make a lot more sense. In fact, if numbers and strings weren’t evaluated through and converted to their rough primitive equivalents, they would actually be Object instances too. A good way to see this is to open a REPL and try the following:

Object(8) + Object(9); // 17
Object('foo') + Object('bar'); // foobar

All of a sudden everything in Javascript wraps up a lot more nicely. Literally any value we deal with in Javascript originates from an object with inherits from Object. This literally means we deal in objects everywhere. This, in turn means, creating new types is as straightforward as generating new objects, which is really what objects are largely about in Javascript anyway.

Let’s play one last game. Let’s create a function which returns a base value and attaches an error state if something goes wrong, otherwise the error is null. This kind of behavior is something that can be performed in Go. Given the power we get with the Javascript Object hierarchy, we can really do some amazing things.

isValid(7).error; // null
isValid(15).valueOf(); // true
isValid(999).error; // Number must be positive and less than 100.

This kind of programming wanders dangerously close to the meta-programming world, so we should probably stop before we spin off into madness. At the end of the day, Javascript has some really amazing, powerful features which are not generally publicized, but can provide for as rich and powerful a programming experience as you might ever want. The next time you wonder if you can do something, open up a REPL and try it out. The worst that will happen is your idea doesn’t work. The best is you will discover a new, relatively unexplored corner of the language. What’s to lose?

Composition and Compose

Dec 23, 2015

A while back we discussed composing functions together to blend behaviors and extend functions to solve more complex problems. The discussion was all about composing two specific functions together. In functional programming composing multiple functions together can actually be part and parcel of the entire new function.

The Lodash Way

If we take a moment and look at libraries like Lodash and Underscore, they handle function composition as function chaining like the following.

_(myValue).chain().filter(fn1).map(fn2).reduce(fn3);

Naive Generic Composition

This is great except, if we want to drop in our own functions we have to either use tap, which is counterintuitive, or we have to devise our own strategy for composing multiple functions together. First an aspect we would do well to avoid is the state management which happens under the covers. Second, an aspect we would like to favor is an ability to create our own transformation behaviors and chain them together in a clean, sane way. Let’s have a look at a simple, rather naive implementation of a generic composition function.

// This is VERY close to mathematical composition, so let's
// not be coy and just use the mathematical function names i.e. f and g
function simpleCompose(f, g) {
    return function () {
        var args = Array.prototype.slice.call(arguments, 0);
        
        // equivalent to f(g(x)) where x = args
        return f.call(null, g.apply(null, args));
    };
}

So long as two functions are provided to simpleCompose, we will get a new, composite function. We could actually create a new function which would perform the equivalent of x * (y + z) with an add and a multiply function. This may seem like kind of the long way around, but with a more complex logic, composition actually simplifies the flow. Let’s take a look at the simple example in code.

function add (a, b) {
    return a + b;
}

function multiply (a, b) {
    return a * b;
}

function multiplySumByX (x) {
    return compose(multiply.bind(null, x), add);
}

multiplySumByX(5)(6, 7); // 65
multiplySumByX(10)(9, 3); // 120

// 3 * (x + y)
var tripleSum = multiplySumByX(3);

tripleSum(15, 6); // 63
tripleSum(8, 4); // 36

// Thanks to user 'newbie' for catching my terrible arithmetic, edited for correctness.

Although this kind of composition is powerful and allows for a surprising amount of flexibility, it’s rather rather limiting to only be able to compose two functions at a time. It would be much better if we could compose multiple functions together to create a new function on the fly. Let’s take a look at an iterative approach to composing functions together.

Iterative Composition

Let’s take our original compose function and turn it up a notch. Instead of letting it be the final implementation we can use it as the foundation for a more powerful approach to composition. We still want our compose function to accept two arguments and compose them, but we want to take two or more and compose them all. We will need to make use of the arguments object available in a function, as well as the slice function from Array.prototype. Anyway, less talk, more code.

function identity (value) {
    return value;
}

function compositor (f, g) {
    return function () {
        var args = Array.prototype.slice(arguments, 0);
        return f.call(null, g.apply(null, args));
    };
}

function iteratingCompose (f, g) {
    var args = Array.prototype.slice(arguments, 0),
        finalFn = identity;
        
    args.forEach(function (fn) {
        finalFn = compositor(finalFn, fn);
    });
    
    return finalFn;
}

// Edited to fix arguments slicing. Thanks Bondi French for catching that.

This is a little more code, but it’s a lot more power. If we take iteratingCompose.length we get 2, but optionally, we can pass in as many functions as we want and it will compose them all! To get a perspective on the kind of power we are working with, let’s make some new functions and compose them all.

var add3 = add.bind(null, 3),
    double = multiply.bind(null, 2),
    subtract5 = add.bind(null, -5),
    divideBy10 = multiply.bind(null, 1/10),

    doSomeArithmetic = iteratingCompose(add3, double, subtract5, divideBy10);

doSomeArithmetic(8); // 1.7
doSomeArithmetic(99); // 19.9

This would probably be more impressive if we did something more than just a little arithmetic. Let’s do something that takes a little more heavy lifting and see what we can really get out of our compose function.

function filter (predicate, list) {
    return list.filter(predicate);
}

function map (fn, list) {
    return list.map(fn);
}

function reduce (fn, list) {
    return list.reduce(fn);
}

function isTaxable (record) {
    return record.taxable;
}

function computeSubtotal (record) {
    return record.price * record.quantity;
}

function salesTaxFactory (rate) {
    return multiply.bind(null, rate);
}

var getSalesTax = iteratingCompose(
                    filter.bind(null, isTaxable),
                    map.bind(null, computeSubtotal),
                    reduce.bind(null, add),
                    salesTaxFactory(0.075)
                  );

var saleItems = [
    {
        name: 'Paper Towels',
        quantity: 3,
        price: 2,
        taxable: true
    },
    {
        name: 'Paring Knife',
        quantity: 1,
        price: 7,
        taxable: true
    },
    {
        name: 'Bananas',
        quantity: 11,
        price: .7,
        taxable: false
    },
    {
        name: 'Trash Bags',
        quantity: 1,
        price: 11,
        taxable: true
    }
];

getSalesTax(saleItems); // 1.8

Clearly this problem is more meaningful and substantial than simply performing a sequence of arithmetic operations. By using composition for function chaining, we can define a simple set of functions to perform small steps toward our goal. Each of the novel functions are simple and easy to understand, yet we can combine them to perform a complex operation.

Reducing Composition

Now that we’ve seen the power that compose brings to our programming life, let’s look at ways we can make the current implementation better. Instead of using a looping structure like forEach and maintaining state outside of the composing operation, let’s use reduce instead. Since our function arguments are being converted into an array, this is a simple refactoring.

function identity (value) {
    return value;
}

function argsToArray (args) {
    return Array.prototype.slice(args, 0);
}

function compositor (f, g) {
    return function () {
        var args = argsToArray(arguments);
        return f.call(null, g.apply(null, args));
    };
}

function reducingCompose (f, g) {
    var args = argsToArray(arguments);
    return args.reduce(compositor, identity);
}

This refactoring tightened up the whole definition pretty nicely. We identified a shared behavior, converting arguments to an array, and abstracted it. Then we replaced our forEach loop with a reduction, which helps us remove the burden of tracking state at each iteration. The only problem we could run into now is if one of the arguments provided is not a function.

The Final Iteration

There are two different approaches which could be taken here. First, we can stop here and say our reducingCompose function is all we want for our final compose function. This means, if someone mistakenly passes an argument which isn’t a function, they will get an error when they try to execute their newly created function.

Although getting an error is good, getting it early is better. What if we were to throw an error while compose is constructing the new function and alert our user, immediately, that they did something wrong? Arguably this is more programmatically interesting and I think it’s the right thing to do. Let’s hop to it.

function identity (value) {
    return value;
}

function argsToArray (args) {
    return Array.prototype.slice(args, 0);
}

function compositor (f, g) {
    return function () {
        var args = argsToArray(arguments);
        return f.call(null, g.apply(null, args));
    };
}

function checkFunctionArgs (args) {
    var badArgs = args.filter(function (value) { typeof value !== 'function'; });
    
    if(badArgs.length) {
        throw new Error('Compose cannot be applied to non-function values', badArgs);
    }
}

function compose (f, g) {
    var args = argsToArray(arguments);
    
    checkFunctionArgs(args);
    
    return args.reduce(compositor, identity);
}

Now we have constructed a compose function which gives us the kind of power we would want from function composition, but with the safety of a well-checked library. Through writing this generic compose function, we now have a new tool which can be pulled from our toolbox when we want all the power with none of the bloat. I compose my functions, do you?

Bind All The Things

Dec 16, 2015

In the time I have written and mentored with Javascript, there is a single core concept which seems to give people a significant amount of trouble: bind. To the uninitiated, bind is a puzzle, wrapped in a mystery wrapped in an enigma. If you are comfortable with functional programming, there are parts of bind which make no sense and, at the same time, if your experience is rooted in a strict OO language, other aspects will be less than sensible. I’d like to look at bind holistically in the hope that all will become clear.

Bind for Object Orientation

If we look at the object oriented nature of Javascript, we come quickly to prototypes. Let’s create a simple object we can experiment with using a prototypal definition and behavior composition to create a rich greeting API. (Yes, this is hello world, no I’m not kidding.)

function Greeter () {
	this.defaultGreeting = 'Hello';
	this.defaultName = 'person';
}

Greeter.prototype = {
	cleanString: function(defaultValue, userValue) {
		return typeof userValue === 'string' ? userValue : defaultValue;
	},
	
	greet: function (greeting, name) {
		var cleanGreeting = this.cleanString(this.defaultGreeting, greeting),
			cleanName = this.cleanString(this.defaultName, name);
			
		console.log(cleanGreeting + ', ' + cleanName);
	},
	
	sayHello: function (name) {
		this.greet('Hello', name);
	}
};

Our greeter object gives us the facility to say hello and to generate a generic greeting. Let’s have a look at how we do this:

var myGreeter = new Greeter();

myGreeter.sayHello('Chris'); // Hello, Chris;
myGreeter.sayHello(); // Hello, person

myGreeter.greet(); // Hello, person
myGreeter.greet('Hey', 'Chris'); // Hey, Chris

Something interesting happens in Javascript when we start capturing pointers to functions. In a purely functional programming language, there is not object or class system to provide function execution context. In a purely object oriented language, functions are second class, so they cannot be separated from their context. Javascript is the only language I am aware of where functions and their execution context can be separated. This context separation is precisely the kind of behavior which introduces the “this” issues people are so keen to bring up. Let’s have a look at what happens when we separate a function from its object.

var hi = myGreeter.sayHello;

hi('Chris'); // undefined is not a function

Bind for Partial Application

The error we see is because sayHello refers, internally, to this.greet. Since hi captured a pointer only to the sayHello function, all sense of object context is lost. This means “this” is referring to whatever bizarre context happens to be surrounding our variable. Best case scenario is this refers to window, but who really knows. Let’s fix this issue.

var boundHi = myGreeter.sayHello.bind(myGreeter);

boundHi('Chris'); // Hello, Chris

By using bind, we define the function execution context explicitly. This means boundHi actually behaves the way our original sayHi method on myGreeter did. Now we get the kind of consistent behavior we wanted. This is not the only thing we can use bind for. Let’s take a look at a function which doesn’t depend on an execution context.

function add(a, b) {
	return a + b;
}

add(5, 3); // 8

Add is a pretty simple function, but we can use it to perform some more interesting actions like doing an inline increment of a value. Let’s use bind to define a new, refined function to perform our increment action.

var increment = add.bind(null, 1),
    always10 = add.bind(null, 7, 3);

increment(10); // 11
always10(); // 10

[2, 4, 6, 8].map(increment); // [3, 5, 7, 9]

Here, bind provides the ability to partially apply an argument, or arguments if you provide more than one. Obviously our second function is both trivial and somewhat useless, but it demonstrates performing a partial application of more than a single argument. Meanwhile we can see a reason for wanting to partially apply a single value to a function for instance applying the same operation to an array of values.

Binding Context and Partially Applying Values Together

We’re in a place where we can tie this all together now. We have seen execution binding and partial application. Let’s have a look at what using all of these behaviors together for a single focused purpose. Let’s create a new function from what we already have which does something a little different.

var sayHola = myGreeter.greet.bind(myGreeter, 'Hola');
sayHola(); // Hola, person
sayHola('Chris'); // Hola, Chris

Tying it All Up

Here we have created a new function, sayHola, with nothing more than the bind function and existing functionality in our Greeter instance. Bind is a very powerful function which is part of the core Javascript language. With bind alone, a lot of work can be done. The next time you are working and discover a context issue, or you simply wish you could use that one function if it only had one of the arguments pre-filled, look to bind. You might find exactly what you need.

Commenting Code: Why, Not How

Dec 9, 2015

If you have written any amount of code in any language you are likely aware of code comments or remarks and how they work. This isn’t really what I’m interested in. I came across a discussion about an open source project which had a requirement that all code must be left completely uncommented. People were surprised and alarmed as to why this project would require all code to be uncommented, and I tend to agree. This post is to address comment content. Hopefully, you will share my opinion that comments are important by the end of this.

New programmers are often told to comment their code by instructors, but they aren’t told what the comments should contain. I remember my C language instructor chastised me for commented all of my functions without regard to the importance of the function or value of the comment. He said “there are too many comments, are you trying to make your code unreadable?” Others received feedback that they didn’t comment enough.

While we are on the topic of novice programmers, let’s take a look at a comment style I have seen in code written by inexperienced developers. It usually contains information about what the function does and how it does it. Although it is lovely to see the program explained in clear English, it is not particularly helpful since good code should be not only functional but illuminating.

// Pulls accounts from type object, flattens accounts arrays then picks accountId from objects 
function getAccountIds (accountsByType) { /* function logic */ }

From this description anyone with experience in the language could probably devise a body of code which would perform the actions listed in the comment. The problem is, I have no idea why this code exists. Code which exists for no other purpose than just to be written is not useful code. This could be dead code, or it could be a problem which could be solved another way. If this code does something which the surrounding context gives us no clue to, we would never understand the value, just the means.

Instead I would write a comment like the following:

// Constructs array of accountIds to send to the service layer which returns updated account information
function getAccountIds (accountsByType) { /* function logic */ }

Now we understand the context for the function. We can not only see what the function does by the name alone, but the comment provides immediate context for the use. Even more than that, this comment is far less likely to be out of date by the next time someone looks at this bit of the code. Comments which detail the inner workings of a function are more likely to fall out of date as the life of the code gets longer. People may modify our function to behave differently, however the context of the creation of the function is unlikely to become obsolete even with (anti-SOLID) modifications.

This brief discussion can be summed up by the phrase “comments should tell the programmer why something was done, not how.” I like to call this my “why, not how” principle. This helps to guide the comment writer’s hand when they feel the need to add a comment to the code. If your code needs explanation as to how something was accomplished, the code is likely too clever. On the other hand, sometimes obscure solutions are unavoidable, which means the function context may not exist within the codebase. This is precisely the why that should be added as a comment. For example, this:

// This code is a generic base for a variety of abstracted functions and is not intended for use alone
function complexGenericBehavior (fn, value) { /* Do complicated stuff here */ }

In Javascript there is another situation where comments are desirable. Although I believe JSDoc is a tool which was ported almost blindly from its source (JavaDoc) it is, hands down, the best tool for the job available in Javascript. I don’t believe that every function, method, class and module in your code should contain JSDoc comments, it is useful to annotate functions which might be used in a variety of situations. Essentially, JSDoc is a good initial way to document slow-changing program APIs which others might want to use. Following is an example of JSDoc use for the same function.

/**
 * @func getAccountIds
 * @desc Constructs array of accountIds to send to the service layer to capture updated account information
 * @arg {array} accountsByType - List of account type objects
 * @returns {array} - List of {int} accountId
 */
function getAccountIds (accountsByType) { /* function logic */ }

As you can see, the context comment is still part of the description associated with our function. This contextual clue is still the best part of our comment. Hopefully this function will be slow to change, so the arguments and return values will remain consistent. Even if they don’t howeever, our context clue will still provide important insight into why this function was created and what purpose it serves.

In the end, comments are not always necessary. They can be extra noise, or they can be misleading. As programs grow large and the context becomes unclear, comments become a life raft for programmers who are digging deep into old code to identify functionality which is important or no longer in use. If you choose to write comments, and I hope you do, think about WHY you wrote your code and let the code tell the next programmer HOW.

Node and Blended Tech Stacks

Dec 4, 2015

The longer people write single page applications, the more of them there are. The notion of a SPA harkens back to the concept of client server architecture, invented some time in the 1960’s or 1970’s. Now we build SPAs with services constructed with Java, C#, Scala and Node. Some of the stacks we use have names like MEAN, and others are a hand-selected composite of disparate technologies with no name.

I have quickly come to believe that any tech stack with a cute name is likely a solution looking for a problem. Sometimes you want Mongo, Express, Angular and Node, but sometimes you want Couch, Ember, Spring and Java, do we call it JESC? Gross.

The important thing here is, we took Node out altogether for the Java stack. The benefit we get with choosing Java’s history and broad set of packages, you lose the ability to share code between services and your client-side code.

We are in a unique situation in the current stage of technology where we can write a client application and provide it as a interpreted file which runs on a remote computer at request time. The code we can push to the client also will run on a server. By ignoring this fact, we lose a great opportunity to write code once and share it client to server.

People call this isomorphic or universal Javascript. If the services are all written in another language, there is no way to leverage the client code in the compiled server code. There is, however, still a way to share business logic from the server layer with the client with a little fancy fingerwork.

First, let’s write a little logic to verify a record doesn’t have a quantity which is greater than the maxQuantity property. Once we have that simple function, we can then apply it across a list of records.

function validateQuantities (recordList) {
    return recordList.map(record => record.quantity <= record.maxQuantity)
                     .reduce((a, b) => Boolean(a &&b), true);
}

If this were in the client side code, and we wanted to do the same kind of check in Java, the code would look something like the following:

Static Class Validator {
	
    public static boolean validateQuantities (List<Record> recordList) {
        return recordList.map((Record r) -> r.quantity <= r.maxQuantity)
                         .reduce(true, (a, b) -> a && b);
    }
	
}

Obviously this logic is almost the same, but two different developers probably would end up writing each of these. This is problematic since we now have the same logic in two different files in two different languages. This definitely a violation of DRY principles. For a single validation like this, we can probably accept the duplicate code, but in large code bases, this kind of thing will go from being a one-off occurrence to a pervasive problem. Let’s look at a way to consolidate this.

  • Web Designers Rejoice: There is Still Room

    I’m taking a brief detour and talking about something other than user tolerance and action on your site. I read a couple of articles, which you’ve probably seen yourself, and felt a deep need to say something. Smashing Magazine published Does The Future Of The Internet Have Room For Web Designers? and the rebuttal, I Want To Be A Web Designer When I Grow Up, but something was missing.

  • Anticipating User Action

    Congrats, you’ve made it to the third part of my math-type exploration of anticipated user behavior on the web. Just a refresher, the last couple of posts were about user tolerance and anticipating falloff/satisficing These posts may have been a little dense and really math-heavy, but it’s been worth it, right?

  • Anticipating User Falloff

    As we discussed last week, users have a predictable tolerance for wait times through waiting for page loading and information seeking behaviors. The value you get when you calculate expected user tolerance can be useful by itself, but it would be better if you could actually predict the rough numbers of users who will fall off early and late in the wait/seek process.

  • User Frustration Tolerance on the Web

    I have been working for quite a while to devise a method for assessing web sites and the ability to provide two things. First, I want to assess the ability for a user to perform an action they want to perform. Second I want to assess the ability for the user to complete a business goal while completing their own goals.

  • Google Geocoding with CakePHP

    Google has some pretty neat toys for developers and CakePHP is a pretty friendly framework to quickly build applications on which is well supported. That said, when I went looking for a Google geocoding component, I was a little surprised to discover that nobody had created one to do the hand-shakey business between a CakePHP application and Google.

  • Small Inconveniences Matter

    Last night I was working on integrating oAuth consumers into Noisophile. This is the first time I had done something like this so I was reading all of the material I could to get the best idea for what I was about to do. I came across a blog post about oAuth and one particular way of managing the information passed back from Twitter and the like.

  • Know Thy Customer

    I’ve been tasked with an interesting problem: encourage the Creative department to migrate away from their current project tracking tool and into Jira. For those of you unfamiliar with Jira, it is a bug tracking tool with a bunch of toys and goodies built in to help keep track of everything from hours to subversion check-in number. From a developer’s point of view, there are more neat things than you could shake a stick at. From an outsider’s perspective, it is a big, complicated and confusing system with more secrets and challenges than one could ever imagine.

  • When SEO Goes Bad

    My last post was about finding a healthy balance between client- and server-side technology. My friend sent me a link to an article about SEO and Google’s “reasonable surfer” patent. Though the information regarding Google’s methods for identifying and appropriately assessing useful links on a site was interesting, I am quite concerned about what the SEO crowd was encouraging because of this new revelation.

  • Balance is Everything

    Earlier this year I discussed progressive enhancement, and proposed that a web site should perform the core functions without any frills. Last night I had a discussion with a friend, regarding this very same topic. It came to light that it wasn’t clear where the boundaries should be drawn. Interaction needs to be a blend of server- and client-side technologies.

  • Coding Transparency: Development from Design Comps

    Since I am an engineer first and a designer second in my job, more often than not the designs you see came from someone else’s comp. Being that I am a designer second, it means that I know just enough about design to be dangerous but not enough to be really effective over the long run.

  • Usabilibloat or Websites Gone Wild

    It’s always great when you have the opportunity to built a site from the ground up. You have opportunities to design things right the first time, and set standards in place for future users, designers and developers alike. These are the good times.

  • Thinking in Pieces: Modularity and Problem Solving

    I am big on modularity. There are lots of problems on the web to fix and modularity applies to many of them. A couple of posts ago I talked about content and that it is all built on or made of objects. The benefits from working with objectified content is the ease of updating and the breadth and depth of content that can be added to the site.

  • Almost Pretty: URL Rewriting and Guessability

    Through all of the usability, navigation, design, various user-related laws and a healthy handful of information and hierarchical tricks and skills, something that continues to elude designers and developers is pretty URLs. Mind you, SEO experts would balk at the idea that companies don’t think about using pretty URLs in order to drive search engine placement. There is something else to consider in the meanwhile:

  • Content: It's All About Objects

    When I wrote my first post about object-oriented content, I was thinking in a rather small scope. I said to myself, “I need content I can place where I need it, but I can edit once and update everything at the same time.” The answer seemed painfully clear: I need objects.

  • It's a Fidelity Thing: Stakeholders and Wireframes

    This morning I read a post about wireframes and when they are appropriate. Though I agree, audience is important, it is equally important to hand the correct items to the audience at the right times. This doesn’t mean you shouldn’t create wireframes.

  • Developing for Delivery: Separating UI from Business

    With the advent of Ruby on Rails (RoR or Rails) as well as many of the PHP frameworks available, MVC has become a regular buzzword. Everyone claims they work in an MVC fashion though, much like Agile development, it comes in various flavors and strengths.

  • I Didn't Expect THAT to Happen

    How many times have you been on a website and said those very words? You click on a menu item, expecting to have content appear in much the same way everything else did. Then, BANG you get fifteen new browser windows and a host of chirping, talking and other disastrous actions.

  • Degrading Behavior: Graceful Integration

    There has been a lot of talk about graceful degradation. In the end it can become a lot of lip service. Often people talk a good talk, but when the site hits the web, let’s just say it isn’t too pretty.

  • Website Overhaul 12-Step Program

    Suppose you’ve been tasked with overhauling your company website. This has been the source of dread and panic for creative and engineering teams the world over.

  • Pretend that they're Users

    Working closely with the Creative team, as I do, I have the unique opportunity to consider user experience through the life of the project. More than many engineers, I work directly with the user. Developing wireframes, considering information architecture and user experience development all fall within my purview.

  • User Experience Means Everyone

    I’ve been working on a project for an internal client, which includes linking out to various medical search utilities. One of the sites we are using as a search provider offers pharmacy searches. The site was built on ASP.Net technology, or so I would assume as all the file extensions are ‘aspx.’ I bring this provider up because I was shocked and appalled by their disregard for the users that would be searching.

  • Predictive User Self-Selection

    Some sites, like this one, have a reasonably focused audience. It can become problematic, however, for corporate sites to sort out their users, and lead them to the path of enlightenment. In the worst situations, it may be a little like throwing stones into the dark, hoping to hit a matchstick. In the best, users will wander in and tell you precisely who they are.

  • Mapping the Course: XML Sitemaps

    I just read a short, relatively old blog post by David Naylor regarding why he believes XML sitemaps are bad. People involved with SEO probably know and recognize the name. I know I did. I have to disagree with his premise, but agree with his argument.

  • The Browser Clipping Point

    Today, at the time of this writing, Google posted a blog stating they were dropping support for old browsers. They stated:

  • Creativity Kills

    People are creative. It’s a fact of the state of humanity. People want to make things. It’s built into the human condition. But there is a difference between haphazard creation and focused, goal-oriented development.

  • Reactionary Navigation: The Sins of the Broad and Shallow

    When given a task of making search terms and frequetly visited pages more accessible to users, the uninitiated fire and fall back. They leave in their wake, broad, shallow sites with menus and navigtion which look more like weeds than an organized system. Ultimately , these navigation schemes fail to do the one thing they were intended for, enhance findability.

  • OOC: Object Oriented Content

    Most content on the web is managed at the page level. Though I cannot say that all systems behave in one specific way, I do know that each system I’ve used behaves precisely like this. Content management systems assume that every new piece of content which is created is going to, ultimately, have a page that is dedicated to that piece of content. Ultimately all content is going to live autonomously on a page. Content, much like web pages, is not an island.

  • Party in the Front, Business in the Back

    Nothing like a nod to the reverse mullet to start a post out right. As I started making notes on a post about findability, something occurred to me. Though it should seem obvious, truly separating presentation from business logic is key in ensuring usability and ease of maintenance. Several benefits can be gained with the separation of business and presentation logic including wiring for a strong site architecture, solid, clear HTML with minimal outside code interfering and the ability to integrate a smart, smooth user experience without concern of breaking the business logic that drives it.

  • The Selection Correction

    User self selection is a mess. Let’s get that out in the open first and foremost. As soon as you ask the user questions about themselves directly, your plan has failed. User self selection, at best, is a mess of splash pages and strange buttons. The web has become a smarter place where designers and developers should be able to glean the information they need about the user without asking the user directly.

  • Ah, Simplicity

    Every time I wander the web I seem to find it more complicated than the last time I left it.  Considering this happens on a daily basis, the complexity appears to be growing monotonically.  It has been shown again and again that the attention span of people on the web is extremely short.  A good example of this is a post on Reputation Defender about the click-through rate on their search results.

  • It's Called SEO and You Should Try Some

    It’s been a while since I last posted, but this bears note. Search engine optimization, commonly called SEO, is all about getting search engines to notice you and people to come to your site. The important thing about good SEO is that it will do more than simply get eyes on your site, but it will get the RIGHT eyes on your site. People typically misunderstand the value of optimizing their site or they think that it will radically alter the layout, message or other core elements they hold dear.

  • Information and the state of the web

    I only post here occasionally and it has crossed my mind that I might almost be wise to just create a separate blog on my web server.  I have these thoughts and then I realize that I don’t have time to muck with that when I have good blog content to post, or perhaps it is simply laziness.  Either way, I only post when something strikes me.

  • Browser Wars

    It’s been a while since I have posted. I know. For those of you that are checking out this blog for the first time, welcome. For those of you who have read my posts before, welcome back. We’re not here to talk about the regularity (or lack thereof) that I post with. What we are here to talk about is supporting or not supporting browsers. So first, what inspired me to write this? Well… this:

  • Web Scripting and you

    If there is one thing that I feel can be best learned from programming for the internet it’s modularity.  Programmers preach modularity through encapsulation and design models but ultimately sometimes it’s really easy to just throw in a hacky fix and be done with the whole mess.  Welcome to the “I need this fix last week” school of code updating.  Honestly, that kind of thing happens to the best of us.

  • Occam's Razor

    I have a particular project that I work on every so often. It’s actually kind of a meta-project as I have to maintain a web-based project queue and management system, so it is a project for the sake of projects. Spiffy eh? Anyway, I haven’t had this thing break in a while which either means that I did such a nice, robust job of coding the darn thing that it is unbreakable (sure it is) or more likely, nobody has pushed this thing to the breaking point. Given enough time and enough monkeys. All of that aside, every so often, my boss comes up with new things that she would like the system to do, and I have to build them in. Fortunately, I built it in such a way that most everything just kind of “plugs in” not so much that I have an API and whatnot, but rather, I can simply build out a module and then just run an include and use it. Neat, isn’t it?

  • Inflexible XML data structures

    Happy new year! Going into the start of the new year, I have a project that has carried over from the moment I started my current job. I am working on the information architecture and interaction design of a web-based insurance tool. Something that I have run into recently is a document structure that was developed using XML containers. This, in and of itself, is not an issue. XML is a wonderful tool for dividing information up in a useful way. The problem lies in how the system is implemented. This, my friends, is where I ran into trouble with a particular detail in this project. Call it the proverbial bump in the road.

  • Accessibility and graceful degradation

    Something that I have learnt over time is how to make your site accessible for people that don’t have your perfect 20/20 vision, are working from a limited environment or just generally have old browsing capabilities. Believe it or not, people that visit my web sites still use old computers with old copies of Windows. Personally, I have made the Linux switch everywhere I can. That being said, I spend a certain amount of time surfing the web using Lynx. This is not due to the fact that I don’t have a GUI in Linux. I do. And I use firefox for my usual needs, but Lynx has a certain special place in my heart. It is in a class of browser that sees the web in much the same way that a screen reader does. For example, all of those really neat iframes that you use for dynamic content? Yeah, those come up as “iframe.” Totally unreadable. Totally unreachable. Iframe is an example of web technology that is web-inaccessible. Translate this as bad news.

  • Less is less, more is more. You do the math.

    By this I don’t mean that you should fill every pixel on the screen with text, information and blinking, distracting graphics. What I really mean is that you should give yourself more time to accomplish what you are looking to do on the web. Sure, your reaction to this is going to be “duh, of course you should spend time thinking about what you are going to do online. All good jobs take time.” I say, oh young one, are you actually spending time where it needs to be spent? I suspect you aren’t.

  • Note to self, scope is important.

    Being that this was an issue just last evening, I thought I would share something that I have encountered when writing Javascript scripts.  First of all, let me state that Javascript syntax is extremely forgiving.  You can do all kinds of  unorthodox declarations of variables as well as use variables in all kinds of strange ways.  You can take a variable, store a string in it, then a number, then an object and then back again.  Weakly typed would be the gaming phrase.  The one thing that I would like to note, as it was my big issue last evening, is scope of your variables.  So long as you are careful about defining the scope of any given variable then you are ok, if not, you could have a problem just like I did.  So, let’s start with scope and how it works.

  • Subscribe

    -->