Say a requiest comes in that someone wants to throw up a new random page on your site that you’ve made. Does that page fit a template you’ve created? Does it fit within the global styles you’ve decided upon? Is it something the custom CMS you’ve built doesn’t support? Or a case where one page doesn’t conform to the exact specifications to pages similar to it, but with different content?

This often means that you’re current solution isn’t flexible enough and will need to be extended to fit with these new requirements.

On the other side, you’ve created a very simple CMS that allows anyone to put in the HTML they desire onto a page. Perfect! You’ve got all the flexibility in the world!

But they want that page to have data that conforms with another 50 pages at all times, and they can’t spend the time updating those 50 pages whenever a change happens. Now you’re in a pickle be ause there isn’t enough customization put into your software.

So, how do you get around this? Sadly, it depends on the particular problem you’re solving, but I, having wasted time in the past building custom software, think that flexibility usually wins out – it means less development later, though it often leads to more administration later, a trade-off that can lead to delays, but usually leads to savings also.

Design and Usability Changes and Updates

• Larger Video Player - This is the first thing that anyone will notice when coming to a video. The player dominates the screen regardless of screen size and acknowledges that the user is there to watch a video.
• Advanced Social Integration - By making use of Facebook, we’re able to tell your friends when you’ve watched a video, share a video with them easily by dragging it to them and seeing your friends playlists. In addition, we create playlists for you based on the music you’ve liked on Facebook and your iTunes library.
• Simpler Homepage - The homepage, instead of having a carousel of images and links at the top with a variety of content below, we have one large carousel that really shows the visitor what the highlighted pieces of content are and what’s new at VEVO.
• Dynamic Resizing - The entire site fits the browser on every page, using more real estate on the screen and ensuring that the content (video) is truly highlighted.
• Persistent Navigation and Header - The navigation on the left, the header on the top and the footer are persistent and fixed throughout the site so a user can see their friends and playlists much more easily and search for a video quickly without needing to scroll.
• Continuous Play - When a user watches a video, we always have a new video to show them after that one finishes. This is a seamless experience for the user and also allows for them to enjoy the music videos without needing to really work to find videos that they’ll like.
• Removing Search Results Page - This sounds like it would be a bad idea, however, it improves the likelihood of a good experience. When a user searches for “Lady Gaga” but mistypes “Ladt Gaga” they, based on their experience on Google and elsewhere, expect to be corrected or brought to the right place anyway. VEVO, however, doesn’t have the resources or manpower to spend time on creating such advanced search algorithms, so we instead used only lookahead search, then a user quickly sees that they mistyped and corrects themselves, getting the results they want right in front of them.

Technical Improvements

• Using HTML5 Pushstate - By using the HTML5 pushstate on the playlist and video pages, we’re able to quickly show new content on the video page and decrease load time and increase overall performance, experience and decrease the number of HTTP requests.
• Local Caching - By caching artist, video and friend information on a user’s local machine, that means fewer data requests to our servers and much faster speeds on each additional page, meaning that the user gets a faster and faster experience as they go from video to video.
• Improved Recommendation System - By leveraging Echonest and their recommendation system, we’re able to give a user many, many more videos that are far more applicable to exactly what they are looking for, making the continuous play mentioned above all that more memorable and compelling.
• Cached Pages - By making all user-based calls come after the page loads via JavaScript, that means we can use extensive caching on most pages and modify the pages once the page has started loading on the user’s end.
• JavaScript and CSS Bundling - While previous versions of VEVO had this in a sense, there was often repeated JavaScript or CSS or multiple calls to different bundles on different pages. In addition, the system we used was hard to manage or tweak and couldn’t be debugged or adjusted on the fly. The new system combines all JavaScript and CSS files into two large bundles that are the same on every page, making it fast and simple, with an option to turn it off if debugging is needed and a switch to regenerate the CSS or JavaScript bundles on the fly.
• Facebook Integration - We were able to heavily leverage Facebook to get information about users of the site, including friends and music likes to greatly personalize the website.
• iTunes Scanning - We used a Java Applet to allow users to scan their iTunes library and create a playlist based on the artists they have in their library. This was one feature that really got some oohs and aahs and showed people some of the more unknown videos we have in our catalog.

Process Experiences and Lessons Learned

• Scope Creep - The bane of all projects, large and small is scope creep. While we did limit it in some ways during the project, pushing things back saying we could add or improve them post-beta, that wasn’t always the case. Especially when we were near the end of the project, the final 10% of work seemed to drag on and on with small, and large, additional changes.
• Time Management - While you always try to plan to have time to tweak features and eliminate bugs, the reality is that you can never plan enough time for that. Again, that last 10% usually takes the most work and there’s nothing like having more time to handle that and not needing to scramble.
• Chaos Versus Agile - While VEVO touts using an agile process, the beta version was given such a short deadline and so many things to accomplish and change that that process started to break down. Tasks were lost along the way or never assigned to developers or designers, so it wasn’t clear who was assigned what as well as what the status was on a given feature, design or bugfix.
• Running on Empty - Given that it was a big project with a small team, people were running at their top performance for quite some time. While this can be good for short times, doing it for two or three months discourages people and hurts motivation as well as quality of work due to overwork and general tiredness. In addition, the ideal of doing things fast tends to hurt the ideal of doing things right, so the final stages, often the most crucial, are filled with the most mistakes. Combine this with scope creep and you are left with a frustrated team in general.
• Beta Means Beta - While I appreciate perfect, often “done” is better. And there should be a criteria for “done.” This eliminates scope creep, gets things rolled out on time and encourages agile development. We aren’t releasing a magazine, newspaper or book – we can always add more features, fix more bugs or improve performance later and start getting user feedback and information sooner.

It was a fun and exciting, while stressful, project to be a part of and I’m looking forward to its reception in the coming days, weeks and months. I’m sure it will be mixed and that there will be both positive and negative reviews, but I’m proud of what the team has accomplished in the time we were given and I’m proud that we were able to change how video sites work and able to make an impact as the second largest video site in the United States.

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?