Plug-in – a plausible solution?
Our development group has a new challenge, of creating an interface to software customization group. The software customization group creates features to the main product, which are custom tailored to specific customers. One area perceived as problematic is the area of GUI modifications and addition of new capabilities. GUI modifications are regarded as hard core modifications due to the complex nature of the solution, and may be done only by the GUI team. This is of course completely incompatible with the requirement of having two different groups working on complementing features.
In order to provide a possible solution, the requirements should be clearly stated:
1. User experience should be adapted to include additional features:
(a) New views
(b) New actions
2. Adaptation should be optional
Judging other products, there is a possible solution; by using Plug-Ins. Plug-Ins as defined by Wikipedia are specific sub-applications that interact with host application. One of the reasons detailed in the article is “to enable third-party developers to create capabilities to extend an application”.
Sample applications using Plug-Ins are Photoshop and eclipse. Photoshop allow 3rd party Plug-Ins that perform new actions on the information – new image manipulation filters and new types of information exchange. Eclipse allows for Plug-Ins that provides editing of new file types, new projects and can modify every aspect of the application. For our requirements, we need the capabilities of Photoshop and Eclipse, but we need also access to central DB, where the information is stored. A similar system is SAP, where the information is stored centrally, but there are Plug-Ins for receiving and modifying information.
A Plug-In system is a plausible solution, but it needs additional refinement, mostly in definition of requirements and hooks for Plug-Ins to connect.
If you read this far, you should
follow me on twitter here.