Well said.
On Fri, May 18, 2012 at 5:45 PM, Jan Høydahl <jan....@cominvent.com> wrote: > > 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.orgfor > >>>> 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 > >>> > >> > >> >
