> This is an important issue. Single click installation is expectation of the > market place that cannot be ignored. +1
Also keep in mind that both Apple and Microsoft are moving towards 1-click installs from App stores as the new default, so in a few years new PC/Mac users (such as students) will never even look outside of the app store when looking for programs. This calls for a single multi lingual AOO installer which "does the right thing" without user input. That "thing" would be looking up users default language, download the corresponding lang pack (remember that user is necessarily connected to Internet when installing from app store) and install it. Next time user starts the app he can be prompted for additional langs. Jan Den 17. mai 2012 kl. 05:24 skrev Kevin Grignon <kevingrignon...@gmail.com>: > Hello All, > > This is an important issue. Single click installation is expectation of the > market place that cannot be ignored. > > That said, we are not an mobile app, and desktop applications require > additional installation configuration by the end user. > > With regards to language pack, I'll leave the back end to the development > folks. > > From a UX perspective, we might consider the following: > > - allow the users to single click to install the application using smart > default configuration (install location, default language pack, default > values, etc.) > - progressively disclose secondary installation requirements, such as > language packs > > There are two paths we could explore here: > > 1 - have language selection as part of install > - the user could select the languages they want, and we download and > install in background > - we should not send people to find installation files for a second, manual > install > > 2 - prompt for additional languages when the user opens the app for the > first time > - again, download and install in the background > > Finally, a user should be able to manage the languages from within the > product itself. Here again, we take care of downloads, unpacking and > installation behind the scenes. Yes, we support many languages and > platforms, this is our choice and we should not burden our end users with > this complexity. I suspect most user just want to install their platform, > select their language pack, and get to work. Let's help them do jsut that. > > Some thoughts... > > Regards, > Kevin > > > On Thu, May 17, 2012 at 4:23 AM, Raphael Bircher <rbirc...@apache.org>wrote: > >> Am 16.05.12 21:53, schrieb Andrew Rist: >>> see idea #5 below >>> >>> On 5/16/2012 12:06 PM, Rob Weir wrote: >>>> Release = Size * Platforms * Languages >>>> >>>> That's the basic math we're dealing with now. Let's ignore SKD and >>>> langpacks since they are much smaller. >>>> >>>> An AOO install is around 150MB. >>>> >>>> We currently support 6 platforms (taking into account different Linux >>>> packaging models), and 15 languages. >>>> >>>> So Release = 150MB * 6 * 15 = 13.5 GB. >>>> >>>> Let's look at AOO 3.4.1 where we will probably add Finnish, UK >>>> English, Norwegian and Hebrew. >>>> >>>> So Release = 150MB * 6 * 19 = 17.1 GB. This gets added to the >>>> previous 13.5 GB, since we keep older releases around, or at least we >>>> do currently. >>>> >>>> Imagine then future growth. Maybe Windows 64-bit, OS/2, OpenIndiana. >>>> Imagine we get back to 44 languages supported via full installers. >>>> Then what? >>>> >>>> Release = 150 MB * 9 * 44 = 59.4 GB. >>>> >>>> So we're not talking TB's here. But it does add up, if we want >>>> preserve the release artifacts for earlier releases. >>>> >>>> Aside from storage, this is complexity for build a release. It is >>>> more stuff to build, more stuff to schlep around people.apache.org for >>>> release candidates, more complexity in download scripts, more stuff to >>>> sign, more places to make mistake. Someone could make a full time job >>>> just managing the builds and releases of this full matrix. >>>> >>>> Now to be fair, this matrix is optimal for the end user. 99% of the >>>> users can download a single file and it has everything they need. No >>>> extra things to download. And their download is as small as it can be. >>>> It is perfect for them. >>>> >>>> But I wonder if we can make a radical simplification while still >>>> making it really easy for the user? Unless of course, someone wants >>>> to volunteer to be a full-time build engineer? >>>> >>>> ==Idea #1== >>>> >>>> Factor out the translations for the install program versus the AOO >>>> program itself. Make the installer support all languages. >>>> >>>> Make core installer only have en_US resources. Everything else is >>>> provided via language packs. >>>> >>>> Make the language pack be platform-neutral, e.g., resources only. >>>> Rely on the installer that you've already downloaded for the logic to >>>> install the language pack. >>>> >>>> Have the installer prompt the user at the end of the install to >>>> install a language pack and then take them to the right webpage to >>>> download. >>>> >>>> Have the installer look in the current directory for any language >>>> packs and automatically install them at the end of the install. This >>>> would support install fro or other places where additional downloads >>>> are not possible. >>>> >>>> Pro: A full release size then becomes 150 MB x Platforms + 20MB * >>>> Languages. So the monster case that was 59.4 GB above now becomes 2.3 >>>> GB. >>>> >>>> Con: A lot of Dev work. >>>> >>>> ==Idea #2== >>>> >>>> Create a single multi-language install that covers whatever languages >>>> are needed to support 99% of our users. I've heard this idea >>>> suggested, but it doesn't really work. We have "long tail" effect >>>> here. Even if you bundle the top 20 languages it is still only a >>>> little over 80% of our users. >>>> >>>> ==Idea #3== >>>> >>>> Create language installs on-demand via a cgi script. An MRU cache >>>> would make the most common ones already ready. >>>> >>>> Pro: Can essentially dial in whatever space you want to allocate for >>>> the cache. Is efficient with respect to bursty traffic, e.g., we get >>>> a sudden appearance on the evening news in Kazakhstan. >>>> >>>> Con: Security aspects of cgi, and low likelihood that mirror operators >>>> are willing to donate more CPU cycles as well. >>>> >>>> ==Idea #4== >>>> >>>> Chill. Relax. Disk space is cheap and dropping. >>>> >>>> Con: It is not just disk space. It is complexity as well, especially >>>> for our release process. >>>> >>>> ==Idea #5== >>> >>> Two changes >>> - create an installer that works from a local file system (or CD) >>> that installs all of the signed and well formed artifacts in the fs. >>> This means that it will install base AOO, language packs, extensions >>> (dictionaries) , and templates. >>> - create a bootstrap installer that will download the appropriate >>> bits from the interwebs to your local fs and then kick off the install. >>> >>> Pro: >>> - has lower disk footprint in archives and limits download bandwidth >>> to required bits >>> - provides seamless install experience for user whether from web, >>> local fs, or cd. >>> - improved install experience, as extensions, templates, extra >>> languages, etc can be added into the base install seamlessly. >>> - allows for value add downstream packaging - with dictionaries, >>> extensions, etc. Once the file structure is created it can easily be >>> written to media, thus custom install on a cd. >>> - with proper design on bootstrap installer, the download can be >>> optimized (compression, restartability, etc) >>> >>> Cons: >>> - it is only ideaware at the moment >> You need internet or you have a ugly puzzle. >> >> Sure, it's the easyest way, but i beleve not the best. >>> >>> >>>> >>>> <Insert your idea here> >>>> >>>> Regards, >>>> >>>> -Rob >>> >> >>
