A WE-CENTRIC SERVICE FOR MOBILE POLICE OFFICERS
TO SUPPORT COMMUNICATION IN AD-HOC GROUPS
Ronald van Eijk
Telematica Instituut, P.O. Box 589, 7500 AN, Enschede, The Netherlands
Nicole de Koning, Marc Steen
TNO Information & Communication Technology, PO Box 5050, 2600 GB, Delft, The Netherlands
Erik Reitsma
Ericsson, Research and Development, P.O. Box 8, 5120 AA, Rijen, The Netherlands
Keywords: Mobile Social Software, Group Communication, User-Centred Design, Human-Computer Interaction,
Police.
Abstract: We-centric services are meant to stimulate and facilitate people to communicate and cooperate with others
in dynamic or ad-hoc groups. Typically, a we-centric service provides hints and reasons to contact others,
and, because these other people receive similar hints and reasons, stimulates and facilitates people to
experience “we”. The paper describes the development and evaluation of one we-centric service prototype
for police officers. We found that key-issues related to developing we-centric services are (1) finding the
proper context elements and information sources to take into account when searching for relevant others, (2)
presenting the people found and the context of those people in an appropriate way, i.e. with clear
explanations and information on their current availability and (3) supporting reciprocal relationships.
1 INTRODUCTION
People are social beings. We belong to different
groups, such as family, friends, colleagues, clubs or
interest groups. We want to – or have to – combine
or balance roles and tasks in order to maintain
memberships to these different groups. E.g. people
combine private and work roles, or balance different
tasks with different people within one job.
Furthermore, many groups are dynamic or formed
spontaneously, i.e. its members may not be known
beforehand and may move in and out all the time,
based on changing context. This has led to a domain
of (mobile) social software, or “MoSoSo”, software
on smart mobile devices that facilitates social
encounters (Kjeldskov and Paay, 2005), (Kowitz et
al., 2005), (Rheingold, 2003) and supporting
architectures designed to help people communicate
with small groups of people such as close friends,
colleagues or relatives (van Eijk et al., 2006), (Nars,
2004).
Currently, Instant Messaging applications such
as MSN Messenger are available on mobile devices,
e.g. Smartphones. Thus, these types of mobile
applications are in theory capable of supporting
dynamic or spontaneous groups. However, they
support one relatively stable group of people that is
manually created and managed by one user. Sessions
are also manually initiated by one user, based on that
specific user’s interpretation of availability of others.
Thus, this type of applications ignore the fact that
people do not know beforehand with whom they
could or should communicate.
Secondly, in this type of instant messaging
applications, sharing of context between (mobile)
users is limited to presenting availability, clues
about mood or activity or recent pictures to the
other. Again, it is one user that controls how and
when she shares context with others. However,
following the definition given by Dey (2001) we
61
van Eijk R., de Koning N., Steen M. and Reitsma E. (2007).
A WE-CENTRIC SERVICE FOR MOBILE POLICE OFFICERS TO SUPPORT COMMUNICATION IN AD-HOC GROUPS.
In Proceedings of the Ninth International Conference on Enterprise Information Systems - HCI, pages 61-67
DOI: 10.5220/0002353500610067
Copyright
c
 SciTePress

should consider that context is any information that
can be used to characterize the situation of an entity,
e.g. an individual or a group. Sharing of all kinds of
context information with others is crucial in the
design of mobile group applications since it helps
people to find efficient or effective ways to
communicate (van Eijk et al., 2006), (Erickson and
Kellogg, 2000), (de Poot et al., 2004), (Schmidt et
al., 2004).
The limitations of the applications given above
follow from the fact that they are designed according
to the I-centric paradigm. I-centric services are
associated with an individual who controls the
environment, including other people (Arbanowski,
2004). It strongly emphasises the “user in control”
concept and it ignores the fact that relations between
people are potentially reciprocal. Therefore, we
propose to use a we-centric paradigm to design
mobile social software, where this reciprocity is an
essential property as we will illustrate here.
2 WE-CENTRIC SERVICES
We-Centric services are the counterpart of I-centric
services. We envision we-centric services that help
people to communicate and cooperate with others in
different, dynamic or spontaneous groups, and to
combine and balance tasks and roles effectively,
efficiently and pleasantly (see Figure 1). We-centric
services are by definition context aware. Context is
used for determining which users are part of a social
context (the “we”) and context can then be shared
between those users.
Figure 1: We-Centric services help people to communicate
and cooperate in different, dynamic or ad-hoc groups.
We propose that a we-centric service
automatically composes and provides a dynamic list
of people that may be “useful” to you – “useful” in
the sense that these people are possibly relevant and
available. Additionally, it may hint that you may
want to contact them.
The three following research questions are
relevant.
How can a we-centric service define the set of
people (“we”) that is indeed relevant in the current
context?
We assume that one must find, for a certain
application domain, some proper and useful context
elements or information sources for this goal.
Typical examples are availability, location and
working rosters of people. The question then
remains what type of context elements are needed
for a specific domain or scenario, how to find and
select them together with end-users and if there are
many, how to convey, aggregate, combine and/or
interpret them.
How to represent these people in a way that end-
users get a shared experience of “we” and indeed
use the information to start communicating and
collaborating?
The supposed added value of we-centric services is
that they support people to form dynamic or
spontaneous groups and communicate and cooperate
with people they would otherwise not or less easily
communicate or cooperate with. Furthermore, the
service must enable the end-user to combine and
balance group memberships and tasks that may
interfere or even conflict.
How to develop a we-centric service together with
end-users?
We-centric services are about people and they are
typically domain-specific and they must take into
account working practice and social relations
between people.
This paper describes how user requirements
were captured, the development of one we-centric
service together with end-users, and an evaluation of
the added value of this service. The intended
contribution of this paper is to position we-centric
services as a new kind of (mobile) social software
for (semi)professional users, and to explain the
development of one application, including a
software algorithm and user interface, together with
end-users.
ICEIS 2007 - International Conference on Enterprise Information Systems
62

3 FIELDWORK WITH POLICE
END-USERS
In order to develop the we-centric service we
interacted throughout the project with the intended
end-users: Police Officers who work in the field.
Introducing applications into the work of mobile
police officers is especially challenging and when
developing such services it is essential to follow a
user-centred design. If not, things like the user
interface, e.g. the way information is represented on
the screen, may end-up with serious design flaws,
making the result unacceptable and unworkable in
practice (Marcus and Gasperini, 2006).
In order to learn about police work, seven project
team members spent a day with police officers – a
method known as “rapid ethnography”. We learned
that two types of police officers work in the field.
Emergency Police Officers respond to incidents and
work in larger areas. Community Police Officers are
assigned to one specific neighbourhood and work
more according to tasks and plans. We observed that
the work of Emergency Police Officers is driven by
incidents: they often do not know what will happen
next and improvise a lot. They cooperate with other
police officers and with external network partners:
e.g. people from the municipality, shop owners or
school directors. Police officers often need implicit
knowledge of others: knowledge in the heads of
other people, and usually not available in databases,
e.g. a person’s personality, a person’s social
relations, or the location of certain keys. When
Emergency Police Officer Nick goes to an
emergency it would be good if he knew what
Community Police Officer William, who was there
last week, knows: namely that when this man X
becomes angry, you should rather ask his neighbour
Y, and not his neighbour Z, to calm him down.
A workshop was organized with the police
officers observed earlier, in order to validate our
observations and to present them our first ideas for a
we-centric service. Based on the results of that
workshop we chose to focus upon improving
communication and cooperation between
Emergency and Community Police Officers. This
focus was also justified by the author of a large
ethnographic study of police work (Stol, 2004), who
saw that the two types of police officers cooperate
relatively little with each other. He suggests that the
overall quality of police work would improve when
other officers could use the implicit knowledge of
Community Police Officers who work for many
years in one area and have an intimate knowledge
about this area.
Based on our observations and the workshop
results sketches were made for a we-centric service,
that we named “WijkWijzer” (in Dutch). This name
is a wordplay, where “Wijk” means
“Neighbourhood” and “Wijzer” can mean both
“Pointer” as well as “Wiser”. The name thus refers
to its function: it points you to other people who
may help you (or you may help them) by exchanging
implicit knowledge, making both parties wiser.
In order to evaluate these ideas several
workshops were organized with both Community
and Emergency Police Officers. A method similar to
Place Storming (Andersen and McGonical, 2004)
was applied to assess the added value in enacted
work situations. The police officers were asked to
play three situations, first without and then with the
WijkWijzer.
In the workshops we first learned that the users
find it important to know why a person is relevant
when it shows up on the screen. This is a bit similar
to the users’ opinion found by Iachello et al. (2005).
They found that the users want to know why
somebody is indicating an interest in their location.
Then we heard that it is likely that Emergency Police
Officers – who must react quickly to urgent reports
or emergencies – will not always contact
Community Police Officers beforehand to obtain
information. It seems more likely that Community
Police Officers proactively offer their knowledge to
Emergency Police Officers. We also learned that
Emergency Police Officers have knowledge that
may be relevant for Community Police Officers,
namely knowledge about what happens during the
evenings and nights, and over larger areas. So the
WijkWijzer should enable reciprocal
communication: either of the two people involved
(“we”) can start the communication.
4 WE-CENTRIC APPLICATION
FOR POLICE OFFICERS
Based on all the interactions with police officers, the
ambition was formulated to develop and evaluate the
WijkWijzer: a mobile application to support police
officers to identify other officers with whom they
can communicate in order to exchange implicit
knowledge about the incidents they are currently
working on. This idea was strongly based on our
obtained knowledge on police processes and our
ambition to improve spontaneous communication.
A WE-CENTRIC SERVICE FOR MOBILE POLICE OFFICERS TO SUPPORT COMMUNICATION IN AD-HOC
GROUPS
63

4.1 Application Functionalities
A prototype application was made consisting of a
client for a PDA and a server. The server hosts an
algorithm that finds relevant officers for a specific
incident (see next subsection). In short, the prototype
does the following.
1. When an incident is reported, a report is
generated and assigned to one police officer (A);
2. The police’s database is searched for police
officers that may have relevant implicit knowledge
about this incident, and for each police officer
found, a “utility” is calculated based on relevancy
and availability – this function is explained in the
next section;
3. The report is sent to the police officer who was
assigned to that incident (A), with a list of
supposedly “useful” police officers (B), their contact
details, availability, a reason to contact them, and an
indication of their “utility”;
4. The name, contact details and availability of the
police officer whom was assigned to that incident
(A) is sent to all the supposedly “useful” officers
(B), with the reason why they may be contacted, and
an indication of their own “utility”.
Figure 2: User interface of WijkWijzer.
A user interface was developed for a mobile device
that police officers are currently using (see Figure
2). When an incident is assigned to a police officer
(A), he receives a message that there are other police
officers (B) that may be relevant and available for
him. The user can easily see reasons and utility
scores and contact details. Additionally, B receives a
very similar notification so B can pro-actively
contact A.
4.2 Algorithm for Finding People
Our goal here was to define an algorithm, which
identifies one or more relevant police officers that
may be relevant for a specific incident. Based on an
analysis of current working processes and
information sources used by police officers, we
designed a data model that links specific incidents to
relevant police officers, via several different paths.
The following information from the police
processes and database is used in this data model
and algorithm:
• Every “incident” is reported as a
“mutation”, and each “mutation” is
authored by a specific police “officer” and
is associated with a (geographical)
“location”;
• Police officers sometimes make additional
notes to pay attention to a certain location
or person: “appointment on location” or
“AoL”, or “appointment on person” or
“AoP”;
• Emergency Police Officers work according
to “rosters” and are assigned to certain
“neighbourhoods” via these rosters.
“Locations” can be mapped into these
neighbourhoods;
• For the purpose of our research and
prototyping we assume that the addresses
of “suspects” (people who appear as
“AoP”) are stored in an address book.
We identified five meaningful paths through this
data model that go from a specific incident to a
specific police officer:
• Mut: The incident is related to an earlier,
previous mutation, which was authored by
a specific police officer
• AoL: The location associated with the
incident appears as an “appointment on
location” (AoL), which was authored by a
specific police officer
• AoP: The name of a person or suspect in
the mutation appears as an “appointment on
person” (AoP), authored by a specific
police officer.
• AoP: The location associated with the
incident is linked via an address book to the
name of a suspect who appears within an
“appointment on person” (AoP), authored
by a specific police officer.
• Area: The location associated with the
incident lies within the neighbourhood
Incident (“Vandalism”,
Piekstraat 34).
Relevant police
officers, with “utility”.
Options for instant
communication.
Reason why officer is
relevant (“Area”).
ICEIS 2007 - International Conference on Enterprise Information Systems
64

where, according to the roster, a specific
police officer is currently working.
These five paths are the basis for an algorithm that
identifies one or more police officers that are
relevant for a specific incident. For paths 1, 2 and 3,
the “age” of the mutation, AoL or AoP are also
important: older entries are likely to be less relevant
than newer entries.
Since police officers often work in emergencies
(especially Emergency Police Officers) it is
important that colleagues are not only relevant but
also available for communication or cooperation.
Preferably the WijkWijzer should enable instant
communication. The availability of an officer
depends on:
• Service: The number of service hours left
for that day of a specific police officer –
which can be found in the roster;
• Status: The current availability which the
end-users sets herself on her terminal: off-
line, busy, available.
From all variables, we derived an equation that
calculates the “utility” of a police officer as a
function of her relevance and her availability:
Utility [between 0 and 1] =
f (AoL, AoP, Mut, Area) + f (Service, Status),
where AoL, AoP, Mut, Area, Service, Status are
between 0 and 1.
Using this equation, the algorithm can rank officers
by calculating their respective ‘utilities”.
5 SMALL-SCALE TEST
All server functionality was implemented on a web
server that was coupled to a database containing all
fields relevant for the algorithm. The client was
originally developed for a consumer PDA with
communication capabilities (QTEK 9090), but for
the test we decided to use the same client on a robust
heavy-duty PDA (Panasonic CF-P1). The
WijkWijzer application was tested in a small-scale
test in which five police officers used the prototype
for a few days on the street during their work. In this
test one observer sat in the emergency room and fed
the WijkWijzer server with information on rosters,
appointments made in the past (AoL and AoP),
mapping of locations to neighbourhoods and officers
assigned to that areas. Then, during the test, the
algorithm was additionally fed with information on
real incidents. So, for each incident, all relevant
utilities were calculated on-the-fly and dependent on
the results, messages were sent to the proper police
officers in the field. Three other observers joined
officers in their car. We observed experience (how
did the end-users react to the information presented
on their device?), added-value (how useful is the
application for their work?), functionality (does the
algorithm produce the proper results?) and usability
(was the information presented in a usable way?).
The results were as following. Concerning
experience we observed that the police officers
enjoyed taking part of the test and were very curious
about what was appearing on their devices. Due to
some technical problems, there was a delay or loss
of some incidents, which lead to some distrust of the
system. Concerning added-value we observed that
the application was not useful in routine cases like
car accidents. It was quit useful in those cases were
Emergency Police Officers had to operate in a
neighbourhood or area that was unfamiliar to them
or that was not their home area. In those cases
Emergency Police Officers for example do not know
who are the assigned Community Police Officers.
Especially in those cases people may be suggested
that are unknown or unfamiliar to them and they
normally would not communicate with.
The application was also useful in cases were
social issues or cases with longer histories are
relevant, like family relation issues. Our assumption
that our application has to be reciprocal was
confirmed; we observed cases were Emergency
Police Officers had knowledge for community
Police Offers and vice versa. Concerning the
functionality, i.e. the algorithm, our observations
seemed to indicate that the algorithm delivers the
right names. Showing the name of the correct
Community Police Officer that is assigned to a
location was found the most useful. What was
missing were names of people that have been at
some location, which are not necessarily the
Community Police Officers of that area. Location
seemed to be another relevant context parameter,
since it strongly influences the decision to
communicate or to travel to and co-assist the other.
6 CONCLUSIONS
Because the evaluation of our application was on a
small-scale we need to be careful with our
conclusions. Furthermore, we realise that
conclusions on added-value of our ideas are only
valid in this domain. Yet, based on our experience in
A WE-CENTRIC SERVICE FOR MOBILE POLICE OFFICERS TO SUPPORT COMMUNICATION IN AD-HOC
GROUPS
65

developing and testing this we-centric service for
police we can draw some preliminary conclusions
and give some preliminary answers to our research
questions.
With respect to the question of how to define a
set of relevant people we learned that developers of
we-centric services should find out what information
people want to have, what knowledge they share in
the field and what their incentive is to communicate.
It is also important to study which context elements
are relevant, for example whether it is relevant to
use positioning technology or not.
All information sources used to find people
relevant for the current context must have at least
two characteristics. First, they must link to the
current situation, in our case, everything was
connected to the current incident. Second, they must
have a link to specific people that can help and be
contacted, for example, in our case, a specific person
edited every source of information used. Note that
we always assume that the person that can be
contacted knows more than what is available in the
information system, for example he or she has
implicit knowledge about a case, a person or a
location. The situational context elements chosen
here were about the availability of the officers and
the location of current as well as past incidents.
Additionally, we found that a we-centric service
may have added value, when unknown people are
suggested, rather than people one would contact
anyway. One must realize that suggesting unknown
people to each other opens a can of trust and privacy
issues (van Eijk and Steen, 2005).
With respect to the question on how to represent
the set of people and induce a “we” experience and
stimulate communication, we found in general that,
since we-centric is people centric, providing
information alone is not sufficient. First, end-users
would want to know why a person is relevant. This
means that a we-centric service should provide
reasons why the system suggests that people are
relevant in the current context. Second, suggestions
are reciprocal: when A receives a suggestion to
contact B, B should always receive a notification so
B can pro-actively contact A. Third, any suggestion
must include the name of a human person. We even
decided to use pictures to improve the sense that
information is coupled to a person. Finally, in order
to stimulate communication it is important to show
people’s availability and the ways one can contact
the other.
From developing a we-centric service together
with end-users, in our case police officers, we
learned the following. It is important to find out the
communication patterns, working practices, culture
and social relations between all types of end-users.
Developers should be aware that their solutions may
change the organization structure, for example
WijkWijzer may change the role of the emergency
room. In general one can say that we-centric
applications are more suited to ad-hoc collaboration
scenarios, rather than to scenarios where central
steering is practice.
The authors are aware that the test was small-
scale and a longer evaluation of the application with
end-users is necessary to draw more solid
conclusions. One might argue that the motivation
triggered by the gadget factor affected the users'
views and their willingness to participate. On the
other hand, we found that police officers are very
critical with respect to the introduction of new
devices that they have to carry around and operate.
This means that as soon as they find it useless or
hampering their work they will quickly stop using it,
no matter what gadget it may be. Their willingness
to operate is thus probably more due to the fact that
they appreciate attention from a research group that
is not related to their management.
It was not our goal to develop, introduce and
enrol a working system. Before this application can
be enrolled and scaled up, more study is needed on
the type of situations where the application may
provide useful tips, more study on the time gain
versus cost, providing a better user interface, more
stability, better security and last but not least, more
support from national police management.
Summarising we found that key-issues related to
developing we-centric services are (1) finding the
proper context elements and information sources to
take into account when searching for relevant others,
(2) presenting the people found and the context of
those people in an appropriate way, i.e. with clear
explanations and information on their current
availability and (3) supporting reciprocal
relationships.
ACKNOWLEDGEMENTS
This paper was written within the Freeband User
Experience (FRUX) project, which is part of the
Freeband Communication (http://www.freeband.nl)
research program. FRUX is a joint effort of
Ericsson, ISC (Dutch Police ICT service
organization), Telematica Instituut, TNO
Information & Communication Technology, Delft
University of Technology, VU University Medical
ICEIS 2007 - International Conference on Enterprise Information Systems
66

Center, VU University Business Informatics, Waag
Society, and Web Integration.
REFERENCES
Andersen, K. and McGonigal, J., 2004. Place Storming.
Performing New technologies in Context.
NordiCHI’04, Tampere, Finland.
Arbanowsky et.al., 2005. I-centric communications. IEEE
Communications Magazine, Sept 2004. pp.63-69.
Dey, A.K. Adowd, G.D., 2001. “Towards a better
Understanding of Context and Context-Awareness”,
Personal and Ubiquitous Computing Journal, Volume
5 (1), 2001, pp. 4-7.
Eijk, Ronald van & Marc Steen, 2005. Location-
Awareness and Privacy in We-Centric Service.
Proceedings Workshop on Location Awareness and
Community held in conjunction with ECSCW 2005,
September 18-24, 2005, Paris, France.
Eijk, Ronald van, Olivier Coutand & Silke Holtmanns,
2006. Sharing of Preferences and Context in Groups of
Mobile Users. CHI 2006 Workshop on Mobile Social
Software, Montreal, Canada.
Erickson, T. and Kellogg, W.A., 2000. ‘Social
Translucence: An approach to designing systems that
support social processes’, ACM Transactions on
Computer-Human Interaction, Vol. 7, No. 1, pp. 59-
83.
Iachello, G., Smith, I. and Abowd, G.D., 2005.
Developing Privacy Guidelines for Social Location
Disclosure Applications and Services. Symposium on
Usable Privacy and Security (SOUPS) 2005, July 6-8,
2005, Pittsburgh, PA, USA.
Kjeldskov J. and Paay J., 2005. Just-for-Us: A Context-
Aware Mobile Information System Facilitating
Sociality. In Proc Mobile HCI 2005, Salzburg,
Austria, ACM, 23-30.
Kowitz, Braden; Alex Darrow; Hari Khalsa and John
Zimmerman, 2005. Gather: Design for Impromptu
activity support utilizing social networks. In Proc
Designing Pleasurable Products and Interfaces (Oct
24-27, 2005, Eindhoven, The Netherlands) 115-128.
Marcus, A. and Gasperini, J., 2006. A Case Study of Non-
User-Centered Design for a Police Emergency-
Response System. ACM Interactions, Volume XIII.5,
September-October 2006.
Nars, E., 2004. A group communication infrastructure.
NordiCHI’04. Tampere, Finland.
Poot, Henk de; Joke Kort & David Langley, 2004.
Enhancing presence and context awareness in
collaborative settings. In Proc EChallenges 2004 (Oct
27-29, 2004, Vienna, Austria).
Rheingold, Howard, 2003. Smart Mobs: The next social
revolution. The Perseus Books Group, 2003.
Schmidt, A., T. Gross and M. Billinghurst, 2004.
‘Introduction to Special Issue on Context-Aware
Computing in CSCW’, Computer Supported
Cooperative Work, vol. 13, pp. 221-222, 2004.
Stol, W.Ph. et al., 2004. 'Politiestraatwerk in Nederland',
Politiewetenschap nr. 14, P & W, Apeldoorn/Zeist:
Kerkebosch (in Dutch).
A WE-CENTRIC SERVICE FOR MOBILE POLICE OFFICERS TO SUPPORT COMMUNICATION IN AD-HOC
GROUPS
67