So far so simple, but an important sector in the tech industry has remained very much underserved by install software: client-server.
Web interfaces, if done well, can keep things simple for the end user and are fine for a certain set of apps like word processing (although some would disagree on their suitability for much beyond that) but for other apps that need a greater level of access to the local computer or better access to its resources a desktop client is a more viable option.
On Premises Server Client Software
Our remote support software is one example of this but there are many others and even for everyday software there is an argument for the model. An organisation-local version of Google Apps would allow all the benefits of centralised storage and management but would also keep the data in the control of the company. In the light of the recent NSA revelations and before that in environments where control over data is a requirement (healthcare for example) these models can provide the benefits of Cloud and local software combined.
Resolving this problem was one of the most difficult issues to solve in JWrapper but the final result - building and signing on any platform for any platform - is a new gold standard for developer ease of use.
Certainly the basic mechanism is the same - the software must connect to the server, check the version and update where necessary. Given the client-server nature of the software though it is important that the client stays in step with the server through both upgrades and downgrades and JWrapper has a special tag to cater exactly for this and again make it trivially easy for the developer.
A less expected but more difficult case though is specific to on-premises software. Here the end user organisation may run their server, install clients and have them connect to the local server (all catered for so far) but when it comes time to update the update should be tied to the local server, not a centralised copy or a provider website since the local server may not have been updated yet. Worse, if the user wants to run multiple servers or more than one version things get very complex and we end up back at complicated usecases with the end user trying to manage versions and point them at the right servers.
Elegance is making complex simple
For this particular usecase then the ideal would be that the user obtains a client, runs it, and the rest (identifying the server, matching versions, updating / downgrading) is done automatically.
This is a lot more difficult than it sounds but because this was an important case for SimpleHelp we wanted JWrapper to solve this well, and it does. Here's how it works:
Firstly the local server hosts its own copies of the client apps for download. These clients, when they are downloaded, are tagged with the server's identity, meaning that when they run they know the server they came from and can automatically connect back to it. We have now removed the need for the user to identify the server to connect to.
Secondly the installation framework (JWrapper) becomes aware of this taggable property (the Update URL) such that it can update from the local server and keep the versions in check. The client app now doesn't need to do any of its own updating or version checking because the version that is launched is kept in step with the server version. We have now removed the need for the user to manage versions on both upgrades and downgrades. This sounds simple but when the client apps need to be signed this is difficult in the extreme.
Lastly the version downloaded from one server may share a codebase or installation folder with the version downloaded from another server. They need to not interfere with each other or get mixed up, and when the client downloaded from server X is launched it should connect to server X - the end user simply has one client per server (e.g. Live and Demo). This requires the downloaded executable to retain the server address and pass it on right through the entire process through update and launch and finally into the app that will connect to the server.
The End Result
The end user organisation can install multiple local servers and versions if they wish, download clients from each and use the downloaded executables to connect to each of the servers seamlessly with no knowledge of server addresses, versions or updates.