Small Inconveniences Matter

Aug 26, 2010

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.

This person will remain unidentified as I don’t want gobs of people spamming his site, nor do I want to give his poor judgement any extra exposure. That said, the basis of the post was, it is preferable to make users authenticate with Twitter every time they logged into the system as opposed to storing the keys and remembering who the users of the site are.

The take-away message was, paraphrased, “it’s a simple back and forth between your site and Twitter each time they log in. It won’t bother the user and it is preferable to storing all of those authentication keys.”

Let me say it again: he was evangelizing inconveniencing the user and stating this was actually the preferable thing to do.

This idea is wrong-headed in so many ways. First, let’s look at Twitter and see how they would feel about it, shall we?

Suppose we stored the keys for the user. Twitter would have to generate a key just once for each user. Once that work was done, they would simply take requests as usual and the day would go on. Their API is built around using stored user authentication so this is no extra burden. Instead it is business as usual.

Now, suppose you make your user re-authorize every time they signed in to your web app. This means that each user would have to hit the Twitter authorization page once per login. Now Twitter has to burn the extra cycles to generate a new key for YOUR user. On top of that, there is storage of that key. Each time you request a key, you are taking up space on their server.

The more times you make your users request authentication, the more it costs Twitter. It might be no big deal to you, but that is money out of THEIR pocket. That is the very same pocket which is financing that lovely API you are using to update your user’s timeline. We haven’t even started talking about your users yet. This is just the mess for Twitter.

Let’s have a look at your user. If you store their authentication, they have to hit the Twitter authentication screen just once. Once they do that, they will probably forget all about it, carrying on with using your application, like they want to. That’s it.

Suppose you, on the other hand, make your user authenticate every time they log in. One of two things is going to happen. Either you make them authenticate through an account screen and they will assume, after the first time, that they are done. The other option is, as soon as your user logs in, they will be faced with a Twitter authentication screen.

Suppose you make them authenticate through an account screen. Your user will reasonably assume this was a one-time thing. Later they will discover that Twitter isn’t being updated by your app anymore. They will check their account and see they have to re-authenticate.

Rinse, repeat.

Eventually, your user will figure out that you expect them to re-authenticate EVERY time they log in. If your application relies heavily on Twitter updates, you will lose that user. If that user liked your application because it updated twitter, you will lose that user. In the end, you are likely to lose users over the choice.

Suppose you force your user to re-authenticate each time they logged in. Your users are going to view logging in to your service as a chore. Eventually they will tire of the whole process and leave. This is the most direct route to losing users.

Regardless of the path you take, you are bound to lose users if you make them re-authenticate through a service each time they log into your service. Also, the more services your app interacts with, the more services your user will have to re-authenticate each time they log into your app. This compounding effect will only drive users away faster.

In the end, what this person was really evangelizing is simply laziness. It is unreasonable to expect your user to go through a litany of special operations each time they log in before they can fully use your service. In this day of “less is more” user interaction, asking the user to perform unnecessary actions is a sure-fire way to drive users from your site and fast. Think about your user. Do a little work for them and make the web a better place.

Know Thy Customer

Aug 17, 2010

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.

Years ago, I built a project tracking system for the Creative department at my current company which they use for everything. More projects come and go through the Creative project queue than I had planned on, but it has held together reasonably well. That said, the Engineering director would like to get everyone in the company on the same set of software in order to streamline maintenance efforts.

In theory, this unification makes lots of good sense. Less money will be spent maintaining disparate software and more will be spent on keeping things tidy, making for a smooth experience for all involved.

Unsurprisingly, I was met with resistance from the Director of Communications. She told me she was concerned about the glut of features and functions she had no use for. She prefers the simple system because the creative team is a small team of three. Tracking all of the projects a small team has is just challenging enough to require a small system, but not so challenging that she needed all the heavyweight tools a team of 50-100 people would.

I am currently acting as negotiator between the Engineering and Creative departments. Proposals and counter proposals are being thrown back and forth and I’m caught in the middle. The challenge I see sneaking about in the grass is that the Engineering team doesn’t know their customer.

This doesn’t mean the Engineering team is bad. It doesn’t mean they don’t care. It simply means they don’t live in the same headspace the Creative team does and they don’t have enough time to think about it.

This puts me in a sticky situation.

I worked exclusively with the Creative team for the first two years I was with the company. I ate lunch with them, worked with them, met their deadlines, played by their rules and build 95% of the tools they use today. It was a really great insight into what a creative time is really like. Something many engineers never have the opportunity to experience.

Now, I am part of the Engineering team again and playing by their rules. Engineers think differently. I am an engineer and my father was an engineer before me. I know a thing or two about engineers and their quirks. Ultimately, I can see both sides of the argument and the standoff is looking a little hairy.

“So, where are you going with all this,” you might ask.

If you are going to propose a solution to a problem, instead of learning all you can about the solution you are going to offer, learn about your customer instead. Don’t try to shoehorn a customer into a solution saying “it kind of does most of what you need as long as you need the stuff it does.” It will never work out for you.

Learn your customer’s language. Uncover little secrets about them and figure out how they really work. Customers will rarely pony up and say “here’s everything you need to know about us and our problem.” Almost always, they say “here is our problem. Fix it.”

If you don’t know your customer, you’ll never solve their problem. If, on the other hand, you DO know your customer, you have a fighting chance. Mind you, even if you know your customer, they may still disregard your solution anyway, but at least you know you gave them the best you had.

Don’t fret if it takes some time to learn to think like your customers, though. It’s not something that comes overnight. I know it took a while for me to stop thinking like an engineer for 30 seconds and think like a designer. One day, I woke up and everything had to be diagrammed. There were so many things which could only be said through images. The shift happened and the code disappeared.

Look for the transparency. If you can stop and step into your customer’s head for a few minutes you may discover that the real problem is not the issue they have with the solution you offered, it may be with the solution that doesn’t solve their problem. Creatives, engineers, accountants, executives and marketing people all work in different ways. Businesses are much the same. Find how their problem is different and you will find the solution. Know thy customer and make the web a better place.

When SEO Goes Bad

Jul 6, 2010

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.

It is important to consider search engines during the site building process, however I feel the SEO guys often get carried away. In this article it is suggested that you de-emphasize navigation and forget footers along with lots of other questionable advice.

These two suggestions alone are enough for me to consider this article, at best, a crackpot spouting extremist ideas. SEO experts often seem to forget a very important element on the web: the user.

Something designers are told and people are wise to heed is, pretty things work better. Do they ACTUALLY work better in some sort of quantifiable way? Probably not, but that doesn’t matter to the user. If a site is attractive and seems easy to use, the user is more likely to invest the time to learn how it works.

User experience people know that navigation is key to moving a user through the site. Let’s take, for example, Amazon. They are a top-rated site for Google searches. Have they gone and done away with navigation? No. Why? They know users rely on navigation to move through the site. Moreover, their designers know that pretty navigation works.

While the SEO nuts will scream “de-emphasize navigation,” Amazon bucks the “trend” and keeps on doing what they know works best for making money: directing users.

Regarding forgetting about footers, if anyone in the SEO world ever thought footers were there for search engines, they are fooling themselves. Footers are only ever implemented for the user. Information which a small group of users may want is typically stored in the footer. This kind of information is stuff like license numbers, contact information and other legal odds and ends.

Other common footer items include convenience links, brief site navigation and polish elements which finish out a site. Footers, especially those of the fat variety, were never intended to be SEO tools. They are for the user.

If an SEO guru were to design a site, it would probably be a huge mass of text with a few peppered images, some meta information at the top, a link which says “home” and the required legal information at the bottom in a big, unattractive text block.

Though a page like this would garner a couple of extra points from search engines for being easy to parse, it would lose mega points for being completely useless to a user. The more useless your site is, the fewer users will return. The fewer return visitors you have, the lower your site rank will be. Ultimately, you will win the battle and lose the war.

Moreover, what is really making the money, the search engine or your product? Trust me, if you have a product everyone wants, the search engines will bump you up the list even if your SEO stinks. On the other hand, if your SEO is top-notch, but your site fails to deliver conversions you may as well pack it in now.

Finally, something I never seem to hear SEO people talk about which should be absolutely top of their list is the semantic web. The semantic web can be horribly complex which seems a little daunting, but it doesn’t have to be. Simply remember to use the right tags at the right time and you’ll be on your way to better SEO without all of the extraneous pain involved in new metadata information embedded in your pages.

Remember to do things like break your pages up into headers, divisions, paragraphs, lists and tables. If you want to get really fancy, add definition lists. This will score big points with the search engines and it will also score big with your audience. The more you can divide your information into digestible chunks and then style with CSS, the happier everyone will be. Users will be able to quickly skim the page in search of what they are there for and the search engines will be able to parse your pages better, potentially leading to better overall ranking.

In the end it is best to build your pages the right way: semantic tagging, strong user focus and dense metadata components. There are many SEO techniques which work better for both search engines and users. Forget about completely re-building your page just to impress the Google spider, because you won’t. Think about the user, build a compelling site, mark it up correctly and make the web a better place.

Balance is Everything

Jun 1, 2010

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.

Ultimately, it is rarely clear where boundaries are in a project. What is too much, what is too little? Somewhere between too much and too little is just right, much like what Goldilocks wanted in her porridge. We know that even the most limited of users should be able to access our sites within certain considerations. A photo gallery is, ultimately, little use to a blind person, but alt tags should still be in place. Sound clips of the Boston Philharmonic Orchestra would be useless to a deaf person, though a caption or indication as to what each sound clip is would be quite handy.

Coming back to the point, finding a balance point is critical to providing rich, meaningful interaction between your user and your site. Perhaps the first question which should be answered is “can this be done without Technology X?”

Technology X is always the hot technology everyone is dying to use. Flash, AJAX, CSS3, these all have fallen under the Technology X heading at one point or another. By using Technology X as your baseline interaction, you may be causing your users pain when you thought you were enhancing their experience.

A prime example of where Technology X is used when standard interaction would do is the Google login procedure. Many, if not all, of Google’s login boxes use AJAX for verification of user creds. It sounds cute and looks vaguely neat, but what happens when the browser barfs on their Javascript or you suddenly lose your internet connection? You have no clue what happened.

Your experience just took a nose dive and left you in the dark.

This is especially bad news for something like a login. Logging into a website should be a simple, straightforward, FAST experience. I want to type my creds, log in and be on my way to my dashboard. If something dies unexpectedly, I want a clean, clear indication as to what happened and why. If someone cut my ethernet cable in the next room, I want to know my computer lost network connectivity and that’s why I’m not seeing my dashboard in all its glory.

CSS is another item which can choke on users, leaving them feeling lost and confused. When things are hidden or altered with CSS in a way that makes them unreadable or unusable to the user, it can get ugly. The user sees a damaged site and moves along. Your rep falls to pieces and your user has moved on to greener pastures. This is especially true for people using Javascript to reveal something hidden with CSS.

The phrase “if it is to be shown with Javascript, hide it with Javascript,” carries a lot of weight with me. If your Javascript is going to die, it would be preferable that you err on the side of caution. Show everything. Make sure the page is as usable as possible.

So, the balancing act. I’m not saying there is no room for Technology X. The Technology X of today is the old standby of tomorrow. People will become familiar with new technology and learn to expect it. In the meanwhile it is important to consider what your user is aiming to do.

As a friend of mine likes to quote: Proper prior planning prevents piss poor performance. Know what it is your user is trying to accomplish by using your site. If they are there to purchase widgets, build a no-frills site which sells widgets. Use styles only to make the page more readable. Make sure everything makes sense without styles. Don’t use Javascript to do anything. Let the server do all the grunt work.

If you plan your site carefully and build something which is clear, usable and meaningful, adding Technology X will only make the site better. If something fails, your user will still be able to interact with the site and get things done. It may take them an extra click here or there, but it won’t be the show stopper it would have been if Technology X had been your only approach.

Balance is everything. Balance your plain site with your desire to incorporate interesting new technology. Just because it might be neat to see something done with AJAX doesn’t mean you should. Flash doesn’t solve all world ills. Sometimes a little bit of HTML a dash of simple CSS and some server-side elbow grease will do just fine. Build your sites for real use. Make your toys secondary. Think about your users’ goals and make the web a better place.

Coding Transparency: Development from Design Comps

May 20, 2010

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.

When I say I am a designer second I mean I am, in fact, a design school dropout. I went, I learned just enough to “get it” and then I ended up dropping out. I did go back to school and I got a math degree, but that is a different story for a different day.

If there is anything I learned from design school, it was that everything in design is done for a reason. Mind you, this is when design is at its best. Every designer that is working to solve a problem and communicate with the viewer has incorporated elements and done things so a specific message comes through.

Unfortunately, many of my engineer colleagues don’t have this insight. Typically people who opt for the engineering route do so when they are in high school or earlier and rarely set foot into the creative world. They may be proficient hobbyists in a particular art or craft, but their real love is engineering. Typically they really have little or no knowledge of design whatsoever.

People who don’t understand design make really poor designers.

Sorry, it’s true. This is not to say people without design skill can’t convey messages, but they tend to be inconsistent and unpredictable. Moreover, engineers, in specific, are typically more interested in solving a puzzle than making the final presentation precisely “so.”

This is the benefit of design comps. Designers, unlike engineers, are trained in design and are able to consistently and deftly communicate ideas with a clear voice. When they create a design comp for a website, or several depending on circumstances, they are creating a visual roadmap to communicate with the world.

Engineers, even as wonderfully detail oriented as they are, tend to see the big-picture items like color and location of items on a page, but they miss items which are equally important, like typography, subtle shading and other items which create a polished look that tells the user this is something made by professionals.

Ultimately, what happens is engineers color the design with their desire to finish slapping that UI together so they can solve the really meaty problems. When I joined Arrowhead, the company I currently work for, much of the Creative-specific projects looked pretty good, though the code was abominable. The collaborative work between Creative and Engineering seemed to suffer.

Mind you, this does not mean the engineers here are bad at what they do. Quite the contrary. They simply colored the output when they worked on it. Designs would fall apart as content was added and the best laid plans met the real world.

Engineers and developers need to work on being more coding-transparent. Regardless of how ugly the first iteration of the code might be, get the page looking good. When you think you’re done, take a printout of the original comp and hold it next to the completed page. Do the look the same? Do they look different? How do they differ?

In order to achieve coding transparency it is important to take a moment and understand what the designer is trying to communicate. See what the pieces of the design do when they work in concert. Understand the intention.

Ultimately, this may lead to asking the designer questions. They don’t mind answering questions like “what am I supposed to be doing here,” or “when I add content, the design seems to break like this, any thoughts?” Questions like these help designers to work with you and, hopefully, develop a more robust design, capable of handling what the world throws at it.

Designers, on the other hand, hate questions like “what is this for? Do you really need that?” The answer is typically “yes,” so don’t ask. Try to implement it and then ask questions if something breaks.

As you work through a design, you may find you have to interpolate or extrapolate on a designer’s idea. If it is clear how to build from what they have done, just go for it and brace yourself for minor tweaks. It’s okay, changes happen. If you don’t understand what they want or it’s not clear how the design extends to what you are currently working on, then stop and ask questions.

When engineers ask questions which lead to better design decisions, designers feel more confident about how the end product will turn out. Much like engineers feel when people ask questions about whether items are possible to implement rather than just assuming they are and promising the world.

In the end, coding transparency is all about communication. It is about communication between the designer and the engineer and it is about communication between the designer/engineer team and the user. If communication breaks down anywhere along the way, the message will never reach the user or worse, it does and it’s ugly.

In the end, everything we do is intended to reach an audience. The more we can do to facilitate the message as it comes down the wire, the better. So, the next time you receive a comp and rush through, slapping elements into place without review, imagine what your system would look like without testing and code review. Practice coding transparency and make the web a better place.

  • 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