So I'm a bit 'biased' here as well. Something that gets missed in a lot of these conversations is presuming that going with a standards-based site or a FLEX/Flash/X approach is an either or choice. In the past this was largely the case and the power of the browser has made that a singular platform of choice for many folks but it's doubtful this will be a viable strategy in the future. As many of the applications of the future increasing move to ad supported models, develop service-oriented orientations or scenarios that require data to move across or be accessed from different devices we are going to see designers asked to build optimized experiences for multiple different channels.
This means in the future you might build a standards-based Web site. A site optimized for a specific mobile platform. A desktop client and even some proprietary interface that is kiosk-based perhaps. There's a barrier to this right now in that it's really expensive and labor and skills intensive to pull this off. But in the future, in the spirit of competitive differentiation those that can will do this. One of the things that makes technology like Flash (and hopefully soon things like AIR, Flex, Silverlight and stuff like Google Gears compelling) is that it might just be an easier way for companies to build things that work elegantly from a user experience perspective than in a standards-based method. It may be 'possible' to do so in each but you may be better off taking advantage of the inherent strengths of each technology versus picking one at the exclusion of the other. Sometimes this may happen in parallel or sometimes you may start with something that needs to evolve into something else for scalability. Which is the thinking behind dynamic runtime engines that will be able to take Ruby, Python and even JavaScript and run more effective using a virtual machine. Similarly we may find that some applications demand the lightweight disconnected functionality that AIR or Gears can provide or will require a more embedded solution focused on WPF or a Cocoa application. >From a developer perspective companies will want to strive to attract talent >pools to their platform and tools that can be flexible and execute against all >these scenarios versus just one. The promise of things like Flex, Flash, AIR, >Silverlight, WPF and Gears is that they all promise development models that >promise ways to target more than just one channel with a common set of skills >and tools. I think all of these technologies are going to enable a new >ecosystem of software development that is far, far bigger than even the Web is >now. Success of all these platforms will really boil down to the effectiveness >of the tooling, the speed and flexibility of the development processes for the >platform, security and stability, and (perhaps most importantly) the size and >quality of the talent pool. Proprietary offerings will also need to continue >to balance the value of openness in their platforms and develop compelling ROI >models for the acquisition costs and TOC to be competitive with standards-based offerings as well. The other thing that will matter is the actual processes we use to design for applications right now. I think we often operate under the assumption that it won't change. Right now our design processes are borne of the same techniques and tools that were largely developed and optimized by digital print production. It's easy to forget that in a little less than two years the valuable skill of being an analog paste of artist went the route of the blacksmith when print production when digital. The question we have to ask ourselves is if these existing practices and standards are going to serve us well in the future or undergo a similar rapid transitions. Tools like Thermo are exciting to us because they help us preserve familiar work practices and processes. But there's a price we pay in preserving the familiar too and that's that it might not really be the best way for us to collaborate and design the software that will have to run on all sorts of different systems and devices and be a hybrid mix of open and closed technologies. We may make personal choices to standardize on one toolset, technology or platform but the markets that pay us for our work may choose otherwise or demand that we master new skills that we might be uncomfortable with. Worse still, we may see direct competitors embrace new methods or tools that allow them to go to market more effectively than we are able to with our existing design methods. What should be exciting for all of us is that having all of these companies vie for our attention creates a competitive environment that is ripe for innovation. I don't think I'd be dismissive of any of these new technologies at this point and I don't think we're talking about a zero sum game where picking one approach automatically discounts ever using another in conjunction with it. These technologies all have large audiences that can execute against them today and the ultimate success will be by those that can leverage the value of their ideas around creating great experiences in the fastest and most effective way possible. Chris Bernard Microsoft User Experience Evangelist [EMAIL PROTECTED] 630.530.4208 Office 312.925.4095 Mobile Blog: www.designthinkingdigest.com Design: www.microsoft.com/design Tools: www.microsoft.com/expression Community: http://www.visitmix.com "The future is already here. It's just not evenly distributed." William Gibson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Meeker Sent: Monday, March 24, 2008 4:13 PM To: Andrei Herasimchuk Cc: IXDA list Subject: Re: [IxDA Discuss] Flex? (was: What's exciting in Adobe Thermo?) I've been really trying to stay away from this... but I have to chime > in. Uh Oh. :) > > > 1) Write once, deploy cross platform > > That "pro" is also it's biggest con, in that you are tying yourself, > your product and everything you do to Adobe in what is effectively a > closed and proprietary format. In other words, you are at the mercy > of the Adobe folks getting it right year over year as technology > continues to evolve. > Agreed. But, with any software, you have to have some faith. Added to that is Adobe's deal with Mozilla this year to license the scripting language to them for inclusion in the browser framework. For me, I think it is as simple as recognizing that Flash (player) isn't going anywhere, is installed on 98.5 (or more) of the computers out there, takes only a minute to install on machines that don't have it, and because of that is pretty much ubiquitous. Lesson #2: Don't launch a mission critical application using any brand new technology you've been working with it for a while and think you've mastered it (or you know a bunch of engineers at Adobe who work on the Flex team). > > > 2) You can turn your Flex application into a desktop application > > without > > much code refactoring (using AIR). > > Indeed. This is a nice argument for creating a thin client product. > But mixing these products into browser environments as well as having > desktop versions is massively confusing in my opinion. I actually > think Flash/Flex is better for the thin client approach, and > desperately wish people would stop embedding massively complex Flash > apps inside web browsers where they make little sense. > I don't disagree with you here. Like anything though, "good" experiences and "bad" experiences shouldn't be blamed on the technology itself, rather the implementation of an idea using a particular technology. I've seen the same concept built by two different teams and feeling that one of them sucked pretty bad, while the other was brilliant. It comes down to execution, paying attention to the little details that can make an embedded application give off bad UX vibes, etc. > > > 3) With the evolution of browsers, you can be less concerned about > > how to > > migrate your code to keep up with changes in the Document Object > > Model in > > AJAX, as the Flash player is backwards compatible. > > This is an argument for dropping the web browser as a development > platform. However, if Adobe ever were honest about that product path, > they'd probably lose 90% of the people who would even be interested > in using Flash/Flex. Why? Because the products would live outside the > massive deployment model of the web browser. Unfortunate as that is. > I hear you. I still think that adobe (like a lot of software companies) have the official plan, but are very cognoscente of the change in the market, etc. I don't think Adobe wants to kill the browser as a platform by any means... (case in point, the deal with Mozilla). Let's face it... it is a hell of a lot easier to deploy a web application than a desktop application. AIR solves some of that, but it still isn't as simple as just going to a URL and having the application sitting there for you. The downside to browser-only applications is that there is not any integration with the desktop. Some of the cool things that a platform like AIR brings you is the ability to drag items (a spreadsheet for example) into the application and have it converted to consumable data on the fly. Some of the comments I have made regarding Mozilla refers to the Tamarin Project: http://www.mozilla.org/projects/tamarin/ > > 4) The Flash player now has hardware acceleration... so you can > > build UI's > > that look and feel the way YOU want the to, and not be limited by your > > development technology > > No. You are still limited by whatever Flash can or cannot do as a > platform. Let's not even bring up how crappy text handling still is > to this day in the Flash rendering environment. You are limited by any of the technologies that we have. Flash isn't perfect, but it is arguably the best we have at the moment. Also... I've been fortunate to work with some of the best and brightest Flash developers out there. So, can flash "do it all?". NO. Can an ActionScript Ninja who really understands the SWF format and the inner workings of the Flash player work magic? Amen. > > 5) 3-d integration (using papervision or another framework) > No one cares about this. Ok... maybe 3% of the development teams out > there do... but really, no one cares about this point. They will. :) check out searchme.com as an example of why. > > 6) Handles LOTS of data much, much, much better (data grids with > > tons of > > rows, etc) > > Based on what metrics? I have yet to find a Flash/Flex app that > handles large sets of data faster or better that a well implemented > browser or desktop version. They all have their pitfalls, especially > when done improperly. And yes, this includes and understanding that > even if you could display a thousand rows of data in less than a > second, people can't process it on something as coarse as the > resolution of a computer screen, so who cares? I could provide proof of concept after proof of concept that I or coworkers have developed that demonstrate this. I will not say that a compiled desktop application suffers from the same lack of data handling that you'd find in the browser though. Desktop binaries are a different class, and would most likely outperform an application in Flex. (almost definitely). But when it comes to pure handling of data, Flex beats Flash, and most of the AJAX frameworks. You also have to take into consideration that if you use Flex with BlazeDS or LiveCycle DS or even products like Midnightcoders' Web Orb, you also benefit from the data compression and passing of native objects between the server and the client. > > All in all, it's been a really good tool in my experiences... But I > > preface > > that by saying I've been fortunate enough to work with some pretty > > talented > > software engineers that really know the framework and how to make > > it sing. > > That's obviously a big issue. The thing I have yet to understand is > that if I'm working with that kind of engineering group, which I have > have done so many times in my past, why not just build a real desktop > client application and regain control of everything you need to gain > control of. Point taken. I don't argue with you here, except for the fact that the "Web" is king and the large majority of these apps have distinct business requirements that require them to be deployed online. The flipside of this is that with the reintroduction of thin-clients (AIR, WPF/Silverlight) the notion of having "Web" or "Network" connectivity inside your application should be taken as an obvious thing to include in the architecture. I agree though. If you want maximum performance... bring your application to the desktop. If you have to play in a world with requirements that require it to be deployed in a different manner..... > Sure, *some* of the up front engineering may take a tad > longer than going the RIA route, but given the total and full amount > of control you'll get for that investment, True. (again!) > > > Now... I'm not saying Flex/Silverlight or any of those technologies > are bad or anything. But what I am tired of are people who aren't > discussing the pros and cons of all of them at a purely agnostic, > "what happens" level, letting people decide for themselves what they > really need to do for their product development. Your list crosses > that line for me. I am an agnostic guy. I have to be. I have a lot of experience with Flash and for the last 4-5 years, Flex... but there is the right tool for the right job, and it might not always be a flash-player based RIA. Case in point: I am working on a project now which is an internal application to be deployed world-wide for a corporation that needs to have the ability to tie in a device plugged in via USB or serial cable with a web application. Whoa.... This will be MSIE only, utilizing AJAX as a UI and data transmission layer with embedded Flash content and OS integration (USB) using a (gasp) ActiveX Control. When was the last time you heard that! :) Thanks for the fascinating challenges to my point of view and the interesting discussion. dave ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
