The increasing use of the Web as a software platform together with the advance of technology has promoted Web applications as a starting point for improving the communication between citizens and administration. Currently, several e-government web portals propose applications for accessing information regarding healthcare, taxation, registration, housing, agriculture, education and social services, which otherwise may be difficult to obtain. However, the adoption of services provided to citizens depends upon how such applications comply with the users needs. Unfortunately, building egovernment web site doesn't guarantee that all citizens who come to use it can access its contents. These services need to be accessible to all citizens/customers equally to ensure wider reach and subsequent adoption of the e-government services. User disabilities, computer or language illiteracy (e.g. foreign language), flexibility on information access (e.g. user remotely located in rural areas, homeless, mobile users), ensure user privacy on sensible data are some of the barriers that must be taken into account when designing the User Interface (UI) of e-government applications. Whilst several initiatives (such as the W3C WAI) focus on how to promote usability and accessibility of content provided via e-government, many governments are enhancing their technology to make their services compatible with new communication channels available through multiple devices including interactive digital TVs (iTV), personal digital assistants (PDAs), and mobile phones. In this paper we focus on this latter issue, which means the development of multi-target e-government services available across several platforms. In this paper we present a case study focused on the development of multi-target e-government services available across several platforms. We discuss the major constraints underlining the importance of investment on the UI's design of e-Government applications.
The large variety of computing systems available nowadays (e.g. desktop/notebook computers, cell phone, Smartphone) has created a milestone for cost-effective development and
Public administration should ensure multiple access points to e-Government applications (e.g. home access via Internet, computer-based kiosks, mobile platforms).
The ever growing number of users of e-Government applications calls for universal access to e-Government applications. Usability has become one of the major challenges for large adoption of many e-services provided to citizens, in particular those suffering from some kinds of disability or having some literacy barriers (e.g. illiterate users, immigrants seeking information about the country).
E-Government applications present several advantages for both front office users (e.g. citizens, associations, companies and so on) and back office people (e.g. government employees, administrative clerks) as they reduce costs of information transfer and treatment. Thus front office and back office users are two sides of the same coin. Whilst universal access should be provided to front office users, usability for back office users should not be neglected as some usability problems could cause errors and/or losses of data that might compromise the quality of the whole system.
As far as the costs of services is a major issue, it should not
be counted as a simply addition of costs related to
implementation, deployment and maintenance of
applications but it must include the adoption rate of
services by citizens. A countless number of e-government
initiatives worldwide failed because by low technology
adoption levels in their communities. Concerned by these
problems, a number of recent studies have investigated the
general adoption of e-government services in developed
countries [
This paper discusses how to envisage scenario for new communication media and in particular, their deployment over many platforms. At the light of a real case study of eprocurement services for students applying for scholarships, we discuss solutions for delivering multitarget user interfaces. Our work is underlined by two main assumptions:
By focusing on end-users’ requirements we can improve the usability of the UIs and select the platforms that best suit their needs, thus reducing the risk of rejection;
By focusing on users’ tasks we can determine the complexity of the steps required to accomplish an administrative procedure and then assess the technical feasibility of deploying tasks on multiple platforms.
In this section we present a summary of the most relevant communication channels nowadays for the e-government domain.
The World Wide Web was the starting point for integrating
services available 24/7 while promoting faster and efficient
connection between agencies, processes and systems. As
far as e-government services are a concern, one can notice
several stages of sophistication [
Emerging Web sites: much of the information is static and there is little interaction with citizens.
Informational Web sites: citizens can download forms and documents including law and regulations;
Transactional: two-way interaction between ‘citizen and government’ where all operations are conducted online (e.g. web-based tax declaration).
Full-case electronic case handling including connections with actors involved in the process (e.g. central and local government agencies, direct connection between citizens and governments, and connections among stakeholders).
In the last years, several initiatives try to develop
guidelines for developing usable and accessible
egovernment services [
Web Consortium (W3C) [
The Web is still the primary platform for delivering
egovernment services but other platforms such as mobile
networks and interactive TV (iTV) are quickly emerging as
suitable alternatives for delivering e-government services.
The huge penetration of mobile technology (even in
developing countries) has motivated many public
organizations to make e-government services through
mobile devices. Nowadays, there are about 3.3 billion
mobile users around the world, and a growing user base,
the prospects and possibilities in using the mobile phones
as a two-way service delivery platform are incredible. So
that the current demand for mobile applications to support
e-government initiatives is huge. Mobile phones are sought
to foster an innovative method for citizens to interact with
Government [
interactive element comes from the channels having a means whereby the user can send their own signals back to the broadcaster. This allows users to request different pieces of information, still images or video clips, within a browser environment similar to but less sophisticated than a web browser. TV, after the radio, is one of the most popular and diffused communication channels even in developing country and iTV are expected to replace traditional TV systems quite soon. A typical example of iTV usage in the e-government domain is the system VOICE3 which is employed in India to disseminate information about government activities and to enable online services (Figure 1).
Whilst the technology of iTV is recent the preliminary
results look very encouraging [
Most of currently available applications are deployed in a single platform but one of the most remarkable trends is the development of multi-channel services. A typical example of such initiatives is ‘Looking Local4’ (see Figure 2), a 3 Versatile Online Information for Citizen Empowerment: http://www.ourvmc.org/
versatile application in UK which is accessible at major UK interactive TV platforms (Sky and Virgin), from mobile phones and on some kiosks.
Indeed, many governmental reports strongly recommend
that e-government services must be deployed in many
different platforms in order to provide better coverage of
services and reach users with special needs [
Constructing and maintaining versions of single applications across multiple devices;
Checking consistency between versions for guaranteeing a seamless interaction across multiple devices;
Building into these versions the ability to dynamically respond to changes in the environment such as network connectivity, user’s location, etc.
The availability of several communication channels does not mean that applications will convey the same information and services across different platforms. On one hand, technical constraint (such screen size) can prevent the display of large amounts of information. On the other hand some applications can convey information and services through the communication channel that best suits user needs. For example, support online fill-in forms via Web and notify users of approaching deadline for complete procedures via SMS.
In order illustrate how the difficulties and constraints for delivering services in different communication channel, we present in this section a case study issued by the Regional French Administration Midi-Pyrenées (RMP), one of the partners in the MyCitizSpace consortium. Due to some private issues, some internal aspects are voluntary removed. We introduce all actors involved and their interactions along the process which is enough for our purpose. Our focus is on end-users’ (i.e. citizens’) requirements for adapting the UI according to different contexts of use.
Vocational high schools offer hands-on training to students and prepare them for careers in fields such as information technology, marketing, business, engineering and the medical professions. However, to attend some technical programs such as Plumbing, Electricity or Cooking, students should bring their own equipment to classes (e.g. purchase of knives, aprons and suits for inn students). BRPE (French acronym for “Regional Scholarship for First Equipment”) is a program of RMP which provides students with a scholarship for buying such equipments.
A student can only apply to this scholarship once whilst attending a specific technical program in a vocational high school. However, a second application is illegible if students change to a different technical program. High school’s principals are in charge of advertising students about the calendar and procedures and help them to prepare applications. BRPE applicants get forms from high school principals. For students under the age of majority, their parents or legal tutor are the ones allowed to firm the form. The forms and required documents (e.g. bank account statement) are given back to high school principals who are in charge of controlling the completeness of forms and sending the complete ones to RMP. On receipt, RMP agents treat BRPE applications. If the application is accepted by RMP, the accounts department (a state institution distinct from RMP) pays the BRPE scholarship through bank transfer to the bank account of the student (or his parents).
The general procedure required for implementing a BRPE
application can be summarized by Figure 3. Like many
other governmental programs, BRPE is a complex program
that integrates actors with diverse juridical status such as
citizens (i.e. students/parents), units of the regional
governmental (i.e. RMP), state governmental (i.e. accounts
department), and educational units (i.e. high schools) [
Government
Public Institution
The most important task for users is to ‘Apply for scholarship’. Users are requested to perform a set of subtasks to accomplish an application as shown by Figure 4. Notice that tasks can be performed either online or by other means, e.g. ‘provide paper-based certificates’ (B2).
Apply for BRPE
A: Request form B: Prepare application
B1: Fill in form C3: Monitor progress
B2: Provide paper-based certificates (bank account and scholarship)
Much of the success or failure of Information Technologies
implementation programs such as BRPE relies on the
adoption rate of the applications by the end-users.
However, it is clear that some actors involved might have
conflicting requirements. For example, citizens would like
to have a close contact with stakeholders which might
delay the treatment of requests. Table 1 presents some
requirements for the three main actors of BRPE. Some
requirements such as “ensure eligibility of applications”
can be a common motivation to both stakeholders and
citizens.
Due to space constraints we focus hereafter only on a
particular category of users, i.e. citizens. Once citizens
agreed on the advantages of applying to a BRPE, we can
start investigating how to better provide access to this
service and what would motivate them to move from paper
based applications to procedures based on new information
technologies. Inside the community of users we can
identify three main user groups: parents (or legal tutors),
students under the majority age and young adults. In order
to understand the diversity of users and capture their needs,
we have created user archetypes using the “Persona”
technique [
First name Age Nationality Family status Education Information Technology skills Motivation for using new information technologies Professional projects First name Age Nationality Family status Education Information Technology skills Motivation for using new information technologies Professional projects
Rémi, the nature boy 16 years old French Single, living with his parents in a farmer.
Repeating first year at the vocational high school Saint Paul on Veterinary Scholar Program after failing a first year in a traditional high school.
He prefers to surf the Web at school because of the low Internet bandwidth in the rural area where he lives. He gave up with cell phones because of the poor mobile network in the farmer.
He does not have any specific motivation but he knows how to use computer to check his assignments at the electronic kiosk available at the school.
To finish high school and go back to the farm to work with his father.
Sarah, the blogger girl 17 years old Lebanese Single, living with his uncle (30 years old) which is his legal tutor in France. Her parents still live in Lebam.
Second year of cooking program in the vocational high school George Sands.
She has created her own web site and she maintains a regular blog.
She makes good use of IT for communicating (e.g. email, skype) her parents and friends staying in Lebam. Since she got an iPhone from her birthday, she is using it for surfing on the Web and read emails.
She plans to open her own restaurant.
The description of the BRPE application does not imply any particular communication channel. However, we must ensure that implementations of BRPE will fulfill specific users’ requirements. Hereafter we present some scenarios that illustrate how the application BRPE could evolve over the platforms Web and mobile (i.e. iPhone) and according to the users profiling described above.
Basic scenario: Rémi is informed about that BRPE system is now receiving new applications. He goes to the school library that is equipped with computers and Internet access. He launches the web application e-BRPE and opens a session. Once registered, he fills in his personal data and selects a scholar program. The next part of the form has to be filled in by his parents as he is under the age of majority. Rémi saves his session. Once back home he can finish the procedure. The system indicates that his application has been submitted to the high school principal. Rémi then provides the principal with specific paper-based certificates. One week later, Rémi is interested to know the state of his application. He goes to the kiosk in his high school where e-BRPE is available. The system indicates that his application is complete and that it will be sent to the RMP. One month later, Rémi receives a letter telling him that his request will be funded. Figure 5 shows the UI for this scenario. The UI remains classic in that it is formbased and centralized in a unique desktop. There is neither adaptation to the user nor to the environment: adaptation is limited to the screen size. It is performed when the user launches the application. The state recovery is the user’s session.
Y Monitor progress
Monitor progress
Multi-platform scenario: refers to applications that provide is available over many different platforms. In our example, we might consider an e-government service that is available over the Web but can also be accessed via a cell phone. This scenario illustrates adaptation to the platform with effects on distribution and interaction styles. Figure 6 presents an adapted version of the application to be displayed on iPhone. Notice that the form fill is presented in several screens (i.e. 2.a, 2.b, 2.c). On one hand, the limited number of form fields per screen reduces the need of scrolling whilst keeping the text legible. On the other hand, the system can record the information filled across the pages so that Sarah does not have to start from the beginning if he is interrupted by a phone call. In addition, a vocal service is offered with phone platforms. The e-BRPE service is also available over the Web, as presented in the basic scenario (Figure 5).
X Request
Z
Monitor progress Receipt
Advanced scenario: in this scenario, the application was conceived to support continuous interaction across more than one interaction technique (e.g. command-line in the web-based version and speech recognition on the cell phone version). The context of use should take into account the changes on user tasks accordingly to the platform. The adaption of the user interface might take into account some unplanned tasks that occur accordingly to, for example, environmental conditions. In this scenario, users can not only decide which platform to use to access the service (the Web browser or a cell phone) but also to interrupt a task on a platform (for example fill in an application form over the Web) and resume it in another one (for example, monitor progress of applications on a cell phone). For example, the student is informed about the availability of the BRPE at the school and on his way back home he uses his iPhone to apply for a scholarship (Figure 7.1). He starts filling the forms (Figure 7.2.a) but as his battery was too low, he could not fill in all the forms fields. Arriving at home, He decides to resume the BRPE using the Web version because his computer desktop provides her with a larger screen (Figure 7.3.b).
Y Figure 8 Continuous interaction with BRPE across devices. [ Monitor progress Z.b
Monitor progress [ Monitor progress
Z
These scenarios could evolve to integrate even more
advanced interaction techniques, such as the user interface
migration from devices. User interface migration refers to
smart applications that can migrate via the network from a
platform to another [
In this paper we have presented a case study describing user needs and technical constraints related to the development of multi-target user interfaces for the egovernment domain. As we shall see, deploying services on multiple communication channels is not just a matter of technological platform. On one hand it requires a deeper understanding of user needs to propose solutions that fulfill their needs and thus has a better chance to get adopted by the community. On the other hand, there are many platforms available and the best user interface depends on the adaptation of services accordingly to platforms constraints. Currently there is no single answer to the questions such as: ‘Which is the best the user interface?’ or ‘Which is the best communication channel for deploying egovernment services?’ So that we need a multidimensional space for supporting decision-making. End-user requirements and user interface are useful criteria for grounding decisions but they certainly should be considered in a larger picture than presented here. However, user interface is a key aspect that it worth to be studied on its own dimension before be aligned with business processes constraints, political/social wills, and so on etc.
Faced to the complexity of such as tasks, it seems clear that deciders need some help to find the most cost-effective solutions to delivering services. In the present work, we have grounded our research on a deep review on end-users’ requirements which are formalized by the means of Persona archetypes. One of the main advantages of Persona is that archetypes can be easily understood by all people involved in the development of e-government services, from administrative stakeholders, IT experts, decisionmakers and even citizens. Based on such as description we can assess credible scenarios that worth the investment on new development.
The case study for the development of the BRPE has lead to successful implementations on two platforms (i.e. mobile and Web). The scenarios presented in the present case study allow us to visualize the continuous interaction across different platforms. However, it is clear that the development of such as multi-target applications is not seamless and requests an intricate composition of services hosted and distributed among the platform used by the user (e.g. mobile) and on the server. As we shall see, such as distribution is also subject to administrative constraints (in our case study the need of paper-based certificates) that might prevent any kind of electronic process and thus some task should be composed with more traditional administrative procedures.
Our goal is not propose a definite solution to the problem but rather to exemplify some challenges one is faced to whilst trying to conceive multi-target user interface for egovernment services.
This work is part of large national project which aims is to provide a framework for developing the next generation of user interfaces for application in the e-government domain. Based on this experience we have started some generalizations towards a plasticity space for multi-target user interface for the e-government domain. Future work will include refinements on criteria for helping administrations to better chose communication channels for e-government services. Additional work will be done to explore the user interface adaptation on promising communication channels (not exploited here) such as the interactive TV.
This work is supported by the project MyCitizSpace (ANR 2007).