PECE Story highlights?
Involved as an undergrad, wasn’t called PECE - 2012, the asthma files. In IT, engaging in different research projects. Eric working on building out asthma files on PLOAN - first exploring what it would look like for each instance not built on a separate platform. As they were looking to build that out, wanted to see it used for Disaster STS network - how to extrapolate a common structure for ethnographic projects that could be more widely shared?
Got started with the team, small background in interface design, more in thinking about data structuring and content organization. Applied to grad schools, stayed at RPI, remained in the project and reimagining what this could look like as a standalone platform.
When we decided to move platform into Drupal - PLOAN was very folder oriented, architecturally didn’t make sense because wanted to break out of codified structures and content organization. Drupal more conducive to that. Didn’t demand so much out of static foldering / organization.
Hired someone to build out things in PLOAN, few, expensive. Limited in what they were able to do on PLOAN - second reason for moving to Drupal.
In Drupal, building each platform (Disaster STS, Asthma files) on an individual basis. Happening “through the web” - functions to build out interfaces directly so no back-end coding experience needed (like wordpress). More grant money to hire developers to build standalone platform that could be downloaded and uploaded for all the interfaces. Lindsay designing the TTW interfaces, applying same layout to each individual site. With developers, able to completely move away from all of that. Lindsay shifted to doing more of a project management role.
What is PECE able to do now?
Working as a space for a personal archive - different community members able to build out / have a space to store different data for their own projects. Works for that, but it’s an open question if people can find those things. Working as a space for building out collections of material and collaboratively analyzing material. “Collaborative hermeneutics” - PECE facilitates idea of collaborating around an interpretive practice. Hasn’t really been formalized before through a digital system. Makes PECE really different from other systems (e.g. coding systems individualized deep dives, versus shared high-level meaning / cultural import)
Also working well in building out curated spaces. Hope is that it will be “cleaned up” - dissertation is characterizing differences between AI “neats” and “scruffies” - singular set of logics v. experimental and deviance. As it’s grown out and collaborative spaces have grown, people want to be able to find their things - that has been a key part of the collaborative practice - coming together to find things in a common way. Aims are to better support resource discovery, talk across different systems, thinking beyond the scope of individual ethnographic projects.
Cleaned up: Primarily referring to enabling discovery more readily. 1. Discover page - main repository for where things get dumped - not necessarily easiest space to find things in the system. Hoping that space will become a space that’s not so broad - a bit more structure for different ways into the material. It’s too open right now. Different ways of visualizing? More than that, there needs to be more standardization of the interfaces across the different pages. When you get to a group page, expect that it will look like this, have these materials, similar to the way the project page is set up. Same with dashboard - will expect to find things because it’s similar to the way other pages are set up. Standard interfaces so that people know what to expect when they’re going to look for content.
Primary aim is to be “generator of surprises” - finding material you didn’t even know you were looking for. Definitely don’t want to lose that, because it’s critical. At the same time, as communities get involved, gotten a lot of feedback from communities who don’t know how to find the things they want to find. How do you walk the balance between finding things you know you’re looking for while also being able to constantly be surprised at things you didn’t know you were looking for.
When starting, these are the logics and the user has to adopt our logics. Characterizing the community we’re working with as “experimental ethnography” - specific theoretical assumptions that are baked in. Early on, open questions as to whether or not other communities edit the design logics - no, they’re coming in to this space that has been designed with these theoretical assumptions baked in. They’re coming in to a generator of surprise space.
The thing that makes this tricky is that when we were originally conceptualizing it, it was as a space that was hosting experimental ethnographic projects. Analysis at the forefront, collaborative archives. When STS infrastructures came on, the logics of preservation became more prominent. As it became more of a gallery space v. research and analysis, the movement toward presenting (and have that be legitimized as a scholarly output / something that people could get credit for) - those experimental components that were so important to the research and archival space, those things were being challenged.
Originally, very firm in the idea that they’re subject to these design logics. But now that it’s more of a presentation space, more of a need to push up against the experimental components.
As a user, can go in wanting to do something, but you should expect to be surprised - because that’s part of the design logic. Some people building it out for publishing think it’s too surprising - that’s what it’s designed for. Can be a hard balance to strike.
Redesign workflows in essay page - ethnographic projects are never done. The whole idea of publishing and having it be “stable” is something that PECE is trying to pushed up against while it’s still legitimized and credentialed. Rethinking publication workflow - at some point, you could hit a button that is a timestamped version that will not be edited - stable, can be cited - basically creates a copy of the essay at that moment and that’s the stable version. The original copy can still be evolving and editable. That work in progress peace won’t be cited, but the new stable copy will be something that can potentially be a published product. Would love to see it happen, one way of thinking through some of this. Another area for what needs to be cleaned up - because things are evolving so much, we’re giving things citations - not really accounting for the ways in which that content is constantly evolving. When we’re referring to that thing, we’re referring to something that is unstable (believes in this theoretically). At the same time, in terms of data management - can never get back to that “original” thing. One of the key challenges of something that we need to clean up. How to timestamp, revisions that we can turn back to, ensure that if it’s cited in one place / associated with a group but the next day it’s removed, tracking the ways in which its changing and its references are changing.
How are people coming to PECE and how do you see that moving forward?
Kim’s work / those platforms have been the most successful because they have a ton of style guides that exist external to the platform that make the system work. “Free agents” come in and make their first PECE essay and it’s all over the place - no template for understanding where to put things. Part of that is a learning experience and people are moving forward. At the same time, the things produced with style guides are getting traction, being cited, etc. There is an element of infrastructuring that’s happening to facilitate groups in order to advance the platform. Thought the platform would speak for itself, but seeing the ways the style guides and protocols has been supportive of groups has been an interesting finding. Unsure if that’s what she hopes will continue - “the system will work best if you develop style guides” - think of other systems like Omeka, basic infrastructure and the community decides how to build it out. Should PECE build that, or more infrastructure so that people can more readily jump in?
If someone wants to start their own instance of PECE, they’re designing it themselves. Thought of a separate page in the user docs specifically for “tips for getting your project off the ground.” Style guides, image sliders, infrastructures happening external to the platform to help them get started in their thinking.
You can pull people on to an instance of PECE and they need to be onboarded to that, but people are creating new instances of PECE which is a whole new onboarding startup process. Bryan takes care of sysadmin, so many more things, user feedback and questions. Does the front page have to look like this? Technically no, but… What sorts of role the design team should be playing moving forward? Typically three new instances per year, the design team needs to be cordoned to deal with that.
Onboarding process for different kinds of users:
Platform: Before we had any form of documentation, man was it a process. Individually approve, even now, site admin needs to approve new memberships. For the 3-4 main instances, core group that gets an email when anyone requests new membership. Someone needs to go in to approve it. Each instance has its own managers. That’s the first step. Gone through different iterations of how to deal with questions - before documentation, Lindsay getting several questions a day. Not sustainable. Really important to build out user documentation - getting two months where Lindsay tried to get that content - “Pece Bible.” Now all in GitHub - questioning has gone down a lot, which is great. Not archiving questions or labor involved in answering those questions, so needs to be in a space where that’s being archived and becomes collective knowledge. Slack channel has helped, GitHub issue queue. People actually have to sign up for github to question.
Instances: Bryan takes care of admin stuff. Everyone is downloading and installing things on different servers. Every new instance is related to a server issue that we haven’t thought of.
Lots of questions up front, but Lindsay happy to help. If people want to customize, what sort of support do we give? They need to develop the skillset to navigate on their own - more than the PECE design team can offer. Haven’t gotten much feedback on that position, but it’s going to require so much more knowledge.
No feedback on documentation itself, not even sure if people are using it. PECE Bible, posed everything as a question, so this allowed people to search for their questions. Whenever getting a new question, responded to the question and put it in that document. Don’t know if it’s working or how people are using it, certain that they could be more detailed with screenshots etc. Other problem, the system is changing. Keeping up with documentation is a challenge. Lindsay wants to try and maintain this documentation but it’s a lot. Sysadmins, the documentation isn’t working, definitely needs to be built out.
Not a lot of engagement in the slack channel. Maybe once every few weeks. More user growth but fewer questions.
See the most new users when a class starts up, before 4S to start building up some curations. Sometimes a senior researcher signs up and lindsay goes to look to see what’s on the front page - how did they find out about us? Primarily, the bulk happens with rapid response and with classes / mandatory exhibit space that’s happening.
Lindsay’s pain points:
Dashboard - the worst space. Hates it. Never go there except to add something new because that’s where you add it. One area that would really like to be cleaned up to something useful - if people are going there to find their stuff and they can’t find it, what would it look like to redesign their space so they can find things? That’s not the space to generate surprises - maybe “did you remember you wrote this five years ago?” For the most part that needs to be where people go to find their own things.
Zotero - beast in PECE. Cleanup involved is huge. Zotero entries are divorced from what’s being imported into the platform, wants to be more integrated but that’s very hard. When the zotero module was designed, very excited - hired company to design the module. Superstars in drupal world - lots of things we wanted them to do. They produced more, anytime a website gets pulled into Zotero from PECE it automatically creates a website artifact. When that started happening, people drop Zotero websites 20x / day. 20 new artifacts every day that didn’t have an author, created date, etc. because it’s all being automated. “Ghost artifacts.” Multiple questions about all these new website artifacts that people don’t know where they came from. Concern, some people have asked for bulk uploads, but just want to make sure we’re thinking about what happens when we add things in a non-deliberate way and what that means for content organization of the system.
Structured analytics - how people structure their responses, navigate question sets. Different ways to visualize question sets? Some people really want nested questions - what does that look like to do without over-codifying / structuring the platform? A question is a tag in Drupal - taxonomy that gets attached to a response. How you can nest question sets as tags through nested hierarchies, if we were able to do that, some way that you can visualize all the different nestings of the questions and how they interlink with each other. Right now, they get lost. They go into this sea of responses and it’s so upsetting because that’s where the analytic work is happening. We want people to see it, but it’s been buried. Drawn out to the forefront.
Deleting things: Artifacts you can go in and delete. This system is so deeply hyperlinked, that almost everything is referencing something else. A PECE essay referencing an artifact, if that artifact gets deleted how do you handle it? Indicating to the essay user, what if it’s published that’s being cited? Really tricky question. What we settled on, if an artifact gets deleted, the essay owner is notified. But it’s technically possible to delete essays and artifacts. Questions are different, because responses would have nothing hosting them - all of the analysis would be hanging in loose space. So we made it impossible to delete questions, but when people were coming in and experimenting, they’d be adding questions that needed to be deleted - admins can delete questions but it can’t be the solution moving forward. Don’t want people deleting things when the attached things go away, but we need the possibility for error correction.
Anonymous, "Redesigning PECE Founder Interview Notes - Lindsay Poirier", contributed by Lucy Pei and Hillary Abraham, Platform for Experimental Collaborative Ethnography, Platform for Experimental Collaborative Ethnography, last modified 16 December 2020, accessed 24 September 2021.