Hello all...

I have an interesting general for platforms supporting: extras, macros,
add-ons, plug-ins, extensions, themes, what have you.  For this post, I'll
jsut use "plug-in" as a *generic* term meaning all things you can
add/theme, etc.


*use-case:*

I've faced the same situation on many platforms, across many
release-cycles, and over many years.  Some identifable examples include
Netbeans, Firefox (since v5), Chrome, Eclipse, even application tools
Excel, Word and OpenOffice/LibreOffice, etc.

Almost with out exception, when new releases comes-out I as an end-user
loose functionality when the "plug-in" version no longer matches or if the
model changes.  Last year Firefox changed the whole plug-in interface and I
lost every day productivity because things aI had a habit of using were no
longer "present" or compatible.

I am sure you are familiar with the feeling when your favoured tool or
add-on is no longer there?  An example to talk to is this: the Netbeans RC
and Beta both happily supported the plugin  QuickOpener during my various
opportunities to trial these two pre-release candidates.

Alas, Netbeans release 9 does not.  I'm sure there are reasons.  I'm taling
to two points.

   1. Capability -- Evidently Netbeans as RC1 can support QuickOpener (it
   is feasible and practical)
   2. Usability -- Those features that I may use 4 or 24 times a day are
   now gone.

I believe there are ways to be nicer to end-uers when migrating / upgrading
versions.

*suggestion*:

Here's an approach to improve the User Experiece.

Support backward compatibility for just one version back.  In this case
Netbeans 9 might have supported existing Netbeans 8 plug-ins.  Not all of
them but from my using of Netbeans pre-releases I had no problem with most
of them.

*process*:

In order to Not be a burden progressing between versions there need to be
some simple rules/steps.

   - Make the previous version compatiblity layer a configurable option in
   the config file (or start-up option).
   - No support is promised for unqualified / out of certification, older
   plugins, but if it works why not let it run.
   - When a compatible version comes along the normal update stream should
   upgrade the plugin.
   - On the Netbeans Tools / Options panel, all plug-ins should report a
   few things in an about box or sub-panel
   - Plug-in version number
      - Netbeans certificaiton / release compatibility
      - Project URL (and source when open source -- encourage folk to
      upgrade old plug-ins)
      - URL-s to report bugs, documentation
   - The infrastructure to activate/deactivate plug-ins already exists
   - Highlight any Retro Plug-in in the plug-ins in a different colour
   (brown??)
   - In the plug-in sources settings provide two plug-in repository channels
      - current plugins
      - retro plug-ins
      - Perhaps even provide a check-box or a tab on the plugin choosing
      panel to select between the two sets of plug-ins.
   - Get plugin to provide a button for displaying or saving settings to a
   human readable format
      - that way settings that are not saved in Export can be kept

*summary:*

I happily installed Netbeans 9 and import-ed by settings from netbeans
v8.2. All was good ...So far as it goes on the technical side.  However all
these platforms that use plugins share the same issue when it comes to
breaking changes -- And the end-user always loses the toss of the coin.
The main tools I would need to use Netbeans day to day are not ready yet.

At least that means without some level of a retro plugin layer, adoption is
retarded and the user base is limited.

In a nut shell, I think that for the sake of continuity of service and
maintaing a great User Experience the software industry (meaning
individuals and projects... ) need to really factor in support for

   - "User Experience Service Continuity".

The label is awkward, I know. Thing is the settings I imported can not all
work because the plugin that might know about them doesn't 'exist' for
Netbeans 9 or Firefox 54 or Excel 2010.  People often say how they want to
support the users, but these workflow breaking changes remind me of the
1980-s user design.

I would keep silent if not for the lucky evidence from  the Beta and RC1
experince where plugins I can't use today worked happily on Netbeans RC1.

That's all.  What about it?  Wouldn't you like to have compatible tools
from the previous version until they are upgraded?

Best wishes,

   aplatypus

-- -- --
Some plugins require plugin org.jdesktop.beansbinding to be installed. The
plugin org.jdesktop.beansbinding is requested in version 1.13.1.121.

The following plugin is affected:
      QuickOpener
Some plugins require plugin Common Test Runner API to be installed. The
plugin Common Test Runner API is requested in version >= 1.31.1 (release
version 1) but only 2.11.1 (of release version different from 1) was found.

The following plugin is affected:
      Gradle Support
Some plugins require capability cnb.org.netbeans.modules.groovy.kit No
plugin providing the capability cnb.org.netbeans.modules.groovy.kit could
be found.

The following plugin is affected:
      Gradle Support

Some plugins not installed to avoid potential installation problems.


 ___________________________________

Reply via email to