building block web – Stay N Alive

Category: building block web

The Next "Facebook Platform" for the Modern Web, and Why Twitter’s Running the Wrong Way

Posted on by jessestay

I’ve talked previously about “the web with no login button”, a vision of the Building Block Web that follows the user where they go, knowing who they are and adapting as they move.  With the advent of mobile, entire operating systems running on the browser, cloud-based personal information stores and APIs such as Kynetx to manage both user and application data for the user, we are so close to being where we want to be!  There’s one hurdle we have to jump before we get there though, and I’m concerned Twitter just ran the wrong direction with their new UI.  The hurdle we’ve got to get around is that of allowing a user’s social connections to also follow them wherever they go, uninhibited by any single corporation.  Not a single big player seems willing to take this step yet, but when it happens, I guarantee you’ll see a revolution at the scale of when Facebook Platform launched in 2007.  The first person to do it gets the opportunity to lead the pack, and hundreds of millions will follow.

I mentioned earlier on Twitter that something about Twitter’s new UI (which I’ve actually only seen screenshots and demos of since I’m not on their Press list) really bugged me but I couldn’t put my finger on it.  Perhaps it was hearing Ev emphasize “yet” when talking about CoTweet-like functionality. Perhaps it was hearing Jason Goldman talk about improving their “following” interface to something that I think could potentially threaten some of what I’m doing with my business.  Perhaps it’s the feature they just asked me to kill on SocialToo that I haven’t announced yet.  Perhaps it’s their lack of a solid roadmap like Facebook has to warn developers of what’s ahead and who will be replaced next.  As a developer, every step like this Twitter makes is certainly a threat to my business model and anyone else like me.  It’s definitely a token to their closed nature.  However I think it’s much bigger than that.

I think Alex Payne, of whom I just became a big fan after his recent post on his perceptions of the new UI (a must read), said it perfectly, “all communications media will inevitably be decentralized, and that all businesses who build walled gardens will eventually see them torn down.”  Now, I don’t think all walled gardens will die – Ev William’s own original startup, Blogger.com, remained closed in a time where sites like LiveJournal and WordPress were going completely open source and it was still bought by Google.  In those days, going open source and giving people the opportunity to own their own data stored on each blog was the equivalent of federating social connections would be today – instead of owning content people would now have the opportunity to own their own relationships and port those from site to site if they choose, or host the relationships themselves if they also choose (I’m kind of doing that at http://community.staynalive.com/jesse).  Blogger obviously survived and is now one of the largest blogging platforms on the planet.

Twitter’s new UI, while I’m sure it will increase page views for them and bring them lots of money, is too late for Twitter to do any sort of innovation in this space.  Facebook already did this, and they were called a “walled garden” as a result and are now trying to break out of this reputation as users were getting ready to revolt.  Maybe that’s what Twitter wants, and I’m sure it will make them a lot of money.  They may even gain a large segment of the masses.  Businesses will still flock and so will the money.  I’ve mentioned Twitter’s need to own the UI before, but I argue it’s now too late to be focusing on that.

Twitter could however, have an opportunity to create a new wild west – a new playing field if they choose, a new canvas.  If they do so they need to focus not on the UI, but on the platform and decentralizing it significantly.  Then new opportunities arise such as payments, new service models, search, ad platforms and more that can still make them profitable.  The difference is they’re now spanning the entire web instead of their own walled garden.

I think Facebook started to make moves in this direction as they released Facebook Connect last year, and then Graph API this year along with no restrictions, redacted term limits on storage, and a push further and further away from building on their own UI.  They introduced a new protocol in fact that enables websites to be indexed more properly and enables those websites to more easily bring Facebook connections into the experience.  Facebook is moving from the walled garden approach out into the open web.  Twitter, it seems, is moving in the complete opposite direction, which seems perplexing.

Even Facebook hasn’t hit the nail on the head yet – maybe they’ll make the first move at the next F8 conference.  The next revolution of the web will be when one of these players that currently owns your Social Graph completely federates, creates a standard for others to follow, and then other companies are forced to follow as a result, forcing all the others to rush to find what they’re good at which wasn’t owning your data or social connections.  Then at that point you will truly be allowed to bring your social connections with you wherever you go, allowing for a web with not only no login button, but one where your family and friends follow with you along the way.  That’s a really powerful concept!

Kevin Marks (who led the OpenSocial platform at Google) mentioned the irony in a tweet earlier today of installing the open source social network Diaspora as we were discussing Twitter’s very centralized real time streaming API and federated environments.  I think that Kevin may be part of the revolution and we just don’t know it yet.  If none of these players make a move, it will be the next open source project like WordPress, or LiveJournal did in the early 00’s that will emerge from the dust, gain traction, and the landscape will naturally adapt.  It has to happen – it’s going to happen, and the first big player to do it will lead the way. I’m excited to find out who makes that move and I’m already thinking of ways I can jump on that bandwagon as a developer.

Picture courtesy http://www.thesun.co.uk/sol/homepage/news/article571291.ece

Kynetx Introduces the Programmable Internet – the Language of the Building Block Web

Posted on by jessestay

Several months ago I talked about a concept I call the Building Block Web.  It’s the next evolution of platforms, with all different types of services able to communicate with each other and work together. Where Web 2.0 is “the Web as a platform”, the Building Block Web is “the Platform as the Platform.”  I talked about the MVC model of the Building Block Web, and how different elements represent different layers of that paradigm.  From Amazon Web Services, to Facebook Graph API, to Twitter API, to even Google App Engine and other cloud-based, API-focused architectures, we’re able to all include our biggest strengths in each others’ applications.  Today, Utah-based Kynetx released its own strength into the Building Block Web and essentially provided what I consider to be the first programming language of this new Platform.

Dr. Phil Windley (or as employees of the company endearingly call him, “Doc”), Kynetx’s CTO and co-founder, described the new “feature” of their event-based language KRL as “A Big, Programmable Event Loop in the Cloud”.  Windley, also a Computer Science Professor at BYU, has taken his deep understanding of language theory and created a new language intended to basically allow all these different building blocks to talk to each other and provide a more relevant experience for users on the web.  He calls it a Purpose-driven ecosystem, one where users go to the web with specific purpose in mind, and the web adapts to help them achieve that purpose.

The new feature (it may as well be called a new revolution, as it is much more than a feature – it could completely change the breadth of what Kynetx can accomplish for companies, developers, and users) enables developers to basically create their own “endpoints”.  These endpoints can be anywhere from Google Calendar, to my own SocialToo API, to your Sprinkler system.  When developers create endpoints, they are essentially, automatically providing an API that developers using Kynetx’ cloud-based platform can tie into and use in their own applications.  So, let’s say for instance I created an endpoint for my sprinkler system (since that’s an example Phil used), which is being installed today.  I could enable you to turn on my back sprinklers, turn on my front sprinklers, and turn them off again.  I could then tell Kynetx’s platform how to do this.

Once Kynetx knows how to turn on and off my sprinklers, I could open that up to other developers using the Kynetx platform, and now someone could easily build a plugin that, whenever you visit Twitter.com and it sees the word “sprinkler” in your stream, it turns on my sprinklers, getting me all wet.  Another endpoint Kynetx itself has provided for developers is one that interacts with Google Calendar.  If you wanted, you could make Kynetx’s endpoint for Google Calendar talk with your endpoint for your sprinkler system, enabling you to schedule your sprinkler system in Google Calendar and have it automatically turn on and off your sprinklers at home based on your Google Calendar schedule.

Or, let’s say you’re Target.com and you want to make your products available to other apps on the Kynetx platform.  If you create a Target.com endpoint, other developers can now tie into it, bringing the option of Target.com into their own applications on the Kynetx platform so your products will now also appear in their apps.  This portable, 2-way, programmable API in the cloud, enables both programmers providing content, and programmers receiving content, to meet in the middle, providing a completely contextual experience for the user.  Basically, developers can both create the API, and consume the API all in the cloud.  The concept is very powerful!

With Kynetx, soon you’ll be able to use one language, one API, to both provide  and consume the services you are providing to your users.  Add a little flag to your app, and soon users will be getting just the experience they desire, with little to do on their part.  Or, perhaps Kynetx will enable users to do this for themselves, providing users the option on Kynetx.com to specify the apps they want to enable as they surf the web.  The possibilities are endless.  Kynetx is making API development really simple with their new API to the Internet!

Have an idea for the Kynetx platform?   What would you create with such an opportunity?

What is Your Core?

Posted on by jessestay

In a typical Lego set, there is a core set of building blocks that make up the core of the object you are building.  My son just got a new Star Wars Tie fighter Lego set.  It relies on a few common objects, such as little flat Legos you might see in other sets, but overall, what you would see in this set would be much different than the core of Legos you would see in, say, a set to build a House, or even my 2 year old’s set of Duplos which builds just very simple objects geared towards people his age.  For a house set you will see more block-like structures.  For a Robot you may see more objects with holes in them, to accommodate for axles and gears.  For a plane you may see more flat structures for things like wings and a skinnier body.  In the end, you’re trying to build one core, unique object that is different than any of the other objects around it.

Too often I think entrepreneurs struggle to find out what their core is.  Social Networks should be ubiquitous.  Real time should be ubiquitous.  Open Standards should be ubiquitous. Search should be ubiquitous.  There are already companies out there that have these things as their core.  They’re the experts.  I think entrepreneurs and developers often get stuck (myself included) in this rut of fixing things the experts are already good at, rather than finding something new and innovative they can take ownership at.

There’s already a T-Shirt out there that says “Twitter destroyed my market segment, and all I got was this lousy T-shirt”.  Well, the reason that occurs is because developers are building core blocks that are already part of the Twitter core.  They are building something, the cockpit, the engine, the wheels, that were already destined to be replaced in the original scheme of things.  We developers like to see, and fix, the big picture – I know because I’m in the same boat (or ship?).  However, I think we need to be thinking bigger.  We need to be thinking about what our core is, not what’s missing from others’ cores.

When we talk about “filling holes”, I think the best position to be in is where others are filling the holes that you create.  You own the core that includes the missing parts.  The propellers of Twitter should be added to your core to make your airplane fly.  The Jet Engines of Facebook should be added to your core project to push it forward.  The wheels of Google should be added to your core project to get it off the ground.  But in the end, you still own the airplane.  You have control of the core.  All the other “cores” get to contribute back to your core to make it better.  Heck, you can even take pieces of your core and add it into the other existing cores to complement their space too – the power is you still own your space that way.

As you build new creations, think to yourself, am I contributing to others’ cores, or am I building the core that other cores can add their parts to and make better?  No one should be building another “social network” project.  No one should be building another “search engine” project.  The focus should be on the innovative creations we create, and how other “social networks” and “search engines” can make us better.  It should not be the other way around.

This is the “core” success story of the Building Block Web.  How are you letting Twitter or Facebook or Google make your core project better?

The Framework of the Building Block Web – An MVC Perspective

Posted on by jessestay

lego houseRecently I talked about the new web being that of “building blocks”, or “Lego bricks” setting the foundations for each application or website which encompasses the new internet.  Applications that embrace this new architecture will both embrace the strengths of other applications and technologies through third-party APIs, as well as provide their own in order to share their own strengths in the building block web.  The idea of the Building Block Web being that of empowering each app that uses your technology to now owning the strengths which you, the developer or entrepreneur or business can add to the puzzle.  I’d like to suggest an overall framework for how Building Block Web apps should be built.  The analogy to me makes sense, and builds off of traditional MVC (Model/View/Controller) models.

Building Block Web – the Model

Let’s talk Model.  The Model component of a traditional MVC framework is intended to provide the structure for abstract data access in a sense that your app never actually sees the underlying data architecture, but rather accesses it through a higher-level layer that can provide inheritance and simple methods for getting at that data.  In the Building Block Web we’re seeing this in the form of Cloud data stores and APIs.

Look at Amazon, for instance.  Amazon provides SimpleDB for abstract data access and storage into the cloud and easy retrieval of serialized information.  Amazon has even provided API methods around processing this information with Hadoop and Mapreduce data processing and crunching (although that could arguably be part of the Controller).  Amazon has provided S3 as a simple file storage and retrieval API.

Other traditional services are also providing their own data store APIs.  For instance, Facebook itself has its own Data store API allowing simple storage of meta information about users and things in its database.  The stream itself allows storage of meta-data with each stream item posted via the API, making the need to build traditional local architecture around social workflows less necessary for the developer.  A simple FQL call to Facebook will pull most of the information necessary from the service.

It should be noted that Google also provides similar services.  The spreadsheet API or even Gmail storage API can be used as simple data storage mechanisms.  Or, for more complex data storage and retrieval, AppEngine provides BigTable for that access, along with an entire API centered around storing, compiling, running code, and retrieving data with that code.  The entire AppEngine API itself is somewhat a Model-based Building Block architecture.

It’s interesting to see people try to compare just the Model component of the Building Block web architecture as Web 3.0.  It’s not – it’s only one component.

Building Block Web – the View

For a Building Block Web app or website to embrace all the components of the Building Block Web, it should also embrace a view of some sort.  Remember a View is code that the user interacts with, usually via a browser, and in the Building Block Web participants must provide components (or “blocks”) that sit at the user level reducing the work a developer needs to do to integrate the blocks into their own environment.  Facebook does this very well with its own internal Applications developers can write, as well as Facebook Connect, enabling developers to integrate  the Facebook environment in their own websites and applications outside of Facebook.

Facebook has provided XFBML and an entire Javascript Client library to enable, at the View, for developers to pull pieces of the Facebook architecture into their own websites and apps.  In addition, they have provided a way for developers to host apps right in the Facebook environment itself, giving an even more native approach to Building Block Web development.  Even the Authorization process is taken care of through the View.  Facebook provides simple HTML and Javascript code (or even an XFBML tag if you want to simplify it even further), and in just a few steps (or even copying and pasting through a Wizard), a popup login box will show up, right on your site, with no backend code necessary to log in the user. Facebook handles the authorization process all for you, giving a unique way to use a user’s Facebook credentials for login and authorization into using Facebook’s pieces of the Building Block Web.

Google does similar with OpenSocial.  Through simple Javascript, any OpenSocial-supported container can run OpenSocial apps.  While not quite as simple as Facebook to integrate into your own environment (due to the decentralization of it all, not a bad point for Google), across multiple environments you can write one simple app that uses Google’s standards to share that app, via simple View (aka Browser-side) code one can add to their environment of choice.  Add to that the ability to embed Waves into any environment, and the simplicity of Friend Connect for finding and communicating amongst users on a 3rd-party website, Google contributes to the View of the Building Block web as well.

It should be noted that Twitter has no View to contribute, and I think if they’re trying to compete against Google or Facebook in the new web they may suffer until they do so.

Building Block Web – the Controller

The Controller is the component of an application that controls the entire application.  It makes the calls to the Model, releases the View code to the browser, and is pretty much the brains of the entire application.  Twitter is mostly a Controller-based Building Block web brick.  When you write a Twitter app, you are writing mostly server-side code that accesses the Twitter API through your server.  No View bricks are provided, and there is no Model API at the moment.  Everything is handled at the application level, making the Twitter API a weak set of bricks in this new Web model.

Facebook also provides a Controller set of bricks through its own REST APIs.  As an application developers I can access the API fully on my own backend and the user never sees that part of the process.  I can even make calls on behalf of the user to do things like send notifications or process data (with the user’s previously given permission at the View level).  I can send data and retrieve data from the Model bricks of the Facebook building blocks.

Google also provides a REST layer to its OpenSocial protocols.  MySpace has implemented it, as has Orkut (I believe).  Developers can do similar things with the MySpace and Orkut APIs that they do Facebook, doing all the work behind the scenes.  The Application layer is critical at handling sensitive data that the user may not have access to.  It is a critical component of the Building Block Web.

Comparison of Various Building Block Web Bricks

I’m sure exceptions could be made for all of this, especially considering the entire idea behind the Building Block Web is that you should be able to mix and match.  For instance, I could technically take an Amazon SimpleDB brick and mix it with an iGoogle brick to give full MVC functionality.  However, this table summarizes the capabilities of various players in the space – note that the space is also much larger than this.  These are only some of the larger players:

Model

View

Controller

Facebook

TRUE

TRUE

TRUE

iGoogle

FALSE

TRUE

TRUE

Twitter

FALSE

FALSE

TRUE

Flickr

FALSE

FALSE

TRUE

MySpace

TRUE

TRUE

TRUE

Orkut

FALSE

TRUE

TRUE

AppEngine

TRUE

FALSE

TRUE

Amazon AWS

TRUE

FALSE

TRUE

Wave

FALSE

TRUE

TRUE

myYahoo

TRUE

TRUE

TRUE

If you’re building for the Building Block Web, you will have the most success finding ways to integrate all three elements of the MVC Building Block Framework.  The idea is to empower users and other businesses in as many ways as possible to fully utilize the strengths you can provide.  If you share graphics (like Flickr or SmugMug for instance), provide not only a REST API to read and post graphics, but a store API for storing meta data about those graphics, as well as a view for enabling developers to create their own wrappers around the graphics. (Note that SmugMug does this, in all 3 layers)

The Building Block Web is about empowering developers and businesses to use a new platform – a platform of platforms, to create, using each brick’s own strengths, their own applications.  Developers and business owners can then take their own strengths and add to that, enabling more bricks to the picture.  My hope is more apps can start to embrace the entire Building Block Web, and not just pieces of it.