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 (24)

  1. Stephane Rodriguez says:

    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.

  2. 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…

  3. In my life as a developer I have somehow never been on a project where I was creating a windows forms

  4. Tobin Titus says:

    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!).

  5. Grim says:

    "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.

  6. Miral says:

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

  7. Mike Johnson says:

    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.

  8. Barry Kelly says:

    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.

  9. Ken Egozi says:

    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

  10. amadrias says:

    That’s funny you’re raising this point as I’m currently working on a project that is requiring both supported client environments and I’m actually trying to find out the best way to go:

    – Either develop two client applications (one windows forms and the other ASP.net)

    – Or just use ASP.net running on either IIS or my windows form application in a webbrowser control.

    All of it can, in my opinion fall into two requirements categories:

    A. Your end users need to access shared information, access it through any platform and they don’t care about working offline: best bet for web apps.

    B. Your end users need to share information whatever the way (centralized on a server or peered <— this one is definitivelly a windows forms), they want to get a highly responsive and extremelly interactive user experience and the may want from time to time to be able to work offline (as far as I’m concerned this only happens to me when I’m on the plane ^^): best bet for windows forms and even smart client.

    For my project, the issue I have is that I want to provide the exact same look & feel to my app either they are on the web or using the desktop application while disabling some features on the web that requires a peer to peer network.

    I’m really fronting a UI design issue here as hosting an ASP.Net app in a desktop application may affect performances a lot in the long term. (I just hate having my windows xp, antivirus and my instant messenger running and using 200 Mb of memory: did developers forgot about those extremelly powerfull applications running on 2 7kb floppies in the early 90’s?!!!).

    The ideal world would be a unique UI description that would be interpreted and rendered in multiple platforms and frameworks such as XAML, XUL and Flash are the paths to get there!

  11. Andrew Webb says:

    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.

  12. Brian Tyler says:

    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"?

  13. Shani Raba says:

    I must admit that most of my experience is in InternetIntranet based application (web-form).

    I think that in the past we assume that Web-application are easy to maintain which is probably not the issue anymore.

    The big problem in Web is that we always thinking and trying to get windows like application (with menu, right click, Ajax) and even if it is easier than it was two years ago, it is still complicated, creating massive code transfer between the HTML and the code. and massive of line going to the client.

    I think that we can think of the "not connected" frameworks as a client must, which you can still close the internet/intranet connection and still work as  usual.

    and in the "connected" frameworks it is up to the UI complexity, if it is too complex using lots of ajax you can start thinking about win-forms(easily interactive UI) otherwise web forms is the option.

  14. devdao says:

    I must admit that most of my experience is in InternetIntranet based application (web-form).

    I think that in the past we assume that Web-application are easy to maintain which is probably not the issue anymore.

    The big problem in Web is that we always thinking and trying to get windows like application (with menu, right click, Ajax) and even if it is easier than it was two years ago, it is still complicated, creating massive code transfer between the HTML and the code. and massive of line going to the client.

    I think that we can think of the "not connected" frameworks as a client must, which you can still close the internet/intranet connection and still work as  usual.

    and in the "connected" frameworks it is up to the UI complexity, if it is too complex using lots of ajax you can start thinking about win-forms(easily interactive UI) otherwise web forms is the option.

  15. David Levine says:

    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.

  16. hemant tawri says:

    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&quot;.

    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.