Archive for Platforms

Segmenting web platforms

Web as a platform is an interesting topic for most people in the software industry. Marc Andreessen (Ning) recently made an attempt to classify this platform in his post The three kinds of platforms you meet on the Internet. In the follow up analysis posted by Josh on ReadWriteWeb Platforms on the Web are Platforms on a Platform, this classification and value of different platform levels is questioned. Before I state my views on this, let me capture Mark’s classification in a summary below:

L1 platform. Loosely coupled REST/SOAP based API integration. Example: Flickr API.

L2 platform. More deeper integration of developer’s application injecting into the platform UI. Example: Facebook API.

L3 platform. A runtime that hosts developer code. Example: Ning.

Marc’s argument that L3 platform are the best, is certainly questionable and Josh makes points in this line. While a scalable web platform with Social Networking API is a powerful one, expecting others to bring their users and user data to your hosted platform is not in the best interest of the company/group that wants to add those features to an existing site/application.

A better solution could be a add-on social networking platform with API which the company/group can co-host and integrate. They get to keep their users and user data and can achieve better integration.

This is like a “Web 2.0 Application Server” as shown in the picture below. Deployed alongside the current Web 1.0 website and can provide social networking features overlayed on top of it.

web122.jpeg

Would this be more acceptable to those currently on using web as a Web1.0 platform and would like to add social networking among their users (use web as a Web2.0 platform)?
Technorati Tags: , , ,

Advertisements

Comments (1)

Desktop Apps built like the web

I was heartned to find this early posting on Netwizard’s blog that points to the thinking behind Dekoh.

Writing applications using markup instead of platform-API-based code is so much more easier. Browser-based UI brings significant advantage of using combined teams with programmers (who generally can’t build great looking UI) and graphics and UI specialists (who can’t wire it up with the backend). The last decade of focus for developers has largely been on building to the web. The programming model and the deployment environment are all too familiar.

A browser-based application need not necessarily mean a hosted application, when a desktop runtime such as Dekoh can serve to your local browser. You have the twin advantage of a common environment for quickly building to the desktop (and web) as well as a fluent integration between the such desktop applications with existing web applications. The best way to build web-desktop integrated applications of the future.

Technorati Tags: , , ,

Leave a Comment

Dekoh announces public alpha at Web 2.0 Expo

Dekoh is starting public alpha program to get feedback from larger community.

We are very excited to show to people at the Web2.0 Expo (San Francisco) starting tomorrow. If you are at the show, drop by at booth number 330 for a demo or discussion with us.

Here is a quick look at the applications we will be demoing.

[rockyou id=64416942&w=426&h=320]


Submit to del.icio.us digg Technorati Yahoo My Web
Technorati Tags: , , ,

Comments (3)

Adobe’s love and hate for browsers

Adobe has 2 of the most popular browser plugins (see Common plugins for Firefox). Flash is by far the best way to deliver multi-media content to web users because of 2 reasons.
1. Same user experience on all platforms and browsers
2. Ability to stream

Flash Player Penetration is 98% of Internet viewers. This is great for any software! Adobe loves browsers.

Then why did Adobe choose to write Apollo outside the browser? Which clearly puts them On A Collision Course With Web Browsers. Here is why Adobe hates browsers:

From a end user perspective Flash has remained at (in)famous “skip intro” on web sites or as a media player to watch videos or listen to music inside the browser. Flash is not as popular for writing web applications as AJAX is.

The main reason for this is the “back button” in the browsers. Hitting the back button unloads the Flash application losing the application context and any interim session data.

Back button is one of the most used features in browsers. It is hard to change user behavior. This has restricted Flash usage to just media delivery on the web. This I suspect is also the reason why Apollo did not leverage existing browser plugin installations, instead decided to keep it outside the browser chrome.


Submit to del.icio.us digg Technorati Yahoo My Web
Technorati Tags: , , ,

Comments (11)

Flash or Java. Which is better?

Ed Burnette has written a blog post Is Flash better than Java? there is a lot of interesting discussion happening on the thread. The comparison needs to be sliced and seen from various angles.

Flash and Java is not apples-apples comparison

Flash is most popular for delivering media content. Most of Flash content is delivered thru browsers. Flash installations on desktops is predominantly because of browser plugins. Whereas Java can be used either as client-side applet for rich application UI or can be used on the server-side for writing the application code delivered to browsers thru HTML/AJAX.

Flash wins hands down if the comparison is with Java applets. But, the number of websites and applications that are powered by Java on the server-side out number Flash applications on the web.

Apollo and Java is not apples-apples comparison

Adobe Apollo is a cross-OS runtime for delivering Web-Desktop integrated applications. Java is a cross-OS platform not specifically for writing web-desktop applications. Java has a huge collection of platform neutral API for accessing OS, hardware, network, graphics, database etc. One part of Java is Swing (UI) which can be used for writing rich UI applications, again swing is not meant for specifically writing desktop-web applications. Swing is traditionally used for desktop only applications. So I would say Swing is more comparable to VB or X-windows rather than Apollo.

A more near comparison of Apollo on the Java side is Dekoh, which is a open source Java based platform for writing desktop-web integrated applications.

Which is better Java or Flash?

Depends on which aspect are you looking at.

  • Media delivery on the browser: Flash
  • Better execution (installation, upgrade, version changes) on client side: Flash
  • Number of web applications written using the technology: Java
  • Richness of API and services: Java

Technorati Tags: , ,

Leave a Comment

Desktop web applications and browser debate

In the last week there has been a lot of debate about Desktop RIA applications. Starting with Alex’s article on Read/Write web Adobe Apollo – On A Collision Course With Web Browsers and then a discussion Which is better, an offline Web App or an online Desktop App?. There were other articles including Zimbra offline announcement and a big discussion on need/use of offline apps here. Finally, I read this nice post from Mike Chambers of Adobe on Why Apollo?. He explains very clearly what Apollo is.  There are a few problems Mike outlines about delivering applications in the browser. Here are my thoughts and ways Dekoh overcomes them.

Conflicting UI:  Since the time Netscape introduced Back button, it has been one of the most used features of the browser. Most sites and web applications work fine with back button and expect people use them. How many popular web applications have you seen that do not work when you use back button? Back button is a problem for Flash based applications, it is not a problem for “web applications” in general.

Distance from the Desktop: For any browser based application there are 2 portions, UI on the browser and a server that serves the logic. When you include the server as part of the desktop platform (as Dekoh does), the distance between desktop goes away. Applications can very well render UI on the browser, as well as integrate with other native desktop apps.

Primarily online experience: Accessing exact same online application in a disconnected mode (Firefox 3?) is different from writing a desktop application that can provide some functionality offline and sync with online counterpart (like ebay demo of Apollo or Google calendar demo of Dekoh).  The online experience problem is relevant to former type. Writing desktop applications and accessing them thru the browser creates a consistent user experience, works across browsers.

Lowest Common Denominator: I agree there are differences between browsers when it comes to complex AJAX applications. But it is not too difficult to write applications that are very usable and run well on all browsers. There are also a number of toolkits that abstract the problem. Mike’s concluding paragraph coincides with my thought. He says The fact that web applications have flourished despite these drawbacks is a testament to the attractiveness of having a platform with a good development model that has the ability to deliver applications to multiple operating systems.

Leave a Comment

Evolution of Dekoh idea

Jay Fortner wrote this article  on Read/Write web.  One observation he made was “…makes it hard to describe what Dekoh is in a sentence”. He is probably right to some extent because Dekoh offers several different things, at a first glance it appears it is doing too many things. That got me thinking about how Dekoh evolved…..Here is the story.

In middle of 2005, few of us at Pramati were discussing about development skills needed for desktop applications development and web applications development. We started to think why should it be so different? How about creating something to merge the two. Chandru played a prank, he created a one-page brochure (pdf) of a product called “Butterfly” that did everything we were thinking and sent it the next day to Jay (CEO). That was the first seed of Dekoh. We made a quick prototype (project codenamed Butterfly)….and story continues. Now coming to the point of one sentence description…

The problem statement we started with was a single sentence “Creating platform to provide seamless user experience for desktop and web applications”. This is stated in the press release. Now, trying to create the platform required bringing the best features of desktop and web together which people are used to, I have explained it in this post. When you try to create a platform, it needs to be beaten up by developers to put the right features in and make sure it is usable. We don’t have the luxury of existing developer base as Adobe, nor can we convince ebay to try our platform before it is popular. So we started eating our own dog food and started writing applications (like photos, music, books, calendar…). Another reason to write such elaborate applications rather than eye candy demos is to make it usable to end users. I am sure developers who adopt Dekoh will come up with smarter and cooler applications, but for initial users Dekoh applications are very compelling.

Leave a Comment

Older Posts »