UX contributions to pip, Python's package installer
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Tyers, Bernard
During 2020 we spent the year working with the maintainers of pip, the Python package manager. The project was to implement a new dependency resolver and improve pip's usability. It was a difficult project as personally, I knew very little about software package managers apart from doing "pip install". How do you do UX design with a piece of software used by hundreds of thousands (possibly millions!) of users on a small budget? Where do you find those users? Combined with this the maintainers were under pressure to do a lot of complicated work in a short period of time. This session will be a recorded discussion between the UX designers and the pip maintainers. We'll talk about what it was like to spend a year working together, the challenges, and the lessons we can teach others. We'll leave 5 minutes (approx) at the end for Q&A.
 So in 2020, the Python Software Foundation's pattern work successfully received one from the Chan Zuckerberg and Mozilla's open source support program to make improvements to PIP. And PIP is the Python programming languages recommended package manager. Today we're going to be talking about the experiences of having UX designers working on the PIP project. We're the PIP development team. My name is Bernard, I'm a UX designer and I let everybody else introduce themselves. Georgia. I'm Georgia, I'm the executive director at SimplySecure and part of the UX team for PIP this past year. Hi everyone, my name is Nicole. I've been working with the PIP team in 2020 as a UX designer with Georgia and Bernard. Previously I've been involved with Python packaging working on the PIP project. Pradyan. Hi, I'm Pradyan. I'm one of the maintainers for PIP. I sort of made most of the releases in 2020. Hi, I'm Paul. I'm another maintainer on PIP. I've done some of PIP's releases in the past. I've worked on the code base for a while now. PIP as Bernard said, it's basically a package manager. So when you set up a Python environment, dependencies, things like packages or libraries that your code depends on or will depend on, PIP is the tool you will use to search for the best copies of those libraries and install them locally on your machine ready for you to use. Getting better understanding from sort of the other end of the user maintainer paradigm, right? The expectation for me going in was to get more information about sort of how users interact with the project and sort of where they see deficiencies that we have just assumed don't exist and sort of expose those differences in understanding as well as gaps in understanding, I guess. Paul, what about you? I was very, very aware that we didn't have a good grip on how our users interacted with PIP. I mean, I came into working on PIP from being a user. I use PIP just as much as I work on it. Once you start seeing feedback from users in terms of issues and stuff like that, you realise there's a huge number of things that people are doing that just aren't stuff that you're doing. And it occurred to me that I really don't know what's important to these people, how PIP fits into their day-to-day work pattern, things like that. The chance to work with UX people on how users see PIP, for me, it was, wow, they're going to answer all those questions for me. It's going to be like a magic wand and everything's going to be brilliant and I'll know everything. There was quite a big learning experience for me in understanding how the process of getting that feedback works, what the limitations are, how much you can expect to get out of it, how much you can't. And what you do in a situation like that, how you make the judgements in the light of not getting as much feedback as you'd like or in terms of not being able to get access to groups of people. All of that sort of stuff was very new to me and so I think it was a huge learning experience for me. I think one of the most interesting things for me was we've been working with incomplete information for a while. We don't have a clear view of what everyone's doing with PIP. But what was interesting to me was even though we had incomplete information, there were some sort of approaches and just general best practices that we just weren't aware of, that we sort of gained some, I wouldn't say, gain some experience in. Perhaps not expertise, but definitely experience. Nicole, what about you? What did you expect? I was a little bit worried about this project because for a start it's a command line interface tool. So I think when we think about user experience, I mean people usually think about web interfaces and sort of the PIPI work that I did. And so to be honest, I was concerned when I first joined the project that perhaps the development team hadn't understood or maybe didn't value the input of user experience people because it's a command line tool. It's not, you know, you don't need UX for a command line tool. George, what about you? I did assume that there wouldn't have been a lot of previous experience, like thinking about design. I wasn't, every time I mentioned the project to anyone, people were like really excited about it or and would also be asked a question along the lines of what do you mean it's a command line interface. What are you, what are UX designers going to do? And it's like, well, there's the language of that experience. There's like feedback loops. There's like thinking about how this plugs into the overall ecosystem. Right. There's an experience there and developers are people too. So we should care about them. Bernard, what about you? What were your expectations going into the project? I had absolutely no idea. It was also incredibly daunting because like I knew that PIP was used by millions. I also didn't expect it to be as difficult as it was. I remember speaking with Pradhyan for many hours to try and understand why soft dependency conflicts were so complicated. How do you provide a user with a good user experience when something is literally mathematically impossible to solve? That really, really took time. It took a lot of time to genuinely understand. I think a lot of it is a communication thing. I mean, you said yourself the whole problem of dependency resolution is really complicated and you weren't aware of that in advance. And I think what I was experiencing was the flip side of that. I knew, hey, we've got some experts. They must understand all this. It can't be that hard. And the fact that it is something you have to learn. And certainly that was a part of the process that I struggled with was getting used to the fact that, yeah, this is a hard problem. It's not just me from the outside not knowing how to do it. It's genuinely a hard problem. And then moving on from that to understanding what tools you've got to deal with that difficult problem. I mean, in coding terms, there's all sorts of libraries. There's all sorts of algorithms for fixing things that dependency resolution is hard. Here's a load of algorithms. Throw them at it. That's done. In UX work, it's a hard problem. What do you throw at it? Like Pradhyan says, it became obvious that there's best practices, that there are principles that I didn't know anything about. And the fact that it's distilled down to something that I can go, yeah, well, I see that. It's actually a good thing. It's not just, oh, they didn't do anything useful. It's something, a whole new area of expertise that I wasn't aware of as an area of expertise, if you see what I mean. I feel like one of the challenges just reflecting on this over the years, I wish we had a little bit more time at the beginning to even just talk about the way the teams work and how this all works. The dependency resolver was the focus for the developers. And one of the challenges was the UX team was coming in without a lot of baseline understanding about the users as a whole. And so it was hard to plug into this really complex problem when we weren't even sure basic day-to-day problems. All of these things are actually hard problems, and we can help each other solve them, but we kind of need to start from some common set of information, both in how we work on both sides or ways that we can answer questions and talk about ways to approach that problem. And the fundamentals of how the technology is working. Because if it's not possible to do a thing, then it's not possible. Then it doesn't make sense to explore an idea of a way to provide user feedback or to change the way it works or things like that. Some things are just not technically possible, and those are constraints. You have to plug into the design process as well, to the user experience process as well. Just to echo what George has said as well in terms of having more time at the beginning of the project. But one thing that's kind of disappointing is that this is the point at which the contract is ending. So we don't actually, I mean, obviously we can in an open source capacity, but we won't have our eyes on the ground as to how those changes are then maybe taken on board and used by the community. So what would have been nice is to do that general UX discovery, like Georgie was saying at the beginning, have those recommendations and then be there to support the team in implementing them whilst also doing the dependency resolve work. Because I think that would have been a nicer process. Maybe would have allowed us to sort of follow up on some of those recommendations going forward. And it was an open question from our development team as to, you know, there's a big long GitHub discussion about the different ways that they can handle this, the pros and the cons. And I said, well, how about we just do know publish a survey and go and get some feedback from the community. And so I was really proud of that work because the way that we structured the survey, I think was quite clear and it allowed people to understand the problem. It allowed them to express an opinion. And then it was the results were so clear that I could then take those results back to the team and say, hey, you should do it this way. And by the way, we got some extra comments. So you should also consider, you know, doing, I think they were doing flags for, you know, other options. So I was really proud of that because there was a really clear outcome to that work. If I can put it this way, I think we busted a couple of myths in terms of, you know, who PIP users are and what they do and what they think. Really, really large percentage of PIP users are not software developer professionals. You know, they are not familiar with the ins and outs of dependency resolution. Georgia, I really enjoyed a lot of the discussions that we had, which resulted in just a story I've repeated to other people. It's like Paul and you and I were talking about PIP search and how PIP search is broken and got into the fact that part of it is people's expectations for it are off. We were talking about like, sure, you could fix that, but one of the ways you could fix that is by changing how you communicate what it does. You don't actually need to make any massive code change. We could literally just change the first, like change the feedback that they're seeing and start to reinforce what it's actually doing so that people understand they expected it to do something different. And so things like that that can be actually lighter weight interventions for improving the type of feedback you get from people. I think every time we got to a conversation like that and there were moments of like, oh, I don't have to rebuild this or remove it and have people be angry at me. Understand that it's a hard problem and prioritize it. It's very easy to get bogged down in the, we've got to deliver this bit of functionality. And sure, if you don't deliver the functionality, then there's nothing there to talk about the UX for. But at the same time, if all you do is think about functionality and think we'll get to the UX stuff, all of the onboarding problems, all of the time that it takes to do that will come back to bite you. You need to be involved at the beginning. We had a lot of history attached. We had a lot of sort of historical baggage coming in with the project for this is how we do things. We do not have the ability to change much. And we're making a big change. So we came in with sort of a really big problem and we eventually managed to ship away most of it. But I think coming at it from an understanding of what are we doing and how much of this needs to be sort of translated in terms of what the user sees before you even begin, right? Before you even begin with sort of the process of making those changes because part of the user experience process is communication with the user, right? And part of the user experience process is setting up feedback loops and action loops for those feedback, right? So I think thinking in terms of those and at least being ready for the fact that these are things you have to worry about and deal with would probably be the big takeaway. I think there's one thing Pradhin said which I'll just elaborate on a little, which is it's a feedback loop. I mean, Georgia mentioned it before in terms of the PIP search stuff. Learning how to talk to your users is as important as learning how to get information from them. And that was something that I don't think we picked up on early. As a software developer on open source, there's the whole thing about scratch your own itch. You're the user, you're writing code that you want to use and that's very true, but it's only true up to a certain point. If you're only ever going to write code that you use, then only you're ever going to use it. The point you start getting other people involved, you've got to find out what they want or you've got to say, I'm not interested. And if it's a big enough project, that means getting in touch with your users either for yourself, if you can, or with experts because it's not easy. Can you guys see me? My version of the, oh, maybe I should talk with you. Yeah, I mean, we will be live in a few. Let's do that again. Subta? Also, hi. Yeah, I think there's a lag. So right now, we are getting what started. Okay, I'm not going there. I'm going to get rid of this. Oh, they can see and hear us. It sounds like, okay. Oh, I see there's a lag. Okay. Okay. I think this is right. Yeah. Yeah. So I see one of the questions is how can we be more accessible to these communities as designers or something to offer? I think Errol put that in. And I don't know, Bernard, if you want to, I have thoughts. Well, I guess the first thing is as somebody who feels a reasonably technical person, I think reasonably good understanding of the technical things. It took me two months, I think, to really understand, or sorry, to have the beginning of an understanding of what PIP is and what it does and how it works. The first thing I would say is for something as specific and complicated as PIP or a package manager, you need to take time, spending time with the developers, reading about the subject. That's what I would say. First thing. Yeah. And the thing I was going to say is it's not just about designers being more accessible to the projects. It's also about the projects thinking about ways to enable design contributions or enable non-code contributions. And I think some of the things that we, or changes we have tried to help support over the year and hopefully will be used going forward is adding tags to the GitHub repo that are around UX and design, things like that. I think the other thing that we try to do that hopefully will make it easier for people to contribute more in the future.
 So in 2020, the Python Software Foundation's pattern work successfully received one from  the Chan Zuckerberg and Mozilla's open source support program to make improvements to PIP.  And PIP is the Python programming languages recommended package manager.  Today we're going to be talking about the experiences of having UX designers working  on the PIP project.  We're the PIP development team.  My name is Bernard, I'm a UX designer and I let everybody else introduce themselves.  Georgia.  I'm Georgia, I'm the executive director at SimplySecure and part of the UX team for PIP  this past year.  Hi everyone, my name is Nicole.  I've been working with the PIP team in 2020 as a UX designer with Georgia and Bernard.  Previously I've been involved with Python packaging working on the PIP project.  Pradyan.  Hi, I'm Pradyan.  I'm one of the maintainers for PIP.  I sort of made most of the releases in 2020.  Hi, I'm Paul.  I'm another maintainer on PIP.  I've done some of PIP's releases in the past.  I've worked on the code base for a while now.  PIP as Bernard said, it's basically a package manager.  So when you set up a Python environment, dependencies, things like packages or libraries that your  code depends on or will depend on, PIP is the tool you will use to search for the best  copies of those libraries and install them locally on your machine ready for you to use.  Getting better understanding from sort of the other end of the user maintainer paradigm,  right?  The expectation for me going in was to get more information about sort of how users interact  with the project and sort of where they see deficiencies that we have just assumed don't  exist and sort of expose those differences in understanding as well as gaps in understanding,  I guess.  Paul, what about you?  I was very, very aware that we didn't have a good grip on how our users interacted with  PIP.  I mean, I came into working on PIP from being a user.  I use PIP just as much as I work on it.  Once you start seeing feedback from users in terms of issues and stuff like that, you  realise there's a huge number of things that people are doing that just aren't stuff that  you're doing.  And it occurred to me that I really don't know what's important to these people, how  PIP fits into their day-to-day work pattern, things like that.  The chance to work with UX people on how users see PIP, for me, it was, wow, they're going  to answer all those questions for me.  It's going to be like a magic wand and everything's going to be brilliant and I'll know everything.  There was quite a big learning experience for me in understanding how the process of getting  that feedback works, what the limitations are, how much you can expect to get out of  it, how much you can't.  And what you do in a situation like that, how you make the judgements in the light of  not getting as much feedback as you'd like or in terms of not being able to get access  to groups of people.  All of that sort of stuff was very new to me and so I think it was a huge learning experience  for me.  I think one of the most interesting things for me was we've been working with incomplete  information for a while.  We don't have a clear view of what everyone's doing with PIP.  But what was interesting to me was even though we had incomplete information, there were  some sort of approaches and just general best practices that we just weren't aware of, that  we sort of gained some, I wouldn't say, gain some experience in.  Perhaps not expertise, but definitely experience.  Nicole, what about you?  What did you expect?  I was a little bit worried about this project because for a start it's a command line interface  tool.  So I think when we think about user experience, I mean people usually think about web interfaces  and sort of the PIPI work that I did.  And so to be honest, I was concerned when I first joined the project that perhaps the  development team hadn't understood or maybe didn't value the input of user experience  people because it's a command line tool.  It's not, you know, you don't need UX for a command line tool.  George, what about you?  I did assume that there wouldn't have been a lot of previous experience, like thinking  about design.  I wasn't, every time I mentioned the project to anyone, people were like really excited  about it or and would also be asked a question along the lines of what do you mean it's a  command line interface.  What are you, what are UX designers going to do?  And it's like, well, there's the language of that experience.  There's like feedback loops.  There's like thinking about how this plugs into the overall ecosystem.  Right.  There's an experience there and developers are people too.  So we should care about them.  Bernard, what about you?  What were your expectations going into the project?  I had absolutely no idea.  It was also incredibly daunting because like I knew that PIP was used by millions.  I also didn't expect it to be as difficult as it was.  I remember speaking with Pradhyan for many hours to try and understand why soft dependency  conflicts were so complicated.  How do you provide a user with a good user experience when something is literally mathematically  impossible to solve?  That really, really took time.  It took a lot of time to genuinely understand.  I think a lot of it is a communication thing.  I mean, you said yourself the whole problem of dependency resolution is really complicated  and you weren't aware of that in advance.  And I think what I was experiencing was the flip side of that.  I knew, hey, we've got some experts.  They must understand all this.  It can't be that hard.  And the fact that it is something you have to learn.  And certainly that was a part of the process that I struggled with was getting used to  the fact that, yeah, this is a hard problem.  It's not just me from the outside not knowing how to do it.  It's genuinely a hard problem.  And then moving on from that to understanding what tools you've got to deal with that difficult  problem.  I mean, in coding terms, there's all sorts of libraries.  There's all sorts of algorithms for fixing things that dependency resolution is hard.  Here's a load of algorithms.  Throw them at it.  That's done.  In UX work, it's a hard problem.  What do you throw at it?  Like Pradhyan says, it became obvious that there's best practices, that there are principles  that I didn't know anything about.  And the fact that it's distilled down to something that I can go, yeah, well, I see that.  It's actually a good thing.  It's not just, oh, they didn't do anything useful.  It's something, a whole new area of expertise that I wasn't aware of as an area of expertise,  if you see what I mean.  I feel like one of the challenges just reflecting on this over the years, I wish we had a little  bit more time at the beginning to even just talk about the way the teams work and how  this all works.  The dependency resolver was the focus for the developers.  And one of the challenges was the UX team was coming in without a lot of baseline understanding  about the users as a whole.  And so it was hard to plug into this really complex problem when we weren't even sure  basic day-to-day problems.  All of these things are actually hard problems, and we can help each other solve them, but  we kind of need to start from some common set of information, both in how we work on both  sides or ways that we can answer questions and talk about ways to approach that problem.  And the fundamentals of how the technology is working.  Because if it's not possible to do a thing, then it's not possible.  Then it doesn't make sense to explore an idea of a way to provide user feedback or to change  the way it works or things like that.  Some things are just not technically possible, and those are constraints.  You have to plug into the design process as well, to the user experience process as  well.  Just to echo what George has said as well in terms of having more time at the beginning  of the project.  But one thing that's kind of disappointing is that this is the point at which the contract  is ending.  So we don't actually, I mean, obviously we can in an open source capacity, but we won't  have our eyes on the ground as to how those changes are then maybe taken on board and  used by the community.  So what would have been nice is to do that general UX discovery, like Georgie was saying  at the beginning, have those recommendations and then be there to support the team in implementing  them whilst also doing the dependency resolve work.  Because I think that would have been a nicer process.  Maybe would have allowed us to sort of follow up on some of those recommendations going  forward.  And it was an open question from our development team as to, you know, there's a big long  GitHub discussion about the different ways that they can handle this, the pros and the  cons.  And I said, well, how about we just do know publish a survey and go and get some feedback  from the community.  And so I was really proud of that work because the way that we structured the survey, I think  was quite clear and it allowed people to understand the problem.  It allowed them to express an opinion.  And then it was the results were so clear that I could then take those results back  to the team and say, hey, you should do it this way.  And by the way, we got some extra comments.  So you should also consider, you know, doing, I think they were doing flags for, you know,  other options.  So I was really proud of that because there was a really clear outcome to that work.  If I can put it this way, I think we busted a couple of myths in terms of, you know, who  PIP users are and what they do and what they think.  Really, really large percentage of PIP users are not software developer professionals.  You know, they are not familiar with the ins and outs of dependency resolution.  Georgia, I really enjoyed a lot of the discussions that we had, which resulted in just a story  I've repeated to other people.  It's like Paul and you and I were talking about PIP search and how PIP search is broken  and got into the fact that part of it is people's expectations for it are off.  We were talking about like, sure, you could fix that, but one of the ways you could fix  that is by changing how you communicate what it does.  You don't actually need to make any massive code change.  We could literally just change the first, like change the feedback that they're seeing  and start to reinforce what it's actually doing so that people understand they expected  it to do something different.  And so things like that that can be actually lighter weight interventions for improving  the type of feedback you get from people.  I think every time we got to a conversation like that and there were moments of like,  oh, I don't have to rebuild this or remove it and have people be angry at me.  Understand that it's a hard problem and prioritize it.  It's very easy to get bogged down in the, we've got to deliver this bit of functionality.  And sure, if you don't deliver the functionality, then there's nothing there to talk about the  UX for.  But at the same time, if all you do is think about functionality and think we'll get to  the UX stuff, all of the onboarding problems, all of the time that it takes to do that will  come back to bite you.  You need to be involved at the beginning.  We had a lot of history attached.  We had a lot of sort of historical baggage coming in with the project for this is how  we do things.  We do not have the ability to change much.  And we're making a big change.  So we came in with sort of a really big problem and we eventually managed to ship away most  of it.  But I think coming at it from an understanding of what are we doing and how much of this  needs to be sort of translated in terms of what the user sees before you even begin,  right?  Before you even begin with sort of the process of making those changes because part of the  user experience process is communication with the user, right?  And part of the user experience process is setting up feedback loops and action loops  for those feedback, right?  So I think thinking in terms of those and at least being ready for the fact that these  are things you have to worry about and deal with would probably be the big takeaway.  I think there's one thing Pradhin said which I'll just elaborate on a little, which is  it's a feedback loop.  I mean, Georgia mentioned it before in terms of the PIP search stuff.  Learning how to talk to your users is as important as learning how to get information from them.  And that was something that I don't think we picked up on early.  As a software developer on open source, there's the whole thing about scratch your own itch.  You're the user, you're writing code that you want to use and that's very true, but  it's only true up to a certain point.  If you're only ever going to write code that you use, then only you're ever going to use  it.  The point you start getting other people involved, you've got to find out what they want or you've  got to say, I'm not interested.  And if it's a big enough project, that means getting in touch with your users either for  yourself, if you can, or with experts because it's not easy.  Can you guys see me?  My version of the, oh, maybe I should talk with you.  Yeah, I mean, we will be live in a few.  Let's do that again.  Subta?  Also, hi.  Yeah, I think there's a lag.  So right now, we are getting what started.  Okay, I'm not going there.  I'm going to get rid of this.  Oh, they can see and hear us.  It sounds like, okay.  Oh, I see there's a lag.  Okay.  Okay.  I think this is right.  Yeah.  Yeah.  So I see one of the questions is how can we be more accessible to these communities as  designers or something to offer?  I think Errol put that in.  And I don't know, Bernard, if you want to, I have thoughts.  Well, I guess the first thing is as somebody who feels a reasonably technical person, I  think reasonably good understanding of the technical things.  It took me two months, I think, to really understand, or sorry, to have the beginning  of an understanding of what PIP is and what it does and how it works.  The first thing I would say is for something as specific and complicated as PIP or a package  manager, you need to take time, spending time with the developers, reading about the subject.  That's what I would say.  First thing.  Yeah.  And the thing I was going to say is it's not just about designers being more accessible  to the projects.  It's also about the projects thinking about ways to enable design contributions or enable  non-code contributions.  And I think some of the things that we, or changes we have tried to help support over  the year and hopefully will be used going forward is adding tags to the GitHub repo that are  around UX and design, things like that.  I think the other thing that we try to do that hopefully will make it easier for people  to contribute more in the future.
improving_the_usability_of_pip_the_python_package_manager_0_155.png improving_the_usability_of_pip_the_python_package_manager_156_251.png improving_the_usability_of_pip_the_python_package_manager_252_2255.png improving_the_usability_of_pip_the_python_package_manager_2256_2411.png improving_the_usability_of_pip_the_python_package_manager_2412_3095.png improving_the_usability_of_pip_the_python_package_manager_3096_3227.png improving_the_usability_of_pip_the_python_package_manager_3228_3275.png improving_the_usability_of_pip_the_python_package_manager_3276_3323.png improving_the_usability_of_pip_the_python_package_manager_3324_3815.png improving_the_usability_of_pip_the_python_package_manager_3816_3971.png improving_the_usability_of_pip_the_python_package_manager_3972_7031.png improving_the_usability_of_pip_the_python_package_manager_7032_7175.png improving_the_usability_of_pip_the_python_package_manager_7176_9239.png improving_the_usability_of_pip_the_python_package_manager_9240_10043.png improving_the_usability_of_pip_the_python_package_manager_10044_10175.png improving_the_usability_of_pip_the_python_package_manager_10176_10295.png improving_the_usability_of_pip_the_python_package_manager_10296_15935.png improving_the_usability_of_pip_the_python_package_manager_15936_17003.png improving_the_usability_of_pip_the_python_package_manager_17004_17195.png improving_the_usability_of_pip_the_python_package_manager_17196_19247.png improving_the_usability_of_pip_the_python_package_manager_19248_23915.png improving_the_usability_of_pip_the_python_package_manager_23916_25007.png improving_the_usability_of_pip_the_python_package_manager_25008_25055.png improving_the_usability_of_pip_the_python_package_manager_25056_25439.png improving_the_usability_of_pip_the_python_package_manager_25440_28331.png improving_the_usability_of_pip_the_python_package_manager_28332_28445.png