Deployment

[Tobias Bley (UltraMixer)]

I absolutely agree with Greg. My company is developing successful commercial java apps for end users (e.g. www.ultramixer.com) and we made the practical experience that the best user experience is the native on. So Java apps should behave like native apps.

But.... it would be great if the user can install a java app (or execute the installer) directly on a webpage with the help of a "Run MyApp" button because there are so many user who doesn't know what to do after download the installer...

Best regards,
Tobi

--
Tobias Bley
Geschäftsführer/ Managing Director

------------------------------------------------------------------------

UltraMixer Digital Audio Solutions
Schillerstrasse 29
01326 Dresden

-------------------------------------------------------------------------
info at ultramixer.com 	      	 http://www.ultramixer.com

Am 20.04.2012 um 19:29 schrieb Greg Brown:

> I personally think that the experience of installing and launching a JavaFX application should be the same as any other application for a given platform. For example, on the Mac, the user would obtain the application as a DMG file or from the Mac App Store; once installed, it would be launched via a Dock icon or from the Applications folder, like any other Mac app. On Windows, the application would be installed from an MSI file and then launched from the Start/Windows menu, like any other Windows app. Any permission dialogs should also be native so the app appears trustworthy to the user. The experience on a smartphone or tablet should be similar.
> 
> In my opinion, users shouldn't have to know or care that an app was built with JavaFX - they should just be able to use it "out of the box" like any other app.
> 
> G
> 
> On Apr 20, 2012, at 12:47 PM, Dr. Michael Paus wrote:
> 
>> Hi, here are my 2 €ent on this issue.
>> 
>> I'll concentrate on option 1 because I think this is the most critical but also the most interesting option.
>> In addition I will only concentrate on the normal installation procedure, i.e. when the correct Java is
>> already available on the system.
>> 
>> What I would like to see then is an installation with as few dialogs as possible but the most important
>> thing is to be able to run every app in a sandbox with only the privileges that the app has asked
>> for and the user has granted. At the moment we only have an all-or-nothing option which is simply
>> not acceptable. If I install something directly form the internet I am not willing to grant this software
>> all rights especially when there is no apparent reason why it should have these privileges. On the
>> other hand an app with almost no rights is in general quite useless. In swing-based apps this situation
>> can be improved a bit by using the JNLP Services but the deployment guide of JavaFX does not even
>> mention this option so my feeling is that using them is currently not supported.
>> 
>> The comparison made by Dan with the installation process of a smartphone app is a good one but
>> I think we even might do better with JavaFX. When I click on a link somewhere then the corresponding
>> app should be installed immediately without asking me anything but should provide me with some
>> installation progress information and possibly an option to abort the installation. After that the
>> application should run in a sandbox without any privileges. Only when I trigger some action which
>> requires more privileges, there should be a dialog which asks me to confirm the privileges needed for
>> this action. This dialog should also provide an option to see all privileges that this app might ever
>> ask for and confirm them all right now, so that this dialog does not pop up for every new privilege.
>> 
>> I also think it is important that the user can explicitly deny certain privileges and the app continues
>> and certain features are then just not activated. It should also be possible to re-enter this dialog
>> at any time to make changes to the current settings.
>> 
>> One further improvement would be if the programmer
>> would be forced to give an explanation why a certain privilege is needed. This information could
>> then be provided in the selection dialog and would help to build up some trust in the app. With
>> smartphone apps I often wonder why a certain privilege is asked for and what it actually means.
>> 
>> Michael
>> 
>> 
>> Am 20.04.2012 17:21, schrieb Daniel Zwolenski:
>>> Perhaps we could collectively try and define what the ideal user experience would be in this area and then Igor and Richard can tell us the hurdles that prevent this experience from happening?
>>> 
>>> Below are the three major deployment scenarios I believe we'd like to have in our arsenal. Please add/correct based on your opinions.
>>> 
>>> 1. Web-based install of desktop app
>>> 2. Web-based launch of Applet
>>> 3. Offline distributable of desktop app
>>> 
>>> For all of these I believe we want a single, minimal-click, minimal-dialog process that installs (if needed), the JRE, JavaFX and the custom app being run. It is not three installs or even two to the user, they are installing one thing only - my custom app. The fact that Java or JFX is needed is not something they want to be overly bothered with. One, end-to-end, simple seamless flow is what the users want.
>>> 
>>> I'll get the ball rolling with my view of the ultimate flow for option 1. In this scenario we are trying to achieve a pretty similar experience to what you get when installing an app on a smart phone. Currently webstart is the closest thing to this but it has the flaw that Java needs to be manually installed first. I suggest a plugin that does a smart install of everything. This plugin may well need to be different to the 'applet' plugin, I'm not sure. If it does however, so be it.
>>> 
>>> As with normal webstart (and smart phones), option 1 is not so much a webapp as a web-based 'install' of a desktop app - once locally installed it can run offline.
>>> 
>>> Here's the sort of flow I'd like to see if the user doesn't have java installed:
>>> 
>>> - User navigates to the URL for the app in their favorite browser
>>> - Browser Plugin is triggered
>>> - Dialog 1: browser's standard, "do you want to install plugin"
>>> - Plugin is installed and runs
>>> - Plugin searches for existing JRE, finds none
>>> - Dialog 2: says:
>>> 
>>>    Installing "Daniel's cool application"
>>>    Developed by Zen Java (more info...)
>>>    Java will be installed to run this application (more info...)
>>>    This program requires the following permissions:
>>>        * Read and write files on your computer
>>>        * Make network connections
>>>    [x] Add shortcut to start menu
>>>    [x] Add shortcut to desktop
>>> 
>>> - User hits 'Install' (or 'Cancel' to abort)
>>> 
>>> - Dialog 3: Combined T&C page for Java + JRE + my custom T&C (preferably one dialog with sections, or as close-to as legals will allow)
>>> 
>>> - Plugin detects system (not browser) OS and 32 vs 64bit (don't ask user, 90% don't know)
>>> - JRE+JFX is downloaded and installed (no further input dialogs shown, just a progress indicator)
>>> - My custom jars (and any relevant bundled native files) are downloaded (same progress indicator as when installing jre)
>>> - Shortcuts are added to the relevant places
>>> - Final dialog: Daniel's cool application is now installed. Would you like to launch it now?
>>> 
>>> From this point on, the user can launch the app from the start menu. A browser is no longer needed (or wanted). Ideally when the app is run it first checks for a new version of Java, JFX, or the custom app online and gives the user the option to upgrade (I feel they should be able to decline). This check is done now by a local pre-launcher, ie the browser/plugin is not involved from here in.
>>> 
>>> As far as signing/permissions, I think it needs to be simple. Permissions should be selected by the developer and listed for the user in the same simple approach that smart phones use (eg "write to files on your computer"). Getting a digital certificate is a pain so if there was a way to avoid this or an easier way to do this it would be great - bonus points.
>>> 
>>> I would very much prefer it if the automatic Java updates weren't going on all the time in the background. It would be best if the version was just checked on app startup and the user given the option to upgrade. Then they have context. The random 'update your java now' dialog that pops up add-hoc freaks out most users and makes the others angry (including me!)
>>> 
>>> If in the above flow, a suitable version of java or jfx was found, then the flow would be the same. The difference would be only that on the second dialog, instead of saying "Java will be installed" it says "Using already installed Java" and the 'more info' link then shows details on where it's installed, etc. Then the T&C section would just leave out the Terms for the already installed stuff. Similar if the JRE/JFX needs to be upgraded.
>>> 
>>> That would be the optimal UE for option 1 for me. I'll stop there to see what kind of response this gets but options 2 and 3 would take similar tacts.
>>> 
>>> I'm interested in hearing from the JFX guys what would prevent this from being implemented. Why cant we have this? Are there technical limitations, do you disagree that this is important or would be a better flow, or is it just too much effort?
>>> 
>>> Just as importantly I'm interested in hearing from all the developers out there. Is this your ideal scenario, is this important to you etc? I raised this issue months ago and the response from the jfx guys was that non-applet, seamless install was too small a use case to warrant the effort needed. I didn't hear anyone chime in to the contrary back then so I don't blame the JFX guys for not moving much in this space.
>>> 
>>> Get vocal (on solutions, not just problems). If you want something like the above, say so loud and clear. If you want something different, say that even louder so the rest of us can consider that too and back it if appropriate. There's a top notch team and community at the ready here and for my money this is a make-or-break issue. Let's work this one out together.
>>> 
>>> Cheers,
>>> Dan
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 20/04/2012, at 2:32 PM, Igor Nekrestyanov<igor.nekrestyanov at oracle.com>  wrote:
>>> 
>>>> On 4/19/12 11:03 PM, Tom Eugelink wrote:
>>>>> Ok. How about the "there is no standard way to distribute a stand alone JavaFX application"? Create a JIRA issue?
>>>> Could you please be more specific?
>>>> 
>>>> What is "standard way" and how do you expect to distribute this package?
>>>> Is it different problem from distributing java application (especially once javafx runtime will be part of the JRE)?
>>>> Do you expect to application "install" on the user system or run from the package?
>>>> Are you thinking about shipping your application to the App Store?
>>>> 
>>>> We might have related feature request already:
>>>> http://javafx-jira.kenai.com/browse/RT-19446
>>>>   "Add ability to co-bundle Java + JavaFX + App into a single native executable"
>>>> 
>>>> It is on 2.2 list right now but it is not clear if we can support other native packages for platforms other than Mac yet
>>>> (see discussion in the JIRA).
>>>> 
>>>> -igor
>>>> 
>> 
>> 
>> -- 
>> --------------------------------------------------------------------------------------
>> Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
>> For more information visit www.jugs.de.
>> 
>