A "steel thread" run through the JobSearch plugin would conform to the steps
displayed in the following process diagram.
Introduction Screen:
When the user enters the job search plugin, they are presented with the introductory screen to the application. This gives a brief overview of the plugin's capabilities, and versioning information.
To continue with the job search, the user clicks the start button.
Select job group, type and title:
The job search is structured in terms of a hierarchy of job groups, job types and job titles. Each one of these entites has a corresponding SOC code. The SOC code for the job title is the one that is eventually submitted to the Worktrain API as part of the search criteria. To get this, it must be drilled down to from the job group screen:
From this, the user will then iterate through the list of jobs, via the "more" button or drill down to the list of job types:
The user then picks a job type, and drills down to list of job titles:
The chosen job title choice then produces a SOC code in the application. This will eventually be submitted to the Worktrain API.
Search Preferences:
The primary search preference screen consists of the following:
The postcode field is mandatory, and must contain a valid UK postcode. The postcode validation in done in accordance with the UK specification
at http://www.govtalk.gov.uk/gdsc/html/frames/PostCode.htm.
The WorktrainApi supports a wide range of distance based search criteria. For example, instead of searching based on distance from postcode, one
could have searched in the whole of Great Britain. Also, it should be noted at this stage that the API can return non job centre plus vacancies and EURES vacancies.
None of the aforementioned however were part of the requirements.
The job vacancy list, and individual job detail:
When the search preferences have been submitted to the API a list of job vacancies will be returned:
Following this, the user can pick a job. Due again to screen size limitations and the level of job detail returned from the API, this data must be paged through:
When the user reaches the end of the job details, they can either return to the job list, via the application back buttons,
or move to the next job in the vacancy list.
For a single job vacancy, the actual quantity of data returned from the Worktrain API to the plugin is significant. The only
fields that the plugin currently displays are, in the following order:
- Job No
- Title
- Closing Date
- Location
- Hours
- Wages
- Pension Details
- Duration
- Restrictions
- Gender Exemptions
- Racial equality exemptions
- Disability equality exemptions
- Required skill
- Agency name
- Agency email
- Contact name
- Employer
- Employer's tel
- Employer's fax
- Employer's email
- Language required
- Description
- How to apply
- Any miscellaneous messages associated with the vacancy
- Information describing whether the vacancy is friendly to disability.
If any of these fields do not have a value in the vacancy returned from the Worktrain API, they will not be displayed in the plugin.
Exceptional States:
The application can move into an exceptional or erroneous state, due primarily to the following:
- Connectivity problems with the Worktrain API.
- Badly formed API queries
- Validation errors, from incorrectly formatted data.
When the plugin reports an error, an error screen will be redirected to, displaying a description of the error encountered. When the user continues from this screen,
they will be routed back to the beginning of the application.
Currently, the only validation performed in the application will be on the submitted postcode. If the postcode does not validate, the following screen will be displayed:
Additionally, if the postcode is not supplied the application will display the same screen with the message
"Please enter a full postcode".
Note the postcode must always be supplied, unless "All of GB" is used as the distance criteria in the search preferences.
