Developing for Delivery: Separating UI from Business

Mar 12, 2010

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.

So, what is really going on here?

The idea behind MVC as well as many other design patterns, is to break programming tasks into chunks and handle them independently. MVC typically fills a need on the web as the view or UI is what the user ultimately sees and keeping it uncluttered makes life easier for the creatives to work their magic after the programmers have performed theirs.

Though frameworks typically make it easy to keep the models, views and controllers separate, programmers tend to get a little heavy with the code. There is a project of which I know, and will remain unnamed, that incorporates business and model logic into all parts of the code. This sets the developers up for two distinct issues:

Requirements change

Maintenance is a nightmare

First, we know that requirements change. Someone is going to say “gee, I wonder if we could do x.” When it is an executive that says this, the whole sentence can be rewritten simply as “do x.” If the code is scattered across views, controllers and models then changing direction is kind of like redirecting an aircraft carrier. You can do it, but it is slow going.

If the code is packaged into neat little controllers and the view is completely separate, then adding new function is much less labor intensive. In the end, functions almost materialize before you, taking a task which could have been a month project and turning it into something which gets done in an afternoon. The savings is tremendous.

Second, the maintenance nightmare. There are many factors that come into play when writing maintainable code, but let’s focus on the single aspect of good, modular practice. When writing code, be it in an MVC design or some other separation scheme, putting together solid modules makes everything a little easier to maintain.

Imagine you have your same, scattered code. A little of the work is done here. Some of it is done there. In the end, it takes fifteen files to get a job done. Suppose something breaks. Don’t say your code never breaks.

All code breaks.

Once something breaks, you have to maintain it. Now, was that function here or was it over there? What all did it do? Where do I find it?

Perhaps you haven’t touched that code in three years. It happens. You could spend a day just tracking down the bug, forget about fixing it.

Now, I don’t want to make this all about MVC, because it’s not. This is about simply keeping the presentation separate from the business logic. Perhaps your business logic is broken into 15 layers. Great. Make sure that none of those layers is the presentation.

So, what does this have to do with delivery?

I’m glad I asked.

Rhetorical questions suck.

On the web there is one goal. Deliver content to the user. I don’t care who you are or what you do. In the end you are delivering something to the user. Sometimes it’s e-mail. Sometimes it’s a blog. Sometimes it’s a way for them to do their taxes. It is all about delivery.

Users on the web are demanding. They want it all and they want it now. If there is a bug, they don’t want to wait for the next five build cycles to see it fixed, they want it now. The simpler you make things for yourself, the easier it is to get down to the business of delivery.

Another benefit you will see is the ability to quickly change direction. If your creative team wants to completely redesign the website, it won’t cost the rest of your life to make this happen. You can keep all of the infrastructure you already have and simply make it look new.

I am currently working on a project using JSP. I am collecting website content from an outside source and presenting it within a JSP page. I could have build a heavyweight page that does all of the collection and presentation, but I opted against it. Instead I built several classes, each meant to perform a single clear task. One collects menu information, another collects the content. Yet another produces nicely formatted menus.

You’ll note there are two classes for menus. This is intentional. I don’t want to have to dig through all of the menu collection code to rewrite the menu presentation engine. These should live separately.

In the end, all the actual JSP page does is present the pre-collected, pre-formatted content I prepared using plain old, run-of-the-mill Java. The extra added benefit: because most of the function is compiled to run in a virtual machine, rather than parsed and executed by an interpreter, the collection and presentation is blazing fast.

The lesson to be gleaned from my rambling post is this: regardless of the particular design model you choose, break pieces apart. Keep the UI separate from the business logic. It will save some gray hair, hours of lost time and it might even make your program function better. Develop for delivery, keep your code tidy and make the web a better place.

I Didn't Expect THAT to Happen

Mar 3, 2010

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.

Boy, I didn’t expect THAT to happen.

You’ve fallen prey to a violation of what I call page-behavior taxonomy. In short, page-behavior taxonomy is a set of rules that certain items must follow when they perform an action or page-behavior. Wikipedia does a reasonable job of telling the user what they should expect after they perform an action as each type of link looks a certain way.

In the current age, a typical website has links that behave in all kinds of ways. Some links move the user to a new page. Some links display information inline. Some links move the user away from the site altogether. The user anticipates the behavior of a link based upon page context and presentation.

Each of the links on a page fall under a particular taxonomical definition. The written list of taxonomical definitions is all but hidden to the user. In the best situations the taxonomy can be used to define the user journey and experience, creating a smooth flow of content from the web to the user.

The most common page-behavior taxonomy I use categorizes links into the following groups: inline content links, intra-website content links, extra-website content links, object display links and other javascript behavior.

When the taxonomy is considered, the user will understand the function of a link given the context they discover it under. This means, if they see a calendar icon next to a date entry field, they won’t be surprised when they click the icon and a calendar pops up. It relies on expectation of the user and the fact that the link was part of the “other javascript behavior” kingdom.

What brought this discussion about was my discovery of a set of tabs that violated the page-behavior taxonomy. I won’t provide the site because they were giving away a script to let others recreate the effect. We discourage bad Ux around here.

The tabs I encountered were AJAX enabled. This means the user clicks a tab and the content is requested and displayed inline. I was generally okay with the behavior. It was something the user could reasonably anticipate or even be pleasantly surprised by. I didn’t see any way for the tabs to degrade gracefully, but I won’t go into that now.

As I clicked through the tabs, I had a nice, consistent experience.

Click -> content, click -> content, click -> content.

Then I clicked the last tab and my browser window was hijacked. I was sent off to a new page entirely. I didn’t know where I was. I didn’t know what I was supposed to gain from the page. I was lost. All I wanted, after that, was to go home.

The designer had kept me distracted while the developer got behind me and crouched. The designer pushed and I fell over. I felt betrayed. How could my friend, the designer, or my colleague, the developer, play such a dirty trick?

This sentiment is shared by users when they visit a site that tricks them. The user, in the end, feels they were somehow dealt an unfair hand. They feel betrayed. They lose faith. They leave.

The important item to note is, no single person is responsible for this kind of manhandling. First, the UxD has to betray the user by not telling them something is going to happen. Then the developer has to build a function to enable this kind of behavior. In the end, both parties were to blame.

The solution to this is to build a taxonomy. Consider the terms you will use. Select copy that is meaningful to your user and use it consistently across your site. Develop a list of page behaviors and implement them, projected against your taxonomical dictionary. Make page-behavior rules clear to your user. If you plan on surprising them, do it by understanding ease-of-use.

Carefully consider your link behavior and develop it against a backdrop of user understanding. Make your site easy to use. Think of your user and don’t give them unpleasant surprises. Construct a page-behavior taxonomy to structure your site around and make the web a better place.

Degrading Behavior: Graceful Integration

Feb 26, 2010

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.

Engineers and designers work together, or divided as the case may be, to create an experience that users with all of their faculties and a modern browser can enjoy. While this goes down, the rest of the world is left feeling a bit chilly.

What happens is, the design starts with the best of intentions and, then, the interactivity bug takes hold. What comes out is something that is almost usable when slightly degraded, but totally non-functional when degraded to the minimum.

In the end, of course, the user needs must be considered. Having a graphically intensive site doesn’t hurt if you are a design firm, but might not be the best option for a company dealing with medical customers.

My suggestion, however, is simple. Instead of degrading your site as the user needs become greater, start with a site that is usable at the lowest common denominator and work up.

Understand who your audience is and prepare to serve those of them who have the greatest needs. Build a site that is attractive and works if the user can only view it through a program that reads for them.

Once your site has been built and is fully functional, build up. Integrate functions to serve the users that have some needs, but aren’t in the highest-need area on the spectrum.

Continue on this path until you have integrated all of the latest and greatest, bleeding-edge functions that your highest-ability users can interact with.

As you build this way, be sure that you are simply enhancing the function that is already on the screen. As you add enhancements, you should be able to remove them cleanly and still get the same experience you started with.

I call this approach graceful integration. Each progressive step, you integrate more functionality and interaction, preserving the layer just below as a separate user interaction.

Each progressive enhancement should be separate and easily disabled. The granularity of your enhancements can be as large as a two-step approach: all or nothing. You may also enhance your site in a careful way that allows for several levels of degradation depending on the user and their distinct needs.

A natural separation of user interaction happens when HTML is written, CSS is added and Javascript acts upon the subsequent design. This three-tier separation, you can use the work that will be done regardless to define your user interaction in a clean way.

One of the best quotes I’ve heard regarding graceful degradation, in paraphrase, is, “if you show it with Javascript, hide it with Javascript.” I offer this with no source as I can’t recall where I heard it. If you know/are the author of this, stand up and reap the rewards.

The attitude in this quote represents the core of graceful integration. As you pile the Javascript on, be sure you manage its behavior with Javascript. Don’t use CSS to manage something that is going to be handled with Javascript. If you must, prepare a style sheet that defines scripted behavior, but set the object classes with Javascript.

There are other benefits you’ll gain from this approach. Not only will your users appreciate the time and care you put into their experience, so will the search engines.

As search spiders crawl your site, they won’t see any CSS that looks to be doing something sneaky like hiding text from the viewer. Spiders have gotten smarter and they recognize when something fishy is going on. As you are already doing something good for your users, you get this bonus for free.

For those of you looking for snippets of code, the best thing you could know and rely on is the “noscript” tag. This is a tag which defines the behavior of the page for users without Javascript. I use this quote a bit to display extra form controls when Javascript has been disabled or is unavailable to the user. You can use it like the following:

<script type=”text/javascript”> //your script logic goes here </script> <noscript> <!– HTML elements go here like style definitions or form controls. –> </noscript>

You can also use noscript by itself scattered throughout the page to display page elements that might, otherwise, be missing for some of your users.

In the end, behavior on your site should be defined by the HTML first, the CSS second and the Javascript third. Should you choose to go to a finer granularity, don’t forget to double check your users can still use all of the layers effectively. Be mindful of your users, integrate function into your site in stages and make the web a better place.

Website Overhaul 12-Step Program

Feb 22, 2010

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.

Some people, in the panic and shuffle, opt for the fast-and-loose approach. They start throwing anything they can at the site, hoping something will stick. Anything means ANYTHING. All marketing ideas go in the bucket, then the executive mandates, the creative odds and ends, some engineering goodness and all of that. This almost always results in a disaster.

Others look to collect everything that people want and need, do a ton of marketing research and then follow that up with user testing. Though this may lead to a usable site, this method probably won’t generate a site that actually solves user needs.

There are various other permutations on these ideas, including the design by committee, the hire a specialist and the design by marketing requirements approaches.

After suffering through most of these approaches, I devised a plan that is reasonable, easy to execute, offers answers to common questions. If executed, this will provide a smart, well designed, user-oriented site which also fulfills business needs.

I call my plan the Website Overhaul 12-Step Program. Let’s dive in.

Step 1: Install analytics and do nothing for three months.

This doesn’t mean don’t do standard updates to information and common, day-to-day operations. I simply mean, don’t design. Don’t workflow. Don’t create nav structures and hierarchy and all of that. Just sit on your hands and wait. For. Three. Months.

Step 2: Review Analytics Data and Collect Client Needs.

Once you have let the analytics bake for three months, review your results. Sometimes they back up what your marketing team is pushing for. More often, there are little surprises and gems you’d never anticipate.

Look for commonly viewed pages. Review common search terms. Watch for people seeking names, phone numbers, account data or anything else that might seem odd in a search. All of these items can give you insight into your user.

While reviewing your analytics data, collect stakeholder ideas, information and requirements. Include this information in your concerns moving forward. Be sure to balance your findings and temper stakeholder information with your analytics findings.

Step 3: Create an Information Hierarchy.

I don’t care what you think your navigation should be, think about the information you have and create a hierarchy of relations. Which documents are gateways to information? Which information is subordinate to other information? This is all useful in developing an information hierarchy for your site.

Step 4: Develop Core Navigation.

Now that you have your information hierarchy and months worth of synthesized analytics data, you can start developing your core navigation. Think about what your users need and what your marketing team wants to accomplish. Apply everything you know here. Think about taxonomy and make sure you have navigation consistency, both in vocabulary and in behavior. This is your first move in actually creating a site.

During your core navigation development, you should start using tools like card sorts and thesauri to solve copy concerns and ensure clear language and categorization. If need be, you can reassess your information hierarchy at this step.

Step 5: Uncover Special Needs Navigation.

This does not mean you need to start thinking about accessibility right now (though accessibility is VERY IMPORTANT). This means, you need to consider items which don’t fit in your core navigation structure, but answer questions your users have. Assess user special, non-core, needs and address them here. Make a list and associate the special needs navigation with specific pages.

Step 6: Wireframes.

Now that you have your navigation structure laid out and your special needs listed, you are ready to start creating a visual guide for the layout of the site. Consider your user, what they look for most, what they look for least and consider Fitts’s Law. Think about scanning behaviors. Build something that begs to be clicked on, even when it’s printed and bound.

Standard (and not-so-standard) user testing should happen here. Be sure to develop your wireframes with the correct granularity for your audience to ensure they don’t get stuck in the mud of details that are unimportant at this stage.

Step 7: Design.

Once wireframes have been created and approved, pass the site along to the design team for their magic touch. Let them bump, nudge and finesse your wireframes into a compelling presentation. If you work carefully with your design team, they can take genius and bring it to life. Let them.

Step 8: Develop Templates.

Volumes could be written on the topic of templates and content management systems, including my notes on Object Oriented Content. For now, let’s simplify the idea and say, templates are good. You should use them. They will make your life easier in the short and long run. Now is the time to build them. Include all of the design goodies from step 7.

Step 9: Implement Site Structure.

Once your templates are built, using all of the designs produced from your previous work, you are ready to start implementing your site structure. If you created solid templates, this step should be fairly simple and straightforward. Take advantage of the separation between your templates and your content. All your content should drop in and you can make tweaks to your presentation. You’re getting close.

Step 10: Test and Bug-Fix.

Once you have implemented the site structure, begin testing the site. Send it through QA. Look for broken links. Look for bad content. Find items that will be a deal-breaker for your users and repair it now. Ultimately you don’t want your user to find the flaws that you already thought of. Be aware and move forward in a smart way. By now, you should have already gotten stakeholder buy-in so they should not still be in the mix unless they are core to user testing.

Step 11: Deploy.

Once you have the final seal of approval from your testers, you should feel confident your site is ready for the prime-time. Launch it and let your users have a crack at it. Give yourself a pat on the back, your site is live.

I’m sure you’re wondering why everything launched at step 11, since this is, after all, a 12-step program. Well…

Step 12: Watch Analytics for New Trends.

Now that your site is live, watch for new trends in your analytics data. Are your users getting their questions answered or are they still having difficulties? Are your users visiting new pages? Is everything still working or are you experiencing technical issues? All of this will appear in your analytics data, so keep an eye out.

There are many small steps that fall within the scope of this 12-step process, but it is up to you to ensure you implement your specific needs and tests. If your stakeholders need you to keep them in the loop, make sure you let them know your process so you can get their input when it is going to be most useful.

Make sure the people involved in the process feel confident about your moves and get buy-in at the right times to facilitate a swift, fluid move through the process. If you move forward with confidence, you will be a hero to your coworkers and a champion of your users. Take control, build confidence and make the web a better place.

Pretend that they're Users

Feb 16, 2010

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.

Typical engineers, on the other hand, live in a world separated and buffered from Creative and, subsequently, the user. They work with project managers, engineering supervisors and other layers of businesspeople that speak on behalf of the user, alienating the engineer from the world they affect.

It becomes easy to dissociate and refer to the user as clients and eventually abstract the interaction by focusing on the system and the software client that will interact with the functions being built. People as users become a vague notion that is hardly considered as functional pieces are built and pushed out.

This is an unfortunate circumstance as engineers exist solely for the purpose of building and supporting systems that people, somewhere, will be interacting with. People use computers. People use programs. People use web sites.

Even when working with Creative people, I still find myself getting lost in the code and forgetting that I eventually need to be able to interact with the user. I work on items that stimulate my brain, but don’t actually solve the user needs.

A popular design pattern on the web is MVC. I prefer this pattern myself. There are pitfalls in any pattern, but MVC allows me to work on three separate items in parallel.

My most recent, major project was constructing a content management system. I built this on Cake PHP. Cake is built around the idea of constructing the entire project on MVC principles.

The thing that happened as I built the system was I constructed an interface for the user to play with, first, then I built supporting architecture.

Recently I had a discussion with a friend of mine, he brought up the idea of constructing screens to show the user, first, then building the support system afterward. Funny how things seem to work out like that.

The point of all this is simple: engineers need to pretend like the clients are users, because they are. When building a function into a system, the engineer should ask, “how will this impact the user?”

Another way of stating this is, everything an engineer does, even at the deepest level of a system, will impact the user and their experience. From speed, to clean integration with a client-side interface, every line of code is important to the user.

The most important thing to keep in mind is that we are no longer in a world where bare forms and featureless landscapes of system interfaces are acceptable. Users don’t want to be reminded they are working on a machine built to do math really quickly.

Users don’t want to see an interface that is a direct expression of code, they want a smooth, human-like experience that leaves them with a feeling of satisfaction and ease.

Depending on how you view this challenge, it is either fortunate or unfortunate that building a system that anticipates user needs requires careful consideration and, potentially, more code.

The age of engineers that build programs in C and COBOL, which run exclusively on the command line is done. Engineers in the new era must be user-aware. They must anticipate user difficulties before they happen and prepare to guide the user, in a smart way, through the minefield

Current-era engineers are the gatekeepers to the computing experience. They hold the keys and empower the user to build confidence and manage the experience they have in a natural way.

Instead of being a guard, keeping common man out, be a host. Encourage your users to click, type and interact. Give them a wonderland. Pretend that they’re users, treat them like people 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

    -->