Project Report By David Farmer, Jennifer Chequer & Richard Whitehouse

User Interface Design & Modeling (UIDM - CM5363-3)

INTRODUCTION

Brief

The brief that has been set is to produce a prototype for the design of an interface for use on a collaborative editing system designed for the production of technical documents.

The project as a whole is split into three distinctive areas; a research report summarizing the use of collaborative editing software, a summary of discussions between the group members revolving around design space analysis presented using ‘Question Option Criteria’ (QOC) diagrams and the artifact, which will consist of various sample screens outlining the interfaces appearance and functionality.

LITERATURE REVIEW

Introduction

Ever since the Internet was first conceived in the early 1960’s, it has had the concept of enabling teamwork. In the 21st century, there has been such a rapid growth in the Internets popularity, and as PC’s have become more powerful and networks have grown from local area networks (LAN) to the World Wide Web, the concept of communication and working as a team has grown and taken on new methods with new potential (Ehrlich, 1999). New software has been developed, called groupware. Web based tools are being developed, that can aid human to human interaction, via the computer, to facilitate working as a team. Chen (2001) defines groupware as: “Computer-based systems that support groups of people engaged in a common task (or goal) and that provides an interface to a shared environment.” Groupware is software which actually allows individuals to simultaneously work on the same document; this function is called Collaborative Editing (CE).

CE has been successfully tried and tested in LAN applications, but the complexity of wider group usage has been less successful due to techniques that could not cope with unreliable connections, etc in a real time environment. Now that groupware has broken away from single user software and that hardware and systems have become more robust and cheaper, multi-user software is becoming more reliable and widely accepted. The revenues are not as great so growth is not as fast as single user applications. However, co-authors are benefiting from safer cache, recovery and better communication devices, which is leading to an advancement in CE applications. These advances are running concurrently with Computer Supported Co-operative Work (CSCW) leading to a positive future for the use of CE in multi-user software (Ehrlich, 1999).

Collaborative Editing Systems (CES)

Editing in this context is meant in a broad way to describe group participation to produce rather than just change a document. There are all ranges of document types, which can be edited in collaboration, not just text documents. Collaboration in this context can be described as a method of sharing a computing environment to achieve a unified goal (Apple Computer Inc, 1996).

CES can be used to help a group over a range of degree of complexity, for instance it can be used to simply aid a group or it can be used to aid groups to work together to produce an new product by helping them to share ideas, questions, files, and knowledge. CES can help groups to be more productive, and even more creative. According to Ehrlich (1999), groupware is about group work. It is technology designed to facilitate the work of groups. It is about developing technologies that support the way people communicate and collaborate to accomplish work goals. Groupware can be any type of software designed for groups and for communication. This technology may be used to communicate, co-operate, co-ordinate, solve problems, compete, or negotiate (Brinck, 1998).

While traditional technologies like the telephone have played a major role in group work in the past, the term is ordinarily used to refer to a specific class of technologies relying on modern computer networks, such as e-mail, newsgroups, videophones, or chat (Chen, 2001). One of the simplest definitions of groupware is that it is any computing technology that helps groups work better collaboratively over digital media (Khoshafian & Buckiewicz, 1995).

Collaborative editing systems are an important category of groupware, which support a group of users to edit the same document collaboratively over the computer network. There are several interesting document types that can be shared including text, image or graphics objects, multimedia data, hypertext, spreadsheets, 3D models and diagrams. From this it can be seen that CE software can range from simple to complex. For example it can range from work on a text document by a small number of people collectively producing a list, to a large group producing a sophisticated model using multimedia and code.

How People Collaborate

There are two ways of working together and interacting, first, synchronously, e.g. people working on the same thing at the same time, which in the computer environment means they will need tools to avoid clashes and to support collaborative editing. And second, asynchronously, e.g. people who, in the past, have worked on the same thing one is now working on, e.g. for recommendations or other relevant experiences (Chen, 2001). People may work simultaneously on the same document, simultaneously on different copies of the document, or at different times on the original or copied document (Apple Computer Inc, 1996).

The traditional way that authors collaborated was by the traditional methods of communication such as telephone, fax and surface mail. This was not true collaboration, only a commentary, because by the time the document had gone around the whole group and ‘edits’ made, it could not be effective for the ‘first’ author to incorporate them in a meaningful way. It was not possible for the group of authors to see edits at the same time and consequently it was not possible to act on them and produce an entire collaborative document (Brinck, 1998).

Since the development of electronic documents and e-mail it is now possible to work on the same document simultaneously in real time, the benefits are enormous, but the authors face a problem. It is not easy to go from the traditional way to the new way without some difficulties along the way, therefore the more like the old way of working the better. That’s why some initial CE tools failed because of the human aspect. Word processors may provide support by showing authorship and by allowing users to track changes and make changes to documents. Authors collaborating on a document may also be given tools to help plan and co-ordinate the authoring process, such as methods for locking parts of the document linking separately authored documents. Although synchronous support allows authors to see each other’s changes instantly (Chen, 2001). Prakash (1999) states that a wide variety of research areas contribute to collaborative editing including group awareness, concurrency control, social interaction, usability and human factors as well as areas such as distributed computing.

To succeed in the market place, there is a problem in implementing groupware, namely: people. For software to work there must be acceptability by the users of it. Usability issues have stressed the need to take the users into account when designing, developing and evaluating interactive software. Groupware usability issues go beyond single user ones, its evaluators need to know about group psychology and social sciences to know how people work together. They also need to know how organisations impose work practices on its workers, etc. Interactive software works better if it is easy to use and if the functions are well designed to take into consideration if it is similar with the work practices of its users. Features which take into consideration group behaviour and how it can lead to a lack of ownership or responsibility can be overcome by features that reinforce the goal and require a role of a team leader, controller or main collaborator to oversee the process of working together (Beaudouin-Lafon, 1999).

The Benefits

According to Chen (2001), groupware offers significant advantages over single-user systems. Normally group activities take up a large amount of time, for example, meetings, telephone calls, mail (electronic or not), and also informal encounters in corridors. This is the reason why Computer Supported Co-operative Work (CSCW) is a rapidly growing multi-disciplinary field (Beaudouin-Lafon, 1999). Some of the most common reasons people want to use groupware is to facilitate communication by making it faster, clearer and more persuasive. It allows consensus through shared comment and editing.

It also enables communication where it would not otherwise be possible, which cuts down on travel costs, leaving people not to worry about the time and location. It helps to bring experts together quickly so they can pool their knowledge and, with the right guidance, work effectively.

It offers efficient problem solving, and gains access to world-class experts, wherever they are located. It allows on-the-job management development. Groupware is especially useful for less structured work that requires high knowledge and skill input, for instance, sometimes shared experience and brainstorming can move a tricky problem forward more efficiently than individual thought. A groupware system improves communication, helps the structuring of thinking, stores and retains information as it advances, and acts as a meetings substitute (Skyrme, 1999).

The Problems and Design Issues

Khoshafian & Buckiewicz (1995) stated that the concept of groupware has appeared and evolved in a number of technologies with different degrees of success. This is because the concept has special problems over single user applications. Groupware applications can be familiar and include discussion databases, bulletin boards and electronic news groups where documents and their responses are often grouped together under a single user. However, the first major difference encountered by any user when moving from single-user to multi-user software is the notion of a shared space in which other people are working. The experience can be awkward until a group has developed an awareness of themselves and each other. Access and control of the shared space has to be worked before the full potential can be realised.

When people are working together, having access to synchronous editing capabilities, the end product can seem disjointed. Synchronisation and updating shared information in a way, which makes sense, can be a problem, as can caching and maintaining data integrity. It may be a problem to get a final draft document done in true collaboration because in some cases it may be better to do a final edit from beginning to end by just one appointed person to make it read coherent (Khoshafian & Buckiewicz, 1995).

Social interactions and group dynamics can be another problem for both the system designers and the members of the group. Apple Computer Inc. (1996) state that applications designed to allow collaborative editing must, take into account user identification, access privileges, passwords, security issues and networking issues, along with common software design concepts such as reliability, usefulness and user interface design, they must be safe (authentic), fault- tolerant and robust. People do not want to be slowed down or loose their data if another participant in the session uses a slow connection or experiences a crash.

Then according to Chen (2001) there are many design issues to consider, as there have been many expensive groupware failures because the unique social dynamics of group work has not been understood. As a collaborative editing session scales up from LAN to the Internet, group dynamics, trust and security become more important issues. Human factors present a unique set of problems and issues not addressed in traditional distributed systems and single-user interactive applications. For example, high responsiveness and timely input promotes mutual awareness of user activities. Collaborative Editing Systems not only need to maintain consistency across different sites but also need to take into account the original user intentions i.e. the context of operations. The wider the group the more complex the technical problems too, for example transformation, multi-versioning, optional locking, and group undo. (ACM Group, 2001).

The Present

Traditionally CS has been used in multi-user text file editors and graphics editors (e.g. whiteboard). Groupware is now becoming more accessible and easier to use by non-IT professionals (Karash, 1999). There are commercial efforts by Microsoft and Netscape to integrate groupware tools in their browsers, by IBM/Lotus to extend Lotus Notes to support synchronous collaboration, and by JavaSoft to provide a collaboration toolkit based on Java. Microsoft Word 97 now incorporates collaborative editing in the word processing program (Prakash, 1999). Groupware is now available on networked PCs, with Windows interfaces, through products such as First Class and Lotus Notes.

Chen (2001) states that the Collaborative Editing Systems can also bring new insights into the design of other distributed applications, e.g. Internet-based multi-player games, collaborative virtual environments, mobile computing, etc. In particular, group collaboration environments are likely to consist of not only Collaborative Editing Systems, but also other groupware oriented versions of applications such as Internet browsers, audio/video/text conferencing tools, data visualisation tools, etc. Traditional groupware systems like Lotus Notes were designed for corporate Intranets and other LANs to support collaborative work. They essentially combined the functionality of e-mail, messaging and conferencing, and document management systems. More recently, groupware applications like ‘Groove’ have been designed with similar functionality for the Internet.

The Future

Groupware and CSCW are still in their infancy compared with the more established development of single-user applications. CE has become accepted in text applications, but other document types such as image, multimedia, hypertext, hypermedia, spreadsheets, 3D models, and diagrams are emerging as the target for the future. Although groupware clearly offers some advantages over single-user systems in the way it can facilitate productivity, it has to overcome many technical and human difficulties that do not exist for the single user applications. The interest and revenue that can be made, compared to single user applications, is not so good and therefore development will have to be worked at and will take comparatively longer. This is why a lot of work is being done to make it more accepted as an influential tool which will be highly beneficial to group work output, eventually.

It can ‘add value’ to a document particularly by enhancing a single persons work effort, which may have gone as far as possible because of waning inspiration or it may bring originality to a thought process using collaborative methods. By using a wider pool of expertise it can advance the starting point of a document i.e. it will not be necessary to go over ‘old’ ground but rather to start from where others have ended.

It enables communication where it would not otherwise be possible and it can enable telecommuting, which will cut down on travel costs and save time in co-ordinating group work (Chen, 2001). Technological developments such as the World Wide Web seem to lead to more need for groupware applications where people are spread across the globe, across the country, or just across the street can use technology to co-ordinate their work and communicate with each other (Ehrlich, 1999).

Conclusion

Groupware has to have extra features. The direct connection between the user’s activity and the systems is broken, and with it, many of the assumptions on which user-interface design rest. For instance multiple actions must be observable in the interface and other peoples activity should be understood by other users. So, as in the previous cases, the needs of CSCW applications often force us to re-think the elements and functionality of the traditional user interface (Dourish, 1999).

Groupware is likely to continue to evolve in the future. Many of the basic concepts in the design, such working on a document concurrently, enabling collaboration awareness and journalising to facilitate an historical undo facility, have been explored. Although groupware still has a way to go until the point where any single groupware provides all the required features and gives a bug free, user friendly collaborative editing system. Nevertheless, according Prakash (1999), successful use has been reported from even prototype groupware, which indicates that it can become widely used. Once they are available as standard tools on common computing platforms and sufficiently robust for everyday use the benefits will be huge.

METHOD

Having researched into collaborative editing it is now possible to list requirements for the prototypes design. The group has decided that the features are split over five areas; standard document editing, user communication, document locking, preferences and accessibility & security.

Standard Document Editing

This area covers all of the editing tools that would be required to produce a technical document on a standalone computer. Although the features do not need to be as advanced as a modern word processor, such as Microsoft Word XP, as a group it is thought that users would need the following functionalities or abilities to be included on top of a basic text editor based program:

1. The ability to choose fonts, font size and font colour.
2. The ability to make text appear bold, italic or underlined.
3. The ability to include tables, and customize them to some level.
4. The ability to include images within the document.
5. The ability to edit and open imported or created individual items though the use of a library.
6. The ability to use conventional shortcut keys to complete frequent tasks.
7. The ability to allow the user to ‘hover’ the cursor over interface features and view textual cues.

User Communication

User communication is an important part of any collaborative editing system. Within the application there will be:

1. A chat feature to allow users to communicate textually in real-time.
2. The ability to use microphones and speakers to speak to one another in real-time.
3. An email feature that allows users to email other users directly through the program.
4. An SMS feature that allows users to send text messages to user mobile devices directly through the program.
5. The ability to leave messages within the software somehow, so that an area of it can act as a bulletin board or log book of progress.

Document Locking

Users will need to be able to lock parts of the document that they wish to edit to disable other users from over-writing their work. The software need to take this into account by:

1. Providing indication to users that parts of the document are locked.
2. Giving the user the ability to lock parts of the document.
3. Giving the user the ability to edit the document without locking an area first.
4. Having a kind of user ranking system to allow administrators or the most highly-ranked to take control of the entire document.

Preferences

The group decided that the user should have the ability to:

1. Change speaker volume and recording volume through the program.
2. Customize the interface somehow to increase workflow.
3. Choose many other preferences to generally please and assist the user while using the software.

Accessibility & Security

Security will play a key role in the use of the collaborative editing system. It will be essential to:

1. Have some form of user identification, such as the use of a username and password.
2. Allow the person that initially created the document to have more control than any other user, with the exception of network administrators.
3. Have an automatic backing-up system that can only be accessed by the original file creator and/or network administrators.
4. Have some form of user identification system, such as a user profile that can be accessed by all other users.

DESIGN

The following QOC diagrams are the result of various discussions that have taken place outlining opinions on various interface design ideas and possibilities throughout the groups Design Space Analysis (DSA) sessions. QOC diagrams have only been drawn for significant areas that were found to reveal disagreement between members of the group or were done to actively assist putting thought behind choosing options that initially would have had less thought applied.

QOC Diagram #1
QOC Diagram #2
QOC Diagram #3
QOC Diagram #4
QOC Diagram #5
QOC Diagram #6
QOC Diagram #7
QOC Diagram #8
QOC Diagram #9
QOC Diagram #10
QOC Diagram #11
QOC Diagram #12

Outcomes Of The Process

 

The QOC diagrams show the options that were chosen based on balancing the positives and negatives of various criteria, many of the examples show immediate justification for their choices, but others require some further explanation. Below are brief accounts explaining some of these less-decisive options.

Q. How should the toolbars function?

O. Dock-able Windows

In conventional windows applications toolbars float but can be docked into panels, from these panels toolbars can be ordered, and individually removed, but they can not be temporarily hidden as a group, therefore constantly consuming screen space. The group has decided that this problem can be resolved by having a panel that can be minimized, therefore temporarily hiding all of the user-ordered and positioned toolbars but still keeping them handy and freeing up screen space. This solution would also allow undocked toolbar windows to conventionally float and when docked allows their window/toolbar names to be shown, unlike standard docked toolbars that hide their names when in the panel.

Q. Should the software follow an OS scheme?

O. Windows (pre-XP)

This was chosen because users would be more familiar with interface concepts that would be applied with the design revolving around a common Operating System (OS) theme. Although Windows XP does have many new useful interface features that could be applied to the prototype, they may distract and discourage older OS users. Pre-Windows XP interface objects are also much more colourful and can distract users from the large amounts of text that would be present within technical documents.

Q. 2D or 3D buttons?

-- Q. How dependant should they be on icons?

-- O. Where appropriate

Certain functions cannot be easily represented by icons, but others have become conventionally used on buttons. ‘Save’ for example is represented as a floppy disk and is virtually always readily available on a static toolbar at the top of the screen. However a function such as ‘save for web’ cannot be easily represented as an icon, especially when the buttons are only 16x16 or 32x32 pixels in size (by convention in a Windows OS), therefore some buttons will need to use textual captions to describe their functionality.

Conclusions

The group’s initial design process of discussing design features and creating QOC diagrams has various advantages and disadvantages, and effects how the prototype will be designed.

The group benefited from being forced into discussion while creating the QOC diagrams, ideas were put forward that would have otherwise not been heard and all members of the group actively contributed to the discussed topics. The QOC diagrams themselves helped to weigh up the available options, show how the design could be different and helped the group to see where discussions were leading. They also aided the group in defining the size of the project and listed a history of the covered topics.

This process of designing did have many negatives though, it took time to draw the QOC diagrams and this often interrupted the discussion, and made the process quite time-consuming. The QOC diagrams themselves do not show the level of thought that went into the choices, and the relationship lines between the option and the criteria are either positive or negative and do not allow for any kind of variable range.

In general the benefits of using the QOC diagram approach outweighed just pure discussion with perhaps some note taking. Although this approach took more time, the discussions were much more thorough and this amount of applied knowledge and increase in concept ideas will positively increase the prototypes appearance, functionality and ergonomics. Each member of the group agreed that this approach is very suitable for large projects, but for anything with a smaller scope it would not be necessary.

IMPLEMENTATION

The following images are sample screens created to represent the prototype interface; they have been created using pixel art through the use of Microsoft Paint and adapted ‘screen grabs’ from various applications:

 

View Image #1 View Image #2

RESULTS

The prototype interface does have many design features that can be classed as conventional or original; there are many positives and negatives to the design.

The most beneficial original design feature is the use of the toolbar panel that can be easily hidden; many more software applications that require toolbars should use this concept. When the group asked other people for feedback on the prototype, virtually all immediately noticed the hide-able panel and agreed that this would be exceedingly beneficial. A comment from one user, who used the Internet for lots of collaborative work said “I like the use of the toolbar panel, this would be excellent with a shortcut key such as [Ctrl] + [Tab]. It keeps all of the users frequently used tools immediately on-hand, and frees up document screen space that would have otherwise been accessed inadequately”. Toolbars in general help to ‘chunk’ the interface, therefore increasing the users ability to memorize the location and functionality of certain interface objects.

Another beneficial design feature is the use of conventional and original icons within the application. Original icons have only been used where their functionality can be easily graphically described without the need for supporting text, and/or, where their position and graphics will make their purpose easily memorable. A good example of the ‘easy’ graphical use of icons is where the lock command is represented by a closed padlock and an open padlock is used to represent unlocking it. A good example of the use of position and memorable graphics to make the icons purpose more memorable is the use of the icons that represent secondary chat commands; they are within the chat window, near to the ‘send’ button showing that their purpose is related to their position. Two red exclamation marks represent sending the typed text as an alert, and a single black exclamation mark represents sending the typed text as an action, although these two iconic images may not be immediately related to their function, once used or ‘cued’ (by hovering the mouse over them) they would be remembered and then seen to be obvious.

The structure and layout of the prototype also boosted the usability of the interface. Standard document editing tools, which would be frequently used while either collaboratively working or working individually on a technical document, are placed at the top of the prototype below the taskbar on a static toolbar. Functions that are primarily associated with the collaborative side of the application are organized within the customizable part of the interface, as certain toolbars would need to be added or removed depending on the user’s preferences and available hardware. Finally, chat commands, thought to be the most frequently used form of communication between members are present at the bottom of the screen. This structure allows for the grouping of interface objects, making them more memorable and would allow the program to hide parts of the interface easily should the user be working on their own and not need the collaborative functions.

One of the main disadvantages of the design includes the software’s lack of originality; some problems within interfaces of other applications are present in ours as although conventional design can often be described as a safe route, problems with these conventions are still present. A good example of a conventional problem that is still present within the prototype is the use of conventional vertical scrollbars that when slid appear to move the document in the opposite way to the mouse i.e. when you drag a scrollbar down, the document moves upwards but your line of sight goes down. New users often have problems with this concept, but all get accustomed to it in the end as it is used so often.

Some of the buttons within the prototype interface are also inconsistent with one another; different styles of 3D buttons have been used, and some buttons should be equal in size to buttons with an equal amount of importance and presence. These faults can lead to problems, buttons can appear to be more significant than others, and the visual complexity and organization of the interface can look awkward and unprofessional. In general buttons should all follow a defined style, and be of equal size.

Another problem is that the prototype is designed for 800x600 resolutions and it doesn’t show what it would look like in larger resolutions. Conventionally in a windows environment most of the interface of any application does not scale itself to the user’s resolution, instead only the ‘blank’ panels enlarge to account for the newly available space. This causes interface objects to look smaller in higher resolutions, and can therefore make the interface more awkward to use due to inconsistency with other resolutions and scale problems.

In general the proposed interface design is suitable for its purpose, but before final production, it would need various tweaks performing. The prototype displays how most of the initial features and abilities, listed in the ‘method’ section, would be accessed and/or used by the user, but it does not show how unconventional features could be accessed through the use of the keyboard.

In general the group likes the design that they have proposed together, but should they have not worked collaboratively, each would have taken different paths in producing their own prototypes. What has been presented is a sample of our combined ideas short-listed through the use of DSA and common sense.

REFERENCES

ACM Group. (2001)
Third Annual Collaborative Editing Workshop.
Retrieved February 19, 2003 from:
http://www.research.umbc.edu/~jcampbel/Group01

Apple Computer Inc. (1996)
Retrieved February 24, 2003 from:
http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-46.html

Beaudouin-Lafon, M. (1999)
Computer Supported Co-operative Work.
John Wiley & Sons

Brinck, T. (1998)
Groupware: Introduction.
Retrieved March 16, 2003 from:
http://www.usabilityfirst.com/groupware/

Chen, D. (2001)
Consistency Maintenance In Collaborative Graphics Editing Systems.
Retrieved February 19, 2003 from:
http://www.cit.gu.edu.au/~david/Thesis.pdf

Chen, D. (2002)
The fourth International workshop on Collaborative Editing.
Retrieved February 19, 2003 from:
http://www.cit.gu.edu.au/~david/CSCW02CEW/

Dourish, P. (1999
Software Infrastructures. Xerox Parc. Computer Supported Co-operation Work.

Beaudouin-Lafon (E). (pp 195-199)
John Wiley & Sons Ltd.

Ehrlich, K. (1999)
Designing Groupware Applications: A Work-Centered Design Approach.

Lotus Development Corp. Computer Supported Co-operation Work.

Beaudouin-Lafon (E). (pp 1-23)
John Wiley & Sons Ltd.

Karash, R. (1999)
Groupware and Organisational Learning.
Retrieved March 6, 2003 from:
http://world.std.com/~rkarash/GW-OL/

Khoshafian, S., & Buckiewicz, M. (1995)
Introduction to Groupware, Workflow, and Workgroup Computing.
John Wiley & Sons Ltd, 1995.

Prakash, A. (1999)
Group Editors. University of Michigan. Computer Supported Co-operation Work.

Beaudouin-Lafon (E). (pp 103-127)
John Wiley & Sons Ltd