This post originated from an RSS feed registered with .NET Buzz by Eric Wise. Original Post: Rich ASP .NET Applications Feed Title: Eric Wise Feed URL: /error.htm?aspxerrorpath=/blogs/eric.wise/rss.aspx Feed Description: Business & .NET Latest .NET Buzz Posts Latest .NET Buzz Posts by Eric Wise Latest Posts From Eric Wise

Peter blogs about why not to focus on building richness into your web applications.  I'd like to go on record that I both agree and disagree with him.

Know Your Audience

Are you building an inward-facing application where all the user's hardware is known and everyone is using the same version of a browser?  This is the perfect situation in which to build as much richness as the users desire into the application!  Outward facing applications can be rich as well, but it does depend on your audience.  If you are serving a known community, like a customer portal, then you can legitimately recommend certain browsers for use in your site.  The more public and anonymous your users get the more you have to back away from richness.

Relative Sizes

Once again, know your audience.  If you're aiming at the general internet you had best make sure that your site behaves nicely on 800x600 resolution.  Also try to anticipate the relative bandwidth users have.  Obviously in the more general internet there are many users still on dialup connections and we don't want to give them a user experience laden with graphics and flash that take a long time to load.

Drilling Down

For the most part this is fine, but try to come up with a navigation system that can accomodate people who know where they are going and want to jump directly to it.  I definitely agree with not cramming many different functions onto a single webpage.  This can cause information overload in a lot of users.  I try to follow the rule of thumb of one page, one purpose.

Context Menus Are Evil

I've never been able to get the average joe blow user to "get" context menus.  Putting context menus in your application is just like begging for more calls to the help desk.  In addition, on sites that are more public facing an older browser may not know how to render the context menu and then suddenly you have a user that can not access the functionality.  In this case you have to detect the browser and render the menu items on the page anyway.  I just feel this is way more trouble than it's worth.