Are RIAs an extension of the Web, the Desktop, or both?
There’s a nice summary of the history of GUIs on Ars Technica today. It got me thinking about RIAs: are they a continuation of the evolution of the Web, the Desktop, or both?
~
When trying to innovate in areas of new technology, I think it is critical that you have the right analogies in mind. I remember when Kevin asked me to join the Dreamweaver 1.0 team. I didn’t want to join unless he recognized that the underlying code was the most important thing. To me, HTML was more like simplfied programming than drawing. He understood that. I joined.
What does this have to do with analogies? Well, at the time, all of our competitors had made the analogy that HTML was like PostScript. According to this analogy, “in the early days, you had no choice but to hand edit PostScript. But once tools came around, no one cared what the underlying PostScript looked like”. In retrospect, this analogy seems silly, but that’s what people said at the time.
RIAs are now at a point where the future is still murky, and people are making mental analogies in order to make sense of things and gather inspration for future innovations.
Here are some things I’ve heard said about Flex and RIAs in general:
- RIAs will make web apps more like desktop apps.
- RIAs are like web apps, but “richer” and more “expressive”.
- RIAs are client-server apps with easier deployment.
- Flex is to Flash as MFC is to C++.
- Macromedia should try to define the “Macintosh User Interface Guidelines” for Flex.
I think all of these ways of thinking about Flex are understandable, but each one can be misleading if taken by itself.
1. RIAs will make web apps more like desktop apps?
This is possibly the most dangerous analogy. We should be looking at desktop applications for inspiration, but the design constraints of the web are fundamentally different than the desktop. If we start from the user interface concepts of desktop apps and work backwards, I am confident that we will end up with Frankenstein-ish UIs that feel completely wrong for the web. RIA innovations should be driven by looking for new solutions to UI issues surrounding the web as it is today.
2. RIAs are like web apps, only “richer” and “more expressive”?
There’s nothing wrong with “rich” and “expressive”, but it doesn’t capture what RIAs should be doing. Are RIAs about special effects? No. Or at least they shouldn’t be. They are about getting the job done in a better way.
HTML-based apps are great, but the UI vocabulary is very limited. As a result, you end up with email applications where every single piece of mail has a checkbox next to it to represent the fact that the email has been “selected”. With RIAs, we should be able to create applications that are more engaging and usable than with HTML.
3. RIAs are client-server apps with easier deployment?
RIAs are about ease of deployment? Sure.. in the way that the web is about ease of deployment. But that’s not the core of what we have to innovate on. And “client-server” sure isn’t the direction to push for when innovating. The rallying cry is deifinitely not “hey.. let’s make RIAs more like client-server apps from the 80s!”
4. Flex is to Flash as MFC is to C++?
This one is basically true, IMHO. But it’s not a great rallying cry for innovation.
5. Macromedia should try to define the “Macintosh User Interface Guidelines” for Flex?
Well, in some ways, we should. For example, scrollbars should all have consistent behavior even when they look different. So we figure out what the behavior should be, we write it down in a user interface guideline somewhere, and we even build a component that encapsulates the desired behavior.
One of the defining characteristics of the web is that all web apps look completely different, and yet they all need to behave somewhat the same if customers are to undrestand how they work.
Coming up with a set of guidelines that captures the “sameness” of RIAs while allowing for the differences is going to be hard work. Looking at how desktop OSs have created UI guidelines can be dangerous, because there is so much more that is expected to be “the same” for desktop apps than with web apps.
So how should I think about RIAs?
When I look at an article like the one cited earlier, it makes me really excited about the possibilites of RIAs. This is admittedly loosey goosey, but I think the best way to think about RIAs is to see the evolution of human/computer interaction as one continuous thread. Look at the pictures in the article and think about the way that human/computer interactions have changed in our lifetimes. The difference is truly astonishing. Add in the innovations on the web. They are not separate from this thread; they are part of the story. The way that people and computers interact has been changing, and will continue to change. For many of us, RIAs are where we have placed our bets as being the most interesting area of continuing evolution and change.
Much as HTML defined a new way of interacting with computers, RIAs will extend this and define a whole new vocabulary for how we can interact with computers, in an easier, more convenient, more intuitive, and more satisfying way.
RIAs are not “web+desktop”, they are something else. To fulfill the promise of RIAs, we will need to solve tough interaction design problems for this new problem space. Like the web, RIAs are highly networked and trivial to deploy, but unlike the web, the possibilities for client interactivity are nearly limitless.
Excellent post! And a very good question too.
To me RIAs are about evolving the web to the next level in terms of usability and functionality. Providing services and interfaces that can’t be done in HTML. And not just for a specific application for a specific website, I mean for the web as a whole.
Eventually we’ll be at the point where there is no line between desktop and web, but that’s still a long ways off. But as this happens, I think it will be moreso the Internet’s design that influences the desktop rather than the other way around. We can see some of this already with Google desktop search, or even Microsoft’s XML UI description language in Avalon.
But in order for RIAs to become the norm of the Internet some key things need to be looked after. As they stand, RIAs are NOT ready to replace most web sites.
What I really want (I guess) is a replacement for HTML. Something that retains the huge power of the web but extends the interface. The biggest problem with RIAs as they stand is they break the existing Internet structure. I can easily link the URL of a news story on CNN, but I can’t do that with a specific “page” in a Flex app. What’s needed is a way to represent the RIA’s state so that it can be recreated by another RIA.
Or maybe I’m still too stuck in the traditional web app mindset? But I don’t see RIA’s redifining how information on the Internet itself is structured anytime soon.
Unfortunately it looks to me that things like Flex are being targeted more towards things like “client-server apps with easier deployment” for corporate Intranets and single apps within an existing web presence when what I really want is the next “version” of the Internet.
Thanks, Jason.
BTW, I agree 100% with your comments, especially regarding the infrastructure of the existing web. People often talk about the “back button problem” or the “bookmarking problem” when it comes to Flash-based apps. These are really misleading ways to talk about the problem. The issue isn’t that bookmarking is so important. The issue is that the entire web is put together with the assumption that (a) an app can be decomposed into lots of independent pieces, and that (b) each piece has a URL which uniquely identifies it. (you can see where I stand on the REST issue…)
There are other pieces to this as well, such as the fact that historically, the connections between these pieces have been declarative (i.e., the <a> tag), and thus discoverable by web crawlers.
These are hard problems, but we’re thinking about them.
Heh, I’m glad someone is thinking about this stuff, because I sure as heck don’t have a solution :-)
As you say, integration with the web as it exists is necessary before RIAs as websites can really start to change things.
I can create a blog app in Flex, but unless Google crawls it, I’m pretty much talking to myself!
I would create a blog app — i.e. the admin console — in Flex, but I would always keep the output in HTML. That’s what HTML is meant for.
A bit late, and sorry if I ask a stupid question, but isn’t Flex targeted at desktop apps?
How can Google crawl my desktop (as I’m not going to install their Desktop Search)?
Another question: could Flex be used to build this: http://time2wonder.blogspot.com/2005/06/online-tool-tot.html ? That would be really cool..
Flex isn’t targeted at desktop apps per se. It can’t crawl your desktop any more than HTML could.
Flex is for creating more expressive and more usable internet apps. It has the ability to display more complex, fluid, and beautiful interfaces, as well as being able to perform more in the way of client-side processing.
Did that answer your question, or did it sound like marketing-speak? :-)
But in order for RIAs to become the norm of the Internet some key things need to be looked after. As they stand, RIAs are NOT ready to replace most web sites.
FWIW, I agree with you. RIAs are not quite ready to replace most web sites. What are the key things that need looking after in your mind?
scam in thailand gem scam in thailand thai scammer list report scam thailand
thai jet ski scam https://siam-shipping.com/
I like how you present and argue all the details in addition to your overall writing
style. From time to time, there is a shortage of time to study long pieces,
but is brief and concise, I spent just a couple of minutes to read the entire article.
It is essential since nobody has time to read.
Thank you so much for this good post. I saw your publications earlier, however this one I believe the best.
How did you find so many facts? I enjoy the way that you organize everything, because it’s really easy to read.
In general, I will recommend this article to everyone who’s interested in that topic.