|
|
Personal Development Planning practice and systems |
This is further help to use the site at http://www.cetis.ac.uk/members/PDPcontent. The site is provided only for registered users. To apply for registration, please send details to the site maintainer (see below).
This is only available to users registered as managers or editors of their PDP information. If you should have this access but do not, please apply to be registered to the site maintainer (see below).
The edit form associated with each object has fields to edit all of the main information that appears on the page. In addition, it has a number which governs the order in which the object appears next to others in the tree display. This is useful to represent any natural ordering of the items.
Clicking on the button will save any changes made. Clicking on an ordinary text link will NOT save any changes made in these input fields.
Below the button will be listed any objects that come directly below the current object, along with a link which allows deletion. Clicking on the delete link leads to a confirmation step. After the confirmation button is clicked, the information may be completely lost. In emergency, if a costly mistake has been made, contact the site maintainer with full details to see if the mistake can be rectified. Nothing is promised!
There is also a link to create any new sub-object that is allowed. Clicking on this link brings up a form on which you can put in the basic identifying details of the new object you want to add. The form generally allows you to create the new object and then
In some cases, where necessary the buttons vary from this, but in each case they should be self-explanatory.
If you are entering a lot of new content, or entering complete new details of institutional PDP practice, or of a complete IT system, you should first try to understand the structure of the objects which you have to fill in. A good first step is to take a good and thorough look at other filled in examples. Beyond that, you should understand a few important principles.
The "programme" is a complete, self-contained set of related PDP activities, perhaps across the institution, or perhaps within a department. Often there will be just one programme in an institution, but sometimes different departments will have originated different approaches, with more than one programme resulting.
What is put in as "processes" is largely arbitrary. In simple PDP practice, there may not be any identifiable processes; but if there are major divisions of the PDP programme (such as: induction; progress review; career preparation or whatever) it will be useful to represent these as processes.
The process element is intended to be a small identifiable unit of practice that is never broken up into logically separate parts. Common examples might be a tutorial, an exercise, a task, a meeting, an interview, a lecture. It is important to identify these process elements clearly, preferably in such a way that the inputs to and outputs from each element are as clear as possible. A long class might have more than one element to it, if more than one output results.
Identifying the process elements is important because three things hang off these: the generic activities (from our list) that happen in that element; any outputs that are produced, and any inputs that are used.
Within each output you then should compare with each of the generic part outputs from the list. Th appropriate input form makes doing this quite straightforward.
The really important things to record about an IT system are the pages (or forms etc.) that make up the interface - that is what users see - and the data structures that are used to store the information gathered on these pages. In a system with many pages and fields it is necessary to give these some structure, and it is expected that the way in which the interface is presented to users has some structure, so that the user can recognise which part of the system they are in, and that the data storage has some structure, so that programmers can understand it and work with it.
Pages are contained by "components". A component is an arbitrary division of a system, and can be sub-divided into lower-level components as much as needed. You may only need one level of component for a simple system. The components should reflect the structure which appears to learners as they are using the system. When you edit a component at any level, you have the chance of claiming that it supports particular PDP activities taken from the generic list. At the end of every branch there will be one or more pages, which capture how the interface appears to learners at that point.
It is often neither necessary nor desirable to record every single different page. In most systems, there are several pages that are there for navigation purposes, to offer the user a choice of next step, or an introduction to the next step, with their interactivity limited to choosing a link. These do not need to be recorded as separate pages - their existence is implied in the component structure.
Each page may use information from the database, and it may contain a "form" which when submitted, changes that information stored. Sometimes the pages are associated with each other - one page displays the information, and an associated page allows its modification (as in this site). In that case, the simplest option is to record a single page, which will allow viewing and editing of that information.
The site then allows you to break down a page into separate "displays" - that is the individual fields, or groups of fields. In many cases this is not necessary, if it is clear that the page as a whole is easily associated with a particular generic "part", as noted in the lists. But if it is done, is allows the finest recording of which data structures are used, and which changed.
Back on the other side of the analysis, data fields are contained by "structures". These may be particularly difficult to represent, because in many databases there is no clear correspondence between the tables and what the information represents. If you have a table which holds more than one kind of data, it is suggested that you create structures below the table, to represent each of the kinds of information that is stored in that table. In that way, you will be able to map the interface pages clearly against the data structures.
At every level in the data structures, you can indicate any correspondence between the system's data structure and our PDP part outputs, seen as data types. It may be particularly helpful here to look carefully at other worked examples. This is likely to be the most difficult part of the description of your IT system on the PDP survey site. If it proves to be too difficult, then it is possible to leave out this section of the survey, as long as the pages and displays are fully related to the generic part outputs, as mentioned above.
It is inevitable that the structures chosen for this survey will not fit every IT system well. Informants are asked to remember that the exact way in which the system is documented is only important insofar as you wish to explain the contents of the site to others, and allow it to be compared. One of the most useful comparisons, which will be able to be worked into several automatic tools which will be developed on this site, is based on the generic activities and parts. As long as all the activities and output parts of the system are reasonably represented in the structure that you record here, it will serve some very useful purposes.
The better-established IT systems tend to develop variant versions: either as the system is extended or updated, or as it is customised for different institutional sponsors or users. The strategy you use for representing different versions should depend on whether the versions represent add-ons to or subsets of the main system.
If you have a main system with add-ons, first document the main system's components and structures, and then create version objects directly under the system as a whole. Within each version, add just those components and structures that do not yet appear in the main system. When readers browse your documentation, all the components and structures from the main system will appear automatically within each different version.
If, on the other hand, your versions are more like subsets, then again first document the whole system. Under each version, you will be able to note the exclusion of any of the top-level components or structures that you have noted in the main system.
You can also mix the two approaches. On the whole, you want to document each component or structure just once. If you try documenting the same thing twice in different places, quite apart from the extra work involved, you are opening yourself to version errors. So if any structure or component is used in more than one version, it should be placed in the main system, and then excluded from all the versions it does not appear in.