[libreoffice-design] Re: Minutes of the Design Hangout: 2016-Jun-17

sberg wrote
> On 06/17/2016 03:47 PM, Heiko Tietze wrote:
> > Enhancements and proposals
> >     + Push extensions (Heiko)
> >       + e.g. tdf#71176, tdf#91874, or color replacer, or overall
> > paragraph changer etc.
> >       + Extensions keep the main UI clean and simple but allows to
> > enhance the app for special use cases
> >       + Suggestion is to have a separate component/keyword in the
> > bugtracker for tasks that can be enhancements
> >       + Find users/coders to work on extensions
> >       + We have a component extension (kendy), qa team should make clear
> > what it is used for (Jay)
> >       + Would need some needDevEval before moving a bug to this component
> > (Jay)
> >       + Will bring it up to ESC for pushing it to the community
>
> Just to clarify: You're talking about .oxt extensions here?

Would they have to be?    From the UI Design/UX perspective we should not
care. But from a development, implementation, and maintenance
perspective--worlds of difference.

If the "extension" allows us to modularize  the UI -- and to not install or 
simply disable  "extensions" that the OS/DE directly support--that should
allow for a UI "clean and simple".   It should not matter if that is an
embedded feature enabled/disabled by UI or Expert Configuration, or is
"external" and configured via the Extension manager. 

Take as an example--the LibreOffice "native" dialogs.   Disabled by default
and using the file management provided by  OS/DE.  But for some users--the
OS / DE does not support the use case(s) and they *have* to switch to the
LibreOffice dialogs.

The bigger issue becomes how consistently an "extension" would be maintained
relative to the core UI elements.   It seems our history has been that
"extensions", whether bundled with LO installers or offered via the
Extensions web site,  are treated with benign neglect by the QA and
development cadre. If the developer looses interest--the extension dies.

It would be unfortunate if we end up pushing substantial UI features and
functionality out of the core and into "extensions" and then have the
project disown them.  For this to move forward there needs to be a class of
"extensions", either as OXT *or* embedded contributions, that will have ESC
oversight to assure long term support.

Otherwise great idea.



--
View this message in context: 
http://nabble.documentfoundation.org/Minutes-of-the-Design-Hangout-2016-Jun-17-tp4186453p4186479.html
Sent from the Design mailing list archive at Nabble.com.

-- 
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted