Estimated Feasibility of User Requirements
Scoring
The following is a paragraph form set of comments on requirements followed by separate desirability and feasibility scores and an aggregate total. The ranked table based on totals follows.
2.1 High Priorities
The high priority user requirements have remained constant throughout the life of the Project with the exception of the 'Radically Simple Interface' which was introduced through the Proof of Concept (POC) at d) below. They are:
a) Cross Platform
b) Basic customisable Features
c) Voice In
d) Radically Simple Interface
a) Cross Platform
The ability of the project to deliver data across platforms depends upon a specified standard for content providers who wish to have MyGuide content provider status.
This has constantly been at the top of the desirability rankings and its score reflects this. The Feasibility score reflects the poor perception of this priority amongst data producers in spite of its technical feasibility.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Cross Platform | 50 | 30 | 80 |
b) Basic Customisable Features
Minimum customisable features should include:
- Foreground/background colour
- Print size, font
- Proportionate spacing and right-hand justification and right hand unjustified
- Leading
- Sound volume
- File size download
NB - Customisation must apply to metadata as well as to data.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Basic Customisable Features | 45 | 45 | 90 |
c) Voice In/Voice Out
Voice in technology using major dictionaries (up to 30,0000 words) works reasonably well on client side computers. Voice in also works on telephone enquiries using very small vocabularies. Technically there is no reason why a user should not be able to use a dial-up method to switch on a server side voice-in application but this would have to be developed and tested.
However, because voice in is so high on the user requirements list this is the area where we should publicly commit ourselves to further and urgent work.
Voice out technology on computers is relatively expensive and works best on the client side; but the key voice out technology for intern=et access is the telephone. Web sites can be written for telephone access, e.g. the current DCMS site. This should be a basic component of the MyGuide data standard.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Voice In/Voice Out | 40 | 10 | 50 |
d) Radically Simple Interface
The radically simple interface did not feature in the initial Ranking; it emerged from the (POC).
In this context radically simple interface is taken to mean a screen oriented to a single task or to the delivery of a single item. For example, when a user opts to send an email the whole screen is cleared for that purpose except for:
- Back to previous task
- Home
- Next steps.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Radically Simple Interface | 40 | 50 | 90 |
2.2 Response to User Behaviour
There are four areas where the system is expected to adjust to user behaviour over time. In the Ranking these were aggregated and this is reflected in the Desirability scores but the reason for disaggregating the four features is their very different feasibility scores.
The four areas of response are:
e) Fit for Purpose
f) Reading Age
g) Ranking
h) Cultural Sensitivity
e) Fit for Purpose.
Fit for purpose means that users receive data to conform with the task they are performing. This can be achieved through an algorithm which separates, for example, peer review journals from more popular data. Google already uses such an algorithm but ours would have to be slightly different, based on a user requirement rather than aggregate use. The performance of such systems is critically improved by good data tagging but most reports are produced through context sensitive search software.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Fit for Purpose | 35 | 40 | 75 |
f) Reading Age.
In many ways, providing adults with adult material at their appropriate reading age is the 'Holy Grail' of a project such as MyGuide. The technologies to produce this outcome all exist separately but have, to my knowledge, never been put together:
- Tabloid newspaper use automated 'reading age' analysis to check their copy
- There are a variety of précis engines
- There are a variety of lexicographic simplification systems based on dictionaries
- Systems can be designed to react to user behaviour.
There is no possibility that these technologies can be combined and tested without a considerable amount of work.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Reading Age | 35 | 25 | 60 |
g) Ranking
The Fit for Purpose criterion in e) represents one kind of ranking; an algorithm will rank material according to genres such as journals, newspapers, and bloggers.
The ranking represented here is ranking according to Cybrarian data standards which, are, provisionally:
- Data which conforms to the MyGuide Content and Standards Forum
- Data that conforms to HMG standards (including WAI)
- Other data filtered
This is relatively simple at the top ranked level because MyGuide compliant data can easily be registered; and at the third ranking level there are a variety of filt3ers that can be applied. The middle level, however, presents some serous difficulties because most HMG data does not conform to its own standards. I suggest that at the second level standards are applied as automated tools are developed to assess compliance; thus WAI can be included as a second rank standard because compliance wit5h it can be automatically tested.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Ranking | 35 | 35 | 70 |
h) Cultural Sensitivity
In theory, selecting for cultural sensitivity should be possible through the use of dictionary barring mechanisms and barring based on pattern recognition of objects. If these were to be invoked whole sites would have to be barred where single pages were deemed likely to cause offence but this is an extremely difficult area as it would almost certainly involve barring major sites like the BBC and encyclopaedias. this needs much more intensive discussion but, in the meantime, the feasibility problems produce a low ranking.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Cultural Sensitivity | 35 | 10 | 45 |
2.3 Language Translation
j) Automated Translation
Although there are some dictionary based automated language translation systems they are of very limited use in a project like this. They naturally work best between Latin-based, Roman script languages and work much less well with pictographs.
It should be possible to use translators for labels but not for long strings.
For those who do not speak any English the Desirability score is, in essence 100% but we have to take into account the statistical prevalence of the need (given that it would only initially cover two languages other than English).
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Automated Translation | 30 | 10 | 40 |
2.4 Broader Requirements
The following are requirements which are somewhat broader than those in previous sub Sections; they are:
k) Portable Profiles
m) Multi Modality
n) Variable Navigation
p) Interactive
q) Tools/Prompts
r) Legacy Compatible
s) Peripherals Compatible
t) e-commerce
k) Portable Profiles
The issue of portable profiles will slip down the priority list as more people carry broad band cellular telephones. In the meantime, the simplest way of achieving portability is for the system to store a profile and respond to the simplest log-in; in this context "Profile" means settings from b) above and any other customer requirements which the system has collected, e.g. the interests and activities of the customer..
Of course there can be a Catch 22 here that the person cannot log in without the profile being loaded but any person is unlikely to be using a third party device in an environment where there is no help unless they are accessing such a device in a private residence, an eventuality we cannot easily cover.
The decreasing importance of the portability of the user profile because of the increased portability of user interface devices explains the lower Desirability rating than in previous rankings.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Portable Profiles | 25 | 45 | 70 |
m) Multi Modality
Multi modality, the simultaneous delivery of data in a variety of forms (symbolic language, audio, graphics) is largely a matter of data standards. It is central to the MyGuide experience for blind and visually impaired and deaf and hearing impaired people, for those with learning difficulties and those for whom English is not their first language.
There are no serious technical drawbacks to providing:
- Description of graphics
- Additional audio (audio and video description)
- Captioning or sub-titling
- Signing.
All these processes are, however, labour intensive and cannot reasonably be required for existing material. Appropriate multi modality should be required of new material created by Members of the MyGuide Content and Standards Forum. The Feasibility rating reflects the cost.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Multi Modality | 30 | 35 | 65 |
n) Variable Navigation
Variable navigation is the most crucial metadata issue for the system. It cannot be imposed on major sites and so our methodology will have to be one of providing variable navigation at our own 'front end', capable of taking customers to relevant pages within sites rather than simply dropping them at a home page.
One simple navigation strategy for use with telephones has emerged during the Project's life and that is high level taxonomy using no more than nine classes followed by SMS key word searching. Whether or not this is adopted the requirements of the Radically Simple Interface (see d) above) would indicate high level taxonomy that accords with the (7 + or - 2) rule.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Variable Navigation | 35 | 40 | 75 |
p) Interactive
There is a deep ambivalence at the heart of the discussion of interactivity largely resulting from mixed views about games as an educational tool.
With the exception of content which MyGuide commissions itself, where it may wish to specify a level of interactivity, I recommend that this issue is dealt with neutrally; that the level of interactivity should depend entirely on the capability of the customer user interface. On this basis the Desirability is scored at zero; the feasibility is relatively high because of the rapidly declining use of legacy PC's as user interfaces for digital content.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Interactivity | 0 | 40 | 40 |
q) Tools/Prompts
The requirement for tools and prompts was tabled early when the Project saw itself as much more proactive in content creation in general and in educational content creation in particular.
On this basis the scoring for both desirability and feasibility could be radically altered as the result of a policy decision; a rise in the desirability score would lead to more MyGuide bespoke content creation which would result in a higher feasibility score. For the time being I have put them both at their mid point.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Tools/Prompts | 25 | 25 | 50 |
r) Legacy Compatible
With the more rapid growth in PC turnover and decreasing dependence on the PC as a user interface, legacy compatibility has been steadily falling as a key desirability factor. Conversely, to maintain this as a high priority becomes less feasible as it would rule out increasing volumes of content. There is a file capacity setting in b) above.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Legacy Compatible | 20 | 20 | 40 |
s) Peripherals Compatible
Peripheral compatibility to accessibility devices such as screen readers and to hard copy printers is an important criterion in design but no longer a major issue with the emergence of the USB for cabling and blue tooth and other cable free protocols for communication.
At some point MyGuide should issue an advisory hardware specification which should allow users to access all of the content in the first and second ranks; but as this is advisory, this requirement is scored in both cases at zero, not because it is not important but because MyGuide has now power to specify hardware.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| Peripherals Compatible | 0 | 0 | 0 |
t) e-commerce
e-commerce was ruled out during the Review. It is desirable for house bound people but it is not possible to limit the kind of e-commerce which could be permitted in the system.
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| e-commerce | 10 | 0 | 10 |
| User Requirement | Desirability | Feasibility | Total |
|---|---|---|---|
| b) Basic Customisable Features | 45 | 45 | 90 |
| d) Radically Simple Interface | 40 | 50 | 90 |
| a) Cross Platform | 50 | 30 | 80 |
| e) Fit for Purpose | 35 | 40 | 75 |
| n) Variable Navigation | 35 | 40 | 75 |
| g) Ranking | 35 | 35 | 70 |
| k) Portable Profiles | 25 | 45 | 70 |
| m) Multi Modality | 30 | 35 | 65 |
| f) Reading Age | 35 | 25 | 60 |
| c) Voice In/Voice Out | 40 | 10 | 50 |
| q) Tools/Prompts | 25 | 25 | 50 |
| h) Cultural Sensitivity | 35 | 10 | 45 |
| j) Automated Translation | 30 | 10 | 40 |
| p) Interactivity | 0 | 40 | 40 |
| r) Legacy Compatible | 20 | 20 | 40 |
| t) e-commerce | 10 | 0 | 10 |
| s) Peripherals Compatible | 0 | 0 | 0 |