OzCHI 2020: Idiosyncratic Practices and Preferences in Collaborative Writing - YouTube

Hi everyone! My name is Ida Larsen-Ledet and I am presenting the paper:

“It Looks Like You Don’t Agree: Idiosyncratic Practices and Preferences in Collaborative Writing.”

This paper was written by my co-author, Marcel Borowski, and myself.

Collaborative writing practices are dynamic and situated.

Several guidelines on how to design software for collaborative writing have been proposed,

including guidelines that try to address its dynamic nature.

However, a problem with guidelines is that they are fixed suggestions.

We wanted to explore more versatile ways of designing for collaborative writing,

with a focus on academic writing.

In the paper, we therefore explore two research questions:

What do co-writers experience as challenging in collaborative academic writing?

And what steps can be taken to address those challenges?

In this brief presentation I will be focusing on the second question

by introducing a protocol for weighing trade-offs when designing for collaborative writing.

We chose to approach these questions through a co-design process,

as it would enable us to obtain accounts of writers’ practices,

like traditional methods  such as interviews would,

but also directly discuss and evaluate technological artifacts with participants.

This meant that our study was focused on exploration and understanding,

while development of a functioning prototype was secondary.

We recruited 18 participants from our local university.

The participants’ academic educational level

ranged from master’s students to associate professors.

Participants’ backgrounds were mainly in the fields of computer science, digital design,

and product design, with some coming from other design fields or molecular biology.

The participants’ experiences with collaborative writing included

master’s theses, project reports, academic papers, and books.

We structured the study into a 3-stage process,

with each stage consisting of one or two workshops:

Stage 1 was focused on dialog and defining what problems we were going to work with.

In Stage 2, participants elaborated on initial ideas from the first stage.

After stage 2, Marcel and I implemented a software prototype

that included ten features envisioned by the participants.

These features could be included and removed dynamically in the running prototype.

In Stage 3, participants  explored this prototype

and reflected on use cases and alternative designs.

During the workshops, we collected video recordings and photographs,

along with artifacts like notes and sketches.

The photos shown here may give  you a sense of the setup.

To contextualize the trade-off protocol I mentioned before,

I will briefly outline our main empirical finding, which is a set of contrasts we noticed

in the needs and preferences discussed by participants.

Those contrasts are listed here.

I will not go through them,

but to provide an example: The contrast between "Calling attention" and "Controlling disruptions"

has to do with sending and receiving of information,

such as messages or notifications  about changes to the text.

The way participants talked about notifications, they could be a service either to the sender,

by pulling somebody else’s attention in,

or to the recipient,

by being available at convenient times but otherwise not disrupt writers.

Contrasts like these are not captured well by guidelines.

We therefore suggest a structured way of framing discussions about contrasts

and potential trade-offs,

in the form of a step-by-step protocol.

You begin by selecting what you want to focus on. The suggestions shown here

are examples of topics that we addressed  with participants during the workshops.

Say that we choose to work with communication.

The next step is to identify mechanisms related to communication.

This could be existing ones or some that were proposed,

for example during a co-design workshop.

In this case, we may choose to focus on  the comment feature in Google Docs.

The next step is to analyze the chosen  mechanism in terms of relevant contrasts.

In this case, the most relevant contrasts are:

"Calling attention" versus "Controlling disruptions"

and "Information availability" versus "Tidiness".

We may then begin by focusing on "Calling  attention" versus "Controlling disruptions"

by assessing where Google Docs comments lie on that spectrum.

The purpose is then to use this as a guideline

for considering alternative designs or features that lie elsewhere on the spectrum.

This could, for example, be a feature

where tagging a co-writer results in  them getting an in-app notification

that is also available in a document overview,  to show the writer where their help is needed.

A couple of the participants actually worked with this idea during the workshops.

You could also pick some of the mechanisms  exemplified a couple of slides back.

The protocol would then involve you reflecting  on the trade-offs of each mechanism or design,

and consider whether to try to balance them or lean more towards one end of the spectrum.

The protocol we propose in our paper is intended as an aid for dialog and reflection,

potentially when designing with users.

It does not give the answers

but provides a structured way of  talking about design alternatives.

The protocol evolved after we finished the workshops

so, unfortunately, we have not tried it out with participants.

We encourage others to try it out and let us know how it works out for them.

Thanks a lot for listening!