3.2.2 - Formative project skills: usability, data and validation

Usability features respond to a user's task

Usability concerns how effectively users can carry out their intended tasks. Describe a feature through a need, an interaction and its consequence. “Make it user friendly” cannot guide implementation or testing. A particular feature, such as a persistent field label, can: a visitor still knows what a field means after typing into it.

Consider a formative equipment-return screen used by volunteers who process several returns quickly. The design might include an always-visible “Equipment identifier” label, a search result showing the equipment name, an explicit “Confirm return” action and a confirmation containing the returned item's identifier. Showing the name before confirmation helps the volunteer spot a mistaken identifier. A confirmation helps distinguish a completed return from an unprocessed entry.

Features have trade-offs. Confirmation for every harmless click can slow frequent work; a destructive action warrants stronger protection. Disabled controls should have an understandable reason, and validation messages should state the accepted format. These are proposed behaviours, not proof that users found an implemented interface usable; that needs actual observation and feedback later.

For the assessed project, the current specification requires a suitable graphical interface and a suitable text-based high-level programming language. Its accepted list includes Python, the C family, Java, Visual Basic, PHP and Delphi. A language outside that list must be submitted to OCR for consideration before use. Project-setting guidance describes rare command-line exceptions requiring prior OCR authorisation. Do not assume a console exercise qualifies. HTML/CSS markup alone does not demonstrate the substantial high-level coded solution. Practise GUI development in an appropriate local IDE or browser environment; NovaLearn's Python console checks do not establish project GUI performance.

Choose variables from meaning and permitted values

A data dictionary records a variable's meaning, type, permitted values and intended use. Choose these from the problem, not from whichever type was quickest to code. An identifier containing leading zeroes may be text even if it contains only digits; a quantity intended for arithmetic needs an appropriate numeric representation.

For a fictional climbing-session booking, the identifier 00742 must remain five characters. Storing it as integer 742 loses information. A participant_count is an integer because whole people are booked. A price_pence integer can represent an exact non-negative price in pence without binary floating-point rounding of decimal money. Display conversion to pounds is a separate responsibility. A confirmed Boolean expresses two states only; a booking with pending/confirmed/cancelled states needs a defined multi-valued status instead.

State range endpoints, units and whether empty values are allowed. A name like price leaves units ambiguous; interpreting pounds as pence changes the result by a factor of 100. Validation checks data against stated constraints. Verification checks that data matches its intended source, for example comparing an entered identifier with the original form. Valid-looking data can still identify the wrong booking; validation does not prove truth.