To know how this should impact our planning, it would be wise to understand the respective app stores better. I only know the Apple store from a user perspective so I wouldn't know how much magic you can do during install or if it's just a plain copy of the .app bundle. And I don't know anything tech about Windows store in Win8.
Jan Den 18. mai 2012 kl. 11:48 skrev Kevin Grignon <[email protected]>: > Well said. > > > > On Fri, May 18, 2012 at 5:45 PM, Jan Høydahl <[email protected]> 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 <[email protected] >>> : >> >>> 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 <[email protected] >>> 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 >>>>> >>>> >>>> >>
