Hello All, Great topic. I too belong to the "less is more" school. Great in theory, harder to realize with a moving ship ;)
Re: connectors - this is a great way to extend the core - perhaps we could create a stronger development eco-system for extensions - perhaps we could make the extension more consumable and discoverable for end users Re: smaller footprint - this is also great - perhaps the core becomes so light that it can be the base for full on custom applications - I assume this is a core theme in Future AOO? Hope so - build a full eco-system like Firefox, or Evernote - the default install for AOO could include the core, and some common extensions - then we make it easy for people to manage extensions - perhaps we explore ways for people to discover and access extension to extend the core in the context of a task ex: I'm doing some advanced publishing, and I trigger a one-click installation of an extension from within an AOO view or dialog related to formating content -- on demand capabilities - more broadly, we could provide a better experience to enable or disable extensions on demand Thoughts? Oh ya, I wanted to mention that UX is in the process of deploying a task prioritization survey<http://wiki.openoffice.org/wiki/AOO_Survey_Templates_-_Task_Prioritization>, the results of which can feed into the conversation. Regards, Kevin On Fri, Sep 21, 2012 at 3:55 PM, Shenfeng Liu <liush...@gmail.com> wrote: > 2012/9/13 Andrea Pescetti <pesce...@apache.org> > > > On 11/09/2012 Rob Weir wrote: > > > >> On Sep 11, 2012, at 12:27 AM, "Jürgen Schmidt" wrote: > >> > >>> Things that comes to my mind where I would always prefer an extension > >>> solution: > >>> - Connectors to some non free, non open source software based on > >>> proprietary API's. ... > >>> > >>> - Dependencies on external GPL, LGPL libraries. > >>> - Rarely used features ... > >>> > >> I think those are reasonable guidelines. Amother category is a > >> "standard extension" that is under ALv2 and is part of a release. > >> > > > > I agree, these components should be packaged as extensions. > > > > > > We should probably think of what install enhancements we can make to > >> better facilitate bundling of extensions. To the developer and user, > >> extension + easy install integration should feel the same as adding a > >> feature to the core. > >> > > > > The main problem is that the ecosystem around OpenOffice is completely > > unknown to most end users. It would be a huge leap forward to use the > > bottom-right part of the Start Centre to promote this ecosystem > > (Extensions, Templates, everything that makes sense) by displaying a > couple > > lines of dynamic content retrieved from sources we control. Examples of > > content we could broadcast there: > > - "Add a grammar checker to OpenOffice: [link to LanguageTool/LightProof > > on the Extensions site]" > > - "Download a CV template for OpenOffice: [link to a template on the > > Templates site]" > > - "Add clipart to OpenOffice: [relevant link]" > > - "Tip of the day: using styles in OpenOffice [link to wiki page]" > > > > Instead of promoting certain items, I think generally we should make the > Search function more visible to users. Just like I don't know what's in App > Stores, I just try a search and see what I can get. > The current 3 small icons at the bottom-left of the welcome page for > templet/extension/website are too far to get users' attention, even though > the web pages they link to are very cool. We can redesign it will more > visible icons and sentences, even search dialog on the welcome page. Of > course, Quickstarter is another good place. > > - Simon > > > > > This shouldn't be hard to do and it would allow us to make users aware of > > the ecosystem around OpenOffice, which in turn means we can be confident > > that users will try to find functionality in Extensions if they don't > have > > it readily available in OpenOffice. > > > > Regards, > > Andrea. > > >
