Stop Thinking of Flex As a Browser Technology. Seriously. Stop It.
Yaniv Golan doesn’t get Flex, which is fine. He talked to Mark Anders at the Future of Web Apps and he doesn’t understand why people would choose vendor-lockin when you can do the same things with standards based Ajax. Well one, it just isn’t possible to build a rich user interface with Ajax. But then Yaniv goes on to list some complaints about problems with Flex in the browser. I’m not picking on Yaniv here, because these arguments come up all the time. He’s just one of the more articulate naysayers. The problem is that people still think of Flex as a “browser technology” because it runs inside the browser. That’s bad because the great thing about Flex is that it breaks you free of the browser while maintaining the idea that we can browse to applications. But people get caught up in how Flex breaks the rules, so I want to run down the Yaniv’s list:
- And what about search engines and other content-aware tools, which cannot easily access the content delivered by Flex applications? Flex is meant for web applications. How do you search an application? Help documentation, maybe, but a full application? Sure there are things you want to associate with your application so it shows up in Google, but is that really searching an application? Web search isn’t meant for applications, and the current methods just don’t apply. I think this goes for both Ajax and other RIA technologies.
- And permalinks, which do not work as naturally with Flex as they do with HTML? How do you bookmark a piece of content in a Flex application on Delicious? This always kills me. Applications aren’t made up of pages, they’re made up of states. Inherently, states aren’t made for the bookmarking model of the browser. States are all about which path you followed and what feature of the application you’re using. Trying to shoehorn that into the page model won’t work. Saving states is valuable, but the browser bookmark is a poor way to implement that.
- And – which surprises will you run into when you hit the browser’s Back button? There is no back button in Microsoft Word. Or Life. Again, the back button is great for turning a page, but when you’re in an application does “back” mean undo? Does it mean up one row? Does it mean the previous menu? Going back with pages is easy, but applications aren’t meant for the back button, and with good reason.
In this rush to throw all of our applications into a web browser, it seems like we haven’t stopped to ask ourselves why these old rules should apply to this new software medium. Is it because we love tradition? Because users expect it? The browser is a great delivery mechanism for web applications, but that doesn’t mean the applications within that browser should try and implement all of the browser rules. It vexes me why we try and fit a square peg in a round hole. But then again, I’m hopped up on caffeine, so what do I know.
[tags]Flex, browser, usability[/tags]
Posted in Rich Internet Applications
February 22nd, 2007 at 7:02 am
Spot on. I haven’t created my first Flex app yet, (though I’ve been looking at it for months in my head), but when I do, I won’t waste five minutes on any of those items. My app won’t be for public consumption, and the back button will be for when the user is finished working with the application and wants to go somewhere else (and that will work without any help from me).
February 22nd, 2007 at 7:05 am
Well said Ryan. I think there is becoming more of an awareness of web applications as multistate units within a single page. You go to the page, you interact with the application. You hit the back button, you go back to the page you were on before you went to the application. And as long as you aren’t getting full page refreshes between each application state, it should be obvious that you are on the same page. I think that’s one thing application interface designers should strive to keep in mind.
February 22nd, 2007 at 8:23 am
You hit the nail on the head Ryan. You search sites, not applications. You bookmark sites, not applications. I don’t know who this guy is, or what his experience level is, but his comments are SO 1990’s.
This would be a good post for Universal Desktop.
Cheers,
David
February 22nd, 2007 at 8:23 am
Great post Ryan. This is absolutely the right way of thinking of a Rich Application, Internet or not. I have been trying to articulate my thoughts on this very subject for a while now in a future blog post and I think I will have to get one up referencing this post. It is hard to change the mold, but sometimes it has to be done!
February 22nd, 2007 at 8:36 am
Ryan you are exactly right! I’ve been building what is now called RIA since 1999 using Flash, ASP, XML, Javascript,etc and have just started using Flex. I’ve faced the questions above many times. My apps have been used by thousands of business users and have been extremely successful. Under most cases they were not available to the general public. Web applications and Web pages are two different beast and should be developed with their purpose in mind. The tide is turning. The rise of the RIA continues. Thanks for joining they fray.
February 22nd, 2007 at 8:41 am
Well
Flex or not, but any Flex app you are talking about must resides in a browser window, right? And although so many names and stuff (Webb Apps, RIA, Web 2.0) and so on, all come to a simple clue – you NEED a browser to load your web/ria/web2 app. At least in 95% of the project/client requirements.
It’s a simple logic (and usability requirements I think), to follow and use the default browser possibilities.
Browser bookmarks? Yeah, a user expects somehow to add bookmarks, doesn’t matter if it is a Flex, Java or any AJAX app.
Back button click? Well, assuming Flex has already a whole class to take care about the Back button functionality, it should be implemented. As Back button is ALWAYS on the same place and can turn you back to the previous state.
Can’t say the same with different Flex app states, especially in a complex app, where interface and functionality could come overcrowded for a common user eye.
It’s like preparing a nice Windows app and NOT using clipboard or ANY of Win functionally, except minimize/close button of the app window
Reminds me the last days of Flex 2 Beta, when MM/Adobe were talking so much that FLEX IS for Web and Internet (RIA, right?), and then there was a nice posting from a respectful MM/Adobe guy, who mentioned that actually Flex is heavy for Web and it’s better to start think of it as a Enterprise App Development. Which is a totally different topic even to scratch anyway.
So I would give a good credit to Yaniv, he uses simple logic and good point of usability. Revolution or not (doubt that), ANY app which resides in a browser window would be expected to implement at least all the obvious browser functionalities, including say Back button click, or bookmarks.
At least that’s what I think
February 22nd, 2007 at 8:51 am
You can use the back/forward/refresh in Flash/Flex. With simple php and the use of External Interface, your all done with a SEO W3C AS site.
With a small search you should find what you need cause even google knows the way.
February 22nd, 2007 at 9:02 am
Whew, lots of comments. I’m glad so many people enjoyed it. Dimitar, my point is that we’re doing users a disservice by encouraging them to use traditional browser actions when they are interacting with web applications. It’s a different ball game.
February 22nd, 2007 at 9:09 am
There’s a packaged solution for handling the back button and deep linking into a Flex app.
UrlKit
February 22nd, 2007 at 9:12 am
Well
As I mentioned, Flex, Java applet or any app which resides in a web browser, it’s a usability requirement (a must especially in governmental projects) to support all the obvious options a browser gives.
Yes, definitely Apollo won’t have this requirement, because it’s simply won’t reside in a browser window and it would be really cumbersome to implement such idea in a Apollo or WPF app for example, but any app web developer who dealt with big projects (no matter if they are in Flash, Flex, applets, Ajax or any other) should agree that it is a MUST usability requirement to support the browser possibilities.
I want to change the users too and their expectations to be dictated from an app POV, not a generic user web experience, but it’s simply not possible.
Loading a browser window presumes support of the browser possibilities, as simple as that.
It’s not stubbornness, it’s simply a conclusion
February 22nd, 2007 at 9:18 am
Again, agree with Ryan on the back button as not applicable in many web apps. what does a back button mean in a flex app? go to the previously selected tab? the previous accordion pane? uncheck the checkbox you just checked? delete the text you just typed in an input field? I would expect it to exit the application and go back to the previous page, and as Ryan says, we should encourage users to think that way, and not use browser controls to control application state.
February 22nd, 2007 at 9:28 am
Back button in a Flex 2.0 app is got to the previous state. At least that;s how I am using it. States are no different than pages except preloaded during the initial load of the app, right? So naming them pages, or states, same thing (almost).
So Back/Forward button could be a really stable and good addition to move back/forward your states.
Or you can ignore them entirely, but try to justify that for a governmental Flex/Flash projects and hear the answer
February 22nd, 2007 at 11:38 am
Ryan – another great post.:)
This is a problem that bleeds over into the design world. A few designers I work with are amazing at web page graphic design and great at usability but have a hard time understanding the principal of ‘an app has states, not pages’. The two are not the same and shouldn’t be treated as such. Heck, most of the Flex apps I build are used as Desktop RIAs wrapped in Zinc but (hopefully) soon to be wrapped using the Apollo runtime.
Dimitar – It sounds like maybe Flash/Flex is not the best tool for your current situation.
February 22nd, 2007 at 11:56 am
I would just say that there are folks don’t understand outside the browser because even though there has been support for outside of browser network function for sometime people perceieve internet applications to be not native to their computer because they work “everywhere”, as opposed to their word processor.
If you look at the results of anti-trust lawsuits etc. you will notice that the courts blocked anything “outside” of the browser so applications were either one or the other. That is now changing.
February 22nd, 2007 at 12:49 pm
Indexing is usually irrelevant because 99% of “web applications” require a login of some sort, so never get indexed by google etc anyway, and even if they did, people do not search for applications they search for documents. So long as those underlying documents are accessible somehow in plain old text or HTML then it doesn’t matter what flex/ajax hackery you do around the diges.
Permalinks are however still relevant. Just because they don’t fit into flash and there aren’t any in word it doesn’t mean they aren’t valuable. If I’m using a webapp to generate some document or graph or whatever, I want to be able to come back to it sometime later. In an ‘old’ app, you’d save the file. In a webapp the bookmarking interface fills this role, and any attempt to implement a desktop-ish file saving emulator is going to come off feeling like the ugly hack it is.
Likewise the back button is relevant. Desktop apps don’t have back buttons… well actually a lot of them do these days, and the ones that don’t will either have some similar action (closing a modal dialog is similar conceptually to ‘going back’) or provide an UNDO function.
The web doesn’t do these things because the back button is it’s interface to that functionality, and once again trying to emulate a desktop system on what is not the desktop is going to be an ugly hack.
You can’t just ignore the world and say they’re wrong because it doesn’t fit what you’d like to see. A RIA is not just a desktop application being delivered via the web, it’s something new and different.
February 22nd, 2007 at 1:00 pm
[...] (j’ai écrit ce billet suite à la lecture de ce billet de Ryan Stewart) [...]
February 22nd, 2007 at 7:34 pm
David – the “universal desktop”, “search sites, not applications” is what I find so terribly 90’s. Haven’t we heard this story before? Java Applets, ActiveX, XUL…
Honestly – In 1996, Java Applets were being heralded in some technology rags as “bringing animation to the browser,” before they were heralded as “bringing rich applications to the browser – all platforms will be rendered equal!”
And now in 2007, a technology that actually started life as a tool to bring animation to browsers (FutureSplash!) is getting the same kind of accolades. Feels like a time warp to me…
Java Applets never lived up to the wild and speculative visions. What makes Flex different (aside from language)?
February 23rd, 2007 at 12:33 am
Good points. Unfortunately, Flex is still served to the browser as a web page containing HTML content, which makes it difficult for things like search engines and assistive technologies to tell the difference between a URL that should be treated as a page, and a URL that should be treated as an application.
It looks like Adobe is trying to clear this final hurdle to a “web of applications” with Apollo. If they can address the runtime installation issues that, in my opinion, sunk Java Web Start, they just might be onto something…
February 23rd, 2007 at 4:43 am
Homerun here Ryan. Great work.
There is definitely a blurring of the lines here with what the back button means in a web app. When it makes since for the back button to work then it should be supported. As a developer it’s a nice challenge but managers have to understand the time hit that it’s going to make on the project. It’s going to be a learning experience for the first few attempts and that means extended delivery dates.
February 23rd, 2007 at 3:10 pm
[...] Ryan Stewart – Rich Internet Application Mountaineer » Stop Thinking of Flex As a Browser Technology. Seriously. Stop It. Yaniv Golan doesn’t get Flex, which is fine. He talked to Mark Anders at the Future of Web Apps and he doesn’t understand why people would choose vendor-lockin when you can do the same things with standards based Ajax. (tags: flex browser programming ajax web2.0) [...]
February 24th, 2007 at 12:43 am
User control over app state…
User control over app state: Ryan Stewart sparked a good discussion here about saving an application as a browser bookmark. A WWW browser can jump back among the different pages it has rendered, or can save a page as a bookmark to come back to later. B…
February 24th, 2007 at 10:25 am
[...] The always awesome Ryan Stewart had a couple of really good articles this week over at http://www.digitalbackcountry.com and http://www.zdnet.net discussing a stigma in the RIA community right now – developers and designers have to stop thinking about design and usability of browser/desktop RIAs as if they were web pages. [...]
February 24th, 2007 at 12:42 pm
[...] Gesamter Artikel: Stop Thinking of Flex As a Browser Technology. Seriously. Stop It. [...]
February 25th, 2007 at 10:57 am
Ryan,
In one of the comments, David said about my post “his comments are SO 1990’s”. This is spot on… back in 1990’s, I’ve developed my first web applications using CGI and friends. A bit later in the 1990’s, I architected and developed several large enterprise scale solutions. The initial versions were built with Java (client side), and later with a combination of HTML + ActiveX + Java applets. It was a complete disaster from a user experience point of view.
When the time came to re-architect our enterprise app (actually, it was a highly customizable framework / app), the lessons were clear – we labeled them RUB: R = Refresh must work, U = everything must be URL-addressable (e.g permalinks), and B = Back must work as expected.
I believe these lessons still hold in 2007, and even more so. The people who use the applications we build for the enterprise were “brought up” (e.g. introduced to computing) using Google, not SAP. When they see an application running in a browser, they expect it to work like they’re used to – they except to be able to hit the back button and have it do what they think it should be doing. They expect to be able to bookmark something so that they can return it later. They would like the default interface for finding an object in an application to be a full text search.
I don’t think they’re aware, or care about things like application states or delivery mechanisms. My experience is that if it looks like a browser, people expect it to behave like a browser. Hitting back to go to the “previous page” is by now almost a natural instinct for people.
When going beyond forms and lists, and venturing into the domain of online text editors or vector drawing tools, they rules change – we’ve educated people to understand that hitting Back will cause them to lose their work and not to “undo”. Mind you, I am not saying this makes sense or is logical, only that this is what today and tomorrow information workers are used to.
The “page” model works for delivering functionality-rich enterprise applications. The page model can easily be enhanced for specific functionalities, like rich text editing or complex graphical query interface with Java Applets \ ActiveX components \ Flash components and now Flex components. There are known techniques for dealing with special cases (like implementing permalink-enabled master-detail browsing without page refresh using the # technique).
Since it works, and since it is what the people who are using our applications are used to, why not align with this and engineer our applications and their states to be compatible with this model. It’s always best to have the application align with the user mental model of how it works, instead of trying to re-educate users.
Mind you, I am not advocating that every application state should have a different URL, and that any object should be searchable and accessible separately. The challenge is architecting your application so that it behaves like the user expects it to – in this case, with regards to R, U & B.
February 26th, 2007 at 11:39 pm
[...] When SWF application cannot natively, easily support for back button, deep linking. Flex zealot will argue it is an application, it is not a website, no need for care about such issue. Why users still ask for such requirement? Because even Flex developers are still stay on the concept of “page based application” instead of “screen based application”. [...]
March 1st, 2007 at 12:42 am
The problem with FLEX isn’t with the technology itself. The problem is FLEX’s licensing. It is closed and proprietary. This incurs a business risk. Before you say Adobe will never screw over FLEX users, look at what happened to MS Visual Basic 6 developers and what could possibly happen to Peoplesoft users….
March 14th, 2007 at 2:01 pm
Flex certainly has it’s place in the world but is it with web applications?
User growth is going to come from non-PC/Mac based devices such as phones, PDAs etc., how does Fflex fit into this model – yes some of these platforms have Flash but will the applications work as well?
When pretty rich applications can be built using xhtml, css, javascript etc., and these applications can be ‘easily’ adapted where does Flex fit and why would someone choose Flex over OpenLaslo?
March 15th, 2007 at 7:58 am
In case he hasn’t noticed, hitting Back on the browser is already dying.
March 22nd, 2007 at 11:44 am
Thanks man, i agree
March 26th, 2007 at 3:10 pm
Is this a wordpress blog? or some other software?
July 1st, 2007 at 8:16 pm
I agree with Ryan that it is hard to have a RIA act as a webpage, it is an application.
But if you are having your application load in a browser and having the back button visible, then the users will try to click it they think it will take it to the previous screen or “state”.
The best way to avoid the back button is do like fauxto: http://www.fauxto.com/ and open the application in a window without any toolbars.
fauxto doesn’t need any bookmarking so there’s no need to implement that, but I reckon most of the RIA’s still need this.
As Yaniv Golan was talking about R,U and B I believe a lot of apps could implement this, and it will be extra value added to the application and keep it more user friendly.
As some frameworks start popping up, I think this will be easier to implement.
Take for instance swfaddress, this is very useful for deep-linking and also the back-button.
It’s the developer that needs to add the calls for the different states.
July 1st, 2007 at 9:10 pm
This fight never gets old
This is the price we all pay for wanting to break way from the browser model, but aren’t bold enough to make it happen. AIR is your only friend in this battle with regards to changing the model of FLEX usuage in the way Ryan has described.
You can’t whip the puppy for its puddles on Monday, only to reward it for the same thing Tuesday.
“..It’s hard to soar like an eagle when you’re surrounded by turkeys..”
-
Scott Barnes
Developer Evangelist
Microsoft.
December 3rd, 2007 at 6:27 am
Interesting info
Thanks for article