Running apps In the browser or Out?

I have been doing some thinking recently about what sort of client application model would benefit customers the most. It seems very clear that parts of the web application model are super important (URL deployed, seamless\transparent install and update, server centric deployment, etc) and we have to provide those in whatever model we build. But there are a few other attributes of web apps (like running the browser frame, navigation, etc) that are also true of web apps today (ASP.NET apps, Atlas apps, etc) but in many ways we have (or could build) the technology to apply all these attributes to out of browser apps as well. So the question I am struggling with is how to think about the end-user model of what runs in the browser or not. That is what is your mom’s expectation when an app runs in browser vs out of browser. There are two schools of thought here…

 

Purely as cosmetic choice – There are no really deep differences between in browser and out of browser apps. We want (nearly) every one of the traditional out of browser experiences (shell integration, offline support, roubutness) in browser apps and likewise we want (nearly) every one of the traditional benefits of browser apps in the out of browser experience (navigation, bookmarks, deployment, etc). Under this model you can imagine it is simply a config file change if you want to run the app in a browser or not…. We possibly allow it to even be a user configurable option. I think XBAPs are a step down this road…

 

Browsers are for connected apps - There is a deep difference in expectations in users – they expect browser apps to be very transient in nature, to primarily be connected and to have limited integration with the shell. Whereas out of browser apps should be thought of as primarily for occasionally connected apps that do have integration into the shell (start menu, file association, etc). Of course we still want all the deployment, install sort of benefits etc of a web app… Think of ClickOnce as a step down this road.

 

Again, we have the technology to do either of these – it is mostly about what users want\expect and more importantly will want\expect in the future…. So please go quiz your mom, non-technical co-workers, your barista and let me know what you find out!

Comments

• Anonymous
  August 24, 2006
  
  Huh? Web apps have discoverable UIs. There is no right-click, no double-click, no menu bar. Everything is in your face. If you run a XBAP app in a browser designed to reflect the Windows UI guidelines, then you expect users to discover functionalities by right-clicking or double-click.
  
  Mom is not going to do much with it.
  

• Anonymous
  August 24, 2006
  I agree with Stephane; i talked about AllPeers to my moom, she seems to have enjoyed ;-)
  
  Their current slogan is the best: "Forget about complicated setup or obscure user interfaces. If you know how to use Firefox you know how to use AllPeers."
  
  And for mom, each entity is a resource, simply and uniquely identified by a URL :)
  
  So, we need a true feed platform, with syndication technologies such as RDF,  Atom, and RSS. REST Design Pattern! Here is a future...
  
  Kind regards...

• Anonymous
  August 24, 2006
  In my life as a developer I have somehow never been on a project where I was creating a windows forms

• Anonymous
  August 24, 2006
  I think the answer to your question is somewhat of a matrix or "all of the above". For instance, consider an accounting package for small businesses developed by a well-known software publisher in Redmond, WA.  There would be benefits to having parts of that accounting package or all of it placed online.  Some of those advantages would be that the package data or feature set would be managed and backed up online by someone else. Business gets robbed and all your computer equipment is gone? No problem, your data is secure online! New features could be rolled into the package and you would automatically benfit.  Obvious disadvantages would be that our data is in the hands of strangers and you have to trust them with it.  Another disadvantage is that what do you do when your network connectivity is lost?  You shut down your business?  Nope. That's where Windows apps come in handy.  I can use my application offline, and sync up my data once my network is back up.  So your answer is the same thing we've been saying all along.  
  
  Here's another instance of this.  Think of mail servers (particularly IMAP).  My data is on the server, but I can access it with my Windows client.  Or, I can log into my web-based app that behaves the same way when I'm away from my office.  I get access to the same data no matter which experience I use.  I can create folders, move mail around, create rules, etc.  I can instruct my Windows client to download the email locally for offline consumption and I can create email on my Windows client that I'll store until I connect again.
  
  So here's the rub.  If what I'm saying is the case, developers would be doomed to develop two versions of all of their products and perhaps, two different data stores (local and web) depending on the customer needs and trust levels.  What would happen, however, if you used a mix of all these techniques?  You create UIs that can be changed to run either on the web (on IIS7!) or on your desktop with the flip of a switch.  You create data providers that can store the data to a local store or remote -- whichever the user decides.  The developer then only has to develop web application storage services one or two light-weight data layers, and one application with a configuration that can be changed.  This lets the user control how they want to run their app:  Windows Client with data on their computer, web-served client with data on their computer, browser based client with data on the remote server (IIS 7.0 cough) or Windows client with data on the remote server (IIS 7.0!).
  

• Anonymous
  August 24, 2006
  "In my life as a developer I have somehow never been on a project where I was creating a windows forms"
  
  Conversely, I've never worked on an actual application that had a web forms interface (as opposed to a web site with little actual back-end functionality, or a CGI-scripted application.)
  
  I've also seldom encountered an actual web application that had a usable interface, and the few I know of that are usable cost hundreds of thousands, if not millions of dollars per year to maintain and evolve.  Not the kind of money most companies are going to spend on what the pointy-hairs consider to be a marketing tool.

• Anonymous
  August 24, 2006
  If a web app did have shell integration, I would be very scared.  Or at least apprehensive, anyway.

• Anonymous
  August 24, 2006
  Didn't we try this before with Active Desktop and doesnt Vista have something like this too ? I know XAML and i thought I saw at a local users group some sort of .aspx esque markup that gives you a web feel but was running in a local window not connected to the web.
  
  

• Anonymous
  August 24, 2006
  The whole navigation, browser frame stuff, is IMO the worst thing about browser apps today. If out of browser apps developed those features, I wouldn't use them.
  
  For example, I've never had much use for the Back and Forward arrows in Windows Explorer, which is just about the only kind of app that such navigation makes sense for - navigating some structure! Very few applications are like that, IMO.

• Anonymous
  August 24, 2006
  I know of (and have developed) applications that was "In Browser" (using asp.net and DHTML).
  Also have some Office based solutions deployed on customer computers.
  At the end of the day, the user has to know wheather he wants the web-based strait-forward UI design (everything in a seeable link, sitemaps, etc.) of the more complicated WinForms UI design, where stuff are hidden in submenues and context-menus.
  the technology itself isn't the matter here, but the UI design is. JAVA has always been able to switch from In Browser (Applet) to Out of Browser (Application), and the ClickOnce is on it's trail. It still doesn't answer the question of the UI design, of weather to be strait-forward or be left-clicked.
  @Tobin:
  Webmail generally looks and behaves differently than POP3 clients. If you are talking about some implementation of webmail (such as Exchange's OWA) then although these are running in the browser, they do not act as browser application in their UI design, and in a way are hybrids that are hard to develop and maintain, and the end-user will expect it to act fully as a WinForm app, and you will never be able to do that perfectly, so imho it's better to have the two roads together as hinted by Brad (aka the XBAP and the ClickOnce) and not to choose a one killer solution to rule the all

• Anonymous
  August 24, 2006
  The comment has been removed

• Anonymous
  August 25, 2006
  I've done exactly as you asked.  And the answer is firmly: "Browsers are for connected apps".  OK, people didn't say those words, but that's what they meant.  
  
  My own opinion: I like using Desktop apps.  I like developing Desktop apps.  I've done so for 20 years, and hope to do so for another 20 years.  I find web apps clunky and I don't like using them.  Over time I hope that this will change, and web apps will be less clunky.  But I don't expect that to happen anytime soon.
  
  I don't have experience of AJAX-enabled apps, but a friend I was talking to last night finds them "brittle".  His opinion is that the use of Javascript is a particular problem.
  
  I think there are deep differences between in-browser and out-of-browser apps, and if you try and lay over an abstraction layer (say) to make it not be so, the Law of Leaky Abstractions is going to come into play quite a lot.
  
  Hope this helps.

• Anonymous
  August 25, 2006
  As a non-UI developer, take this as you will, but I'm wondering if we're missing the forest for the trees. We are talking about what is the right way to provide next-gen UIs. But to do that, we need to think what platform they're going to be running on.
  
  The desktop isn't going away anytime soon, but my mom isn't going to be using it. She'll be in front of the HDTV using things like Media Edition (or whatever the cable companies provide), XBox Live (okay, maybe not my mom), etc. That is how the internet is going to be surfed by the non-tech (i.e., the majority) crowd.
  
  I think the WPF demo done by the BBC is a better example of Web 2.0 and what we should be thinking about.
  
  This raises the question: Is the browser, as we know it today, a dead end?
  
  Another question? Is the TV remote going to have a "right click option"?

• Anonymous
  August 25, 2006
  The comment has been removed

• Anonymous
  August 28, 2006
  The comment has been removed

• Anonymous
  August 28, 2006
  As with all other things, the correct answer is: "All of the above", and "It depends".
  
  There's a huge difference between using a browser and an desktop app. I would hate to use a browser when I need the power of a UI dedicated to accomplishing the needs of a desktop app (e.g. Autocad or FlightSim), and I would not want to a desktop app (e.g. Word) when surfing the web. It also matters if I am living inside the app all day long doing my job or if I am shopping online comparing prices.
  
  Use the right GUI for the job; there's a place for both.
  

• Anonymous
  October 05, 2006
  Good Evening Sir, I have working on window form application in c#. I am using WebBrowser Control on win form. then in WebBrowser Control i have passed Url of any global web site like "http://www.msn.com". And after i want to do Change the textbox property of MSN Search textbox  type ="text " to type ="password". in DocumentComplete Event. Reply please it's urgent.

• Anonymous
  May 31, 2009
  PingBack from http://woodtvstand.info/story.php?id=6987

• Anonymous
  June 01, 2009
  PingBack from http://uniformstores.info/story.php?id=16177

• Anonymous
  June 07, 2009
  PingBack from http://greenteafatburner.info/story.php?id=4044

• Anonymous
  June 08, 2009
  PingBack from http://hairgrowthproducts.info/story.php?id=4875

• Anonymous
  June 13, 2009
  PingBack from http://thestoragebench.info/story.php?id=11007

• Anonymous
  June 18, 2009
  PingBack from http://barstoolsite.info/story.php?id=1129

• Anonymous
  June 18, 2009
  PingBack from http://fancyporchswing.info/story.php?id=2355