Functional Analysi

User profile

As defined in the Functional Specifications, this regards the production of:

  • Access control: allowed or denied depending on the user profile or the user’s group authorisation.

  • The option to manage all, or part of, the data to be entered: it must be possible to introduce a view where user A inputs a part of the data and user B another part.

  • Authorisation level: it is the option to input and consecutively view only one’s own inputted data, or to have an access level of type “supervisor” to manage the data related to user groups.
  • The level of competence: i.e. the individual ability of inputting data, this involves giving the administrator the information regarding the speed level and ability of entering data for every user (1=able and expert user, 2=able but not expert, etc...), such that the quantity of work is prepared based on the disposable amount of time for every user.

In the first version, all the data entry operators had to be defined during the design phase. This resulted too constraining especially to those who wanted the liberty to manage the operators another time. To amend this, the user had to define a number of fictitious operators for example; operator 1, operator 2 etc…and then assign them to a particular user by giving him the access information.

To amend these deficiencies and to integrate the new functionalities, it was decided not to bind the data entry designer to enter all the users in the design phase. To do this it will be necessary to define an administrator and generic profiles. These generic profiles will be divided in 3 groups:

  • Simple data entry person
  • Expert data entry person
  • Supervisor

The simple data entry person is granted access by the system if he passes the login checks. He will be assigned his user profile along with the characteristics and the authorisations.

The user will be assigned to a part of the data entry with limited functions. He will not be able to do operations such as “Export” or “Archive”. Moreover, if a part of the data is defined as reserved for expert users, the simple user will not be able to view or modify the data.

Once the expert data entry person passed the access checks, he will be assigned to his profile with the authorisation of an expert user. This will consent the expert user to carry out the data entry activity, including Archiving and Exporting. The authorisation logic will be inclusive, i.e. every superior level will have the authorisations of the inferior level with added functions.

When the supervisor is recognized with the authorisations of the system, he will be able to carry out all the operations of the data entry equivalent to the expert data entry person. Moreover, the supervisor will have the option to view a series of the entered data which regard the information of the data entry. These aspects will be elaborated and integrated with the tracing module.

The administrator will have the option to define the group authorisation level for every user, along with having the supervisor authorisations. In this way, a user, which uses the data entry for the first time, can be set as a simple data entry person, and after analyzing his work, the administrator can change his group authorisation level to expert data entry person or supervisor without the need to modify his account.

Dynamic Layout Personalisation

We want to give the data entry designer the possibility to personalise and define more characteristics. The following possibilities were considered:

  • Personalising the data entry from the graphical point of view by using the company logo.
  • Choose and change the background or field colour depending on the fields of the data entry
  • Specifying a label for every field individually, directly modifiable from the viewer.
  • Create new fields by duplicating or multiplying existent fields;
  • Include further information within the interfaces.
  • Define a specific data entry guide, including an explanation of the field meanings.

Inserting a company logo for better graphical personalisation of the data entry: The user must keep present that one of the priorities of the data entry is that to have the major amount of space available therefore the designer must carefully consider the option of including a logo or not. The possibility to insert the company logo in the login screen, and eventually even in other screens of the data entry, can also be made available.

The possibility to personalise the visual aspect of the data entry by choosing the background colour: This can also be useful in the event where the document is in a different colour other than the normal colour. The designer will be able to choose a different colour which facilitates viewing the document. We also want to include a feature that allows the user to change the colour of the fields, or their background. This may be useful as part of the data entry may be assigned to a different operator; being able to distinguish the different parts of the data entry in a simple and visual way will facilitate the supervisor’s work. This eventuality will not affect the simple data entry persons; it is possible that only the parts that are under their responsibility will be shown.

Specifying and modifying labels in a simple way: It is not always possible to specify most appropriate label to define when specifying the fields. Moreover, the current application can only specify one name, which is extended automatically, when using multiple choice i.e. check box or single choice i.e. radio button. Although this method is very effective, it is difficult for who is not familiar with information technology to understand. In addition, in case of multiple choice that has to have different labels, it is not possible to modify one single label. If it was for example an indication of the characteristics of the document, and label Type_1, Type_2 etc… it would surely be less explanatory than using different labels to indicate for example; Fax, Invoice, etc… even if they make part of the same block. Moreover, the procedure to change the names of the fields, for the labels seems somewhat difficult to carry out. It would be better to give the designer the option to change the labels directly from the table of fields, or from one of the visualisation views that check the contents of the data entry, before generating it.

Creating fields in a simple way to avoid editing all the characteristics repeatedly: This can be done by allowing the user to be able to duplicate and eventually multiplicate an existing field. That is, having to create similar fields, one can specify to create fields identical to an existing field.

Include further information within the interfaces: even in this case, it involves of an adjustment that facilitates the work of the data entry person. The possibility of integrating might allow the operator to include an a priori checking phase. In reality, this feature may result to be pointless works, such as those that make use of an image to read the data, as the data entry person has to copy the contents of the image. This feature would be more useful when entering data directly on the interface such as, a feedback form for a website, a service, or a participation form for an event for example, the one we used for the presentation of the project for HANDImatica 2008. One must always bear in mind that the balance between including more information and clarity, and the cleanliness of the interfaces of the data entry is of fundamental importance.

Defining a data entry guide: a possible solution for some of the previously described problems may be, making the data entry designer write a specific guide, which includes information regarding a specific job, For example specifying the expected values and their meaning. This can be helpful if an operator is asked to correct any imprecisions of who has compiled the corresponding paper document. In practice, this guide will contain the information, which will be also used to specify the automatic checking although it can also include information, which is non-formaliseable with automatic tools.

Control Management

The control management gives the data entry designer the opportunity, to define for every field whether it must be checked or not. The type of control depends on the field type. This function may appear useless when the data is being read from a paper document, which is already complied. For Example, if there is a field with an identification number, defined as a numeric field, which accepts numbers between 0 and 15000, and in the scanned image, the person who filled the form wrote COPER, the data entry person must simply input what he reads, therefore COPER. However, if the operator inserts COPER, later when loading the exported text file, which contains the data, in a manager or an application, they will cause an error, depending on the complexity of the system and the procedure, for its level of importance. To prevent this, we intend to include a series of checks to inform the data entry person that the type is not acceptable. This will either bring about a “correction” on behalf of the data entry person, which will eliminate the forbidden value or the substitution of the forbidden value with a predefined value chosen by the designer, and shown in the guide to the data entry. A predefined value, which is correct for the applications used afterward, but indicate an irregular value which is a specific code indicating an error, or something similar. The checks to include and automatize can be catalogued in different levels:


· Data type;

· Permitted Values;

· Cross-Checking,


Data Type refers to the type of data which is accepted for given field. For Example, for an identification field, it can be useful to include a check, which verifies whether the inputted values are a numerical type, or for a Surname field check that all the characters are letters, without numbers.


Permitted Values indicates the accepted values for a given field. For Example if a field contains an identification number, where only values between 0 and 15000 are accepted, apart from the data type check mentioned previously, it would be convenient to be able to include another check on the values. This check can be defined as a range of accepted values or if a specific range of values cannot be formalized, a list which consists of all the accepted values. In the case where the field consists of a date, it can be useful to check the validity of the given date, and eventually the accepted dates. If the job regards a given year, it does not make any sense accepting other years other than the correct years.

Even if shown in the written data, the list of the accepted values can be also used for non-numerical field types, for example if there is a numerical field type, in a form regarding the Emilia Romagna, which represents the province, the list of the possible provinces can be predefined. Thus, it is possible to check a given value. It will be the designer’s responsibility to implement such checks, as he deems most fit.

Cross Checking involves at least two fields. The objective is to have a function, which allows the designer to define a control that checks a value, depending on the value of another field. For example, if the number of workers is 10, the total number of hours cannot be more than 80. In this case, the field that consists of the number of hours will have a control, which indicates that the number of persons multiplied by 8 is the greatest number allowed. Otherwise a flag in a field is set, thus the value in another field has to be greater than zero.

For all these situations it can be useful to define whether it is the case to substitute the wrong value with the predefined default value, or leave it to the operator to carry out the substitution after flagging it in some way.

Work Monitoring

Work monitoring is useful to distribute work better. That is, knowing which is the work done by an operator, rather than another operator, consents to balance better the load of work depending on the operator. This information serves also to be able to define the classification of the operators inside the defined profiles. The information of the traces must not be viewable by all the operators, but only by the supervisors and the administrator. There must also be the possibility on behalf of the supervisor, to specify a quality evaluation on the operator’s work.

Technical Analysis

Once determined which are the technologies to be used, i.e., the entire LAMP solution stack, we elaborate on the technical integration.

User Profiles

To implement the logical functions which regard: access controls, personalised data management, different levels of power and competence. in the functional analysis phase it was decided to move such management inside the data entry, allowing the administrator defined in the planning phase to define the groups and the users

This logic implies that when logging in to the data entry, the credentials aren’t only controlled to grant or deny access, but also to assign the user to his group, and inherit the operational credentials inside the data entry.

This implies that when the administrator logs in to the data entry, his interface will be different from that of the operators. He will be able to choose whether to go to the data input section, or to a management interface where he can define new users, choose which group to assign them and move a user from a group to another.

To do this it is necessary to add more information to the users. Furthermore, another table with the groups needs to be added. Otherwise, insert another field, which indicates whether it is a user or a group, for every user. It is recommended to use 2 separate tables for a cleaner structure and because the number of groups is limited, while the number users is superior. Thus, it would not make much sense repeating the information in all the records. However, there is still the need to show which the group a given user makes part of. It is also possible to do both contemporarily, inserting 0 in the field if the user is not associated with a group, the id of the group if the user is associated with a group, and the groups own id if the record belongs to a group.

The administrator might have his own group.

To implement the different functions of the groups with respect to the data entry, the Archive and Export buttons are blocked for the simple data entry person. It is also possible to hide them, instead of only blocking them, for better clarity.

The expert data entry person will have the already included existing functions, including Archive and Export. The supervisor will have additional control functions and views of the collections data. To access these interfaces a button can be included inside the data entry screens, or introduce an initial interface to choose whether to access the information section, or the data inputting section.

Dynamic Layout Personalisation

All the previously discussed functions are to be implemented during the Design Phase of the Data Entry.

For the company logo, it will be necessary to define some characteristics beforehand because they may be restraining as to refrain from graphically obstructing the insertion of data.

Particularly, the logo will be present in the log in interface, and in the selection interface, in which the user chooses among the different sections of the data entry, being; data input, information on data, or user profiles. It is then the designer’s job to decide whether to insert a logo inside the data entry screens as well or not. The logo should have reduced dimensions, and developed horizontally. It will be positioned on top of the page, and must be an image of a standard format: jpg, gif, png.

It is recommended to refrain from exceeding a height of 50pixel, and the width at will, keeping present that a size, which corresponds to a normally used standard monitor is about 1024pixel, it is recommended to use 800pixel for a correct view even on monitors with an inferior resolution.

It will be possible for the designer to choose the background colour and modify it in the planning phase.

Furthermore, in the case that the designer defines different sections to assign to the expert data entry person, the designer can choose a background colour for these sections. In a way, such that the supervisor will have an immediate visual indication that it is the expert’s section with respect to the normal one. The possibilities are showing the background colour of the field, or else the background colour of the border

For the Label a further field will be assigned to every piece of data, which brings back the Label to display, which can be different from the name. In the viewing of the data entry screen, before the generation, it will be possible to modify the Label directly from the interface, if possible

The structure with a further field, which represents a description of the contents of the field, will be integrated in the same way to give major information to the operator.

Regarding the creation of fields, starting from the existing fields, a button for the duplication of every field will be added. The logic regarding the position of the fields to avoid the overwriting of the fields is to be identified. In particular it has to be decided whether they will all be placed at the end of the already specified fields, or in succession of the duplicated one, sliding the others, or simply by checking that there isn’t already another field when saving.

The Guide to the Data Entry will be a pdf file or a document of in any other textual format, which will be uploaded by the Data Entry designer and linked by means of a button from every Data Entry screen, such that the operator can access the guide when needed.

Control Management

Once the controls are specified one must decide whether to implement them in JavaScript, for a quicker response, or in PHP and present a screen with the result of the controls in the successive phase to the insertion. The second option would be better for the interface accessibility problems with respect to the Italian Legislation on Accessibility (Legge Stanca) and the W3C regulations, but to speed up the processing the first option is better.

There can then be further developed by integrating the possibility of defining whether a control has to be blocking or not complying with the work’s continuation. However, we find that from our experience this too binding, thus it is preferred to leave a higher level of flexibility and delegate this job to the human control of the supervisor.

Work Monitoring

To achieve work monitoring it is necessary to integrate a field in the data table of the data entry, where to insert the nominative of the user in every input. This data must not be overwritten in the case of modification, and thus successive input. Furthermore, when exporting the data, the associated data will be saved for a successive view by the supervisor and administrator. Having given the designer the possibility to divide every page of the data entry between the simple data entry person and the expert data entry person, it would be the case to have more than one field with who has inserted the data. There should be three fields, in such a way as to save in each one, the simple data entry person, expert data entry person, and the possible supervisor who operate on the data entry.


This section will indicate how much was actually developed, starting from the analysis documentation. The explanations of the motivations which have brought different decisions with respect to those predicted, thus a type of guide of the application for better orientation inside the code, being an open-source project.


User Profiles

As emerged from the analysis, apart from the administrator, three user profiles were implemented. The administrator is the only user which is defined in the designing phase of the data entry. He will then be able to define new users at any time, modify their data, and assign them to the appropriate profile.

In fact once finished designing the data entry, and thus specified the administrator, a standard login interface is presented when accessing the deployment. Once logged in, the personalised home page is accessed. This home page shows a different menu depending on the profile of the acknowledged user. In case of the administrator, these options will be available:

Homepage: to go back to the initial page;

Data Entry: to go to the actual data input interfaces

Administration: to access the part of the application that consents the administrator to manage the users and groups;

Control: to view the information concerning the data inputting jobs in progress.

Queries: to view the statistical information of the past jobs which were carried out.


In case of supervisor there will not be administration, the expert data person will not have Queries and the simple data entry person will not have Control.


Possibility of dynamic layout personalisation


The possibility of integrating a personal logo to the interfaces was added. This can be done through a simple upload of a local image file, to be selected through a standard procedure which consents the user to browse the files in his computer. It is suggested to use images which aren’t very high, as to prevent taking space from the application. For the same reason it is possible for the designer to define whether the personalised image has to be visible only in the homepage, in all the data entry, or else hidden.


Regarding the possibility to indicate specific fields for expert users, the option to indicate the fields and the colour to highlight them was implemented. As to the possibility of hiding them to the simple data entry person, it was preferred to simply disable them. As the position and the sequence of the fields is fundamental in the view’s graphical setting, the designer has to follow as possible the graphic of the prospective paper from which to trace the data. Therefore hiding some fields can confuse the data entry person, furthermore it can be formative for the data input person to see how the expert fills in the mentioned fields. The possibility to indicate which are the fields reserved to expert users hasn’t been considered for multiple choice fields, or check box, and single choice, or radio button, as by their nature these type of fields are more easy and intuitive to use, as a result they are not included in the hypothesis of a field which is reserved for the experts.

The possibility to indicate an ulterior text for every field has been implemented, thus trying to avoid that the screen is filled up chaotically. A field in the advanced options was predicted, where an explaining text can be specified explicitly, this text is visualised when the mouse is positioned on the concerned field of the interface. In this way the screen remains clean and the information is available in case it is requested. Moreover, the text is also captured by the programs used for the unsighted. In the advanced settings, it is possible to define a different label for each item when dealing with multiple choice fields,


To facilitate and speed up the creation of “similar” fields to those already defined; a function which consents to “duplicate” a field was implemented. In practice once defined for example, a Name field, and defined the characteristics, length, type, etc, it is possible to define a Surname field, by simply clicking on the Duplicate button, at this point it is sufficient to indicate which are the characteristics to be modified, precisely the name of the field and the position.


To support the usability of the data entry system, the possibility to define a guide was implemented. The administrator can thus upload a file, in a pdf format, where he explains how to carry out the data inputting. Since it was considered that such a guide may be modified later on, such an operation was implemented successively to the design phase. Therefore the administrator can change the reference guide file, even while the operators are working.


Control Managing

The definite policies were implemented in the analysis phase. It has been considered convenient to leave the simple managing part separated from the advanced control one. This was done to consent a simple use of the system for those who have simpler needs, leaving the elaboration of the advanced part only to those who consider it necessary. Moreover the checks have been implemented under two forms:

· In JavaScript: for an immediate comparison as soon as the user exits from the controlled field, in this way a warning window appears with the relative error.

· In PHP: to consent control even if JavaScript is disabled. Furthermore this modality is available to supervisor users, who through the control button obtain a list of all the returned non stopping errors, and a direct link to the related form.


It is possible for a field to indicate whether its contents should be numeric, or literal. Furthermore the minimum and maximum values can be indicated, to carry out the checks of the value inputted by the operator, in such a way that it respects the range

Work Monitoring

Work Monitoring was implemented in two ways; the first one allows keeping the processing state of the operating block under control, while the second allows relooking everything which was processed on the same server.

In this way it is possible to see the state of the undergoing process in a simple way, in such a way to be able to monitor the flow of work, control the possible deficiencies, and know how much was done by a simple user, and by an expert user and anticipate the job’s end time.

Through the second modality, estimates regarding the complete job duration can be established, program with the major precision the subdivision of the jobs and assignments, be up to date of the evolution of the users’ capabilities and eventually modify their assignments.

Audio Transcriptions

Our direct experience in using the production of the application and in meeting the users in events such as HANDImatica2008 has emphasised how, despite the complete accessibility of the application, it was lacking in the possibility of use and work from the unsighted people’s point of view.

This stimulated us to create, design and achieve an additional component which can bring this possibility. The characteristics of the idea are precisely these: accessibility, teleworking, ease of use, and real possibility of application on behalf of the unsighted.

For this purpose we have noticed that one of the possibilities of employment could be that to exploit the other senses, which are very well developed and functional, in particular the hearing and the ability of interpretation and use of the keyboard in a nearly automatic way.

It consists of a component which consents to transcript audio files in a textual form. Through the application it is possible to upload an audio file in mp3 format, which is the most common format, for example from the recordings of a conference, or a meeting or a lecture. At that point after selecting the audio on to work on, it can be listened to, with the chosen speed through the player and the audio can be transcripted in the field below. Successively it is possible to relook all the work done for an eventual integration.

Like all the application, its accessibility and its technology consents a temporarily geographical splitting of the parts involved, achieving teleworking.


The system has been installed and tested on our web servers. We have implemented some data entries of our works on the application. Furthermore external people were asked to evaluate the comprehension and ease of use.