This chapter presents an empirical account of the design process that was undertaken in order to produce systems that were later deployed.
This phase of research was important because it transitioned the research from the fieldwork accounts of the previous chapter into a phase where design work was being performed and tools were being produced. This allowed for sense-checking of the findings from the previous phase of research as well as a field-test for trying to embed these sensibilities into designs. It also allowed me to reflect on the performance of the design work and the implications for designing Transparency tools in charities and other civic spaces in the future.
As such this chapter begins with accounts of the performance of design workshops and how these transitioned into an iterative design cycle. It then gives an account of the systems themselves which I present as a design rationale for their core features. Finally, I reflect on lessons learned from this design process including early insights into the nature of these tools; where the responsibility for doing the design work lies; and considerations for performing design work in spaces such as these.
As noted in Chapter 03 design activities began in late August 2016 with the performance of design activities building on my fieldwork at Patchwork. This section elaborates on the design activities encapsulated in a Futures Workshop and the resulting discussions and space it created to take forward into development.
I originally intended to perform a single workshop using the Futures Workshop (Jungk & Müllert, 1996) framework, however due to scheduling restrictions was instead performed as three separate workshops spaced roughly three to four weeks apart in each instance1. Each workshop was performed with Patchwork in the main room at their central hub (Patchy 1) and the workshops lasted approximately 60 - 90 minutes in each case.
Chapter 03 discusses these workshops under the heading of Fieldwork Methods, but I must reiterate that these research activities marked a transitional phase from the strictly investigative fieldwork activities and towards the design phase of this research. They served as a bridge where I was situated at the field site but beginning to bring design activities into the work there. The workshops allowed me to first check assumptions by presenting them back to Patchwork in a particular way and then use these discussions to fuel a reflective process about work practice and digital systems that could in turn be used to organise design work. Full details of the workshops can be found in the appendices of this thesis (Details of Design Workshops).
With this in mind the performance and “output” of the workshops was captured and conceptualised as part of the ethnographic corpus with which to begin the iterative design process that lead to the implementation of a system. Each of these workshops were audio recorded and some photographs were taken at each but the data was later damaged. This left only an audio recording and partial transcript for the first workshop, as well as some photographs for the third amidst my field notes. The remainder of the iterative design process was started quickly after the performance of these workshops so these additional materials were used as prompts for memory during the early stages of sketching and prototyping.
Following the three sessions that began the iterative design process I launched into a User-Centred Design (UCD) cycle which resulted in the design and implementation of lightweight, inter-operable, systems which were later evaluated (evaluation detailed in Chapter 06). The details of these systems will be given in the next section but consisted of: a mobile application to capture data; a data standard to standardise and facilitate transmission of data; and a web application to consume, manage, and present data in the system.
This portion of the iterative design cycle was performed across six months from October 2016 to April 2017 with Patchwork and was incorporated into my field visits to the charity. Output from the initial workshops, as well as the analysis of initial fieldwork presented in Chapter 04 fed into these designs. At early stages I followed a straightforward process of sketching out system architecture diagrams, interfaces / wireframes, and sequences of interactions in pencil and then checking these with the team at Patchwork each week in a process derived from the Design Crit (Goldschmidt et al., 2010). At later stages this process remained the same excepting that I demonstrated early stages of implemented interfaces on phones and web browsers. Feedback from these sessions was captured in my field notes and then acted upon in the next week’s worth of design iterations.
It became clear early in this process that although Patchwork valued the principles of Participatory Design as I presented them; they trusted me to design them a system or application to address their needs based on my time spent there. As such their interest and engagement varied across the weeks based on a number of factors, and in some cases my sketches were only glanced over with a cursory “yeah this looks fine! Excited to see it” (Andi) from one of the team. The result of this is that I had a large degree of flexibility in designing the systems based on the requirements and design implications discussed in the previous chapter; although these were presented back to Patchwork early on as a way of sense-checking my interpretations of their work practice. These requirements were accounted for by embedding these principles into the system architecture and while I tried to make it clear what principles were guiding the design of the systems; Patchwork remained focused on how the interfaces and processing of data supported the pragmatic accomplishment of their work practice.
This skewed the priorities in the design process towards data capture early on; meaning that the early focus was on the production of what later became the Accounting Scrapbook mobile application. While Patchwork did indeed care about the types of information that they could capture in the system and how to link it up there was less enthusiasm about the concept of a Data Standard as this was out of the immediate scope of their concern. Because a goal of this thesis was to understand how to capture data about charity work and spending in a standardised way, I felt like it was too important to “drop” as part of the system. I instead made it clear to Patchwork that our discussions about capturing information in an application were also feeding into the design of what became the Qualitative Accounting data standard. Although, oddly, Mick was very keen on influencing the name of the standard for no discernible reason and my attempts to move away from the term “Qualitative Accounting” were met with lighthearted but firm protests2.
By the Christmas break in December 2016 “Accounting Scrapbook” was in a condition where no substantial or controversial changes were being introduced at each crit session. In the January I shifted focus onto designing a web service to consume and present back the information that was captured using the mobile application. This followed a familiar route progressing from sketches to early prototypes across the months of January 2017 to April 2017. Notably it was difficult to get sessions and design input with Lynne during this time because of her role as part-time. Our sessions at Patchwork rarely coincided and Lynne’s limited hours per week meant that the taking up of her time was felt very keenly. This made sense-checking these designs with her difficult and presented a challenge since I was envisioning that she may be the primary user of what became Rosemary Accounts when it came to deployment and evaluation. I believe Patchwork as a whole were slightly fatigued by the design process when it came to designing this portion of the system, as I noted less enthusiasm at this stage. This may have been partly due to the timing of this process as Patchwork had to accommodate their regular activities as well as planning for several school holidays (where their programme resembles the intensive summer-programme).
In May 2017 I was preparing for deployment and evaluation and sought other charitable organisations to participate in this. A chance meeting with the CEO of Community Project Gateshead (a pseudonym), a charity based in nearby Gateshead, in the offices at Open Lab (they were participating in other projects) was met with enthusiasm on their part and they expressed keen interest in joining the research. I followed this up with an initial meeting with them onsite at their project to find that they had also invited workers at Older People’s Charity (OPC), another Gateshead charity, who also appeared enthusiastic at testing out the systems and who both agreed to be part of the research. This initial meeting was followed up by separate follow-up sessions at each of these organisations to introduce myself and the research to the workers and communities there. As I was introducing the Rosemary Accounts software the staff of Community Project Gateshead raised several concerns about some design features which resulted in a discussion on how best to address the balance of data protection, privacy of service users, and the display of media. I ratified these concerns with OPC and suggested improvements before informing Patchwork of the changes and sense-checking with them before implementing them in the system. These adjustments were made to accommodate these new enthusiastic partners and hopefully see a successful and involved evaluation stage, but resulted in the development work stretching across May 2017 and into June 2017. I will discuss the specific adjustments made in the next section.
This section outlines the systems and design rationale of the software that was developed for deployment. Attention is first spent on an overview of the systems including their decentralised architecture and how this addresses design requirements that were raised in the Chapter 04. I then take each “component” of the system in turn and walk through its features and elaborate on the design process that lead to them.
The previous chapter makes clear that a design requirement was to support a configurable Transparency which did not impose a specific presentation or collection process for the data, and was flexible to the needs of workers. I also stipulated that, since it is established that values may be embedded in the design of a digital system (Pine & Mazmanian, 2014), any design seeking to be useful in this space embeds the values of Flexibility and Worker Control. I also suggested that data in the form of linked data is required to create contexts required to understand a charity’s work.
This data also needed to be produced in a way that it would be inter-operable with other systems that other actors may be using (e.g. software for signing off accounts) however this potentially would have provided a contradiction with the requirement that any systems be provided as community software with no charge for the organisations. This is made clear by Mick’s utterance in the previous chapter where he expresses distaste at being asked to use Sage’s expensive accounting software, yet the accountants require this tool to do their job.
To address these design challenges the system architecture took the production, exchange, and consumption of the data as the fulcrum upon which other interactions should be built and to decentralise the systems that exchanged this data. Heeding lessons from my previous work which called for standardisation (Marshall et al., 2016) a data standard was produced to describe what data should be captured and how it should be structured. The decentralisation of the systems, as opposed to producing a monolithic ‘platform’, addressed two key requirements: that Transparency may be configurable as new systems and interactions may be designed to make us of the data in new and interesting ways as needs emerge; and that an organisation can not be forced to use a proprietary system as different pieces of software would be inter-operable by using the data standard for communication.
Evidence of this approach being technologically and interactionally feasible came from a review of existing decentralised social media technologies on the Web; namely those found on The Fediverse (Gehl, 2015; Holloway, 2018; Liu et al., 2020) and The Indieweb (Werdmüller, 2013; Indieweb.org, n.d.a). This was useful because these technologies were attempting something similar to this project in that they were developing interfaces and rules for the production, exchange, and viewing of data that were not bound to a specific platform. In this case; status, likes, and other activity commonly found across social media. The Fediverse and Indieweb are themselves separate but inter-operable spheres of decentralisation of social networking on the web. The former focuses on producing explicitly federated platforms for large groups of users but which share a common language and protocol known as ActivityPub (Webber et al., 2018) which describes how data should be structured and shared. On the other hand the Indieweb’s attention is around achieving networking and compatibility of individual sites and blogs (Werdmüller, 2013).
During the design phase of this project the Fediverse was yet to reach its current level of maturity but I followed its development closely in order to learn from it. It provided a useful case study as to how a rich variety of different interactions may be had when heterogeneous systems shared the same language (the ActivityPub standard) and how different needs may be addressed. From the same vocabulary the fediverse produced: Mastodon (Mastodon gGmbH, 2021), a Twitter-like interaction around microblogging ‘toots’; Peertube (Framasoft, 2021), a decentralised alternative to YouTube with comment and subscription provision; Friendica (Friendica, 2021) providing a Facebook-like experience; and more recently Pixelfed (Dansup, 2021), a decentralised image sharing service like Instagram. There are many others such as Diaspora* (The Diaspora Foundation, 2021) and GNU Social (Free Software Foundation, 2021) which provide new or other combinations of interactions around ActivityPub data which are not intended to be direct or close-to-direct analogues of proprietary, closed, systems. Through the ActivityPub standard each of these pieces of software are able to communicate not only between instances of themselves but between instances of each other as well (e.g. subscribing to a Peertube channel via Mastodon (Derek Caelin, 2020)). This was valuable as a living and field-tested proof-of-concept for attempting to enable new interactions around charity spending and activity data.
Taking a decentralised approach early on in the design process also had the benefit of allowing for the potential to add new applications, services, interfaces and interactions for evaluation very simply and without needing to modify existing systems. Although only a few systems were evaluated in this thesis (see Chapter 06) if the potential to work with new stakeholder groups arose then systems evaluating or addressing these needs may be developed and deployed very easily and contribute to the ecosystem without affecting the work practices of those already using existing tools.
It is in this way that decentralisation also begins to address value-driven concerns in its design that were surfaced in Chapter 4 Platform Capitalism is the term used by Srnicek to describe the economic model where a private, for-profit, entity owns the software platform (apps and associated web tooling) by which economic exchange is done and work is organised (Srnicek, 2017a, 2017b). It is closely linked with the rise of the so-called Sharing Economy (Martin, 2016) and classic examples of this model are: “ride-sharing” platform Uber; rental platform AirBnB; and food-delivery service Deliveroo. In this sphere it has raised concerns on the future of worker’s rights (Vallas, 2019), but in addition to those companies associated with the Sharing Economy the definition of Platform Capitalism includes popular work and social platforms such as Facebook, Twitter, Google and the increasing amount of software that is run on web technologies as a service (Srnicek, 2017a, 2017b). Kleiner, adding an explicitly Marxist analysis, writes that this is expected of the web overall since it is capital’s attempt to reduce peer-to-peer exchange on the Internet by reconfiguring the shape of the network to a more centralised Client-Server model so that resources may be accumulated, commodified, and controlled more easily (Kleiner, 2010). Again Mick’s criticism of being forced to use expensive proprietary accounting software that he does not control embodies this concern as experienced by a worker in this setting. With this in mind, producing a decentralised system architecture was essential in order to achieve the goals of embedding the values of Flexibility and Worker Control which have been established as design goals.
The result of embedding these principles and technical concerns to address the design requirements was the outline of a system architecture that had at its centre a prototype data standard which was termed, as noted in an earlier section, the Qualitative Accounting data standard. In order to support collecting information I produced a lightweight mobile application called Accounting Scrapbook and in order to support the curation, presentation, and sharing of the data Rosemary Accounts was produced.
Taking design cues from existing data standards such as Open Contracting (Open Contracting Partnership, 2021) and 360Giving (360Giving, 2020) it was also important to make each component of the overall design available under Open Source licensing. During the reseach period, both Accounting Scrapbook and Rosemary Accounts were developed “in the open” via an open-source repository on Github, a popular open-source code repository (Github.com, 2021). When Microsoft acquired Github in 2018 (Microsoft News, 2018) I transferred the repositories to an open and public repository on Gitlab, a popular alternative (Hethey, 2013) which many users migrated to after Microsoft’s acquisition of Github (Reuters, 2018).
I continue by providing an overview of the features and development of each of these component parts.
In order to achieve interoperability and move towards a decentralised ecosystem, applications and services need a common language with which to communicate; allowing them to share and process data amongst themselves. A standard is a way of defining vocabulary and rules that dictate how data is described and structured (Field & Sansone, 2006). As data becomes increasingly available online there have been multiple calls for standardisation across various sectors of industry and academia (Mucina et al., 2000; Quackenbush, 2004; Hammond, 2005; Marshall et al., 2016). As such a prototype, lightweight, standard was designed with Patchwork to inform later system design. This also provided the design benefit of being able to synthesise findings around what elements of practice were crucial to capture and communicate as well as an opportunity to check this with the workers.
This standard was tentatively named “Qualitative Accounting” (hereafter QA) in reference to the findings from earlier work (Marshall et al., 2016) although during the design process I raised concerns about how this may be a misnomer. This was because the inclusion of latitude and longitude coordinates for locations, financial data, etc could not necessarily be said to constitute “qualitative” data by themselves. After I raised this as a concern Mick protested saying he thought the term was “catchy” and that “Qualitative is in the eye of the beholder. Eh I like that, write that down!”. Because of this the name remained in place as focus soon shifted towards developing the individual tools that implemented the schema.
Since our technical challenge involved both the structuring and transmission of data I took inspiration from ActivityPub (Webber et al., 2018) and as a result our prototype standard contained two main components: a data schema for collecting and annotating data representing money and work which was design more collectively; and a Web URI schema which defined expected URI endpoints and behaviour so that systems implementing the standard could communicate with arbitrary domains using Web technologies. This latter component was mostly tended to by myself as Patchwork saw it as a purely technical concern although they did express mild curiosity as to how the component systems were communicating.
Given the above the key challenge became unpicking what was essential to capture and transmit. This was achieved in the design process by drawing upon the field notes and my ethnographic work at Patchwork, looking at existing practices, and then sense-checking these with the workers. During this process it became clear that to ensure engagement that the fields and structure of the data be kept as simple and minimal as possible to make it simple to collect and organise. The end result is the schema outlined in Table 5.1, and this section outlines the design rationale behind each field described in the schema.
| Field | Type | Description |
|---|---|---|
| id | string |
Unique identifier for the transaction created by your system |
| date_created | date-time |
Date the record was created on the system (ISO 8601) |
| date_given | date-time |
Date given for the record, to allow for retroactive creation of accounts (ISO 8601) |
| tags | array[string] |
Qualitative tag descriptors for the item. No hashtags (see below) |
| quote | Quote (see below) |
Snippet of text to capture sentiment. E.g. “It was a good day - Anon” |
| financial_data | FinancialData (see below) |
Financial data associated with the item, such as spend or income. |
| media | array[string] |
Array of Uris to media items, such as images, documents, or videos. See below for details. |
| location | Location (see below) |
Geographic location of item, such as an address or lat/long |
| description | string |
Any additional information or notes that the producer would like associated with the item |
The base metaphor for the schema was an individual action or item to which information could be appended to account for various dimensions. The schema was designed to be as simple and flexible as possible so that the workers could appropriate it for their own ends and not having separate schema for different activities meant that we avoided arbitrary delineations for different types of activity that may not make sense to other organisations. Something that the focus of this research was to try and avoid.
In order to link the performance of work with the charity’s income and expenditure it was necessary to record this financial data. I presented Patchwork with the MonetaryAmount schema (Schema.org, 2021b) as defined by Schema.org (Schema.org, 2021a), a community and collaborative project intended to create and maintain common schemas for components such as these (Schema.org, n.d.). This was met with raised eyebrows from the Patchwork staff, and Mick went as far to say “This is a bunch of useless rubbish. We just need to say how much we spent”. Taking this as a design cue I wrote down each of the fields inside of MonetaryAmount and we began crossing them out as we decided we didn’t need them. The end result was a much more simple FinancialData building block (Table 5.2) which contained only two fields; the value of the transaction and its currency to make it internationally accessible.
| Field | Type | Description |
|---|---|---|
| currency | string |
Three letter currency code as designated by ISO 4217 (e.g. ‘GBP’ for Pound Sterling) |
| value | Number |
Financial value associated with the item. Positive for income, and Negative for expenditure |
During this conversation we also noted the requirement to model income as well as expenditure although Patchwork left it to me to decide how to implement this. Initially I had thought to add an additional field within the FinancialData block which described how the value should be interpreted. However I decided that since the same field would be used to describe the flow of money that it should be interpreted based on the value of the transaction where a positive number is associated with income and a negative number is associated with spend. This gave the technical benefit of reducing the amount of information to be recorded but added a semantic rule that needed to be explained if others were to develop tooling around the standard.
I next turned attention to unpicking what other information Patchwork communicated to others. The description field was included in the schema as a foundational element which would add context to the other dimensions of data included in the item. For example a description could detail the purpose of a spend, give a description of an event that was run when combined with location data, or describe the story behind images. My field notes on Patchwork’s activities as well as the annual report (The Patchwork Project, 2015) placed a high prominence on photographs as well as quotations and testimonials from their beneficiaries. A discussion from fieldwork also noted in the previous chapter denotes this:
Andi: “Part of it’s capturing that moment in time because it’s gonna be gone. Y’know, and it would be very easy for them to forget […] So you’re capturing it for them, you’re capturing it for their parents to see what they’ve achieved, or for the Duke of Edinburgh so they can prove whatever it is they’ve done. You’re putting on the wall as a celebration, you’re putting it in the annual report for funders to see and also for young’uns to see […] Like loads of kids will be like ‘will this be going on the wall?’.”
Mick: “We just take lots of pictures because it becomes a resource for us as well. The ones on the wall are of the D of E because they’re positive images. Sitting down two people and talking one to one and that — it’s not very entertaining.”
To address this, as well as leave the option open to attach other forms of media such as videos etc, I added the media field to the schema which was to take an array of URIs which pointed to images, videos, reports etc. Originally this was a single URI as I had envisioned Patchwork would want to create separate items for each photo (such as on Facebook or Instagram) but feedback from Andi during some evaluation of Accounting Scrapbook prompted the change to an array: “It’d just be easier if I didn’t have to go through and create a new photo every time”. The URIs meant that photographs and other media could be hosted elsewhere which decoupled the media storage from the data transmission. This would allow Patchwork and other organisations to continue using their existing services for photos (Facebook and Dropbox) and to append the URLs later if necessary. For images transmitted using Accounting Scrapbook this opened up a technical challenge of how to generate URIs for an arbitrary endpoint which I discuss later in this section.
{
"media": [
"https://rosemary-accounts.co.uk/qa-media/ebc6df075e0200c451757ba3d051f79b47b2c976",
"https://rosemary-accounts.co.uk/qa-media/28cf4ef03ac7023ce0dc816b4aab6558d7e6079f",
"https://rosemary-accounts.co.uk/qa-media/f659164d121f53c10af8b626ec110e2e48ff21bc"
]
}Once photographs were modelled as it was also important we developed the Quote block (Table 5.3) to capture the testimonials that were prominent in the annual reports. Similarly to FinancialData I originally presented Patchwork with the Schema.org Quotation object (Schema.org, 2021d), but this had inherited a lot of complex fields around “Creative Work” and only added the SpokenByCharacter field. While Dean noted that “All of our lot are characters like”, after a brief discussion the Schema.org model gave way to a simpler model allowing Patchwork to capture the text of a quote as well as the attribution.
| Field | Type | Description |
|---|---|---|
| text | string |
Content or body of the quote |
| attribution | string |
The name of who or what the quote is attributed to |
Geographic data was included to allow the schema to represent place in the records. This was added because of my field observations and participation in Patchwork’s activities that took place outside their main sites and allow them to start mapping these. For example when Patchwork take a group of young people out camping they will then reflect on their experiences at a location, and provide a narrative of “experiences” for groups or individuals. Similarly Patchwork often support members of the community in situ. On one site visit I visited a member of their beneficiary’s extended family’s home with Andi to diagnose why their washing machine was not working. Place and location were thus deemed important to support making visible the work Patchwork do and their effects in the community.
| Field | Type | Description |
|---|---|---|
| name | string |
Name of the location |
| address | string |
Address of the location |
| latitude | string |
Latitude point of the location |
| longitude | string |
Longitude point of the location |
The result was the addition of the Location building block (Table 5.4). Similar to previous blocks, I discussed the Schema.org Place (Schema.org, 2021c) object with Patchwork who thought that it was very difficult to understand all of the different fields. I then presented them with a trimmed down version which included a single address field, latitude and longitude coordinates, and a place name. The single address field was chosen so that workers did not have to spend a lot of time entering the address, and the latitude and longitude could provide detailed locations if desirable but also could be omitted for privacy and protection reasons. This would allow Patchwork to create details about events or work within a community and give either precise locations or street / area level details which could be mechanically resolved to a radius of impact or activity later.
Finally, two fields named date_created and date_given were added to the schema to date each entry. The dates are separate because this would allow for Patchwork to retroactively add data which could be dated appropriately (for example to produce a timeline of activity) using date_given. The former field, date_created could be used by systems and interfaces to group activity on the system itself ie to support providing logs of when data was added.
One of the key design challenges as raised in Chapter 04 was to provide a way of linking discrete items together in a flexible but consistent way in order to support Patchwork, similar organisations, and stakeholders in creating contexts around work and thus making their work practice accountable.
To build this into the data model I took initial inspiration from the phenomena of hashtags on the social web. Hashtags are a form of metadata tag used on social websites such as Twitter, Instagram, Youtube etc. which allow users to add dynamically generated and embedded metadata to a post (Panko, 2017; Zappavigna, 2015). This allows content to be thematically grouped and searchable without requiring direct or directional links between individual posts (Zappavigna, 2015) and Bruns and Burgess state that this supports the formation of ad-hoc publics around topics and events as information can be released and added to the narrative at great speed (Bruns & Burgess, 2011). Given Patchwork’s familiarity with social media and use of sites such as Facebook to communicate images with hashtags this seemed an appropriate way to support linking in the standard as it meant that data did not have to be so heavily curated by linking it manually after initial creation. The social media use of hashtags also provided a case study around how data users may potentially interact with the hashtags and search through items around a particular topic or theme of a charity’s work.
I sense-checked this idea with the staff at Patchwork during a site visit, Dean and Andi seemed enthusiastic about the idea (they were by far the most social media-savvy and understood hashtags) whereas Mick and Sonia did not have strong opinions.
In the background I decided to keep flexibility as much as possible and decoupled the “hash” element of the hashtag to allow for multi-word tags (not possible given pure hashtags (Doctor, 2012)), however discussions with Dean and Andi lead to Accounting Scrapbook retaining the hashtags as part of the interface as that made the most sense to them.
With the flexibility built into the architecture it became necessary to describe a way in which both applications developed for this research and theoretical future applications could communicate with each other consistently. ActivityPub and Indieweb protocols each describe stepwise protocols for discovering Application Programming Interface (API) endpoints on heterogeneous systems (Webber et al., 2018; Indieweb.org, n.d.b) however to make future development easier and to test the proof-of-concept simply I instead imposed that my applications would follow rules about what API endpoints should be provided by systems, detailed in Table 5.5.
| Endpoint | HTTP Method | Description |
|---|---|---|
/qa-data |
POST | Accepts a JSON payload to store a single QA data entry |
/qa-media |
POST | Accepts a form-encoded POST request with form label media to support uploading files |
/qa-media/[sha-1FileHash] |
GET | Using the [sha-1FileHash] as a key, retrieves the media associated with that key to the requester |
The technical response was to require receivers of QA data to at least provide a /qa-data url on their system e.g. https://example.org/qa-data, https://rosemary-accounts.co.uk/qa-data to provide a common way for applications to send the data. This means that sending applications can construct a full URI to send the data to a receiver given only a domain name. Separate endpoints are also provided to decouple the sending of media items (/qa-media) and, later, to retrieve the item (/qa-media/[sha1FileHash]) in a standard way (since hosting services may provide their own URI schemas to retrieve images). This was done to support use-cases such as mobile applications so that they may send data entries and media asynchronously, and that upon failing to send a large image file the rest of the data is not lost and workers may recover the media another way.
This gave the following stepwise process for sending QA data from a standalone application to a hosted service:
For entries with media URIs I noted earlier that this provided a challenge when sending from a mobile application with local images to a service where the URIs will not necessarily be known; especially since the sending of media was decoupled from the action of sending data. The lightweight technical solution I implemented to address this was to agree the way that media URIs were constructed if they were uploaded to the receiver rather than hosted on a third party prior to transmission. To accomplish this the application or service doing the sending makes a cryptographic hash of the file using SHA-1 (Burrows, 1995) which gives a unique identifier for the file. While SHA-1 is not perfect (Biham et al., 2005; De Canniere & Rechberger, 2006) it was deemed appropriate for the research as it was lightweight, many programming platforms support it as a hash function natively (e.g. android (DevProf, 2012) and PHP (The PHP Group, 2021), used in this research), and the use-case in the research would not be working with a large dataset where there were risks of collisions or exposing data to malicious attacks.
After the hash is generated, it acts as a unique key to form part of a URI slug. This slug is then appended to the path /qa-media/ on a given domain e.g.
https://rosemary-accounts.co.uk/qa-media/629095bf6f1d232fe9d21f05be7bea2cf8f8d10fOf course, if the sending application also hosted the media in a manner that was available over the internet (e.g. two hosted web services communicating), it would mean that a URI already existed and the generation step could be skipped. For other cases, such as in local applications (desktop / mobile), means that a URI can be generated and sent as part of the associated data entry seamlessly.
For retrieval of the image the receiver may choose to store the image themselves or further decouple it and host it on a third party service. This approach is described below for Rosemary Accounts. As long as a receiving application provides the API endpoint of /qa-media/[sha-1FileHash] to later reference or redirect to the media hosted elsewhere then this meets the protocol set out in the standard.
The last challenge for the transmission of data was how to later identify each individual item that was being transmitted. For this reason the id field was added to the schema which was to be treat as a unique key for the item, and separate to an application’s internal database identifier. Since this thesis was concerned only with prototypes this aspect of the design was not as important in the design space as it may otherwise be. Therefore the QA standard only gave recommendations that item ids take the form of a string in the format of applicationName_deviceid_itemid where itemid is the unique internal identifier for the item in the internal database. This was an admittedly under-explored aspect of the design at this stage as lack of good identifiers would mean that analysis of the data would be difficult if large datasets from multiple organisations were accumulated. Given the limits of the scope of the thesis and the lack of interest from Patchwork in data standards, however, I felt it best to swiftly move on to designing components that felt more tangible to them.
Given this the focus of design shifted to how the staff at Patchwork and workers at other charitable organisations may collect the data as part of their everyday work.
With the QA schema setting out the basis of what it was important to capture and communicate; our attention turned to designing a system that the Patchwork staff could use to collect and transmit the data in a flexible and lightweight manner. My initial ideas were to try and build upon collective work and activities that Patchwork were already performing e.g.:
After discussing each of these, and others, with Patchwork we decided to produce a single mobile application to support workers doing data collection. This was because when presented with all of the various options that did specialised or single things Patchwork didn’t like the idea of having to learn to use a plethora of tools (Andi - “Eh? I thought it was just going to be one or two things like a button on the website”). The Facebook and wordpress plugins were discarded after a technical review on the complexity of the Facebook platform (and privacy concerns from Patchwork), and upon confirming with Andi that uploading to the Patchwork website (a wordpress install) did not occur as part of regular activity. I then reviewed findings from field notes and the workshop sessions in order to target the key areas of technology use that could be built upon. Andi, Dean, and Sonia (to a lesser extent) each used their phone prominently in the collection of photographs which were tied to groups and events. Mick also used his phone for this purpose but during my field visits he was mostly working at Patchwork 1 while I was at a group session with the others, and during the earlier drop-in sessions he was often concerned with funding bids or one-on-one interactions with drop-ins.
Targeting a phone thus provided an opportunity to make an application that was carried with staff and could be used on-the-fly as they went about their day, or later as a curatory activity. This was deemed viable as Andi discussed during a site visit how she would spend some hours on the evening sorting and uploading photos to the Facebook album after the fact; I later confirmed she did this when checking if that’s how she envisioned using the app. She responded with “I guess, yeah”.
As noted in the earlier section the various screens and components that made up the application were sketched out in pencil either by myself ahead of a site visit or during a site visit itself3. Later when the application was in active development I would instead present them the current version of the app on my phone and any feedback on the interface or features would be noted down via quick sketches or through fieldnotes.
The result of this process was Accounting Scrapbook; a lightweight mobile application designed to allow the charity workers to collaborate in collecting and curating information about their work and spending. This section continues by describing the design rationale behind core features of the application.
With the notion of ‘tagging’ items being central to achieving the desired outcome of a linked dataset it became a key task for the app to make it as easy as possible for a worker to simply and quickly add tags to items. The way we addressed this was to embed the notion of collections within the app to which many items could be added and semantically grouped together. Discussions with Patchwork the concept of “collections” initially did not make sense other than to Dean and Andi; who were more familiar with social media. To make the concept more accessible to other members of staff I decided to employ a real-world metaphor into the design first choosing “envelopes” as the metaphor and in fact most of the early design sketches used this to communicate the idea of collections (Figure 5.2). This was chosen because of the prevalence of envelopes in budgeting apps (e.g. Goodbudget (Dayspring Partners, 2021), Budget with envelopes (Notriddle, 2021)) and because I suspected that simply using the term “collections” would be too high level for some of the staff.4
The notion of envelopes did communicate the idea of collections to Patchwork; who became relatively enthusiastic about it but did not like the term “envelopes” as it sounded very formal. Andi said that it was “weird” as envelopes were used “for letters and documents”. Brainstorming new terminology at Patchwork didn’t bear immediate fruit but after several site visits I was able to suggest framing the collections as Scrapbooks. The scrapbook metaphor was rooted in informality and flexibility as well as being an established practice of using otherwise disparate items to form a narrative (Christensen, 2011; Goodsell & Seiter, 2011). The team approved with Dean commenting that “Well scrapbooks always look a bit tatty, and that’s us like”. Following this the app was named Accountability Scrapbook and then later Accounting Scrapbook where the latter sounded “snappier” (Dean). The individual items in the app were also referred to as Scraps from then on.
Organising items into scrapbooks matched Patchwork’s organisation of their Transparency work into discrete activities such as “annual report” or “photos of lads group”. A key benefit of collections from the perspective of the staff (and the desired qualities of the dataset) was that they themselves could be given tags which rapidly could be applied en masse to all of the items stored within a collection – this made it possible to generate links between all of the items within a collection. The QA schema has no notion of collections so this was a way of ensuring that this semantic group was kept intact once the data had “left” the app to be sent elsewhere. From the point of view of the staff, this meant that they didn’t need to spend several minutes tagging each individual item (although tags could still be applied on an individual scrap to add even more context).
During my fieldwork and the design sessions described above I saw evidence of items being used for multiple contexts; a photo might be used in the annual report or put on the wall and a receipt may be used to provide evidence of a spend or evidence of work having been performed for a specific project. For this reason the ability to add a single item to multiple scrapbooks was added. Technically this provided the benefit of being able to add the tagsets of multiple collections onto a single item. I checked whether this made sense to Patchwork who agreed that it did although Sonia did query how it would work (“So I can move it to another one later?”) and I needed to explain that an item could be added to as many scrapbooks as one wanted at once.
To support staff differentiating between their scrapbooks I added the ability to choose a colour for the scrapbooks which would be rendered visually within the app (Figure 5.3). Not wanting to worry about which colour palette to choose I implemented a custom colour selector, although later when it came to evaluating the app there was feedback that the palette should have been more limited: “I found it hard to choose what colours to have, and it was hard to pick the same colour twice” (Andi).
The format for tags also required several iterations and design decisions. The initial sketches of the app gave the format of hashtags since I had checked this with the team beforehand and they were familiar with the concept. Initial design sketches also contained the provision for Twitter-like handles which could be used to reference individual people or workers where appropriate (e.g. @dean) which can be seen in Figure 5.2. Conceptually I envisioned these being treat the same way as regular tags except with separate semantics, but when I asked Dean and Andi about them they were confused as none of the team used Twitter or other sites where the “@-handle” syntax was used. Initial versions of the app also enforced the hashtag rules of “no spaces” (Doctor, 2012) in tags despite QA’s flexibility around tag syntax to try and leverage Patchwork’s familiarity with the concept. During later stages, however, Andi and Dean (by far the most engaged in the testing) expressed a frustration at this, and OPC has also fed back that they’d like to use multi-word tags. As a result the app was adjusted to allow this, alongside an interface change to make it easier to enter the tags.
The original interface for entering tags was a minimalist, proof-of-concept, field was used which allowed free-text entry and parsed tags as separated by commas. This remained in place until much later when I had asked each Patchwork and OPC to use the app across the space of a week. Feedback was that it was difficult to add tags easily as remembering to type a comma was difficult. Patchwork also noted that a small typo could result in using a different tag. I then implemented a slightly different interface with an auto-suggest box and list of tags which was populated one by one (Figure 5.4). Both charities reported that this was much easier to use following implementation.
Adding entries to a collection was done via the interface used for creating an entry and didn’t require any modifications after its initial development. When creating an entry a button labelled Choose Scrapbooks brought up a checklist of scrapbooks which the staff member could use to add the entry to multiple scrapbooks.
Accounting Scrapbook provided the facility to capture several discrete types of entry which were called ‘Scraps’ colloquially and in-keeping with the scrapbooking metaphor:
These types of entry were produced to mirror the components of the QA data standard (described above) as well as Patchwork’s work practice. Initial sketches of the interface did not differentiate between adding different types of entry and supported building it up iteratively but conversations with Patchwork indicated that would not be as intuitive as, to them, it seemed to contradict the goal of having a large number of items rather than a fewer, richer, entries. To address this I took post-its which each represented the different fields of the QA model that we had outlined several weeks before and sat down with Dean to start combining them in various ways to see if different combinations “made sense”. The exercise only lasted 20 minutes before Dean needed to make time for a drop-in but resulted in the four discrete types of entry that made it into the application. A rejected combination using fields for an Image and a Quote was nearly included as a fifth type but Dean changed his mind at the last minute saying that Patchwork collected quotes separately to images at times, and having too many types of entry would “confuse [Andi and Mick]”. Another key outcome of this exercise was that I managed to confirm my analysis that the staff did not want to manage income on the app as accounting for that was much less distributed and mundane. As such the application only has provision for spending. Internally, the application’s database does not differentiate between types of entry and instead stores all entries as a single class and displaying the different types of entry by checking a variable; this was to reduce overhead if the need for a new type of entry emerged from early deployments.
Adding entries is performed by selecting one of the options on the main menu of the application. Each of these takes a worker to a screen set up to gather this information (Figure 5.6), add tags to an entry, and add it to one or more scrapbooks.
While Add a Quote and Add a Spend screens were designed and implemented without any fanfare or excitement from the staff, the Add an Image section was one of the key areas Andi fed into the design of the app although this was after an initial deployment. My early sketches and the early versions of the application envisioned that staff members would take photographs using the app and tag them as they go. As noted during an earlier section; during an early evaluation of the application Andi contributed she found it would be easier if she could add multiple photographs at once. I agreed to change the interface to support this (which also involved a change to the QA model) while retaining the camera feature. Later that day I observed Andi taking many pictures at once during a play session and when she drove me home later in the evening she was reviewing them as I entered the car. I asked her whether she checked the pictures before sending them to Facebook and she replied that she did. Finally I asked whether it’d be easier for her if the app opened up her gallery to choose existing photos rather than take them to which Andi said that it “probably would”. These changes were implemented for the next iteration.
Similarly Add an Event required reviewing during an early evaluation stage. The interaction on this screen was actually fairly effective; staff could open a map which allowed them to choose the location for the activity using their phone’s native maps interface however staff were confused around term Events. This hadn’t come up during initial sketching and conversations to this point because critically they understood what the screen did and the interaction around it but what Patchwork called Events and what I had envisioned as Events were different things. I noticed this when, during an early evaluation, it was clear that none of the staff had collected any Event entries in the app and asked about it. Andi looked confused and said that “We haven’t had any events this week though” so I enquired about what they’d been up to and it became clear that they didn’t conceive of their group sessions, drop-ins, and mundane performance of work as “Events”. Feeling embarrassed, I asked what they thought of as events and Dean responded with “The AGM, the activity day down the play centre in the summer, stuff like that”. Searching for a term to bridge the gap I asked the group what they’d call their work activities to which Dean, taking the lead in this exercise, said “Just… activities!”. The rest of Patchwork nodded silently in agreement. As OPC were also involved at this stage (following design, and in initial evaluation) I checked this with them and they agreed that Activities was a better word.
As part of the system architecture required the transmission of data it was necessary to discern a way which would feel quick and simple for Patchwork to do this. Patchwork, as I expected, were less enthusiastic about this aspect of the app because it felt to them like it was my job to come up with something they could use.
My address of this was to include the ability to “share” scrapbooks with web services. Nicholas John writes that the act of “sharing” has become a key characteristic of participating in the social web (John, 2013). Sharing in this context is the act of contributing new resources (e.g. user-uploaded photos, statuses etc) or using one’s space on a channel to further distribute the content of others e.g. a re-tweet on Twitter (Yang et al., 2010; Starbird & Palen, 2010; Nations, 2021). It is often presented as a feature in social media apps, and phones can have a “share menu” where users may share content from one application to or via another. Sharing scrapbooks of information thus fit with contemporary web and mobile design languages and leveraged an understanding that Patchwork would already understand, especially Andi and Dean. This was checked with them early on.
I knew that there needed to be a way of adding and managing endpoints for an arbitrary number of services because Accounting Scrapbook was not designed to be tightly coupled with another service. Thus to share a scrapbook there needed to be a way of adding a place to “share it with”. A screen was added under the title “Manage Sharing Services” which would allow anyone using the app to connect it with the web service later. Originally this was done purely manually through typing out a URL as well as a “token” to facilitate identification (ie so that the receiving end could identify who was sending the data and assign it appropriately). The reason for this was expedience; Patchwork and myself had been designing the screens for the app for several weeks and it was harder to enthuse the team about this. At later stages when we were designing Rosemary Accounts I demonstrated connecting Accounting Scrapbook to the website. Andi and Sonia said it was confusing to type in the token and while Dean understood the process said it could be awkward to do it many times. A brief brainstorm resulted in a new feature to both Accounting Scrapbook and Rosemary Accounts which could be used to swiftly connect to services using a QR code and scanning using the Accounting Scrapbook application. Since some theoretical future web services may not require tokens to connect; I made this field optional and added a small icon to indicate that a token was present (Figure 5.7).
Sharing is performed by then accessing the Share screen (Figure 5.8) on the main menu. Staff could select scrapbooks using a checkbox interface and then individual Share buttons were presented alongside a list of endpoints however in this research only a Rosemary Accounts endpoint was ever added. After pressing a Share button the application would begin the sharing process outlined in the QA transmission protocol and share media items (images in this case) and QA entries as JSON. A pop-up on the app indicated progress as well as notified of any errors.
To support the staff using the application and not duplicate their work early versions of Accounting Scrapbook also included the functionality to generate a short spending report in .csv format. This report consisted of a basic export of all of the Scraps with spending data with description, amount, date, and tags. The .csv file would be generated and saved to their phone. The reason for this is that if they committed to using the application in lieu of regular receipt practices it would provide a way to quickly “import” the spending data captured in the app directly into their existing spreadsheet. This was effectively a safety net so that if Patchwork had collected a large amount of data it would not be lost if deployments did not go well.
Initial evaluation and discussions following this indicated that, contrary to my estimation that it would provide reassurance, this feature actually introduced ambiguity into the use of the app. The workflow so far was established by analysing how receipts were collected and processed (Figure 4.3) and building on these. In effect Accounting Scrapbook was trying to provide ways to make the Acquisition phase easier by facilitating the transmission of spending data. The ability to generate a short budget report file broke this established work practice by introducing a new potential job of work that didn’t fit the organisation. For this reason it was removed as a feature.
This section briefly outlines the technical implemenation details of the Accounting Scrapbook application.
Accounting Scrapbook was designed and build as a mobile application targetting the Android platform (Google, 2021). It was build natively for Android using the Android SDK tools provided by Android. Android was targetted as a platform for practical reasons: most of Patchwork staff had Android phones, and those that did not could be provided with phones owned by Open Lab; I owned an Android phone myself for testing and debugging initial versions of the application; and I did not possess a Macintosh machine which was required to develop an iOS version of the software. At the time of development, the latest version of Android was Android 7.0, so the development tools were configured to target this version of the platform as well as several versions prior to account for older versions of the system that my participants used.
A key external library that was used in the development of Accounting Scrapbook Realm (Realm.io, 2021), a persistance library that promised greater efficiency and ease of development compared with the native Android database tools. This was used to model the classes for the Collections, Tags, and Items.
My own Android phone does not include key featues provided by Google5 such as Google Maps, and therefore I was aware that I needed to develop a method of allowing the user to select their location from a map even if Google Maps was not installed. This was to account for my own ability to debug the application, but also I felt increased the application’s attractiveness to the broader Open Source community and would permit the application to be distributed on app stores such as F-Droid (F-Droig.org, 2021) following the research. To effect this I built a lightweight location chooser using resources from OpenStreetMap (OpenStreetMap, 2021). In practice, Accounting Scrapbook checks whether the user’s phone has Google Maps installed and prefers it if present. This is because during this research I was more likely to encounter participants who were using Google Maps. If Google Maps is not found, then the app opens up the lightweight location chooser instead.
In a similar vein, a technical challenge that I was presented with during the development of the application was how to support the capturing of QR codes for users. This was because there was a potential that not every user’s camera would support parsing QR codes and returning the result. This was achieved by integrating a QR capture library (Owen, 2022) into the application which is called regardless of the user’s own device.
The source code for Accounting Scrapbook is available online6.
I now turn to the design and implementation of the final component of the design used in this research, Rosemary Accounts.
Once Accounting Scrapbook was in a place where it looked like it may be an effective way of allowing workers to collect data my attention started to turn to designing a place for this data to go. From my fieldwork working with Patchwork’s spreadsheet and observing Andi selecting photographs to share I knew that there needed to be some process of curating the accounts before they’re presented to stakeholders. Like with Accounting Scrapbook, the initial stages of design were the result of brainstorming activities either by myself or with Patchwork staff where available. Unlike with Accounting Scrapbook the staff who were most engaged with this process (Andi and Dean) were not those who I envisioned would be directly using the system (Mick and Lynne) due to Lynne’s limited time at the office and requirement to focus on her work at hand. This meant that I had to rely more on both my own understanding of the setting from my fieldwork, as well as the other staff’s natural reflexivity as members. In short; because Andi and Dean had a broad understanding of Lynne’s work and how she performed it I could rely on their accounts for some degree of insight to inform design in matters where my fieldnotes were sparser.
The result of the exercise was a web application called Rosemary Accounts, which was designed overall to superficially imitate the trappings of a professional accounting system such as Sage accounts (Sage UK, 2021) to facilitate the curation of financial data (activities such as reconciling transactions and managing income). A web application was chosen as the implementation technology for this for several reasons: firstly, the scalability of a web application meant that I did not need to be concerned about installing the application across participant machines and that updates could be issued easily; secondly, it provided a central point to collect information during the study. This meant that during evaluation, it would be easy for other stakeholders to find and evaluate the information that my participants had collected.
An additional design concern for the system to address was the social elements of Transparency noted in Chapter 04 such as the creation of contexts to present to others. This meant that I needed a way to explore both: the interface requirements to support Patchwork (and other organisations) in curating the datasets; and interfaces for presenting these contexts to others. Therefore there were two main functions or “facets” to the application:
When questioned about the purpose of this “website” by Patchwork I explained Rosemary’s as “Sage Accounts and Facebook mixed together. But hopefully not rubbish”. Dean raised his eyebrows and nodded, Andi seemed disinterested, and Mick replied “alright then.”. Core features central to the QA data standard were also carried over such as the presence of tags and support for the different fields outlined in the schema.
The name Rosemary Accounts was derived from an in-joke between myself and Mick at the beginning of designing this application. I said we should be looking to do “one better” than Sage Accounts (the de-facto standard that Mick was standing in defiance of) and he replied “What’s one better than Sage? Like Parsley, Sage, Rosemary, and Thyme?” in reference to the folk ballad Scarborough Fair (Wikipedia, 2021). We chose Rosemary as the item that came immediately after Sage thus accomplishing our goal of “doing one better”7.
Design and development on Rosemary began near the end of January 2017 and progressed slowly, taking several months. Patchwork were the ones mostly involved in the design process early on but I noted a lack of interests compared to other engagements particularly Accounting Scrapbook. My interpretation of the reasons for this is that Andi and Dean, by far the most enthusiastic participants in giving me feedback, were not going to directly use this system so it was not central to their work practice. As noted, Lynne was harder to get hold of due to limited hours so my interactions with her were more limited although I did manage to use our sessions curating the spreadsheet to ask pointed questions and show her screens or sketches. She did proffer feedback but I often left the field site that my academically-informed grand visions of participatory design were not manifesting as planned. Thus I was left to rely on the requirements set out by my field notes and the brief reviews of sketches and interfaces that I could wrangle from Mick or Lynne.
In May 2017 I was building up to a trial deployment of Rosemary Accounts and I met the CEO of Community Project Gateshead who expressed interest in participating (noted in Section 5.3 of this chapter). Before deploying the system I had several meetings with them and OPC to demonstrate Rosemary and Accounting Scrapbook and solicit feedback. They raised important design issues that had not come about from my interactions with Patchwork that affected a key interaction on the public-facing portion of the site. This needed to be adjusted before deployment and I discuss the design rationale behind this in Section 5.9.4.5
I now turn my attention to describing the features and interactions that Rosemary Accounts supports.
Managing income is a key part of financial data in charities that was still left unaddressed by Accounting Scrapbook. In Patchwork’s spreadsheet there is a tab for managing income streams from grants, and with the Play Centre (Patchy 2) being hired out to groups it made sense to try and accommodate potential income from this as well. To begin the design process for this I signed up to a free trial of the web based version of Sage accounts to understand the design features of the interfaces. Lynne and I spent half an hour together understanding which features would be useful and I later sketched some ideas out. After sense-checking these findings with Mick and Lynne where possible I began implementing them.
From these chats with Lynne and my previous fieldwork it became clear that the core requirements of the interface were to: keep track of where income is coming from and whether it constitutes a “funding pot”; or whether it is in “unrestricted funds” for a charity. Initially I thought to explicitly establish funding pots to make it easier to tie expenditure back to each. However Mick and Lynne reminded me that, generally, a single grant constitutes a pot and that most of their unrestricted funds would be coming from the Play centre so it might be unnecessary and would create an extra administration burden that Lynne needed to manage. My fieldnotes confirmed that a spend is retroactively applied to a grant by Patchwork rather than through creating a specific interaction around pots.
To address this I made it so that Rosemary Accounts supported the creation and management of Customers and Funders, and added screens to Add Income which would create QA data entries for incoming money. Importantly; the system distinguished Customers and Funders as any incoming money associated with a Funder would be classed as a grant whereas income from a Customer would have the income totalled as unrestricted funds. This was grounded in the fieldwork as Patchwork were noted to be hiring out the Play Centre building, and as such the design needed to accommodate this. This also had the benefit of the system being able to infer a particular level of unrestricted funds; as all income derived from “Customers” would be unrestricted.
When adding income (Figure 5.10) Rosemary enforced that it should be associated with a Customer or Funder in order to minimise additional work later. The system retrieves a list of all Customers and Funders and requests that income is associated with one.