Smart boss + smart employee = profit
Smart boss + dumb employee = production
Dumb boss + smart employee = promotion
Dumb boss + dumb employee = overtime

I heard an interesting comparison today.

During a video conference with our corporate brethren, someone compared the use of mobile technology to the use of internet in 1998. While I think that’s accurate, I think that there’s an important distinction to make.

Namely, the speed by which the landscape changed in the last ten years is not a constant. The users are not going to continue to evolve at the same rate. The general acceptance of the internet into daily life, combined with the rapid advances of technology/infrastructure guarantee that things will change at a different pace.

So when do I think “Mobile 1998″ penetration will catch up to current traffic patterns/usage of traditional web sites? Realistically, I’d say about 24 months.

What that means is that we’d better get off our collective asses and start developing a real strategy for all of our web sites and applications that take full advantage of the mobile platform now.

Seriously, 24 months. Now that says a lot when you consider that my current traditional sites generate roughly 40 million page views per month and over 2 million unique visitors, while our mobile footprint is a fraction of that.

It doesn’t matter whether we can quantify the development resources needed at this juncture in time or not - it’s about protecting the future of our businesses and organizations.

Either we embrace mobile now, or be undercut by others who will have less to gain by relying on existing technology. Really, it’s the same argument that we made with print media 10 years ago - evolve or risk losing your market share to someone else.

In 24 months were going to be looking at digital devices that can deliver high speed video, perform every function of current web sites, and maintain advanced social networking - in the hands of more than half of the people in the United States, and more than that in Europe/Japan.

Better get started, because we’ve got a lot of work ahead of us.

Question: Who spends an entire afternoon working on a coverletter, only to notice AFTER sending, that he’s mislabeled the opening as proJECT manager, rather than proDUCT manager?

Answer: Yours truly.

However, that brings to mind an important point; we ALL need an editor. Whether it’s writing code, designing interfaces, or scripting a storyline, collaborating with others will result in a stronger product.

I think that we have a tendency to try and do everything on our own, in order to prove just how talented we are. The problem with that line of thinking is that you could miss an obvious problem.

Let’s use IndyMoms.com as an example. When I first designed the look for that site, the color scheme was based around the color orange, which I liked a lot. However, when I showed it to my wife, she had a very different reaction and I was a bit miffed at that. She suggested an alternative, violet/tan scheme.

As much as I wanted to be right, it was more important that the site be perfect, so we asked several people in the targeted demographic which they preferred. The purple design won 8-0.

The point is that we must encourage a culture of interdependency, where we can bounce ideas off of others.

Our Innovation and Development group uses Basecamp for just that purpose. We set up projects in it and then use writeboards to shape the requirements. For the visuals, we post jpegs and then use the commenting feature as a way for team members to suggest improvements. We also utilize Basecamp to track todos, milestones and documentation for all projects. Y

Basecamp takes a fresh, novel approach to project collaboration. Projects don’t fail from a lack of charts, graphs, stats, or reports, they fail from a lack of clear communication. Basecamp solves this problem by providing tools tailored to improve the communication between people working together on a project.

You can also give people outside your organization access to as much - or as little - of the project as you need. For example, Basecamp features a simple permissions system that allows you to specify who can see which projects. For example, if you want Employee-X to see only 5 of your 13 projects, just uncheck a single checkbox on the projects you don’t want them to see.

My favorite feature is that it saves me time in the note-keeping and meeting-holding departments. People can access the files at the leisure and they document their comments themselves - saving me time.

Now if only I’d posted that cover letter on Basecamp, first.

I was doing some surfing today, and I realized that Flash - which is a great tool - is often more annoying than it is useful. The reason for that is simple - the developers that utilize it tend to be one trick ponies. Many of them are masters of the tween and the art of action scripting, but couldn’t do a simple ajax affect if their lives depended on it.

To best utilize Flash, you need to understand that it is just another tool in what should be a comprehensive toolbox. If you really want to serve your clients and users interests, you should build everything simply and economically. Use Flash where you need to use it, but don’t force it to accomplish every little task.

The end result of over-Flashifying a site is that you end up with something that is incredibly difficult to maintain over time - thus driving up production time and costs. It becomes even more complicated once the original designer has handed off the Flash piece to someone else. There’s nothing as frustrating as trying to fix a Flash file that was build incorrectly in the first place.

One thing that I find frustrating is the overused Flash intro. It’s great to see a cool intro on my first visit to a site, but when I come back I should never have to sit through it again. It’s just a waste of my time. Since an intro - which I’m not a fan of anyway - is used to introduce your brand/product/message to the users, do you really want that brand/product/message to be irritating? The answer is a resounding no.

Flash works best as a user-initiated method within an established web 2.0, css framework, so let’s use it that way. To all the Flash designers out there that can’t cascade a stylesheet, it’s time to join learn.