Blog Archives

User as center of the Universe

I am slowly catching up with some articles I read and over which I wanted to comment. I am dealing with this one SOA needs RIA – Burton Group, because there are few sentences I liked and because it lacks, in my opinion, a proper “end”.

The Value Hierarchy of Web 2.0So, here are the quotes I liked most:

  • “We firmly believe the user experience needs to be a first level priority at the same level as SDLC, platform languages, SOA and security.”
  • “If the business depends on people and people depend on information technology, then the interface between people and information technology — the user interface — naturally has to be very good. If you have an ineffective user interface, you’re going to have a less effective organization.”
  • “…people are the platform. IT is ephemeral. It continues to change over time, but what does not change in business is that the quality of any organization depends on the quality of its workers.”
  • If developers think the goal of SOA is to provide agility in assembling loosely coupled Web services into an application that provides real-time sales data to managers and marketers, they are missing a key component in the Burton view:  “The idea is to make user experience the end goal of any IT initiative and not an afterthought.”

I, personally, subscribe to all the above statements. They remember me a very nice article I read a couple of years ago, from Dion Hinchcliffe, titled The Web2.0 Trinity: People, Data and Great Software. The pictures in this post are both taken from Dion’s article, and I use them consistently in my talks around Web2.0 and the evolution of Desktop technologies.

Going forward, there is another quote that my few readers may appreciate:

“We see the next step as RIAD, the rich Internet application desktop. Here you need to look at Adobe AIR, Google Gadgets, the Microsoft Widget Library, to see resident applications that provide you with a visual experience associated with RIA.”

This is even more close to what I have often written in my blog: moving beyond the browser (as we see it today) towards a mechanism where applications, delivered via the web, will be executed locally. GREAT !

What seems missing to me is the very last part of the article

In Burton’s view, the future of the UXP is in using Web widgets, portable chunks of code and gadgets, miniature objects that can be placed on a Web page to provide dynamic content.

With widgets and gadgets, real-time sales data is on the sales manager’s desktop without requiring him to do multiple click-throughs to find a table or chart, the Burton analyst said.

What I think is missing is the name to this approach, a name which already exists. It is called Mashups, isn’t it? What is needed is the possibility to define those widgets in a standard way and be able to mix and match them in different contexts: a Portal, a Mashup environment, a Rich Client, the desktop even….

Speculations on Google Browser (GBrowser) ?

I have read this morning an article speculating on the arrival of a new Browser on the market, a Browser labelled “Google” (or Gbrowser).
The few readers of my blog can immediately imagine that this is not the kind of news that I would have liked to hear. I personally do not like this invasion of things from Google which, under the cover of being “free for everybody”, tie us to a new monopoly (see my previous post “Internet Search should be property of no one“).
I state this even if I have no problem admitting that most of the technologies that Google, in its immense altruism, offers us are very cool and really innovative and really pushing for significant progress in the Web space.
The problem is not around how cool the presents from Google are… it is about the concept of “present” itself !

Anyway, in this specific case (GBrowser… yes, you can see that the domain name has already been registered by Google!) I think that, if the speculation actually reflects a reality, it may become something very significant, and perhaps not completely bad.

If really Google will put on the market its own branded Browser, I think that :

  1. Google will finally admit that some “footprint” is required in order to properly run today’s internet applications (this will have consequences on AJAX as we see it today, I think)
  2. Google will automatically transform what they published as “contribution” into a de-facto standard (because it will be working naturally with the new browser….)
  3. Google will create a platform onto which developers will build RIA applications

Yes, in the last bullet I wrote “RIA applications“. Because, if the Browser from Google will become true, it will obviously promote the use of Google Gears and of all the other G* things that invaded the web. A couple of months ago, I wrote my first reaction to Google Gears:

[with Google Gears] Google starts to install something else than the browser in order to keep the browser relevant”

The advent of Apollo AIR (paved by Flex) and the approaching of Vista (via Silverlight) may create serious alternatives for running applications delivered over the internet (see here and here and here for a summary of my opinion on this topic); the default mean to access to applications delivered over the net, will no more be the browser, at least when some significant experience and richness of functionality will be required.

Will Google redefine what we know today as “the browser”? Will Google remove the impedance that somehow forced the two main actors in this space (IE and Firefox) to comply (at least formally) to standards?

Again, if Google will indeed go into the Browser business, all what it gave away so far could be interpreted as a way to create “addiction, so that people will find it normal that Google will also revolutionize the browser space. After all, Google is not perceived as the “bad boys in the block“, so it is likely that this move will find only few opposers.

Despite these considerations, though, I initially wrote that this may not be a bad outcome for the web. My readers know that I consider that the browser needs a big evolution in order to support the new challenges and the execution of applications delivered over the internet. So, this move may represent a shock that will benefit the whole community.

I wished Firefox and XUL could have become this shock!!!! Perhaps they will anyway (why wouldn’t the GBrowser be based on Firefox after all?)

Of course, this is all speculation at this moment….

Firefox as a Phoenix

I am starting to digest and sediment a series of articles that recently popped out on Mozilla. The one who hit me most was Chris Messina’s Thoughts on Mozilla, but also Alex Faaborg’s Web2.0 Expo presentation. I will certainly add more comments in the next few days.
For the moment I would like to comment on the Innovation aspect.

Imho, Firefox should not bet its future on “being the best browser”. In this way it will simply set its path, in one way or the other, “on respect to something else” (notably IE).
What the user interface of Linux already did (KDE or Gnome for that matter) in trying to, first “catch” and, then, “be better than” Windows… did not produce any significant result in terms of innovation (in fact if the price wouldn’t play a role, most of the people would choose a Mac because of its interface, certainly not Linux).

So, if from the phoenix (of Firefox as we know it) could raise something new, a platform where applications delivered through the web could be executed, then, I think, it will be great. Yes, certainly, this is the domain in which Adobe and Microsoft are also directing their efforts (I tend to agree with Scoble that JavaFX is more for the mobile-phones) .
But Mozilla could consolidate the effort from the Open Source community and this would be really a great advantage.

Let’s dream about XUL+SVG ….

AJAX second’s birthday. What’s next ?

Today is AJAX’s second birthday, as this article remembers us.

I remember when I started blogging on this topic. And, in all honesty, I have to admit that I got in love with AJAX when it happened. I liked very much the idea of building web applications that “last longer”, that provide a fluid experience to the user and that do not require additional plugins. At that time, in my previous team, we were trying to understand how things like Flex, OpenLaszlo and other technologies would impact the way in which our customers think to Web applications.

Today, after two years and some posts… I changed my mind. I start thinking that AJAX has been artifically keeping the browser alive:

  • regardless of the merits of some of the AJAX technologies that were developed so far
  • beyond the excellents things we see around (more or less everywhere on the web, today! even if one of my favorites is still Zimbra)
  • despite the fact that the emergence of the Web2.0 phenomenon is certainly due to the availability of the AJAX technology (which made people caring of Web2.0 because they could immediately see the advantages)

well, today I am more prone to think that AJAX represents the swan song of the “browser as a mean to execute applications delivered over the web“. The arguments that make me thinking that way have been often posted in this blog.

In the previously mentioned article on AJAX Birthday, I think I agree with what Richard Monson-Haefel wrote:

  • While AJAX has set the world on fire and caused a renaissance in user experience, it’s not the best Rich Internet Application (RIA) technology available today.The technology, or “approach” as some like to say, suffers from serious problems….
  • ….The fact that AJAX has ignited a renewed interest in making the Web a much better user experience is to be applauded, but don’t confuse the hype around the technology with the basic facts about the strengths and weakness of AJAX compared to its counterparts…
  • ….Another area where AJAX really needs to advance is in terms of tooling…
  • …the number of code-level AJAX frameworks and APIs available today is ridiculous. At my last count (August 2006) there were something like 160 AJAX frameworks….
  • …Here is another problem with AJAX, it’s not very deep

Ditto !

Now, I would like to take this opportunity, AJAX’s birthday, to comment on an excellent article, Web 2.0 Re-examined, from Coach Wei, the founder of NexaWeb.

One of the interesting concepts introduced by Coach Wei is the one of “Architecture of Partition“.

The truth of the matter is that neither server centric nor client centric architecture is always appropriate. Unfortunately developers never had the flexibility to deciding the right architectural partition for their applications. Web 2.0 brings architectural partition flexibility to developers for the first time in history. With web 2.0, developers can partition the application in a way that is best appropriate for the application, rather than trying to fit into a pre-determined architecture. Some applications are best served by leaving only user interface and some UI logic on the client side. Some applications require all UI logic on the client side to deliver optimal result. For even more sophisticated applications, there is requirement to have a certain business logic and data on the client side as well. Web 2.0 technologies enable developers to decide how much computation stays on the client side and how much stays on the server side, delivering optimal results.

Somehow, if “Architecture of Participation” represents an Usage Paradigm Shift, the “Architecture of Partition” represents a Technology Paradigm Shift.

This Architecture of Partition is, actually, realized by means of the 3 components drawn by Coach Wei in the picture on the left.

The way in which Coach Wei describes  the Application Client Container (ACC) has many of the points that I try to push since few months:

  1. ACC is stateful. A web browser is designed to be stateless … …but Applications are inherently stateful.
  2. ACC supports asynchronous interactions by default while browsers require careful developer coding to do so
  3. ACC can support offline computing while web 1.0 applications are online only
  4. ACC supports mobile computing as a first class citizen
  5. ACC supports accessibility
  6. ACC supports rich user experience.

We start seeing instances of ACC appearing. Not necessarily, hopefully, in standard browsers!

As to the third component described by coach Wei, I personally think that the “Enterprise Mashup Server” is a component that is realized partly by a Portal (on the Server) and, partly, by some clver use of the ACC. See my post Composite Applications, Mashups and Portals: “relay race” or “team spirit” ? for more details.

In any case, Coach Wei’s paper is the first one I read in which some architectural foundation for the new generation of Web-based applications is depicted.

Today, AJAX’s second birthday, these concepts make a lot of sense to me. Perhaps, the future of AJAX may be in some ACC !

Will browsers ever deliver applications instead of documents?

Finally I found it spelled the way I thought. Great article, Beyond HTTP; something that made me thinking again.

Just yesterday evening, I received a mail from a colleague asking me what did I think about Windows Presentation Foundation and if I have seen the New York Times Reader application.
I replied to him pointing to a series of internal posts I wrote on this subject, especially one in which I was quoting “The browser has a terminal illness and is dying” and another one in whihc I quoted “Death to the Browser“.

What is needed is the Post Browser, the Next Browser, whatever name you want to give to it. Sure, it can still run HTML (the old stuff), in a container that is essentially the same as today’s browser. However it should be capable of complete look-and-feel customization via a standard markup language. It should provide a rich set of custom controls and be able to access the desktop (with appropriate security, of course). It should have a native, secure, bidirectional mechanism, and one that supports multiple connections so that we can access services from multiple sources in a composite application. It should also have extensible controls so that we can extend and improve the behavior of controls and applications as needed.

Ajax is certainly great, but its reality is very much what the author of “Beyond HTTP” says:

I find myself in a bizarre position. The fact that I’m an expert in this kind of thing and have the technical know-how and aptitude to design and pull off such a complex beast on time and as designed means that I got paid quite well for the six months it took to develop, and I’ll continue to get paid as and when upgrades are needed. If any old John Doe could have opened up Visual Studio and slapped it together then I probably wouldn’t find myself getting paid quite so much for my services….
….Compare the Visual Studio .NET Windows Datagrid with its Web-based counterpart. There’s no comparison: a confident user of the former wouldn’t immediately be able to even recognize the latter.

But, even beyond the intricacies of AJAX programming, the real issue is the REST architecture laying behind “the Web as we use it today“:

Finally we get to the rub: The document-based Web as we know it is not a platform for developing complex applications; sure it’s possible and there are plenty of bright people working at places like Google who are doing it as we speak and creating frameworks to make it easier. But is this really the way forward? A tree-based object model accessed by an interpreted scripting engine tacked onto a specification designed for static read-only documents?

So we need to avoid any dogmatism. Again, the author of the article asserts:

Now would be a really good time in history to stop, step back, and look at what we have and what could be done better. What we need is a Web browser that doesn’t just server up documents, but serves up applications: full screen native GUI, network-transparent and, most important, fast, lightweight, real-time applications. Ideally we’d want to start over, build a whole new spec running on an entirely new platform and set of protocols….

it should have state, and that state should begin by initializing the application’s main source file on the server when the client first connects. The application would maintain state between calls, allowing the use of global variables and custom classes that persist…..a move away from the top-heavy and stateless HTTP protocol to a true lightweight binary client/server relationship between the user and the application…

…All it takes is the will to step away from the Web browser and start something new.

I subscribe! 🙂

  • I subscribe because I am not against the browser, do not get me wrong! I am in favor of the browser for when it needs to support what it was born for: supporting the delivery of documents and supporting the REST (stateless) model.
  • I subscribe because an evolution of the browser is the only possibility to save it (or to save its central position in the Internet).
    Windows Presentation Foundation” (WPF) seems to be the way that MSFT is taking to make the browser irrelevant. WPF Applications can be delivered as Web Browser Applications : “…from the user’s point of view, no installation occurred, but rather an application was “ephemerally” loaded into the user’s browser in much the same way an HTML page is loaded. In a sense, it feels as though the user simply “visited” the application…

  • I subscribe even if I find that “AJAX is a cool thing“.
    But, somehow, AJAX (with which I got in love a couple of years ago), seems to me today the swan song of the “browser as it is today“.

  • I subscribe because I start suffering from the limitations of an AJAX model which forces me to open a new browser tab to cope with anything I need.
    Web2.0 and AJAX are different things!
    AJAX may not be always the best technology to support Web2.0

  • I subcribe because, as the New York Times reader example shows, the risk is that we will not compete on the AJAX battleground in the future:
    • Microsoft with Windows Presentation Foundation is pushing for a convergence between standard applications and internet applications
    • and Adobe with Project Apollo is freeing Flex from the constraints of the Browser

    The battleground is already shifting!

  • I subscribe because of the laws of evolution.
    I think that the only reason to keep the “browser as it is today” alive is that it took so much effort to arrive to an agreement! All that effort sorts of prevents people to recognize that the laws of evolution apply in this domain also… and that the glorious browser has made its time.

Certainly, the “Browser as it is today” will stay, probably forever (after all, the reason for not driving all on the right side of the road is because of too much legacy 😉 ). A “cheap”, “ubiquitous” layer to access the information everywhere will always be required:

  • certainly to support the access to static, REST, stateless content.
  • Perhaps to support many of the pervasive Web2.0 things…

But real-world application development leveraging the Internet that goes unnoticed by the photo-sharing, music-downloading, blogging masses” may really benefit from a quantum-leap in this area.

Why not starting from XUL? It is declarative, it can be hosted in browsers….

  • Social Slider
  • RSS
rss Follow on Twitter facebook linkedin