Content as Navigation Steering the Course

Picking up on the last posting, what exactly is content as navigation? To me it’s something we’re already seeing on sites like Amazon, but as more services open up that offer content streams and feeds, we need to start to think of ways to use this content. It’s not enough to simply get an RSS feed, there needs to be categorization and linkages within the content. RSS addresses categorizing by having the “category” tag. What’s missing is the related content.

As the web evolves through web 2.0 which currently seems to be defined as social media and moving some elements with javascript on a page and shiny icons.  What web 2.0 was really defined as was web services or the internet as a platform.   However that platform is only as usable as the content provided.  It’s not enough to simply say here is content; there needs to be some sort of connotation to it.

As the internet evolves content will only continue to expand.  I suspect there must be an algorithm to capture this rate of expansion and I would not be surprised if it correlated closely to Moore’s law.  As this content expands we will want ways to use this content on different “platforms” I put that in quotation marks because it’s rather vaguely defined right now.

I think the platform is only as good as the content.  The first level of the platform is the content. The second layer to me would be the delivery mechanism and the third layer would be the interface.  Each of these layers needs to have elements defined, I want to look at the first layer right now.

Embedding navigation

If web sites or more accurately content syndicators want to be useful they will need to also include some sort of embedded navigation, this embedded navigation should include a few elements. These elements need to be:

  1. Related content within the current feed.
  2. Related content not in the current feed but available from the feed provider.
  3. Related content not in the current feed but available from another feed at a different provider.

I think elements one and two are not much to ask for from content providers.  Element three will most likely need a third party to intervene, a sort of Google for application feeds. Something that can be configured and controlled to automate the searching of feeds specifically and provide to the platform developer a way to refine the related content.  This middle-ware also needs to be something you can trust in almost how we trust Google will serve us the right information on the first page.  This content middle-ware needs to provide easy on the fly access to this content, this would be part of the second layer of the platform the “delivery mechanism”.

If a system like this can also spring to life it will allow the smaller sites to appear as larger sites, and help cater information to their customers. It will also help the larger sites open up new streams of revenue. Off the top of my head I can see content providers offering ad sponsored content, and paid subscriptions. Something like the Associated Press.  Something that allows content sources to come together to syndicate information out.  Further if you are a company that sells product through partners then you MUST have a feed for that partner that is easy for them to implement and understand.  Something that provides what your product is, the product specs, demos, white papers, and any other sets of information you have that may relate to it. Think about it, if you are the company creating the product who is going to know the details on it the best?  It is your duty as a company to provide an easy way to export content to your channels and partners to make it easier for them to sell your products, should you want to remain profitable in the online market.   Amazon on its product spec pages allow for blog posting and images to be uploaded by the publishers and owners of the products, the more information provided to Amazon the more likely someone is to understand your product and decide if it is right for them.

You Can’t Manage it All by Hand.

This system will have to come into place sooner rather than later; as I stated content is growing at such a fast rate that it will not be possible to manage it all manually. Businesses that sell other companies products will need to rely on those companies to provide the data as retail moves online and catalogs can become infinite with ship-on-order becoming the norm instead of sitting on tons of inventory.  The manufactures will have to start to provide product specs to their outlets in ways that not only provide product specs but related supporting content (content that I referred to as psychological triggers) that identify you are looking at the correct product, or a set of related products from that manufacture to ensure that recommend products are not those of competitors. The web will not just be about displaying your content but about making it easy to pick up that content instantly with little work to integrate it into other sites on demand. RSS is the first step of this, and its use right now is limited mostly to news updates.

As content starts to fall away from the source and into other realms of the web 2.0 platform there will need to be ways to link it all back in and together should we want to practice macro informational architecture.  That’s where navigation will have to evolve to. There will also have to be ways of updating the content once it’s been syndicated out.  A way to push out new updates, should relationships or links change in the feeds. Right now this may sound all very in clouds but it’s the way content is evolving. I setup my Google reader to pull in different RSS feeds, which I then read on my iPhone, and then share out again through Google reader and at some point I’ll probably pull in that shared RSS back into this blog and that suits my needs.  If I were to ever sell products there’s no easy way for me to get product information that I need except by hand today and unfortunately for manufacturers that means lost opportunity for them as well, which I’ll discuss in a future article.

The last reason I think we need embed navigation is that as we see AJAX style sites become more prevalent the easier you can make it to find the next piece of relevant information to the application the more likely your content is to be the next piece of content clicked to. We’ll see the same thing happen as other devices become internet enabled, where only portions of content can be displayed and it needs to be blocked out on smaller scales or scale up to larger scales (I’m think from cell phones to internet enabled bill boards). Making your content usable on so many different levels means YOUR content is the content most likely to be used next, and for that to happen you need to embed your navigation into it.

One last thing that might be of interest on this is do we really even need a navigation in the traditional sense?  This article at Devloung discuses this.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.