Year over year, we saw revenue grow by 1,348.93% from 2010. This came from both our expanding role in the development of FCC.gov and MyFCC, but also work with new clients.

In 2011 we developed a product and service strategy focused on API publishing and consumption. This strategy is tied together by the API Platform Concept, an approach to building the next generation of applications on the web. We spent about 30% of our time on R&D projects that implement this strategy, including the Drupal Content API Module, and Cumula, our own framework for API Web Platform Development.

In order to support our growth and new clients, we quadrupled in size from 2 to 8 employees. When Seabourne began, we offered PHP and Rails development services. At the end of 2011, we are able to offer the full spectrum of services necessary for developing great online experiences. Our services now include system architecture planning, UX/UI design and branding, front-end and back-end development, mobile app development, and project management. This enables us to tackle entire projects from start to finish, and we focused and improved our internal workflows to ensure that our clients see a huge benefit from our ability to deliver complete products.

In order to support our growing team, we moved into a great new office in Dupont Circle. We also gathered as a team 3 times over the year: twice in DC and once in Phoenix for multi-day strategy and planning sessions. Our ability to work together as a cohesive team has never been stronger, despite being in multiple cities around the country.

Looking forward, 2012 is going to be huge. We have an organization that is humming, and a series of products, services and ideas that we are committed to building. We continue to grow, and are always looking for new challenges to which we can bring our unique talents.

Lastly, we want to give a big thanks to all our friends, partners, clients and families for the help and support over the last year. Seabourne certainly would not be the company it is today without you.

Does that sound like you? If so, you can apply by sending the following to jobs@seabourneinc.com:

* Cover letter
* Resume
* Portfolio / Website
* Code examples

We can't wait to hear from you!

Solving A Common Problem
MyFCC seeks to solve a common problem: many website users who know exactly what they want, but can't easily access that content. By providing a clean interface that enables the user to customize blocks of content, called widgets, they can create customized pages that are a single point of access for anything of interest published by the FCC. Widgets are collected on a user's dashboard, allowing them to create fully customized pages containing multiples streams of information. The initial set of widgets include a Topic Watcher, Latest News, the FCC Twitter feed, and a version of the FCC Daily Digest. Lots of content can be intimidating for users, but the Dashboard and Widget approach creates a manageable experience where users control how the information is displayed.

An API Approach
MyFCC utilizes a content API published by FCC.gov. Because we were able to leverage the FCC.gov content through the API, the time and cost to develop MyFCC were radically lower than alternative approaches. This is a great example of how a Web API Platform architecture can help to reduce development cost while supporting cutting edge applications.

Social Sharing Tools
MyFCC includes a series of innovative social sharing tools designed to help make FCC content accessible to a wider audience. Each widget inclues an embed code, allowing users to take a widget and embed it natively into another website. Each user dashboard also includes a 'Share' button that generates a unique URL they can send to others. When clicked, the link opens up an exact copy of the dashboard. This is a great tool for creating a dashboard that monitors a series of topics for specific content coming from the FCC.

MyFCC is a new approach to open government — making the content easily available to everyone, everywhere via APIs. Using the Content APIs, the public can create their own tools like MyFCC. An exciting time for technology and government!

By working with content APIs, designers (who code, you code right?) can deliver unique user experiences to a range of devices without the "hacking" that is involved when using media queries. By hacking, I mean all the showing and hiding of content depending on the device, which often results in loading a ton of data that is useless to the viewer (images, background images, specific javascript, etc). A unique, tailored experience is a better experience for your customer.

Content first

We design for content. Content that is (hopefully) accessible across all devices. So let me ask you: does your design achieve the same goals when viewed on a mobile phone? Does your information architecture solve the problems for a customer on the go? Are you loading unnecessary content and toggling it visible or hidden depending on the device? No matter the answer, I hope to give you some things to think about.

When I switched from table-based markup to semantic markup and CSS (thanks to one Jeffrey Zeldman) I convinced myself that for the rest of my life I would write thought-out, semantic markup and never have to worry about it down the road. We would adjust our layouts later in CSS, right? Write once, view everywhere. This method worked great for a long time. Now that we actually have multiple devices to deliver content to we’ve found ourselves in a rut. My image-heavy homepage doesn't work in a mobile browser. My text-heavy homepage is pointless in a mobile browser. My navigation with all those dropdowns is a pain to use in a mobile browser.

Now, of course you can change the presentation of all this information using media queries, but do you stop to think about all the data you’re asking your viewers to download when you may be only presenting 80% of that to them? Let’s take a pharmacy like CVS (not Walgreens, I’m from New England and have pride). A pharmacy's mobile site should be very different from the desktop counterpart. As a customer you probably expect to see the closest location at the top of the screen with a phone number, and the hours they're open. Then maybe you’d want a list of action items such as refilling a prescription, or checking if your photos are ready. This is all important (but not a lot of) information. Would you load the entire cvs.com and rearrange it using media queries? You could, but you'd be forcing the user to download more data than necessary, resulting in slower load times and a less focused design.

A different solution

There are probably a hundred different ways organizations solve this problem; some develop entirely separate mobile sites, some go the media query route, some decide to deliver the same desktop experience and that’s where they stop. Using content APIs, you can build both mobile and desktop applications/websites using the same content and underlying system, but serve different markup that's tailored to each browsing experience. Now, I am not going to dive into what a content API is as my colleagues can do that much better. I am going to tell you how we approach design and front-end development.

Think about where else your content is going to live. Are you going to have a native iOS app? Android? How about on the Apple TV or Roku? Will people want to view it on their mobile phone and tablet? The answer to all these questions is without a doubt, yes.

With content APIs (and any API in general) we can quickly develop multiple applications off of the same data source. We can design and develop a big, complex application for a pharmacy or bank for the desktop, and then, with access to the same exact data, build a simple, stripped down version for mobile. We can do this using any technology we want, and usually with way less development time.

On the frontend it's an entirely new ballgame. New libraries are popping up constantly focusing on client-side rendering (here's a great related article), backed by APIs. A great tool we've been using is Backbone.js. We believe it helps us create the best experience possible for not only mobile customers, but also for the desktop. Tools like Backbone fit into the approach to software design that I find most efficient: serve content and layout separately, serve layout based on the device (or user agent), do all of this on client side.

I've been thinking a lot about the perfect CMS (who hasn't?). As a front-end developer I require one thing; I want direct access to the objects I will be manipulating and displaying. I don't want to ask the backend developer for help (which is a constant in Drupal theming), I don't want markup being served out of the CMS (Drupal), and I don't want to assume the content being served up is for a web browser. Imagine drawing out your models in a UML diagram, hitting 'Save', and having all of that data available to you as JSON. This allows simultaneous development of mobile apps, desktop apps, websites, and mobile sites that are all rendering that content on the client side. This means less back-end development time. Front-end developers and designers that have direct access to the content they need can build a multitude of unique user experiences quick and easy. This is also known as profit.

Think about where your content is going to live. Are you going to have a native iOS app? Android? How about on the Apple TV or Roku? Will people want to view it on their mobile phone and tablet? The answer to all these questions is without a doubt, yes. It’s time to think about the most efficient way to bring a unique experience to each device without being limited by the devices themselves. By implementing content APIs into your project you give your team (or client) the tool they need to rapidly craft custom experiences for each device, resulting in true responsive design.

DCWeek Presentation Slides

Putting the Response in Responsive Design

Existing methods of supporting mobile design have significant limitations. The combination of Drupal and content APIs gives designers a strong alternative set of tools to deliver content to multiple devices. Jay will talk about these new technologies and how decoupling the front end creates responsive user experiences.

Building Flexible Platforms with Drupal and APIs

Drupal's powerful features have made it the standard in open-source content management systems, but Drupal developers know there are still several drawbacks in the platform's architecture. Using content APIs with Drupal creates an architecture that directly addresses some of these issues. Mike will take attendees through the approach of an API-based architecture, with real-life examples such as FCC.gov.

Introducing the Content API Module: Instant API publishing with Drupal 6 and 7

You know what content APIs are, you understand the advantages to the approach, and you want in on it. Come join Dirk as he takes the group through how to setup and configure the Content API module, including how to include (and exclude) the exact information you want to publish.

So here are some ways to think about the problems data normalization is trying to solve. First, you don’t have to store information the same way across all your systems. Tools and best practices have evolved to the point where developers are comfortable working with structured data that may not match their own data base tables.

Instead of focusing on normalization, spend time on transformation. It’s OK that each component might have a different routine for transforming incoming data. Unless you are working in very rigid structured data (think scientific information) the time it will take you to parse and transform incoming information is negligible. Instead, you can spend your time figuring out what to do with the information.

Second, information will change, and you should plan on being agile. Create your transformation routines so that they can be changed when needed. Create your system to be error tolerant, so that when incoming information is different than what you expect, everything can keep on humming until you update your routines. As other systems evolve, the structure of the information will change too. Expect and plan for it, and change will be manageable.

In fact, APIs are all around us. You probably already spend significant time interacting with APIs and don't even realize it. Plus, it's easy to understand – an API is little more than a template.

What is an API?

As humans, we consume structured information every day in a variety of situations:

• Flipping through channel listings
• Preparing a recipe
• Reviewing bus schedules
• Checking last night's box scores

For each of these items, because the information is structured in a certain way, we as humans know what to expect. The channel listings contain the name, time and maybe a short description of the program. Recipes contain ingredients, measurements and instructions. Bus schedules tell you the route number, stops and times. You've even created structured data to be consumed by someone else when you fill out a Girl Scout cookie order form.

The online services you use take advantage of structured information. Your iPhone consumes Facebook feeds in a manner similar to your consuming of channel listings. When you open Facebook on your phone, a lot of information streams from the Facebook server. Your phone discerns what's a status update, check-in or comment because, like the channel listings, the information is structured with tags followed by content. This sort of standardized structure allows different web applications to talk to each other.

So, APIs provide structure to information so computers can use and understand that information, the same way you use and understand a recipe or bus schedule.

What is a content API? How is that different?

Traditionally, we've used APIs to transfer data between applications (such as those status updates, box scores and recipes) but not full-fledged content.

To exchange content between applications, we need to transfer not only the data but an understanding of the meaning of the data, inferring the relationships between the data (something humans do with great ease; it’s a tremendously harder task for computers). Those relationships between the data to be transferred can be described as the taxonomy of content. Stay with me here…

Taxonomies, similar to categories, are ways of classifying and understanding the content, kind of the like the Dewey Decimal System on steroids. Wikipedia has a really nice, simple example:

...for example, "car" might appear with both parents "vehicle" and "steel mechanisms"; technically, this merely means that 'car' is a part of several different taxonomies. A taxonomy might also be a simple organization of kinds of things into groups, or even an alphabetical list.

The inclusion of taxonomies with the content ("vehicle," "steel mechanisms") give it meaning and far greater detail than what we've been able to work with in the past. This structure allows us to use applications to draw much more powerful relationships between content than was ever possible.

And that's what makes a content API valuable: it contains not only tags that tell a computer application where the title, main content and subheads are, but also information that gives meaning and context to the data in the content.

Why are content APIs so important? Why the emerging focus on them?

Another frequent question is, "But if I can understand the content, why do I care if the computer can understand?" There's one particular explanation that sums it up nicely: information discovery.

Because content APIs enable developers to expose greater amounts of information to users, you can find the content you're looking for much more quickly.

And you can organize this mass of content in much more powerful and flexible ways -- since the application now realizes there are taxonomies associated with the content it's downloading. The application can sort, package and serve in new and different ways.

Content, when combined with other content, becomes dramatically more powerful. Take Google Maps. Google Maps has integrated the Wikipedia API, so when you look up a place and select "Wikipedia" from the menu, you get the information Wikipedia has alongside the Maps' information. There are millions of these types of applications and reasons for combining content APIs.

As more and more content providers use this concept, content APIs will become a more powerful part of your daily life. Your computer, smart phone, iPad, and every other device you use to access the Internet will enable you to consume more and more dynamic information in the coming years.

We're just on the edge of learning how to leverage application-aided understanding of the data that's available, and the future is very exciting.

Who is using content APIs?

Content APIs are increasingly being created and refined by the largest and highest profile content creators on the web. To learn more about specific applications of the concept, follow these links:

• The New York Times Developer Network
• guardian.co.uk Open Platform
• NPR.org Tech Center
• The Lonely Planet Content API 
• If This, Then That (This site will allow you to tie different services, such as Facebook and Twitter, together using APIs.)

Content publishers, whether news organizations or government agencies, want to be positioned to provide users an online experience regardless of device or media. Using traditional online publishing systems is going to be expensive, inflexible and expensive to develop.

A Platform Approach

But there is another way: content owners can plan to use a web platform, rather than websites. Web platforms easily scale to support multiple devices and multiple data sources, ensuring that an organizations online presence can target multiple audiences with the latest technology.

To be clear, the word ‘platform’ in this case doesn’t mean a large proprietary system. Rather, we think of a platform as a loosely coupled set of technologies that communicate via open API standards. Think of it as a design approach you can use with any existing set of applications, rather than a product.

The platform approach to designing systems has several advantages:

• Leverage existing systems and applications: Your organization has likely invested a lot of time and money in your existing infrastructure. Using open standards means that you can continue to leverage your existing systems and tools, assuming they work for you. The power of the platform approach is in tying disparate applications together into a coherent system.
• Extensible: As your organization grows and you will add new technologies, databases or applications. With a platform based on open API standards and with everything loosely coupled, integrating new systems into the platform is simple.
• Easy for Developers: The use of open standards means that you can use the best tool for the job to develop user-facing applications. Rather than being tied to a particular vender’s technology stack, you can use whichever tool is right for your users, and still access the content.

Components of an API Web Publishing Platform

Any API web publishing platform has three main components: a data source, a content management system, and a user interface. In an API-based platform, there can be one or many of each component. The glue that holds these different components together are the APIs based on open standards. Which API doesn’t particularly matter, as long as its an open technology that can be implemented across vendor stacks.

• Data Source: Data sources are the repositories of content. Traditionally, these have been large databases housed in the back office of an organization, accessible only via a direct connection. Accessing these data via an API, without requiring the data to be moved from the legacy store to a new physical structure will save substantial money and time. Going forward, data sources are just as likely to be APIs as they are discrete databases. In the platform approach, all data sources, no matter what the storage solution, are exposed and consumed as APIs.
• Content Management System: The primary role of the content management system is to organize content. Content is only useful when users can find it, and the content management system builds out a layer of relationships and organization between content that makes it discoverable.
• User Interface: The user interface is the part of the platform that presents the content from the data sources, and exposes the organization of the content management system to users. The user interface doesn’t have to be on the same system as the content management system. In fact, in holding with the goal of using the right tool for the job, the user interface should be built in whatever language will best suit your users.

More on APIs

What makes the platform approach work, the glue that holds everything together, are Open APIs. Open APIs are basically any mechanism for transferring machine readable information that anyone can implement. The last part is really the key to the platform approach. To ensure that your current and future systems can interoperate, they need to be able to talk to each other. A vendor specific transport protocol means that you are locked into a specific set of technologies and applications, and this drives up costs.

Opportunities

Organizations seeking to expose content in established databases, as well as those who are establishing new data stores may want to consider the API Platform approach. It can minimize expensive, delayed projects focused on building monolithic systems and frees the task of delivering of content from proprietary methods. It makes exposing legacy data that is currently unavailable on the web easy and simple to do.

Moreover, developers utilizing an API Platform on both publishing and delivery ends will enjoy significant benefits when combining and processing content. The really exciting opportunities come from have a flexible architecture that supports innovation by embracing flexibility and easy access to information.

VanRoekel is the former managing director at FCC who oversaw the new FCC website, and was just named the US Fed CIO.

The Content API module is a drop-in solution that publishes Drupal content as web APIs. The module includes a full featured administration interface for choosing which content types and fields to publish. Built on top of the Services module, the module provides all you need to publish web APIs without having to do any programming, even as your site structure and content changes over time.

Publishing your Drupal content as web APIs makes it accessible to any application or platform, while allowing you to continue leveraging Drupal’s strengths as a great Content Management System. Using Drupal and the Content API module, you can create a publishing platform that includes multiple websites, applications and mobile apps, all using Drupal as a single source of content.

We’re obviously big fans of serving content as APIs, so this is an exciting release. With many other government websites running Drupal, its an opportunity to get a lot of public domain content available immediately as APIs.