Proposed Workflows for Design contributions and Collaboration

Development & Design
1

Hi all,

As part of milestones and deliverables for my internship, I researched workflows open source communities employ for design contributions and collaborations: To help make it easier for designers to come in and contribute to opens ource projects and collaborate with developers.

In that week, I examined a couple more open source communities like Wordpress, Cal.com and Open Source Design (OSS)
This research is ganered towards creating a welcoming environment for designers who want to contribute to OpenRefine and improving OpenRefine's workflows for design contributions.

My mentor @lozanaross and I would like to share my research documentation with you and would also like some feedback (what the community thinks) on my proposed workflows for design contributions in OpenRefine.

Here's the document and just a heads up, it's quite lengthy :sweat_smile:

2 Likes
2

Thanks for sharing @Lydiaofficial - for anyone interested in contributing feedback - please just add comments, like I've done towards the end of the doc. We'll review all feedback in the end and Lydia will make adjustments accordingly, which we'll then publish and seek further consultation on from other designers in OSS communities. Any questions about the process - let us know!

1 Like
3

Very nice! Thank you for this impressing work!

I'm glad to see that some of the proposed measures have some overlap with some discussions we have been having recently:

It is also very useful to see which aspects of the project were hindering @Lydiaofficial's contributions in the contribution phase.

Unsurprisingly, quite a few of these hurdles seem to be linked to the social structure of the project (for instance, the development team not being subordinated to an executive body which tells developers what to implement - which reduces designers' visibility about where the project is heading).

One factor that would be interesting to add to the reflection is: which sorts of personas of designers could be interested in contributing to the project, and what do we need to do to help them? Are there particular personas we should support more? I am thinking about factors such as:

  • are they OpenRefine users themselves?
  • are they volunteers, hired contractors, Outreachy applicants, students…? If hired, by the OpenRefine project itself or by some other organization (for instance a partner institution developing integration between OpenRefine and a platform of theirs)?
  • do they have formal training in design? Have they got access to specific tools (Adobe Xd, Figma…)?
1 Like
4

Another question, to better identify the profile(s) of designers we want to support is: which sort of design tasks do we expect them to tackle? Design can mean a lot of things. If it is understood as visual styling, to help maintain a consistent style throughout the application, this is something quite accessible to newcomers. If it is about product design, as in specifying new features to be implemented, that requires much more knowledge of the application and its users, I would say.

I am asking those questions because I really don't know the answers myself. Where do you all see potential? What sort of profile do we miss the most in the team, and what sort of person can we reasonably hope to onboard and retain?

1 Like
5

Thank you @Lydiaofficial for putting this document together. I left some comments in the document.

I will also elaborate on @antonin_d comment on the social structure of OpenRefine. OpenRefine development takes place asynchronously over long periods. A feature can be scoped over several months, and sometimes a similar lag can occur before it is picked for development (either by a volunteer, an intern, or via a grant). This workflow will impact the discussion format (comprehensive vs. scattered in different platforms, easy to find and refer to ...) and limit the usefulness of a prioritization framework.

1 Like
6

Thanks, @antonin for the comments and questions.

One things that is perhaps good to clarify is that this internship is just the first step in a long process. The long process is getting designers more sustainably involved in OpenRefine community, but it is part of a much larger problem in the entire software dev industry and OSS dev more specifically - a problem that puts design down as nonessential decoration and prioritizes dev skills, even at the cost of building products that do not adequately meet user needs.

There is an entire design community (https://discourse.opensourcedesign.net/) dedicated to exploring this problem and providing support to new designers entering the field, but there are no silver bullets and a systemic problem like this cannot be solved by a single project.

Another important point to clarify is that the internship idea was inspired by my own experience working on a paid project for OpenRefine and realizing I needed to spend a long time onboarding myself to get a basic understanding of established UI / UX patterns in OpenRefine before being able to meaningfully contribute to the paid project. What I really wanted to contribute in the end of the paid project was proper design documentation and component system, but there wasn't the time/funding for it. So the internship is for me an opportunity to finish this endeavour with help from another person who will thankfully get paid for the work and hopefully also learn something in the process.

So to get back to your question:

I think in an ideal world, we'll have a tiered system of onboarding that welcomes contributions of different scale and skill-level. However, to start with, we should not be overly ambitious and target the most straightforward 'designer' audience - that is professional designers who are needed for paid projects. I think it's unrealistic to expect these people will be users of OpenRefine, so the onboarding should be thorough. For the time being we're focusing on using Figma as a design system tool, which is widely popular among designers, easy to learn / use (due to fact it has far less options than older, more complex products like Adobe or Sketch), and crucially - it is also free, so no financial barriers to participation.

Ideally the documentation will have an easily accessible and highly visible component on the OpenRefine site itself, alongside the documentation for developers / users. Thus it will be possible also for existing OpenRefine contributors (volunteers, students, developers, etc) who may not be formally trained designers themselves to get helpful tips if their contribution also includes a design element.

I am suggesting we take a practical & achievable approach basically, and then iterate in the future and see how this can be developed further after the workflows and documents we produce this summer are tested with some real paid projects / internships in the coming months / years.

2 Likes
7

I hope my previous answer is useful also in terms of these questions.

which sort of design tasks do we expect them to tackle?

The docs will include onboarding for different levels of contribution. Better issue labeling system will be needed too. A proposal for the latter is also part of the internship deliverables.

Design can mean a lot of things. If it is understood as visual styling, to help maintain a consistent style throughout the application, this is something quite accessible to newcomers. If it is about product design, as in specifying new features to be implemented, that requires much more knowledge of the application and its users, I would say.

I think product design is much more realistic to be done by people hired to work on paid projects, the design system documentation we're building is for them essentially. And then they'll just have to do the job of any pro designer and familiarize themselves with the application itself, run user studies, etc.

'Visual styling' is not necessarily a designer task IMO - it should be possible to be done by anyone with sufficient knowledge of the existing design system in place (hence good documentation here is important, too). I think we could include something in the redefined issue labeling system that will be focused on "good first issues" for designers or frontend developers and it can include some cleaning up / consistency checking for the visual styles.

8

Thanks @Martin - indeed I discussed this at length with @Lydiaofficial in the beginning of the internship and we agreed some more information about the social structure of the project should be part of any newcomer onboarding. I still think it's useful she shared her initial frustrations upon approaching the project, because they confirmed this kind of understanding of social structure is taken for granted within OSS communities, but is pretty foreign to newcomers.

1 Like
9

That's a legitimate choice - thanks for making it explicit!

Writing an introduction to OpenRefine targeted at design contributors would likely be also very useful to developers. We have quite some developers coming to the project with the aim to contribute to an open source project, without being familiar with OpenRefine itself. Currently, in our contribution guide we ask them to get familiar with OpenRefine first. We provide some links to external tutorials but it would be great to have a better curated resource which would fit their needs better, so that they can understand the main concepts of the tools and what users do with them.

That being said, I am not sure I wish the project to get a lot more "hired guns" who have no previous relationship to OpenRefine (be they designers, developers or have other roles), on short-term funded efforts. Onboarding them feels generally harder and retaining them seems basically impossible without a steady income stream (which we do not have). They can be very helpful to just get a job done well and quickly but it does not really help us build a team on the longer term.

On the other hand, we have a big community of trainers. People who are organizing training sessions about OpenRefine and other tools, as part of their jobs or as a side activity. Those people already know the tool very well and are in a great position to observe what users struggle with. They might not think of themselves as designers, but I do believe they often would be able to articulate very valuable design proposals if given the opportunity. And it feels easier to retain them on the longer term: they have an incentive to contribute because the results are useful to them as trainers. The challenge to get them involved are in my opinion:

  • how to make them feel invited to contribute in this capacity? How to reach out to them?
  • how to highlight their proposals so that developers implement their suggestions? Submitting GitHub issues and seeing them disappear in a vortex of oblivion is not super motivating.
  • how to give them tools to formulate their proposals (Figma, Penpot… or just any image editor to scribble on screenshots?)
  • how to give them some design methodology and good practices that they might lack because they come from a different background?
  • how to recognize their contributions and make them feel part of the team?

I think involving people with this sort of profile is really not that unrealistic. We already have some, in fact. For instance @ostephens ticks quite a few boxes: active as a trainer, involved in many design discussions in the project. We also have @b2m who wrote tutorials and is also active in design discussions on the forum. Of course @Sandra is also an active trainer who contributed many design proposals (#5557 comes to mind in particular).

10

I think it's important to take into consideration the realities of the context in which the OpenRefine project finds itself. It would be hard to find an example more diametrically opposed in terms of scale, maturity, organization, and any number of other factors than Wordpress. Wordpress is used by 43% of all sites on the Internet and 36% of the top 1 million sites. It has 60,000 plugins, 9,000 free themes, and over 20,000 paid themes (one of the things all those designers are doing).

OpenRefine, on the other hand, has a bus factor barely above one and struggles to attract and retain contributors of all stripes, not just designers.

I strongly agree with the need to focus on long term contributors, not solely short-term mercenaries.

To the suggestion of looking to trainers for usability feedback, I'd add super users as candidates for providing valuable feedback. Most (all?) trainers start out as experienced super users themselves, growing their informal mentorships into more formal training classes. They also have valuable domain knowledge about the tasks for which users are attempting to use OpenRefine whether it be library/GLAM cataloging, biodiversity data wrangling, etc. Historically, they've also provided valuable feedback on ideographic languages, RTL languages, and other things that Europeans might not be as familiar with. The first order of business, though, probably needs to be to rebuild the community that was left behind when we abandoned the mailing list, so that there's an audience to solicit suggestions from.

Tom

1 Like
11

I am a trainer indeed. I wish I needed to do so much less of it. Training people to use OpenRefine is hard work, and the income, network and experience it generates for me doesn't cover the effort I put into it at all (every course I teach brings hours of preparation, diving into users' use cases, and after the fact, quite a few frustrated hours of following up on all the confusions and questions users will have when they get their hands dirty with the tool and its extensions and all the variably (non)maintained reconciliation services out there). Being a designer is an entirely different skillset - I am not capable (nor willing) of producing / presenting solutions to the pain points I see. I am not trained to do that, I don't have the creativity for that, and certainly not the capacity, with all the support requests that OpenRefine already has brought and continues to bring into my life.

I really would vastly, vastly prefer OpenRefine to work with trained designers to lighten this load.

One argument I miss here: the long-term benefit even a short-term paid engagement can bring to end users. Every single, skillful UX fix by a trained professional, that addresses pain points in the tool, will make the workload for people like me lighter. A general user survey by trained design professionals (not just for trainers but for users in general - newcomers and more experienced users alike) and a UX research project on pain points and priorities will provide guidance that's useful for a long time, and if addressed well, will also make the workload for trainers like me lighter.

So yes, please, do bring in the "mercenaries". By the way, can we please be a bit more respectful? Thank you. Volunteering is not possible for everyone; being able to volunteer is a massive privilege.

As for 'a community that was left behind when we abandoned the mailing list' - I have been observing with the folks I've trained that the vast majority of OpenRefine users have never been on the mailing list to start with. If you want to reach OpenRefine's user communities: you'll be able to approach and target them much better via their own channels where their main discussions about OR take place.

2 Likes
12

I think this discussion is great! Touching on so many important things. Thank you @Lydiaofficial and @lozanaross for sparking it and everyone else for the insightful comments.

@Sandra sorry if you felt that "mercenaries" or "hired guns" is disrespectful (it certainly is a loaded term at the moment given the recent news). By using this analogy my intention was not to put emphasis on the fact that they are paid, but rather about the short-term aspect of the engagement and the distance to the project.

Perhaps it's too ambitious or idealistic, but I hope FOSS projects like OpenRefine can integrate designers better than by occasionally hiring one as an external helper. I would ideally hope that their contributions can be baked into the normal workflows of the project, so that they can be meaningfully part of the team.

13

Dear all,

I’m afraid that due to my hastily written initial comments, this whole discussion has taken a rather unexpected turn.

Perhaps I gave undue emphasis on “paid” in my initial comments. Please do not imagine a revolving door of expensive consultants. What I wanted to emphasize is professional designers as core target audience for the internship deliverables – aka people who either have design education background, and/or have experience working in positions involving UX / UI tasks as part of the job description.

I merely referred to “paid projects” because in the years I have been involved with OpenRefine so far, all major development seems to have been done thanks to grant funding, which in my experience with other OSS communities is the norm, nothing unusual here. Sure – long-term contributors are not guaranteed steady monthly income in any way, but significant product changes are generally not done for free. It stands to reason that when we talk about professional design, we also talk about major product updates, improvements, new releases, etc. It also stands to reason that such major work will be paid.

Taking OpenRefine seriously as a software product in the long-term, in my opinion, means having a stable core group of designers (this doesn’t mean dozens, it can be 1-2 experienced people and several students / interns) who can be ongoing contributors, but they will also be paid for any major work. I think the project lacks such a core group at the moment. Besides myself, I am not aware anyone else here has design education and experience, and I alone don’t have time capacity to put in the amount of work that the project deserves. I also truly hope such a core group will be happy to do routine maintenance, and help out in smaller ways with the project on an ongoing basis, including in the gap periods outside of concrete funding grants. But we have to get people excited about the project first, and we can’t expect to onboard people into the community without any initial project, simply because there is very little overlap between design communities and data science / information science communities using OpenRefine. It’s not impossible, but let’s not rely on that too heavily.

As to the other points – of course – having a main target audience doesn’t mean that we don’t care about other audiences, or that we won’t test with them and evaluate, but it’s just more straightforward to have one specific audience in mind that is particularly high impact, and then adjust for additional groups iteratively.

2 Likes