Best And Worst Practices Building Ria with Adobe and Microsoft
•Als PPT, PDF herunterladen•
8 gefällt mir•3,067 views
Come listen to leading Rich Internet Applications (RIA) experts from Microsoft and Adobe discuss many of the best and worst practices when building RIAs. RIAs provide a similar user experience to traditional desktop applications combined with the ease of deployment of web/browser based applications. This produces a fair amount of confusion because there are a number of potentially conflicting practices depending on whether you approach your RIA as a desktop or a web application. This session dives into the definition of RIA and walks through the best and worst practices that have appeared over and over again. We will explore architectural patterns and practices such as state management, fault tolerance, service composition, communications protocols and message formats and goes into details on how RIAs can be developed using runtime environments such as Adobe AIR or Microsoft Silverlight. For more read our blogs at http://www.jamesward.com http://www.joshholmes.com
![Contact Josh Holmes RIA Evangelist [email_address] joshholmes.com James Ward RIA Evangelist [email_address] jamesward.com](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Andere mochten auch
Andere mochten auch (16)
Ähnlich wie Best And Worst Practices Building Ria with Adobe and Microsoft
Ähnlich wie Best And Worst Practices Building Ria with Adobe and Microsoft (20)
Mehr von Josh Holmes
Mehr von Josh Holmes (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Best And Worst Practices Building Ria with Adobe and Microsoft
- 1. Best and Worst Practices Building R IA from Adobe and Microsoft
- 2. Contact Josh Holmes RIA Evangelist [email_address] joshholmes.com James Ward RIA Evangelist [email_address] jamesward.com
- 3. What is by Kushal Das
- 4. RIA for me is all about expanding the experience for the user. Those "gray beards" amongst us remember the old days of just being happy seeing plain, static text show up in the browser . We've come a long way since then. While dynamic web sites have pushed us way beyond the simple pages of the old days, RIA is helping us now provide the same level of dynamic interaction on the client side as well. I think this is wonderful as it improves the entire process (server and client)! While we have a great opportunity here to help users, the challenge is to not actually make things more difficult . Like any new feature, the web is rife with examples of poorly designed and hard to use applications. It is not enough to learn how to make HTTP requests and change content dynamically, but rather how to do it well in ways that help the user and not scare them off. Raymond Camden http://www.insideria.com/2008/01/what-is-ria-1.html
- 5. But the term still begs the question: Rich in what sense? Responsiveness, immediacy, convenience? production values, chrome, animation? http://www.insideria.com/2008/01/what-is-ria-1.html Christian Crumlish
- 7. Back Button and Refresh Visual Vocabulary State management Browser Sandbox Business Logic in UI Component Level Logic Animation new for Desktop Developers new for Web Developer What’s different with RIA? Limited Runtime Service Orientation Non-text based layout Hype
- 8. Ubiquity Richness Next Generation
- 15. Taliesin West: Drafting Studio
- 28. ..but don’t forget the power users 70 20 10
- 35. with usability
- 49. by Caution Mike
- 52. private void Application_Startup( object sender, StartupEventArgs e) { string startPageParameter = "/StartPage" ; if (!e.InitParams.ContainsKey(startPageParameter)) { this .RootVisual = new DefaultStartPage(); } else { switch (e.InitParams[startPageParameter]) { case "DefaultStartPage" : this .RootVisual = new DefaultStartPage(); break ; case "NonDefaultStartPage" : this .RootVisual = new NonDefaultStartPage(); break ; default : throw new Exception ( "/StartPage must be 'DefaultStartPage' or 'NonDefaultStartPage'." ); } } }
- 56. by billaday
- 65. by joeltelling
- 73. by mikeyexists
- 77. Best and Worst Practices Building R IA from Adobe and Microsoft
- 78. Contact Josh Holmes RIA Evangelist [email_address] joshholmes.com James Ward RIA Evangelist [email_address] jamesward.com
Hinweis der Redaktion
- Contact information – I don’t hide on the internet, I’m joshholmes.com, joshholmes on facebook, joshholmes on linked in, joshholmes on twitter and most of the other social networking sites out there. If you don’t take any other notes – get my email address down because you can take the slides home but you can’t take me home… Unless you’ve got really good Scotch.
- The first question that we have to answer is “What is R.I.A.?” http://www.flickr.com/photos/88746839@N00/2102287933/
- Raymond Camden did an interview for InsideRia back in January 2008 and said - Ria is about the experience in the browser – pushing dynamic web sites on the client side. The challenge is not to actually make things more difficult. Poorly designed applications do not help the user.
- In the same article, Christian Crumlish wisely asked the question – Rich in what sense? There are thousands of things that you could mean by rich. So what do we mean?
- And then if you go to Wikipedia (the compendium of all human knowledge), they define Rich Internet Applications as web applications that bring the features and functionality that has traditionally been reserved for desktop applications. It’s about the user interface on the web but keeping the state and et all on the application server. RIAs run in a web browser and do not require a software installation (for this exact application – a plug-in may be required to provide the RIA platform but this application doesn’t require an install) and runs in a secured sandbox.
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- Form factor that supports needs User context Different ux/data on different forms (phone, desk, xbox) Different users, different needs Try to make all options doable on the platform It's all about the end user! Be an advocate for the end user Know your users define personas behaviors & workflows proficiencies & deficiencies Fight for what you feel they will really benefit from Photo credit: http://www.flickr.com/photos/frischmilch/
- Frank Lloyd Write was a huge proponent of form following function. This is a picture of his http://www.flickr.com/photos/ddwise/2312837211
- He often spent more time inside than he did outside. He invented furniture, track lighting, acoustical techniques and a ton more. The tie back here is that we should some time thinking the architecture of our client side as well as our server side and how it fits in with the rest of the application. http://www.flickr.com/photos/sminor/316037308/sizes/l/
- Model-View-Controller is the concept introduced by Smalltalk's inventors ( TrygveReenskaug and others) of encapsulating some data together with its processing (the model) and isolate it from the manipulation (the controller) and presentation (the view) part that has to be done on a UserInterface . A model is an object representing data or even activity, e.g. a database table or even some plant-floor production-machine process. A view is some form of visualization of the state of the model. A controller offers facilities to change the state of the model. Smalltalk provides mechanisms to link models, views and controllers in some standard way in order for a model to communicate state changes to every attached view (there can be several, as you can see). Model state changes happen either because a controller issued some command or for some internal reason. An easy way to understand MVC: the model is the data, the view is the window on the screen, and the controller is the glue between the two.
- The MVP pattern is a UI presentation pattern based on the concepts of the MVC pattern. The pattern separates responsibilities across four components: the view is responsible for rending UI elements, the view interface is used to loosely couple the presenter from its view, the presenter is responsible for interacting between the view/model, and the model is responsible for business behaviors and state management. In some implementations the presenter interacts with a service (controller) layer to retrieve/persist the model. The view interface and service layer are commonly used to make writing unit tests for the presenter and the model easier. Key Benefits Before using any pattern a developers needs to consider the pros and cons of using it. There are a number of key benefits to using either the MVC or MVP pattern (See list below). But, there also a few draw backs to consider. The biggest drawbacks are additional complexity and learning curve. While the patterns may not be appropriate for simple solutions; advance solutions can greatly benefit from using the pattern. I’m my experience a have seen a few solutions eliminate a large amount of complexity but being re-factored to use either pattern. · Loose coupling – The presenter/controller are an intermediary between the UI code and the model. This allows the view and the model to evolve independently of each other. · Clear separation of concerns/responsibility o UI (Form or Page) – Responsible for rending UI elements o Presenter/controller – Responsible for reacting to UI events and interacts with the model o Model – Responsible for business behaviors and state management · Test Driven – By isolating each major component (UI, Presenter/controller, and model) it is easier to write unit tests. This is especially true when using the MVP pattern which only interacts with the view using an interface. · Code Reuse – By using a separation of concerns/responsible design approach you will increase code reuse. This is especially true when using a full blown domain model and keeping all the business/state management logic where it belongs. · Hide Data Access – Using these patterns forces you to put the data access code where it belongs in a data access layer. There a number of other patterns that typical works with the MVP/MVC pattern for data access. Two of the most common ones are repository and unit of work. (See Martin Fowler – Patterns of Enterprise Application Architecture for more details) · Flexibility/Adaptable – By isolating most of your code into the presenter/controller and model components your code base is more adaptable to change. For example consider how much UI and data access technologies have changed over the years and the number of choices we have available today. A properly design solution using MVC or MVP can support multi UI and data access technologies at the same time.
- So what really are the differences between the MVC and MVP pattern. Actually there are not a whole lot of differences between them. Both patterns focus on separating responsibility across multi components and promote loosely coupling the UI (View) from the business layer (Model). The major differences are how the pattern is implemented and in some advanced scenarios you need both presenters and controllers. Here are the key differences between the patterns: · MVP Pattern o View is more loosely coupled to the model. The presenter is responsible for binding the model to the view. o Easier to unit test because interaction with the view is through an interface o Usually view to presenter map one to one. Complex views may have multi presenters. · MVC Pattern o Controller are based on behaviors and can be shared across views o Can be responsible for determining which view to display ( Front Controller Pattern ) Hopefully you found this post interesting and it helped clarify the differences between the MVC and MVP pattern. If not, do not be discouraged patterns are powerful tools that can be hard to use sometimes. One thing to remember is that a pattern is a blue print and not an out of the box solutions. Developers should use them as a guide and modify the implementation according to their problem domain. http://www.flickr.com/photos/14448070@N00/1584043910/sizes/o/
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- 5-10 principles or values that guide your decision making process These are you guideposts to focus your thinking when you have to make a tough decision The fewer the better Helps to make sure entire development team understands the big picture and cares about the end user Examples: Speed before beauty 3 clicks or less Drag & drop instead of menu commands One that I always use is that if you have to hit search for normal navigation, then I’ve failed in the design. Photo credit: http://www.flickr.com/photos/psd/
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- Use the appropriate level of fidelity. There are two places that this is important. (next slide) Photo credit: http://www.flickr.com/photos/sarchi/
- First, in the design phase. When you draw a form with a black marker on a white board, people don’t expect that to ship next week. They also don’t start arguing over color choices or logos or exact placement. Rather they start looking at the rough functionality and focus in on that. http://www.codeplex.com/protoxaml
- The second place that fidelity comes in to play is in the level of detail that you should your user. As an example, when someone is looking up a phone number, do you need to show them the 4 addresses, resume and all recent communications? Maybe – probably not. But you should definitely have that as a close at hand option. The same goes for reporting – what’s your audience? Your CFO doesn’t need to see how much you spend on a pencil but does need to know how much office supplies are over the entire company. This is one of the things that Deepzoom is really good at. Let’s take a look at this Virtual Earth example and see how that works. As you zoom in, you get more and more detail because more is warranted. It makes no sense to show street level information from the sky.
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- They’re not necessarily the same person! Usertest.com is a great site for letting public users use your application and provide feedback. Photo credit: http://www.flickr.com/photos/piccadillywilson/
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- Build for easy learning curve Minimize training Use standard keyboard and mouse shortcuts Use focus and tabbing conventions Nobody reads manuals! However: Don't forget the needs of power users (70/20/10 rule here!) Easy to learn, lifetime to master Photo credit: http://www.flickr.com/photos/thiru/
- Just as two objects can’t occupy the same space, two people can’t edit the same data with out a conflict. Build for multi-user concurrency right up front. Optimistic concurrency is NOT concurrency! Photo credit: http://www.flickr.com/photos/conanil/
- Decide where the logic and processing balance on where’s the logic? Client/Server - this line is starting to get more and more blurry but there are some guideposts that we can throw out there. Deciding on where the data goes. What’s the balance between client side/server side. Think S+S and multiple clients and state management. Speed verses flexibility. Photo credit: http://www.flickr.com/photos/saschapohflepp/
- This neat system allows more than one person to open the gate, each using their own key. Overdone security can kill the user experience. If there is too much impedance, smart users will do their best to get around all the locks Too much security leads to systems that are hard to administer and maintain Photo credit: http://www.flickr.com/photos/psd/
- Smart error messages and reporting Troubleshooting by end users and support staff Instrument the application for feature usage tracking If you don't plan on maintaining a dev staff, avoid completely custom code Build for agility Web services are the ultimate decoupling tool Build for ease of deployment Photo credit: http://www.flickr.com/photos/oskay/
- Not thinking about the offline usage with a complimentary mobile app or WPF application Smart error messages and reporting Troubleshooting by end users and support staff Instrument the application for feature usage tracking If you don't plan on maintaining a dev staff, avoid completely custom code Build for agility Web services are the ultimate decoupling tool Build for ease of deployment Photo credit: http://www.flickr.com/photos/oskay/
- Why? Is it pretty? Is it functional? Is it compelling? (Does it make you want to use it?) Does it improve your quality of life? Does it just plain work?!? What would make it better?
- No best practices talk would be complete without some worst practices.
- Remember that HTML/Javascript still rock. They are very good at information dispersal. There are a number of RIA applications that have been thrown out there into the world that have made the user’s life more difficult. If you need simple dispersal – then HTML is probably the right choice for you. http://www.flickr.com/photos/rocketnumber9/7731212/
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- The issue with the refresh button is that when someone clicks it, it takes the application out of memory and completely reloads it. In the windows world, it’s as if they pulled up task manager, killed the app and restarted it. There are a lot of strategies that one can take to deal with this. One is just let it happen and start over at the beginning of the application. Sometimes, that’s the right move. Another idea is to write out the status every time there is a change. This could be server side or client side depending on the circumstances. Another idea is to write out the status on unload. If you write out the status, you need to write in the loader the function that checks the status and sets the application appropriately. http://www.flickr.com/photos/randomchu/251646898/sizes/l/
- Quick sample code in the app.xaml.cs to deal with the startup.
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- Do not break web standards. Don’t do things like trying to disable the back button/refresh button and so on.
- http://www.flickr.com/photos/billselak/2198421021/
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- http://www.flickr.com/photos/joeltelling/69492277/
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- Regardless of your front end technology, too many containers is a bad thing. It slows down rendering, adds memory, becomes hard to maintain and locks you into a single display format. This is bad for a number of reasons. There’s a push in HTML world to get away from tables in favor of CSS because you can swap out the CSS and radically change the layout from say three columns with a right hand nav to a mobile layout with a nav bar across the top or something. That promise only comes true if you don’t get into the other trap of divitis. That’s substituting divs for tables and going nuts that direction. The same is true in Silverlight, WPF, Flash, Flex, JavaFX, Winforms – name a UI technology. Too many containers becomes a bad thing. http://www.theiff.org/oexhibits/paper06.html
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- http://www.flickr.com/photos/63101308@N00/451421591/
- Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff). Breaking standard browser experiences. Slowing the application down with the use of too many containers. Slowing the application down by using XML for data transfers over optimized protocols (read binary when possible or compressed) Not applicable from the article but we could add one easily here. Forgetting about the page refresh – that could be our sub there. Over use of animations Not setting up an enterprise ecosystem Not using the entire framework Slowing the DataGrid (and any other control) down with complex renderers Not thinking about the offline usage with a complimentary mobile app or WPF application
- Religion does not belong in technology decisions. That true from the UI/Server technologies that you work with to the architectural practices that you employ.
- Why? Is it pretty? Is it functional? Is it compelling? (Does it make you want to use it?) Does it improve your quality of life? Does it just plain work?!? What would make it better?
- Contact information – I don’t hide on the internet, I’m joshholmes.com, joshholmes on facebook, joshholmes on linked in, joshholmes on twitter and most of the other social networking sites out there. If you don’t take any other notes – get my email address down because you can take the slides home but you can’t take me home… Unless you’ve got really good Scotch.