Maybe I missed it, I’m not really sure, but I’m definitely going to look for some references to it. If they weren’t, then Waze missed a great opportunity, though it’s better late than never.

It was a great Viddy among many awesome Space Shuttle Endeavor Viddys today. These are the moments Viddy was made for and should be recording. Simply astounding.

I certainly agree with his point, but I think there’s a far bigger point here. Diego says Silicon Valley is not the same as the Internet, but then there’s also the point that Silicon Valley isn’t the only start up game in town (granted, I’m saying that as the lead web developer at Viddy on Silicon Beach, but hey).

I know I fall into the trap all the time that start-ups have to be some web app or mobile app or a combination or cross-platform, what-have-you. In reality, there are so many more opportunities for start-ups than that. The web and mobile space is just a much easier place for entry – the cost is so much lower, the opportunity cost is the highest portion of this.

Many other areas: automotive, healthcare, insurance, finance, are all ripe with inefficiencies, poor experiences, wastes or gluttons that there are plenty of places a start-up could come in and really disrupt what’s around them. Personally, I’m hoping against hope that Simple might be that for banking, granted, it’s all of those things I mentioned: mobile, website, etc, but it has an extreme potential to disrupt an industry that has gotten a whole lot of flak and is known for a terrible customer experience.

It might be harder to break into other areas, but it being harder could get you that much more in the end.

I tweeted to TIME with one of their videos and I was glad to see it came up.

And here’s TIME’s viddy from this morning:

Oh, and we moved to YouTube-style iframe embed code. So, without further ado, I present the happiest puppy in the world.

The weather has been incredible and though I haven’t had the time to get out and about much, what I’ve seen of the area is pretty awesome. How much better can you get than a camera phone picture below I took on a Saturday evening without much thought about it at all.

I’m looking forward to seeing what we can do with Viddy and where we can take it as a start up and as a company.

The first thing to realize is that Facebook’s OG is built around a Facebook user doing an action to an object. When you really look at it, someone liking a wepage using Facebook’s Like Button, this is just a pre-built way of doing this.

Many of VEVO’s actions revolved around a user watching a music video. Similarly, they could create a playlist. The first step in all of this is adding the required Open Graph metadata. You’ll want to add this to any and all pages (which will then be considered Open Graph objects) to have the most accurate and compelling OG metadata as possible.

<meta property="og:title" content="[A very short description
  of the page that appears as the title on Facebook and can be
  the same as the <title> tag]" />
<meta property="og:type" content="[What the object is that the
  page represents (movie, article, person, product)]" />
<meta property="og:url" content="[The url of the page, note
  that this should match the canonical url on the page as
  well]" />
<meta property="og:image" content="[The url of the thumbnail
  you want people to see on Facebook, can be more than
  one]" />
<meta property="og:description" content="[Something to tell
  you about the page, shows in the preview text on
  Facebook]" />

As a rule, the required properties that the Facebook linter throws an error for are:

• Title
• Type
• Url

Though, in reality, to have a high click-through rate (you can see your application’s at https://developers.facebook.com/apps/[YourFacebookApplicationId]/insights), you’ll likely want to have all of these filled out with accurate and compelling information about the page.

Now that we’ve gone over creating a basic OG object, you can add additional properties to objects as well. You can create and add any properties you want to this OG object – this comes into play later with actions and relating objects to one another. When you’re editing your object in Facebook’s admin (https://developers.facebook.com/apps/[YourFacebookApplicationId]/opengraph), you can add a custom property. Then you’ll add them in addition to the metadata above like so:

<meta
  property="[YourApplicationsNamespace]:[YourCustomProperty]"
  content="[Whatever content that might be appropriate
  here]" />
<meta
  property="[YourApplicationsNamespace]:[YourCustomProperty2]"
  content="[More content appropriate to this
  property]" />

The next issue we want to deal with are actions. In this case, you’ll want to call to Facebook using FB.api (we’ll be using the Facebook JavaScript SDK directly, though you can also make the calls directly. If we wanted to record a video watch, we would call:

FB.api('/me/video.watch', 'post',
  { video: '[UrlOfVideoOGObject]' });

This will record an action on a user’s timeline. You can also create your own custom actions and once you’ve done that in the Facebook Developers app admin area, you’d call the JavaScript API using your custom action combined with the action’s name. It would look something like this:

FB.api('/me/[YourApplicationsNamespace]:[YourCustomAction]',
  'post', { [YourObject]: '[UrlOfYourOGObject]' });

Note that these custom actions must also be listed in that object’s page’s metadata as a custom property above for Facebook to respect the action call.

Finally, in your application you can have that content attribute point to another object (ie page on your site) to relate them. So, if you have an application with namespace AwesomeApps where Developers can create a variety of Applications, where both a Developer and an Application are objects and an Application has the ability to be created, you’d have OG metadata like so:

Developer:

<meta property="og:title" content="Brian Manning" />
<meta property="og:type" content="profile" />
<meta property="og:url" content="http://brimanning.com" />
<meta property="og:image"
  content="http://brimanning.com/img/bm.jpg" />
<meta property="og:description" content="Feel free to find
  out more about me, Brian 'Bri' Manning. I'm a web
  developer." />
<meta property="AwesomeApps:created"
  content="http://www.vevo.com" />
<meta property="AwesomeApps:primary_focus"
  content="Web Development" />

Application:

<meta property="og:title" content="VEVO" />
<meta property="og:type" content="application" />
<meta property="og:url" content="http://vevo.com" />
<meta property="og:image"
  content="http://www.vevo.com/a/img/logo-vevo.png" />
<meta property="og:description" content="See. Music. Play." />

JavaScript API Code:

FB.api('/me/AwesomeApps:created',
  'post', { application: 'http://www.vevo.com' });

I had to come up with a system to make sure I “got around” to the less fun things.

My last job introduced me to the free bug/task tracking software package called Mantis. I still use that for a lot of collaborative things I do with other people since I have my own instance installed and can share projects among different people. The other tool I use for less software-oriented or detailed tasks is Wunderlist. That’s something I use for remembering to mail my rent check or something similar and I’m a big fan because I have the app on my work computer, home computer and my phone, so I can keep track of things very easily.

Say I’m in a meeting or out with friends and have an idea or want to remember things, I used to carry notecards around, but I often lost them or would forget them. I don’t forget my phone, so I can just enter it there, at least as a reminder to add to Mantis, or take care of when I get around to it. With so many things flying around between work, independent projects, family, friends, the Village Lions and my hero dog Rugby, there’s a lot to remember, so I’m still working on the best system, but this is the one I have so far.

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.