So today im going to talk about designing in GLAM, by telling you about my experience designing in the national trust. Which I have illustrated with this can of treacle. And this is because one of my national trust supervisors described trying to basically get anything done in the trust as swimming through treacle. And it feels like it encapsulates my experience of designing in the trust.
//
To give you an idea of what I mean. I’ll show you my initial project plan I made right at the beginning of my phd.
So quick bit of CONTEXT my phd was developed off the back of the final project I did for my masters in multidisciplinary innovation. The task for the project was create an oral history project at Seaton Delaval hall and one of our conclusions was this archiving of oral history thing, you could make a phd out of it. And so we did. And I was going to look at creating something that specifically allow visitors to reuse oral histories on heritage sites. So in my mind this was likely to be some kind of sexy software that would just be so sleek and amazing that all oral histories problems would be solved. And this was my original plan on how I was going to do this is this. Now pretty much everything about this is wrong. Firstly because it is three years instead of four years, it does not include any of the placements I did. But also the entire process just did not or could not happen.
[UNPACK PROJECT PLAN]
I did realise that the usual iterative testing process is just not really possible because but I could never properly test them.
The only example I can give of iterative testing is with my own archive. But this has nothing to do with the working with GLAM bit.
I did give prototyping a try and although I did not test them.
However I thought the lack of testing told me a lot about the design environment.
I could not test the ghost boxes because they did not know what material to give me to test this with nor did they have the space for it, and most importantly they did not want to make any promises. The sound box could not be tested bc you are not allowed to have external tech in Nt and what oral history was I going to possibly use. The transcription ribbon was also one that could not tested because what laptop would that work on. So the lack of testing was not a complete failure in the end.
But I still need a new approach which I found after I looked at previous attempts at making oral histories more reusable. There have been a collection of attempts to make oral history more reusable. And most of them have failed ish. It is weirdly hard to do research into this because people did not really write a lot about when things failed. They publish papers on the super new tech and then they just disappear. Luckily there is one book that does talk about some failures. Boyd quote, VOAHA and stories matter
These all failed because people did not think about the maintenance of the work. And if we look at my prototypes you see the same issue. What these prototypes told me and the various attempts at making oral history more reusable. Was that it is not about what you make but about how you maintain it.
Which is how I get to Mierle Laderman Ukeles. Is a maintenance artist. She wrote a manifesto for maintenance art. Where she wrote the line “after the revolution who’s going to pick up the garbage Monday morning? I remember seeing her work during my time in art school and absolutely loving at the time but I had forgotten about it until it was mentioned by The British Library oral history archivist Charlie Morgan, who used this quote in a blog post about all the recordings that were made during the pandemic and how someone is going to have to archive these someone is going to have the clean up after the revolution.
So from this I wrote a manifesto for maintenance design, which I had totally forgotten I had written. So ukeles spilts the world into two systems in her manifesto the development system and the maintenance system, which she labels the death instinct and the life instinct. In terms of maintenance design I have put under the death instinct is that this is about drive by collaboration and the life instinct is simply life goes on. The designer is only a visitor to this space.
– labour
– limited resources (which also basically include labour. And I. Think that is also why I connected it to earth maintenance and looking after the planet)
So I decided to work through the lens of maintenance. but maintenance as a thing is really annoying because it is really hard to see if you are not part of it. IF you look t people who write about maintenance or infrastructure like Susan Leigh star a recurring theme is that you cannot see the value of maintenance until it breaks down. So my idea was that I would probably have to get very close to the situation in order to try and understand and map out the maintenance in these heritage sites, archives and look at how oral history needs to be maintained.
And this is how we get to Action research as a design strategy but while action research is normally the researcher going in and working with the stakeholders, but really what I did was work for the stakeholders. I literally went in and was like what do you want me to do. I have these skills how would like to use them. And so they would give me a task to do and then I would bring it back to them for feedback and they would yes no no no no yes maybe, not yet. In the reflective practitioner Schon compares being a reflective practitioner to what jazz musicians do, as they make it up and go with the flow. And that is very much what I had to do because no one tells what you need to know, either because they do not know or more often they simply do not have the time. I could have rocked up with my cute little sound box, they could not care less. They are thinking about the car park and whether the cafe has enough stock. You know how I found out the issues of IT at the national trust, my lovely supervisor was like you are tech could you sort this out and it was a nightmare. I then told the IT guy and he was like I’m gong to pretend I did not here you say that. You have to think on your feet the entire time and by working with or for them you can start building a better idea of the space you are designing in.
So action research was my strategy and under that came all these different case studies I was able bc my funding body is like go do placements. So what did I actually learn on these placements, well firstly my phd was going to be super unsexy.
– Seaton Delaval Hall:
research room design:
leaving room for change:
working with maintenance, leaving room for the stakeholders to make their own changes. It is about setting up a framework.
– NCBS: policy development: takedown policy and sensitivity check doc: have to really thorough think about what we mean by archiving: understand what GLAM does
– bl: audits: what can history tell us: working with change
So I learnt some good things while on these placements
– working with maintenance is allowing room for the existing structure to absorb your work by offering a framework not dictating a single solution.
– what GLAM does. It collects people’s property and thats complicated
– things changes and this effects how we maintain. So although I am focused on maintenance I also recognise that maintenance has to move with the times otherwise it breakdowns down and we working to restore not maintain.
But what do I say if someone comes up to me and is like “how do I design in GLAM?” How do I swim through the treacle?
Well I can tell you what GLAM does.
1. It collects peoples stuff. It collects people’s property. It might be something they own or something they made. and there are laws, ethics, and cultural customs that are around this you cannot forget. Also they might change and vary between countries.
It does two things with this stuff. It keep it and it curates it. how long something is kept can vary from whenever an exhibition is finished to forever either way however long it is kept it must be maintain and safe. How it curates it is also deeply political and never truly objective.
So if this is the why and what. The how is creating the balance between creation/collection/development and maintenance. Or more simply said Change and stability.
First It is about spreading the resources you have other these two spaces. NCBS
And the second is to one big ol’ theory of change or risk assessment.
The Methodology Bit – Version One (very bad draft)
The above graphic was my initial project timeline. To say this is not how the project eventually played out would be an understatement. Both the initial chosen design methods and what I was intending on designing turned out to be highly inappropriate for the situation I was designing for. The central aim of my project was to develop a solution to encourage the reuse of oral history recordings, a problem infamously dubbed “the deep dark secret” of oral history (Frisch, 2008, p. 00). I was specifically looking at how to solve this deep dark secret with public history institutions, museums, heritage sites etc. My case study was the National Trust property Seaton Delaval Hall just north of Newcastle. I assumed I would make some kind of software or product to help ‘solve’ this issue, which would involve creating a prototype and then testing it out. However, within the first year it became apparent my plan was not going to work for two reasons. Firstly, my testing ground, Seaton Delaval Hall and National Trust were very risk adverse. The structure of the property and the National Trust in general is not a space where radical change or experimentation can happen easily, stability is key. Secondly, after researching the previous attempts of trying to solve the problem of oral history reuse, I realised me creating a new product was not going to work. There was something more fundamental that was being overlooked – maintenance.
Although there is little written on how certain attempts failed, what was written nearly always referenced how after the project money ran out the software or website fell apart (Gluck, 2014; Boyd, 2014, p. 9). This issue of oral history reuse is not about snazzy interfaces but about maintenance, politics, and wider complexities of institutions. Therefore, maintenance became the lens through which I did my project, specifically the way the performance artist Mierle Laderman Ukeles describes maintenance in her Manifesto for Maintenance Art 1969!. For Ukeles maintenance is: deeply undervalued in society; consist of many interconnecting boring tasks; and cannot afford to radically change (Ukeles, 1969). All three of these properties, but especially the latter two, led me to seek a methodology which could handle complex issues and be sensitive to the environment it is designing in, as I mentioned before the National Trust and the hall were risk adverse. I landed on Research through Design, a relativity young design methodology where the focus is not the creation of a product but creating new knowledge by using design methods (Stappers and Giaccardi, 2017). In my particular case this new knowledge would create a better understanding of how oral history recordings are/can/should be maintained. This in turn might lead to the development of more appropriate solutions to the deep dark secret of oral history.
I will unpack the concept of Research through Design or RtD and how it functions within the context of my project. Since the field of design is broad and there are the various interpretations of RtD, I will focus on the use and understanding of RtD within the field of Human Computer Interaction or HCI and Interaction design or IxD. HCI and IxD handle information technology and my work addresses the management of archive material, which is a form of information. Therefore, borrowing from HCI and IxD feels appropriate because their main purpose is to understand and design for the relationship between humans and their technology, which within my project can vary from analogue archive index cards to online catalogues systems. I will explain how RtD is explicitly suitable for researching and understanding maintenance systems, through its use of simultaneous problem and solution development, which originates from Rittel and Webber’s concept of ‘the wicked problem’. Following this I will focus in on what design methods I used as part of my research to generate knowledge. I will also explain how this knowledge and research is then presented in a way to demonstrate rigour.
Understanding RtD
RtD is a relatively young concept and it currently does not have a fixed methodology, which seen by some as a positive and some as a negative (Gaver, 2012). Although there is no strict definition of RtD there is consensus that, firstly, RtD as a method is excellent at handling complex problems, and secondly, the goal of RtD is to produce knowledge (Zimmerman et al., 2010, p. 311; Stappers and Giaccardi, 2017). The former is helpful to me because I am looking at the maintenance of oral history recordings in public history institutions. The latter is helpful because I was unable to do any thorough testing of prototypes as was originally planned, instead I will create knowledge which can help individual public history institutions understand and handle their own versions of the oral history reuse issue. To start with let us investigate the how RtD helps us understand maintenance infrastructures, and then move to looking at how creating knowledge is more appropriate for tackling this issue.
Wicked problems
RtD, like many other methodologies in design is focused around solving complex or ‘wicked’ problems. The term ‘wicked problem’ comes from the paper, Dilemmas in a General Theory of Planning, by Horst Rittel and Melvin Webber. The origins of the wicked problem come from the 1960s where designer shifted from exclusively thinking about the product they were designing to thinking about the systems around the products and the wider systems of our society. These systems of our society were becoming increasingly complicated due to the rise of more complex technologies, and increased awareness of societal inequalities and the emergence of Post-structuralism, which challenged the idea problems could be defined in an objective manner (Bayazit, 2004, p. 17; Rittel and Webber, 1973, p. 156). What became apparent was how the Newtonian and more scientific problem-solving methods and theories used in the early half of the Twentieth Century could no longer handle the complexity of the post World War Two problems (Rittel and Webber, 1973). The types of problem which could be solved using this method, where a problem is easily defined, and solutions either fail or succeed, Rittel and Webber refer to as “tame” or “benign” problems. And the complex problems appearing in the latter half of the Twentieth century are referred to as “wicked problems”. Wicked Problems are societal problems involving multiple stakeholders and are of a complete opposite nature to benign problem. They are extremely difficult, if not impossible, to define and there is no correct solution, only ‘better’ or ‘not bad’ solutions (Rittel and Webber, 1973).
Through their explanation of the properties of wicked problems Rittel and Webber do give a simple structure to the ‘solving’ of wicked problems – simultaneous problem and solution(s) development. This has become the basis of much of design research in the last fifty years including RtD. The idea of passing between the editing of the problem definition and creating solutions is a way to continually challenge the underlying assumptions made during the initial formulation of the problem (Zimmerman, et al. 2007, p. 495). In order to understand why the wicked problem, simultaneous problem and solution development, and the continuous challenging of assumptions is helpful in the context of reusing oral history recordings within public history institutions, you need to understand the nature of maintenance.
The invisible web
In Ukeles’ manifesto there is the line: “Maintenance is a drag: it takes all the fucking time (lit.) The mind boggles and chafes at the boredom” (Ukeles, 1969). Maintenance and how it works is boring. The sociologist Susan Leigh Star makes a call for the study of boring things in her paper the Ethnography of Infrastructure, and although Star does not directly use the word ‘maintenance’ in her work, her idea of infrastructures has been used to better understand and unpack maintenance (Graham and Thrift, 2007). There are several of Star’s infrastructure properties which can help to understand maintenance infrastructures, such as:
“Embeddedness” – Small maintenance infrastructures live within larger maintenance infrastructures (Star, 1999, p. 381). For examples, cleaners, janitors, and IT support are all part of a wider maintenance infrastructure of a building.
“Reach or scope” – As is written in Ukeles’ Manifesto for Maintenance Art 1969! “It takes all the fucking time.” Maintenance is not a one-off event, it goes on forever (Star, 1999, p. 381).
“Links with conventions of practice” – Those who work within an infrastructure will develop habits which are heavily influence by the technology they use. (Star, 1999, p. 381).
“Built on an installed base” and “Is fixed in modular increments, not all at once or globally”- The maintenance infrastructure did not appear overnight it was built bit by bit in reaction to changes in the community it is meant to support or the technology it uses (Star, 1999, p. 382). And as Ukeles says there is little room for change once it exists (Ukeles, 1969).
However, it is specifically the “invisible quality” of an infrastructure, where the idea of wicked problems and simultaneous problem and solution development come in.
A maintenance infrastructure is a wicked problem. It is a complicated web of interconnected elements which is slowly, yet consistently, evolving in order to hold off any collapse. It is made up of technology, people, and their actions or labour which stops breakdowns from happening (Graham and Thrift, 2007, p. 3). These three aspects can be invisible in one way or another. Technology becomes invisible because it is buried underground like pipes or is suspended high above our heads like telephone poles. People can be invisible because maintenance workers are made invisible by either the location or the time the work takes place. For example, domestic workers stay in private homes and commercial cleaners work outside opening hours (Star and Strauss, 1999, p. 16). Within the context of my project the technology and the people are both invisible because the majority of work happens inside the closed doors of a storage space or office. The work associated with the maintenance and keeping of historical items, like oral history recordings, has always been invisible, however, like everything else, it has only gotten more complicated with the rise of technology. Technology has, in a way, opened up the storage space through the creation of digital archives, but this has also buried all those who maintain historical material deeper behind screens and servers. Actions or work can also be invisible. This is often emotional labour or other forms of care. A nurse is a great example of such a worker, because their work with patients is often “taken-for-granted” due to its completely intangible nature (Star and Strauss, 1999, p. 15). Oral history also has elements of invisible emotional labour because it relies on living humans to tell their stories. In order to ‘extract’ these stories the oral historians have to make the interviewee feel comfortable, which often involves many cups of tea.
In addition to the three main elements of a maintenance infrastructure being invisible in one way or another the outcome and function of a maintenance infrastructure also somewhat invisible. The main aim of a maintenance infrastructure is to keep things from decaying (Graham and Thrift, 2007, p. 1). However, because the product of the labour is a lack of decay it is difficult to quantify since there is no measurable outcome, only the absence of something, making it invisible. Everything about a maintenance infrastructure, the technology, the people, the work, the outcome, can or is invisible. These various elements are invisible in different ways making it additionally complicated. To solve the issue of oral history reuse in public history institutions we need to understand and map its maintenance infrastructure. This maintenance infrastructure and how it comes together is a wicked problem and the mapping of this maintenance infrastructure is equivalent to defining the problem in simultaneous problem and solution development. But in order to map the maintenance infrastructure we need to make it visible. Luckily how one makes an invisible infrastructure visible is relatively simple — you break it.
“The normally invisible quality of working infrastructure becomes visible when it breaks: the server is down, the bridge washes out, there is a power blackout.” (Star, 1999, p. 382).
You can see this with the previous attempts of solving the oral history reuse issue. Those who have written about it state how the eventual collapse of the website or software revealed how much the systems relied on the maintenance of digital systems (Gluck, 2014; Boyd, 2014, p. 9). The breakdown of the solution developed by these projects revealed part of the maintenance infrastructure for their particular situations. However, the information was only discovered after the project was finished, therefore the information could not be fed back into problem development.
Breaking the maintenance infrastructure to gain information for simultaneous problem and solution development is not an option; the system must keep maintaining. This is one of the reasons why the National Trust and Seaton Delaval Hall were worried about me widely testing prototypes, they were apprehensive to anyone who might disturb the delicate equilibrium they have in place. As I mentioned in the introduction the National Trust’s aversion to risk and testing, and the history of attempts to solve the oral history reuse issue led me to move away from designing a product. This is where RtD becomes different to other forms of design methodologies which also used simultaneous problem and solution development, because instead of creating a product or some other form of full realise system, it creates knowledge.
Knowledge, not a product
To understand why RtD focuses on creating knowledge rather than a product and why this is helpful within the context of mapping maintenance infrastructures through simultaneous problem and solution development, we need to look at how knowledge is defined within the terms, ‘research’ and ‘design’. Generally, research and design have often been pitted against each other, as Stappers and Giaccardi show in this table in their chapter Research through Design.
Research
Design
Purpose
General Knowledge
Specific Knowledge
Result
Abstracted
Situated
Orientation
Long-term
Short-term
Outcome
Theory
Realization
Table 2.1 – In general, the terms ‘research’ and ‘design’ carry different connotations (Stappers and Giaccardi, 2017)
The definitions in the table above originate from the different types of ‘knowledge’ produced by academic and vocational forms of design education. Within the former, the ‘knowledge’ produced is in the form of research such as theories, frameworks, and matrixes, which can be used by others. The latter’s ‘knowledge’ comes in the shape of more tangible products for very specific situations (Glanville, 2018, p. 14; Stappers and Giaccardi, 2017). RtD sits somewhere in the middle where it produces knowledge which can be used by others but this is still grounded in the specifics of real-world application (Stappers and Giaccardi, 2017). According to Zimmerman et al. the outcomes of RtD can vary from new design theories, frameworks or philosophies to artefacts offering a possible new future, to tools to encourage wider discussion in the field (Zimmerman et al., 2010, p. 311). However, the goal overarching of RtD is to produce knowledge used to simulate conversations with interested parties about possible futures (Zimmerman et al., 2010, p. 311; Stappers and Giaccardi, 2017).
The knowledge created is purposefully ambiguous to make it more transferable to other situations and to allow it to be flexible when change does come. People are able to take the knowledge and interpret it for their own specific situation (Gaver et al., 2003). This recognises Rittel and Webber’s idea that a wicked problem is never truly solved, and each variation of the issue is completely unique (Rittel and Webber, 1973, p. 162, p. 164). Its ambiguity means it is removed from its specific situation and time; therefore it allows room for slow implementation, which is again essential to maintenance infrastructures because there is little room for radical change (Ukeles, 1969, p. 2). If a product was being created instead of knowledge this would not work. Creating a product is akin to the design description in the table above, specifically fixed in one location and time, this makes it difficult for others to replicate or use in anyway. Within the context of my work making something which does not need to be implemented immediately and can be used by other public history institutions is more suitable than making a product which cannot even be tested properly. By not having to do thorough testing of a product RtD can help avoid breaking the maintenance infrastructure. However, RtD still requires some form of simultaneous problem and solution development which by nature of the method would require some probing of the maintenance infrastructure. By using less invasive design methods in RtD you can navigate the delicate maintenance infrastructure and still do simultaneous problem and solution development.
The right to repair is important and connected to my work because like many things in the world it has to do with maintenance. I had a chat with O Hemstock from Northumbria University about slow design and he brought up that maintenance is about agency. It is about the right to repair and the power you have over the objects that make up your life. Having agency means that you can fix it when it is broken, you don’t need to rely on others to fix it for you and you are not forced to buy another. But it is also about the ability to customised and edit and make the object fit to your needs instead of the other way round. It is important to think about maintenance not only because of the planet but because of the effect objects have on people’s lives. For example you want a pan to be good but what if the person burns something in the pan, which they are likely to do because they are human. What do you as the producer of the pan do then? Sure technically the ownership of the pan has moved from one to another but what can you do to help the new owner with maintenance of the pan. Handy youtube videos on how to clean your pan or a cleaning service for example. Now I am aware that the pan scenerio is a bit of an odd one but thinking about maintenance is always a good thought exercise in design.
From conflict to catalyst: using critical conflict as a creative device in design-led innovation practice
by Nathan Alexander STERLING, Mark BAILEY, Nick SPENCER, Kate LAMPITT ADEY, Emmanouil CHATZAKIS, Joshua HORNBY
I read this on Mark’s recommendation because I was talking about the workshops I wanted to run and how I wanted to set them up in a way that allow there to be tensions that can then be explore creatively. So reading this paper was probably a sensible thing to do.
Diversity?
The piece features a project that brought together a “diverse” group of people to think of ways to solve the wicked problem of cyber-crime under teenagers. The “diversity” of the group is not expanded on beyond that it was several people who either were doing or had done the MDI masters, police officers, and a couple of members of the public. This does not really explain the diversity to me. I want know where these people came from, how digitally literate are they, what ages are they? None of this information is enclosed which makes it hard for me to fully imagine the diversity. For all I know the diversity lies in the participants different heights.
We need to show this information because then I can truly see the diversity rather then relying on people word, which is really hard since the idea of diversity is subjective and it is a word that is very much thrown about.
Get out of my shoes
The paper talks a lot about “deep empathy” which when I first learnt about it during my masters I was on board with, now I very much reject this idea. Why the sudden change of heart? Well, for me it started to become clear that terms like “deep empathy” is a gimmicky way to show the performance of diversity. Instead of actually employing a diverse group of people we bring diversity in for a workshop, get them to do a couple of exercises and then send them on their merry way. The paper does note that some participants thought that you could not really get a in depth and nuanced idea of someone’s point of view because of the time limit and the group setting.
I personally think that telling ourselves that we can fully understand where people are coming from in a short space of time is delusional and reductive. If I am being completely honest I do not think I will ever be able to understand the experience of a black man. A white man? Maybe. But only because of the cultural domination of white men. But a black man? No way. A person in a wheelchair? Nope. A transgender person? No. It is not because I do not try, but because I believe that one cannot communicate a human life through words alone.
“Deep empathy”, “active listening” etc. these can all work in an attempt to understand people, but we should not deluded ourselves that we can embody another person’s life experience. I think it’s really necessary to put an intersectional feminist lens over this, because it is a dangerous path to go down.
The DaDa way
Now here is something fun. The participants thought that by blowing up the creative tensions and making them very obvious people could better understand them and use them. They also wanted the view points to be a bit more than a line of text (news flash you cannot judge someone by their tweet). People wanted images, videos, animations. These were things they felt they could relate to better. This got me thinking about a discussion I had with Joe about a podcast, the Bodega Boys. The podcast is super strange to listen to but because everything is very absurd they can tackle difficult issue. In this podcast they create this strange but safe space. The absurdity makes the issues more approachable and digestible. This then got me thinking about DaDa and how they came to be in a time of a nonsensical war. We are kind of in a nonsensical time now, maybe we need Dada to create empathy.
I took part in a Createathon because it has been a while since I had done a design workshop and I wondered if I could still do it.
During the first day of the workshop I started to remember some of the painful aspect of doing design workshops. For example the time limit, in my opinion, dulls the creative process a bit, so you start thinking of easy wins instead of bigger pictures. There is was also a lot of rambling talking which was a little frustrating.
However…
In the end my group, which was a girl from Azerbaijan and a PhD student who had also work with Seaton Delaval Hall, delivered a pretty good presentation and we didn’t mention social media once! We had not really come up with super great ideas, instead we had kept it pretty open ended and offered the person whose business we were working with only a vague direction for the future. I personally thought that it wasn’t going to go down well but it really did. After we had explained the plans of actions and presented our Pecha Kucha, the client was super enthusiastic, because she suddenly saw her business in a different light. We told her her story but how we understood it and this process of multiple translations help her get an inspirational boost.
What I took away from the Createathon is that what I really want to do as a designer is not give someone a stack of clear cut ideas but a new way of thinking. I want this because that is far more sustainable in the long run and it is also harder to dismiss. You can throw away a stack of ideas but if I have incepted a new way of seeing the world into your brain that is hard to ignore.
I did a mini design sprint today. It was really fun to do something design-y after such a long time. It was about data and data collection. At the beginning the workshop lead showed us different data collection tools, including ‘My Activity’ page on my Google account. On this page I could see what they had been tracking but I also saw how I could turn them off or at least ‘pause’ them. This makes me think that they can unpause them at some point like how your bluetooth automatically switches on all the time.
During this mini design sprint we were challenged to design the app for Newcastle University, which is something I had already done for the university across the road during MDI. The end product my team came up with was a personalised data set report.
The main aim of the personalised data set report was to make the data less passive. We found that the way the data was presented in an example version of the app was flat and not very informative, so we wanted the information to be more personalised. The idea of having the data set report was because I asked the others if they would actually look at this information every day if they had access to it? The answer was no, they won’t look at it every day, but they might if one, it wasn’t constant and two, if it was personalised. So we made the personalised data set report.
This way the information can be condensed and the user can get a better overview of their data over a certain period of time, instead of being bombarded with information constantly. The second thing we did was make the data less passive by getting the user to respond to it. For example, the user could put in targets in response to the data set or they could tweak their recommendations to get the app to push for a different genre of event.
The lead was very happy with our idea.
My big problem with data collection is that one, it’s sneaky, two, it’s too much and three, I don’t have easy access to it. Basically you can boiling these three points down to one – data collection is not user friendly. Firstly, the user is often unaware of it because it is hidden in long ass terms and conditions. Secondly, the shear quantity of data mined off one person makes it impossible for that same person to look through it and digest it. And lastly, the user does not have access to it or at least the access is hidden and complicated. I need to read up on the freedom of information act…
I just realised this is the exact point that guy tried to make to Cambridge Analytica and Facebook in the Great Hack and real life obviously.
BTW did you know that there is an online library which you can log onto and sit in a virtual library? I need to know where to find it.
