Browser-based application or stand-alone GUI app?
Question:
I’m sure this has been asked before, but I can’t find it.
What are the benefits/limitations of using a browser-based interface for a stand-alone application vs. using a normal GUI framework?
I’m working on a Python program currently implement with wxPython for the GUI. The application is simply user-entry forms and dialogs. I am considering moving to PyQt because of the widgets it has (for future expansion), then I realized I could probably just use a browser to do much of the same stuff.
The application currently doesn’t require Internet access, though it’s a possibility in the future. I was thinking of using Karrigell for the web framework if I go browser-based.
Edit For clarification, as of right now the application would be browser-based, not web-based. All the information would be stored locally on the client computer; no server calls would need to be made and no Internet access required (it may come later though). It would simply be a browser GUI instead of a wxPython/PyQt GUI. Hope that makes sense.
Answers:
The obvious advantages to browser-based:
- you can present the same UI regardless of platform
- you can upgrade the application easily, and all users have the same version of the app running
- you know the environment that your application will be running in (the server hardware/OS) which makes for easier testing and support compared to the multitude of operating system/hardware configurations that a GUI app will be installed on.
And for GUI based:
- some applications (e.g.: image editing) arguably work better in a native GUI application
- doesn’t require network access
Also see my comments on this question:
Cross-platform GUIs are an age-old problem. Qt, GTK, wxWindows, Java AWT, Java Swing, XUL — they all suffer from the same problem: the resulting GUI doesn’t look native on every platform. Worse still, every platform has a slightly different look and feel, so even if you were somehow able to get a toolkit that looked native on every platform, you’d have to somehow code your app to feel native on each platform.
It comes down to a decision: do you want to minimise development effort and have a GUI that doesn’t look and feel quite right on each platform, or do you want to maximise the user experience? If you choose the second option, you’ll need to develop a common backend and a custom UI for each platform. [edit: or use a web application.]
Another thought I just had: you also need to consider the kind of data that your application manipulates and where it is stored, and how the users will feel about that. People are obviously okay having their facebook profile data stored on a webserver, but they might feel differently if you’re writing a finance application like MYOB and you want to store all their personal financial details on your server. You might be able to get that to work, but it would require a lot of effort to implement the required security and to assure the userbase that their data is safe. In that situation you might decide that the overall effort is lower if you go with a native GUI app.
Browsers can be accessed anywhere with internet and you deploy it on the server. The desktop app has to be deployed to their computers and each computer somehow has its own uniqueness even with same OS and same version. This could bring you lots of hassles.
Go for web.
When it comes to simple data entry using user-entry forms, I’d argue that using a browser-based solution would probably be easier and faster to develop.
Unless your core feature is the interface itself (“If it’s a core business function — do it yourself, no matter what.” , see In Defense of Not-Invented-Here Syndrome from Joel on Software), I feel that the browser will be able to perform the form rendering and handling better than having to develop a GUI from scratch. Also, not to mention the it would take a much longer time to code a GUI as opposed to generating HTML forms and processing them after they are POSTed by the browser.
What I found in the past was that I was asked by a friend to write an application to enter results from a survey. At first, I was writing a Java applet to display the survey itself with all the radio boxes, when it hit me that I would be better off writing a simple HTTP server which would generate the forms and process them.
What it really comes down is to whether you are either developing:
- the user interface
- data-entry application
If you are making a data-entry application, then leave the user interface to the browser, and focus on your core functionality.
Benefits of browser-based interface:
- Easier to manage: no installation required on user machines, upgrades need only be performed on server side and are immediately available to all users. Data backup can be performed on a single machine as data won’t be spread out across multiple clients.
- Application can be accessed from any machine with a browser.
- Can easily support multiple platforms consistently.
- Memory and CPU requirements may be considerably less on the client side as intensive operations can be performed on the server.
- Increased security: data is stored on a single server instead of multiple client machines and access can be better controlled.
- Many other benefits of a centralized environment including logging, data entered from multiple sources can immediately be available from other clients, etc.
- In my experience, it is often easier to debug and faster to develop web-based solutions.
Benefits of GUI-based interface:
- May be easier to design a more responsive, fluid interface.
- Can take advantage of OS-specific functionality that may not be available via a browser.
- Doesn’t necessarily require network access.
- Don’t need to worry about browser compatibility issues.
- No single point of failure if server goes down or becomes unavailable.
There’s pretty good evidence that the trump-card issue in most cases is deployability and supportability. Browser apps are lower overhead in general; implementing and supporting more than a couple dozen users can end up consuming substantial support resources.
I saw a table a year or two ago that showed something like:
UI quality – Desktop
Granularity of validation – Desktop
Responsiveness – Desktop
User acceptance – Desktop
etc. – Desktop
etc. – Desktop
Install & Support – Browser
and the Browser wins.
Let’s pretend for a moment that the development/deployment/maintenance effort/cost is equal and we look at it from the application user’s perspective:
Which UI is the user going to find more useful?
in terms of
- Ease of use
- Responsiveness
- Familiar navigation/usage patterns
- Most like other tools/applications in use on the platform (ie, native)
I understand that “useful” is subjective. I personally would never use (as a user, not developer) a web interface again if I could get away with it. I hate them.
There are some applications that just don’t make sense to develop as browser based apps.
From a development perspective
- No two browsers available today render exactly the same.
- Even with Ajax, javascript and dynamic, responsive interfaces are non-trivial to implement/debug.
There are many, many standalone GUI applications that are just terrible, no argument. Development/deployment and maintenance for a multi-platform GUI is non-trivial.
Developing good user-interfaces is hard, period.
The reality is that I’ve made my living over the last 10 years developing mostly web based applications, because they’re faster to develop, easier to deploy and provide enough utility that people will use them if they have to.
I don’t believe that most users would use a web interface if given an alternative.
IMNSHO
For this task (form-based text entry) a browser is great. You don’t need anything that being a desktop app will give you (speed, flexibility)
There are draw-backs to being a web-application, such as..
It’s a web-page. There are things you just cannot (easily) do
You cannot easily map the ctrl+j key to do something. For example: Google Spreadsheet tries to map keyboard shortcuts and works most of the time, sometimes the browsers default handling of the shortcut takes over..
You cannot make Growl alerts (An OS X notification framework). You cannot access the filesystem. It’s difficult to allow access while offline.
Javascript is very CPU-heavy.
Try resizing a Google Spreadsheet document, or load a page on Digg (a very javascript heavy site) – the browsers CPU usage will be at 100% for a while.. Doing the same in a native desktop application is trivial
When you perform upgrades, you force them on all your users.
With a desktop application, they have the choice of not upgrading. For example, I didn’t like one of the Google Reader upgrades, but I was stuck. Using NetNewsWire (a desktop application), if I don’t like a change in the newest version, I can quite easily keep using this one (or try it, and downgrade)
You web-server must be accessible at all times, for ever
If the server disappears, your users have no recourse. The application is gone. If it’s down for 10 minutes, they cannot use it.
With your application, while I’m not too sure what it is, none of the above seems like its going to be an issue.
“It’s a web -page”: Forms and dialogue boxes are easy to do in HTML and javascript (or even using server-side scripting, for example <?php if($_POST["email"] ==""){echo("Are you sure you want to continue?); ?>)
“Javascript is very CPU-heavy”: Doesn’t sound like your application will require any Javascript (maybe some client-side input-validation when the user clicks “Submit”, to warn them about any input errors?)
“Forced upgrades”: I imagine this may be desirable, as you wouldn’t want users inputing data in the old way.
“Server must be accessible”: Could be an issue, but I don’t think it’ll be a large one.. Say you want to store all the users data in a central database, this issue becomes inescapable anyway – keeping a web and database server running isn’t much more work than only a database (for the GUIs to connect to)
Also, you get the benefits others have posted – you develop it once, and it runs identically on every operating system that can run a sane browser.
Everything has advantages and disavantages, but:
I have yet to use a single browser-based application on localhost, intranet, or internet that feels nice to use, is responsive, and who’s user interface isn’t strictly limited by the limitations of HTML/JS/CSS.
Note: Flash/Java-based UI is an exception (but that’s even worse in some regards and I don’t think it’s really what you are talking about here).
One of the things I hate about web based UIs is the fact that they run inside another window. Meaning, you have controls — maybe dozens of them — that have nothing to do with your application. From a usability point of view this can be confusing though most of us have adapted by “tuning out” the extra stuff.
As I look at my browser window as I type this, the window is perhaps 12 inches tall, but the window in which I type is only maybe 3 inches. And out of that 12 inches overall, perhaps two full inches are taken up with browser toolbars, tabs, rows of bookmarks and the statusbar, none of which have anything to do with the web app I’m interacting with. There’s a lot of wasted space (the edit window isn’t as wide as the window as a whole, for example), space filled with stuff I don’t need, etc. Some of the most fundamental controls (back button, I’m looking at you) can completely break poorly designed web applications.
Not to mention the fact that if I type a sufficiently long response I now end up with two sets of scrollbars. stackoverflow.com partially addresses that by giving me a resizable text area but I still have to interact with the inner scrollbar to scroll the text I’m editing, then scroll the whole window up or down to access the app controls at the top or bottom of the editing window.
All in all, a web based application just can’t compare to the usability of a desktop application. For me, then, the question simply becomes “are you more interested in usability, or in making your (as the developer) life easier”.
If you want usability, go with a desktop application, hands down. If you’re concerned with deployment and support a web app is something to consider, but there are still many easy ways to deploy desktop apps, including creating apps that can update themselves over the net at runtime.
I think the browser based UI concept is here to stay. There is nothing more portalble than the web itself, and as long as one stays within the boundaries of decent javascript libraries…the rendering would be almost the same. Plus since the rendering is not your headache, you can concern yourself more with developing the business logic itself.
I am all for it…
The rich client GUI will generally be faster and better integrated with the look and feel the user is accustomed to deal with – this does not only mean bells and whistles, but also means a lot of time saving features like keyboard shortcuts.
The web based UI will be more portable since does not bound the development to a single platform, and if the application runs in remote it is easier to update and to test all of it (excluding the GUI…) on a consistent environment (your server).
But you should understand that while all of that is great and really groundbreaking, it also comes with some serious drawbacks.
You should not only debug the application under all the target systems, but also under each single browser running on each single target system… and don’t forget many versions of the same browser may coexists for some time, and that each browser’s settings will be probably running different sets (and versions) of popular plugins which makes it behave differently, and probably network settings will be customized by users.
If the application is in remote it opens a lot of interesting new problem, starting from different ISP that will drop different problems in the middle, or services downtimes due to network problems of you server, the user’s machines or anywhere in the middle.
A remote application is not an option for all the users in countries where the network service is of low quality, or is not reasonably priced; the same is true for you: you can start providing such a service only if in your country bandwidth is reasonable and reasonably priced.
And if the application has to do something nontrivial on the user’s system, you will be probably doomed in creating a lot of platform dependent code anyway.
As bottom line, today there are advantages and disadvantages in any of the two solutions.
There are some applications that really need to be developed under the rich client model, and there are applications that really need to be developed under the web based paradigm.
It’s good to have both the options, it is critical to have a clear idea of what is the way fitting best our development / deployment / support strategy, and, I may add, it is silly to go after one or the other as if it is the definitive silver bullet following the fashion of the moment.
My solution is this
- Website applications obviously go on browsers
- Networked applications that do not need accessing client’s computer goes by browser
- Any application that need to be accessed by more than a client at a time goes by browser
- Applications that will be used per client with no obvious need for network stays with gui and this may include software that needs a lot of security on its use (same security can be addressed for browser based though).
This is something learnt through the hard way. One main reason for this is that customers find it easier to install and manage browser based apps much easier than gui based eg where using JavaWebStart means the client will need to have a minimum JRE and their likes whereas the browser based only needs a link.
IN all the decision is really yours!. As a Java developer using JavaFX and Swing can solve my problem with this issue.
I’m sure this has been asked before, but I can’t find it.
What are the benefits/limitations of using a browser-based interface for a stand-alone application vs. using a normal GUI framework?
I’m working on a Python program currently implement with wxPython for the GUI. The application is simply user-entry forms and dialogs. I am considering moving to PyQt because of the widgets it has (for future expansion), then I realized I could probably just use a browser to do much of the same stuff.
The application currently doesn’t require Internet access, though it’s a possibility in the future. I was thinking of using Karrigell for the web framework if I go browser-based.
Edit For clarification, as of right now the application would be browser-based, not web-based. All the information would be stored locally on the client computer; no server calls would need to be made and no Internet access required (it may come later though). It would simply be a browser GUI instead of a wxPython/PyQt GUI. Hope that makes sense.
The obvious advantages to browser-based:
- you can present the same UI regardless of platform
- you can upgrade the application easily, and all users have the same version of the app running
- you know the environment that your application will be running in (the server hardware/OS) which makes for easier testing and support compared to the multitude of operating system/hardware configurations that a GUI app will be installed on.
And for GUI based:
- some applications (e.g.: image editing) arguably work better in a native GUI application
- doesn’t require network access
Also see my comments on this question:
Cross-platform GUIs are an age-old problem. Qt, GTK, wxWindows, Java AWT, Java Swing, XUL — they all suffer from the same problem: the resulting GUI doesn’t look native on every platform. Worse still, every platform has a slightly different look and feel, so even if you were somehow able to get a toolkit that looked native on every platform, you’d have to somehow code your app to feel native on each platform.
It comes down to a decision: do you want to minimise development effort and have a GUI that doesn’t look and feel quite right on each platform, or do you want to maximise the user experience? If you choose the second option, you’ll need to develop a common backend and a custom UI for each platform. [edit: or use a web application.]
Another thought I just had: you also need to consider the kind of data that your application manipulates and where it is stored, and how the users will feel about that. People are obviously okay having their facebook profile data stored on a webserver, but they might feel differently if you’re writing a finance application like MYOB and you want to store all their personal financial details on your server. You might be able to get that to work, but it would require a lot of effort to implement the required security and to assure the userbase that their data is safe. In that situation you might decide that the overall effort is lower if you go with a native GUI app.
Browsers can be accessed anywhere with internet and you deploy it on the server. The desktop app has to be deployed to their computers and each computer somehow has its own uniqueness even with same OS and same version. This could bring you lots of hassles.
Go for web.
When it comes to simple data entry using user-entry forms, I’d argue that using a browser-based solution would probably be easier and faster to develop.
Unless your core feature is the interface itself (“If it’s a core business function — do it yourself, no matter what.” , see In Defense of Not-Invented-Here Syndrome from Joel on Software), I feel that the browser will be able to perform the form rendering and handling better than having to develop a GUI from scratch. Also, not to mention the it would take a much longer time to code a GUI as opposed to generating HTML forms and processing them after they are POSTed by the browser.
What I found in the past was that I was asked by a friend to write an application to enter results from a survey. At first, I was writing a Java applet to display the survey itself with all the radio boxes, when it hit me that I would be better off writing a simple HTTP server which would generate the forms and process them.
What it really comes down is to whether you are either developing:
- the user interface
- data-entry application
If you are making a data-entry application, then leave the user interface to the browser, and focus on your core functionality.
Benefits of browser-based interface:
- Easier to manage: no installation required on user machines, upgrades need only be performed on server side and are immediately available to all users. Data backup can be performed on a single machine as data won’t be spread out across multiple clients.
- Application can be accessed from any machine with a browser.
- Can easily support multiple platforms consistently.
- Memory and CPU requirements may be considerably less on the client side as intensive operations can be performed on the server.
- Increased security: data is stored on a single server instead of multiple client machines and access can be better controlled.
- Many other benefits of a centralized environment including logging, data entered from multiple sources can immediately be available from other clients, etc.
- In my experience, it is often easier to debug and faster to develop web-based solutions.
Benefits of GUI-based interface:
- May be easier to design a more responsive, fluid interface.
- Can take advantage of OS-specific functionality that may not be available via a browser.
- Doesn’t necessarily require network access.
- Don’t need to worry about browser compatibility issues.
- No single point of failure if server goes down or becomes unavailable.
There’s pretty good evidence that the trump-card issue in most cases is deployability and supportability. Browser apps are lower overhead in general; implementing and supporting more than a couple dozen users can end up consuming substantial support resources.
I saw a table a year or two ago that showed something like:
UI quality – Desktop
Granularity of validation – Desktop
Responsiveness – Desktop
User acceptance – Desktop
etc. – Desktop
etc. – Desktop
Install & Support – Browser
and the Browser wins.
Let’s pretend for a moment that the development/deployment/maintenance effort/cost is equal and we look at it from the application user’s perspective:
Which UI is the user going to find more useful?
in terms of
- Ease of use
- Responsiveness
- Familiar navigation/usage patterns
- Most like other tools/applications in use on the platform (ie, native)
I understand that “useful” is subjective. I personally would never use (as a user, not developer) a web interface again if I could get away with it. I hate them.
There are some applications that just don’t make sense to develop as browser based apps.
From a development perspective
- No two browsers available today render exactly the same.
- Even with Ajax, javascript and dynamic, responsive interfaces are non-trivial to implement/debug.
There are many, many standalone GUI applications that are just terrible, no argument. Development/deployment and maintenance for a multi-platform GUI is non-trivial.
Developing good user-interfaces is hard, period.
The reality is that I’ve made my living over the last 10 years developing mostly web based applications, because they’re faster to develop, easier to deploy and provide enough utility that people will use them if they have to.
I don’t believe that most users would use a web interface if given an alternative.
IMNSHO
For this task (form-based text entry) a browser is great. You don’t need anything that being a desktop app will give you (speed, flexibility)
There are draw-backs to being a web-application, such as..
It’s a web-page. There are things you just cannot (easily) do
You cannot easily map the ctrl+j key to do something. For example: Google Spreadsheet tries to map keyboard shortcuts and works most of the time, sometimes the browsers default handling of the shortcut takes over..
You cannot make Growl alerts (An OS X notification framework). You cannot access the filesystem. It’s difficult to allow access while offline.
Javascript is very CPU-heavy.
Try resizing a Google Spreadsheet document, or load a page on Digg (a very javascript heavy site) – the browsers CPU usage will be at 100% for a while.. Doing the same in a native desktop application is trivial
When you perform upgrades, you force them on all your users.
With a desktop application, they have the choice of not upgrading. For example, I didn’t like one of the Google Reader upgrades, but I was stuck. Using NetNewsWire (a desktop application), if I don’t like a change in the newest version, I can quite easily keep using this one (or try it, and downgrade)
You web-server must be accessible at all times, for ever
If the server disappears, your users have no recourse. The application is gone. If it’s down for 10 minutes, they cannot use it.
With your application, while I’m not too sure what it is, none of the above seems like its going to be an issue.
“It’s a web -page”: Forms and dialogue boxes are easy to do in HTML and javascript (or even using server-side scripting, for example <?php if($_POST["email"] ==""){echo("Are you sure you want to continue?); ?>)
“Javascript is very CPU-heavy”: Doesn’t sound like your application will require any Javascript (maybe some client-side input-validation when the user clicks “Submit”, to warn them about any input errors?)
“Forced upgrades”: I imagine this may be desirable, as you wouldn’t want users inputing data in the old way.
“Server must be accessible”: Could be an issue, but I don’t think it’ll be a large one.. Say you want to store all the users data in a central database, this issue becomes inescapable anyway – keeping a web and database server running isn’t much more work than only a database (for the GUIs to connect to)
Also, you get the benefits others have posted – you develop it once, and it runs identically on every operating system that can run a sane browser.
Everything has advantages and disavantages, but:
I have yet to use a single browser-based application on localhost, intranet, or internet that feels nice to use, is responsive, and who’s user interface isn’t strictly limited by the limitations of HTML/JS/CSS.
Note: Flash/Java-based UI is an exception (but that’s even worse in some regards and I don’t think it’s really what you are talking about here).
One of the things I hate about web based UIs is the fact that they run inside another window. Meaning, you have controls — maybe dozens of them — that have nothing to do with your application. From a usability point of view this can be confusing though most of us have adapted by “tuning out” the extra stuff.
As I look at my browser window as I type this, the window is perhaps 12 inches tall, but the window in which I type is only maybe 3 inches. And out of that 12 inches overall, perhaps two full inches are taken up with browser toolbars, tabs, rows of bookmarks and the statusbar, none of which have anything to do with the web app I’m interacting with. There’s a lot of wasted space (the edit window isn’t as wide as the window as a whole, for example), space filled with stuff I don’t need, etc. Some of the most fundamental controls (back button, I’m looking at you) can completely break poorly designed web applications.
Not to mention the fact that if I type a sufficiently long response I now end up with two sets of scrollbars. stackoverflow.com partially addresses that by giving me a resizable text area but I still have to interact with the inner scrollbar to scroll the text I’m editing, then scroll the whole window up or down to access the app controls at the top or bottom of the editing window.
All in all, a web based application just can’t compare to the usability of a desktop application. For me, then, the question simply becomes “are you more interested in usability, or in making your (as the developer) life easier”.
If you want usability, go with a desktop application, hands down. If you’re concerned with deployment and support a web app is something to consider, but there are still many easy ways to deploy desktop apps, including creating apps that can update themselves over the net at runtime.
I think the browser based UI concept is here to stay. There is nothing more portalble than the web itself, and as long as one stays within the boundaries of decent javascript libraries…the rendering would be almost the same. Plus since the rendering is not your headache, you can concern yourself more with developing the business logic itself.
I am all for it…
The rich client GUI will generally be faster and better integrated with the look and feel the user is accustomed to deal with – this does not only mean bells and whistles, but also means a lot of time saving features like keyboard shortcuts.
The web based UI will be more portable since does not bound the development to a single platform, and if the application runs in remote it is easier to update and to test all of it (excluding the GUI…) on a consistent environment (your server).
But you should understand that while all of that is great and really groundbreaking, it also comes with some serious drawbacks.
You should not only debug the application under all the target systems, but also under each single browser running on each single target system… and don’t forget many versions of the same browser may coexists for some time, and that each browser’s settings will be probably running different sets (and versions) of popular plugins which makes it behave differently, and probably network settings will be customized by users.
If the application is in remote it opens a lot of interesting new problem, starting from different ISP that will drop different problems in the middle, or services downtimes due to network problems of you server, the user’s machines or anywhere in the middle.
A remote application is not an option for all the users in countries where the network service is of low quality, or is not reasonably priced; the same is true for you: you can start providing such a service only if in your country bandwidth is reasonable and reasonably priced.
And if the application has to do something nontrivial on the user’s system, you will be probably doomed in creating a lot of platform dependent code anyway.
As bottom line, today there are advantages and disadvantages in any of the two solutions.
There are some applications that really need to be developed under the rich client model, and there are applications that really need to be developed under the web based paradigm.
It’s good to have both the options, it is critical to have a clear idea of what is the way fitting best our development / deployment / support strategy, and, I may add, it is silly to go after one or the other as if it is the definitive silver bullet following the fashion of the moment.
My solution is this
- Website applications obviously go on browsers
- Networked applications that do not need accessing client’s computer goes by browser
- Any application that need to be accessed by more than a client at a time goes by browser
- Applications that will be used per client with no obvious need for network stays with gui and this may include software that needs a lot of security on its use (same security can be addressed for browser based though).
This is something learnt through the hard way. One main reason for this is that customers find it easier to install and manage browser based apps much easier than gui based eg where using JavaWebStart means the client will need to have a minimum JRE and their likes whereas the browser based only needs a link.
IN all the decision is really yours!. As a Java developer using JavaFX and Swing can solve my problem with this issue.