First, here’s some benchmarks from September 27th from Lifehacker. There’s an article about a very promising IE10, then there was a follow-up two days later about the upcoming Opera build.

As for Windows 8, here’s a good video from June demoing some features and the updated UI (the Internet’s Wadsworth Constant applies, so feel free to skip to 30% in).

Granted, until you use it yourself, it’s hard to say what the truth is when updates are announced. Personally, I thought the iPad UI seemed silly because it was just a spread out iPod/iPhone UI with wasted space, but using it is still really nice. So, we’ll see how things change.

One aspect, which is likely the most important aspect of them all, is your team’s structure and the different roles that people take and how those roles fit into getting things done well. Even when the team is really just one person, that one person has to take on those different roles. Though there are many different names for these roles, I’ll give them the most generic classifications possible and then give examples of those kind of roles and their relationship to the features or requirements needed for a project or effort.

Source – Examples: Client, Business Analyst
This is the person who has the inspiration or idea for what should be created and at least some vision of what that will look like. This could be a client who needs a website made, a developer with an idea for the next killer app or a business requirement coming from management. I tend to think of them as “the Source” because they are where the work or project is coming from.

Refiner – Examples: Project Manager, Lead Developer, Designer
Here we have the person who really delves into what needs to happen to make something useful and compelling. They either can be the Source who refines their own idea, or they could have a back-and-forth with the source to really find out what is going to happen, what’s needed and what benefit the idea is going to provide.

Architect – Examples: Technical Lead, Lead Developer
After the Source and Refiner have done their jobs and come up with what should be built, the Architect decides how it’s going to be built and how it’s going to happen. That can include deciding the technology or methodology that will make the idea into an actual project and how it’s going to be completed.

Builder – Examples: technical Lead, Developer
The Builder will take what the Architect, Refiner and Source have put together and make it a reality. They will take the project and actually build or complete it, likely with a fair amount of interaction with the above three as unforeseen or unplanned events, complications or considerations come into play.

Tester – Examples: End User, Project Manager, Client, Developer
Once the Builder believes they have finished creating the project, or at least portions of it, someone checks to make sure it’s behaving and works as expected. This Tester will often go back and forth with the Builder when unintended problems are found or missing features are discovered or additional requirements that weren’t thought of before are found.

User – Examples: General Public, Employee, Client
Finally, once the project has been completed, there is the actual user of that project. This is the person who the project was built for and who should be the main consideration throughout the project, making their life easier or more enriching in one way or another.

Now that we have these different roles defined, I hope to go into what an ideal structure would be on a given project in a follow-up post.

That’s all old news and the debate is still raging about how to go about it and what tools to use and there are plenty of different, great arguments on both sides.

Then I thought about XBox, Playstation 3 and Wii.

Granted, I haven’t yet looked into the technical aspects of it, but being able to create a channel or app for each of those common consoles with a common codebase would be more than helpful for a variety of organizations. Whether you’re creating a small game that you want to run both on mobile and on those consoles without going through the process of distributing disks and working with publishers or you’re creating an application for an organization like the NFL, being able to roll out on all of those platforms relatively easily and at a lower cost to development would be an amazing asset.

This is just a thought experiment at this point, but it certainly makes me wonder about what could happen when you have that kind of cross platform development available.

While I’d like to cater to my ego and say that developers are the rockstars while project managers are the band managers, I don’t think it’s quite that simple. Of course, each team is different and has different dynamics, so there are no universal truths.

However, with regards to the above article, ultimately, project manager has to have an in-depth understanding of the business rules, business goals and requirements, as well as an accurate understanding of technical practices, methodologies and restrictions.

I say accurate because that’s really what’s important. He or she doesn’t need to know the details of how changing an application to a new framework is a lot of work, just that it is. And when they’re unsure, they ask questions to get that accuracy. It would be perfect for the project manager to have enough of a technical background to be able to have that in-depth technical understanding, but nothing is truly perfect in this world.

Tim argues that instead of looking at what the general market trends in browser usage is, you should look at what the usage of your users are. I completely agree with that sentiment.

Given the current state of modern browsers, however, there is very little reason that your website design and development can’t support the majority of browsers. There might be slight display issues in some cases, but the big hitters: IE7/IE8/IE9, Chrome, Firefox and Safari, are all relatively easy to support. Of course, there are occasional bugs here and there (I’m looking at you IE7) that require special attention (and often additional hair-pulling), there is little reason beyond working with some intense JavaScript or cutting-edge CSS3/HTML5 features that your website will not work in the above browsers.

Once that’s accomplished, it becomes a business decision how far you want to go to support less common situations or exotic browsers or antiquated browsers (hey, IE6). Just like how how much A/B testing you do becomes a business decision, how much cross-browser compatibility your company is going to pursue is also a business decision.

In the case of software, this is a tremendous issue. How many people use the default theme in Chrome or Firefox? How many people have the grass background in Windows?

Those are certainly mundane examples that matter very little to a user, but there are certainly other cases where the default does change their experience. Take signing up for a newsletter, for example. Or getting notified when there are additional comments on a blog post. Those choices will greatly affect a user’s experience with that piece of software.

Much of Nudge discusses giving people the option to control their environment and what they want should they want to make an explicit choice. Otherwise, give them a default that will most likely work best for them and educate them about the possibilities out there and what’s available.

For software, do you make your default something that will make your company money right now? Or money in the long term? Or promote customer retention and recommendations?

Ultimately, those are business decisions. Though, personally, I think it’s always clear that those last goals go hand-in-hand.

The best way I can describe software development for me is with a list of pros and cons. So, starting with the pros:

1. Solving problems. Personally, this gives me a sense of accomplishment, at the end of the day, I can look back and point at something that I did or made or finished.
2. Alone time. I’ve found over the years, I need alone time. Otherwise, I just get to the point where I can’t take people. There’s plenty of alone time in software. This, in particular, is a pro for me, but could be a con for others.
3. Smart people. There are a fair amount of smart people in this field. People who make sense and think logically and, in general, aren’t crazy. Of course, there are some horribly awkward people, but sometimes that just makes things more fun.
4. Always something to work on. Now, this is both in terms of the job market – compared to other areas in the current economy, it’s still quite strong, and in terms of being able to play around with things outside of work and improve yourself.

Now, cons:

1. Not-so-smart people. There are, as in all areas, the less-than-smart people you have to work with. I think, however, that this is something anyone is going to run into in any field, so it’s really in the con list of having a career or job at all. However, I certainly do not have the horror stories that some people seem to have.
2. Getting bored. Personally, I get bored with a certain task or single project after a few months. If it’s the same project, but with a new twist or interesting new updates, that’s enough to keep my interest.
3. Working on uninteresting things. This is very similar to con #2, but it’s still slightly different. Generally, I tend get frustrated when I make something that no one is going to use or provides little value.

Personally, the pros, especially #1 and #2 are what really makes me love what I do. #4 is also a great thing in terms of long-term value and career, and #3 makes the day-to-day passable.

Then, in discussing where to find work, I wrote:

Generally, I’d say look for a small place, and one who’s goal is to make websites/software if you can, not just that they do have a software division to make tools to use internally. That’s not bad, but that means that you’re always going to be a coder to them, but at a place where software/websites are the goal, then you’re the MVP and everything is built around you getting your job done the quickest and best way possible. Because of this, they’re also harder to get a job at a place like this because they are in higher demand.

Great reason I’m happy to work at Bootstrap Software.

The only case I can come up with where one wouldn’t want to A/B test is really when it just becomes too cost or time-prohibitive to do so or when there are more important business updates (features, fixes or enhancements) that resources should handle first. In addition, you have sites that just might be for personal use that just aren’t worth the time or effort.

In the cases where those conditions are not true, what happens far too often with sites is that whoever makes the business decisions on the look or text believes they have the best solution. They aren’t necessarily wrong, but their personal preference or belief isn’t necessarily going to maximize their site – whatever maximizing might be for them (purchases, newsletter sign-ups, etc).

Often, what an A/B test will show you is that what you or someone else thought was best was truly not. That’s the real goal: finding what’s best, and that’s what A/B tests do. And who doesn’t want to be the best?

What’s interesting, though, are people’s reactions when you start asking what they want in a site and what they want it to do. I’ve found I usually get one of three reactions:

The “I’ve Never Thought About…”

This is typically the most common. People think they have a great idea for a site, or they know they need a site or an update to their site, but they don’t actually know what they want. While this can be frustrating for a developer who is looking for problems that need solving versus creating a new problem they then need to solve, it can also lead to a very collaborative relationship between developer and client. In this scenario, ideas can go back and forth, discussed and bought into.

The “Here’s Exactly What I Want, Let’s Do It Now”

These can be both good and bad. People think that just because decisions have been made about how something should work or what it should look like that that’s the hard part. In truth, the idea is generally the easy part – the implementation is hard. Take flying cars: the idea is great, true, but it’s an easy one to come up with and no one’s been able to implement it well. Yet…

Often, you will find people in this boat can have unreasonable timetable expectations or it will be a case where they don’t know what they don’t know and have unreasonable requirement expectations. On the other hand, if they have reasonable expectations, and they know what they want built, then you’re generally in the clear.

The “I Just Want a Site That Works”

Personally, I find these the hardest to deal with. The best way I’ve found to handle this is by means of analogy: “I just want you to build me a house, I’m not going to tell you the number of bedrooms I need, my price range, the town I’m looking for, the building materials…” Generally, the house example works well because everyone knows there’s a wide variety of houses and that a house is an extremely general term. If they still continue down the route of just needing a site, then I don’t really think that they’re worth the time. After I build them a site, then they’re going to have requirements and we’re just going to be back at square one.

In many other fields, requirements gathering can be glossed over or forgotten; however, as my friend and coworker Jamie Forrest wrote for our Bootstrap Blog, to do something right the first time, you need to gather requirements right the first time.

Sure, the title of the article notwithstanding, the author, Nick Johnson, compares and contrasts and draws attention to some major Chinese designs that are what a Westerner would call bad. Note that last part. It would be a Westerner’s opinion and not absolute truth.

It got me thinking about localization in general. For example, I work on Leading Hotels of the World on a day-to-day basis. That website comes in a variety of languages: English, German, Japanese and more recently, Spanish and Italian.

Notice that the biggest difference among the localizations of the site are the translations. Much of the functionality stays the same. None of the languages are left-to-right, so we don’t have to account for that, either. The design essentially stays the same.

This doesn’t have to be the case. For example, many cultures interpret colors very differently from one another. What if you’re trying to design a website around love. Something that evokes many powerful emotions from many people. More than likely, your company will be target only a certain culture, but if you check that chart, Western, Eastern European and Japanese cultures associate red with love, while Native Americans associate yellow, Hindus green, and Africans blue.

After taking something that is so ubiquitous, you already have some major design issues on your hands in terms of just color. You’re already getting into issues, and we don’t even have a design.

In addition, you have to consider cultural preferences, practices, understood symbols, on and on.

It’s relatively easy to see that every culture is going to have a certain design that works best for it. There is no best design for all cultures, just as there is no best design that will please all users.

To truly achieve localization, an organization will need to consider everything it does in regards to that culture’s users and their wants and needs. To be truly localized, you’ll really need a designer from every culture to design for that culture.

Of course, the world’s not perfect, few companies have to deal with these issues, and fewer still have the resources to devote to so many different approaches, but next time you see an “ugly” design, you can re-consider the audience and culture it was designed for.