Michal's Design Study
(I must be tired) |
|||
| Line 15: | Line 15: | ||
* Create instance(s) of components | * Create instance(s) of components | ||
* Link components together | * Link components together | ||
| + | |||
| + | === A little more detail === | ||
| + | The basic function of the plugin system (henceforth known as PluS) is to load and activate plugins. Information about each plugin will be stored in an XML file, in a known location. PluS will use this information to fulfill its purpose, and gain entry to software nirvana. | ||
== Stuff I currently need help with == | == Stuff I currently need help with == | ||
Plugins shouldn't be loaded if not all their dependencies are there. However, their dependencies may exist but not be loaded until later... Any ideas on how to deal with this? Information on each plugin & its dependencies etc is given in a separate xml file. | Plugins shouldn't be loaded if not all their dependencies are there. However, their dependencies may exist but not be loaded until later... Any ideas on how to deal with this? Information on each plugin & its dependencies etc is given in a separate xml file. | ||
Revision as of 07:38, 3 October 2009
Contents |
The Problem
Many clubs or charitable organisations are staffed by volunteers, or staff with little training in computer use. Commonly used software (such as Micrososft Office, or accounting packages) are complex and can be difficult to use due to the vast array of options presented to the user. Most of the features will never be used by a particular person, yet all options are available regardless. This can leave users bewildered and unable to figure out which option they want.
Furthermore, some tasks require the use of multiple pieces of software. Integrating these creates another layer of complexity on the users part. For example, to create a contact directory for members, it can either be all typed up manually, or a database created and then combined with a template to create the directory. One option is more time consuming and error prone, the other more conceptually difficult for a novice user.
The Solution
I propose to create integrated, modular systems tailored to individual organisations. Customers would be able to choose form an array of prewritten components, or choose to have custom components created, if what they want doesn't yet exist. The first step in doing this is to build a plugin architecture which will support the loading and linking together of these components.
Requirements
The basic list
- Load required libraries for each component
- Create instance(s) of components
- Link components together
A little more detail
The basic function of the plugin system (henceforth known as PluS) is to load and activate plugins. Information about each plugin will be stored in an XML file, in a known location. PluS will use this information to fulfill its purpose, and gain entry to software nirvana.
Stuff I currently need help with
Plugins shouldn't be loaded if not all their dependencies are there. However, their dependencies may exist but not be loaded until later... Any ideas on how to deal with this? Information on each plugin & its dependencies etc is given in a separate xml file.
