Ideas converge. We take one thing and see how it fits another. Then that thing gets bandaged together with another. Sometimes these things work and sometimes they do not. But we only step on to new things by doing this. I was randomly browsing the web. These days it always seems to start from some link I get from Twitter. Then I came across StartUpWeekend.com. If you like hackday, you will love this. To quote from the site:

Startup Weekend recruits a highly motivated group of developers, business managers, startup enthusiasts, marketing gurus, graphic artists and more to a 54 hour event that builds communities, companies and projects.

The way I see this is like a super hackday. Most hackdays involve individuals or a small group working towards a small goal. Typically, these are techies, developers and such. The StartupWeekend approach is more on the group level.  I don’t think individuals could achieve anything significant enough in a weekend.  The development process happens at the group level with individuals getting to submit their input. What I like about this is that other disciplines get to participate such as, marketing, graphic designers, entrepreneurs and so on.

The goal of these events is to produce something that can be a product. The right group of individuals focused on a product for an entire weekend can produce something interesting. Ideas can be bigger; more ambitious than traditional hack days. If you take a look at the site, you can see that they have produced an enormous number of products. Will all of them succeed? Probably not. They have produced some interesting things I think.

Convergence is within sight. I see plans within plans. At least it is in my mind.

I am envisioning a company. I will call my fictitious company CloudPlace.  CloudPlace provides an application hosting environment and an advertising platform. CloudPlace would create a base environment whereby external entities could create properties which CloudPlace would host.  CloudPlace would use these properties as advertising inventory, sharing the revenue with the property creators.

CloudPlace would have to provide more than just a platform to host applications. It would have to create the basic identity and authentication functionality. I also envision that it would provide some standard applications like mail and profile.  I’m assuming that they would provide some serious storage and computing services.

Someone I know always says “We have to do things to make peoples lives easier.” And this does just that in a big way. This business model provides a direct path for any great idea to become a monetized product in a weekend using an approach like StartupWeekend. The development entity would be responsible for building and maintaining the application. They would provide some placeholders for advertising. They register the application. There would probably be an approval process and bingo it gets turned on.

The power of this is similar to the expansion of McDonalds via franchising. CloudSpace could grow its application space dramatically by not having to pay anything for the pieces unless it drew a clientelle. If they wanted to seed the system initially, they could do that.

The application space would get saturated pretty fast wouldn’t you think? Not if you let competing products exist.

One of the downsides to this is the quality of the applications provided. This is very important. The failure of the original Atari game console was blamed to a large extent because Atari let anyone build anything they wanted. Developers started making any junk they came up with. And the game playing public got fed up with it and it all came crashing down. Nitendo changed that when they came along. They created an approval process and patented a small device that was required for a game to play. That way they could regulate who got access to their console. That approach would have to apply in this case and it would be easy to do so.

What I like most about this approach is that CloudSpace does not have to be responsible for any properties. Properties could come and go. CouldSpace would not be a content provider. It would only be a conduit for content. I might call it the super connector. Because that is all it is doing, creating a place for connections to happen between people, advertisers and products.

CloudSpace is an idea that uses a convergence of hack culture taken one step further, the theory that there is more profit in connecting than content, and means to very quickly create and deploy new properties with very little up front cost.

I took a look at the Yahoo Application Platform.  The idea of building applications that can run withing Yahoo is very intriguing.  Obviously, any application that would run within Yahoo would include several restrictions.  Afterall, Yahoo won’t open up their environment without making sure it was secure and stable.

The first thing to know is that the application only partially runs within Yahoo.  It actually runs on the developer’s server. The developer must have access to a server that is on the internet.  Access to the root folder of that domain is required to authenticate they keys.  This process is intended to maintain security of the keys and to ensure that if someone steals a key, the key thief won’t be able to use the key without access to the domain.

Yahoo users access the application as if they run within Yahoo and Yahoo, in turn, interacts with the application for them.  It does this so that it can sanitize the interaction and make it secure.  The other side of this is that is does not have all the capabilities of a standard web application.  Before I get into that, let me cover some of the basics.

A Yahoo Open Application can access user data like the lists of friends or activity updates.  This is a formidable reason to use the Yahoo Application Platform as it can create an enormous viral effect if done right.

The Small View

Let me start by talking about the visual parts of a Yahoo Open Application.  A Yahoo Open Application has two views.  This means that it has two ways of looking at the same application.  The small view is a small minimal sized view that is meant to be hosted in another page.  The intent is for Yahoo users to be able to put these small views onto Yahoo pages like the Yahoo front page and profiles.  At this point (Nov 23 2008), this isn’t possible as those Yahoo properties have not been upgraded to allow deployment of these types of modules.  But that should not stop someone from making one and trying it out.  It should be noted that the small view is fairly static.  It has no JavaScript so it cannot be interactive and dynamic like an Ajax application.  It does have some capability to be customized for each user seeing it.

For discussion purposes, I’m thinking of a “My Favorite Team Score” application that lets a user choose their favorite team.  And it shows the score for the last game that the team played.

When the small view is first created, this is only the default view.  The small view is cached on a per user basis.  That’s right.  Each user who installs the application gets their own cached version of the small view.  And the application can update the small view from another application that runs on the server.  I’ll admit that I don’t have all the answers.  I have en expectation that someone could use a cron job to update the small view.  I still have to verify this.  The small view is intended to entice a person to go to the full application

The Canvas View

Then there is the canvas view.  This is sometimes referred to as the full view.  The terms canvas view and full view This is more like a standard web application although it still has some limitations.  Remember that this application appears to live entirely inside Yahoo.  Therefore, an application can deliver content from outside Yahoo to Yahoo users.  The canvas view is 760 px wide and unlimited height.  The canvas view does support limited JavaScript.  The one downside I see is that external JavaScript is not supported.  This means no YUI, jQuery etc unless you are willing to paste all the code into the page itself.

This is the part that got me.  The canvas view is not necessarily a single page.  In fact, the canvas view can present any page from the developer’s server.  There may be some limits on where the page is located.  But I know for sure that if all the pages are located in the same directory on the server, this will work.

YML - Yahoo Markup Language

No discussion of the application platform would be complete without mentioning YML.  YML provides tags which access social data and provide other functionality for open applications.  Review the full list of YML tags for a complete description.  I will only talk about a few of them.

Each YML tag looks like this: <yml:tagname …>.  For example, <yml:a> is analagous to the HTML tag <a> which provides clikckable links to other pages.

Tag <yml:a> attributes

view - this is the name of the view.  Valid values are YahooFullView or YahooSmallView.  YahooSmallView points to the small view.  YahooFullView can point to the default canvas view page or any other page that is colocated with the default full view.  I discovered that I can add additional path information after YahooFullView to point to other files in the same directory.  So far I have only been able to point to other php files, not html.  And it does not allow the content output of that other file to contain <title> or <meta> tags.  It may prevent other tags.

<yml:a view=”YahooFullView” >Link to full view</yml:a>

<yml:a view=”YahooFullView/other.php”>Link to other page in full view</yml:a>

params - Any additional parameters included in this attribute are appended to the end of the HTTP request string.

replace -This is the ID of a DOM node to replace with the output of the view as requested.  The entire DOM node is replaced.  And example of this would be replacement of a DIV with an IMG.  Of course, there is no restriction on the node type.

insert - This is the ID of a DOM node whose contents are replaced.  The DOM node itself remains but its contents are changed.  An example of this would be putting new content into a DIV that already exists in the DOM.

Tag <yml:name>

This tag resolves to the name of a user.  It can resolve to the name of the viewer or the owner.  If you are looking at the application on your own page you are the owner.  If someone else is looking at your profile, they are a viewer.  Therefore, the tag will resolve differently for those two situations.

<yml:name uid=“viewer” linked=“true” capitalize=“true” useyou=“false”/>

linked - this is a boolean value.  If set to true, the tag is rendered as a link to the profile.

useyou - If this is set to true, the tag renders the word you instead of the user’s name if the user is the viewer.

reflexive - This attribute is used together with the ‘useyou’ attribute. If set to true, renders ‘yourself’ instead of ‘you’

capitalize - If true, makes the first letter uppecase.

uid - Use “viewer” to represent the name of the person viewing the application.

continue reading "First Pass at Yahoo Application Platform"