[00:00.000 --> 00:10.500]  So, this is the second talk related to Open Project. I don't know if anyone went to the
[00:10.500 --> 00:16.200]  talk about integrations yesterday, anybody? All right, designers, I get it. So, this is
[00:16.200 --> 00:21.040]  Practical UX at Open Project. So, I've been working there for a year and a half, and these
[00:21.040 --> 00:25.640]  are musings about the things I've learned, things we've gone through. It will all become
[00:25.640 --> 00:31.480]  clearer in a second. I'm Parimal, and that's a very elaborate site to tell you. My name
[00:31.480 --> 00:37.840]  is Parimal, and I'm a UX designer at Open Project. So, I think we can start with, I
[00:37.840 --> 00:43.640]  think we can all agree that the UX in Open Source could use a little bit of work. I think
[00:43.640 --> 00:49.320]  it's fair enough to say that, right? We know the reasons, but very quickly, some of the
[00:49.320 --> 00:55.520]  challenges we've had. Data design. When you have data design in software, in Open Source
[00:55.520 --> 01:01.840]  tends to have this sometimes. It is not necessarily intuitive, which makes it less attractive
[01:01.840 --> 01:06.640]  to new users, because they're comparing with a lot of other newer tools, and they tend to
[01:06.640 --> 01:11.880]  have all this shiny stuff, right? There tends to also sometimes be inconsistent behavior.
[01:11.880 --> 01:15.920]  The good thing about having contributors, all sorts of contributors over the years,
[01:15.920 --> 01:22.200]  is that it's open, anyone can do things, can add new features, but if you lack a consistent
[01:22.200 --> 01:28.000]  coherent design language, then you do have the problem of inconsistency over time. There's
[01:28.000 --> 01:33.240]  also a lack of investment in designers. Now, this is, I think in general, in Open Source
[01:33.240 --> 01:38.440]  there's a lack of resources in general, right? Not always, but there tends to be this problem,
[01:38.440 --> 01:44.680]  and design does not tend to also be the priority for a lot of projects. There's also this tendency
[01:44.680 --> 01:50.080]  of Open Source projects being engineering driven. Not necessarily a problem, because
[01:50.080 --> 01:58.640]  this can generally mean a very fully functional, very feature-rich software, let's say, but
[01:58.640 --> 02:03.320]  that does not necessarily translate to beginner-friendly software, as we don't manage to again attract
[02:03.320 --> 02:10.280]  new users. UX and accessibility tend not to be immediate concerns of developers if they're
[02:10.280 --> 02:18.560]  not necessarily topics that concern them directly. This also means that these tend to not be
[02:18.560 --> 02:26.000]  prioritized for that same reason. However, there are some positives to UX and Open Source,
[02:26.000 --> 02:31.160]  and that's that UX has also taken this dark turn through all the sort of the Facebooks
[02:31.160 --> 02:35.880]  and the Microsofts and the Googles, where there's a lot of dark patterns, and UX designers
[02:35.880 --> 02:40.000]  and a lot of companies are encouraged to produce these dark patterns. We tend to not have this
[02:40.000 --> 02:44.280]  in Open Source because we tend to want to create things that people like, and we're sort of
[02:44.280 --> 02:49.040]  bound by these values. I think the fact that we're in our foster means we sort of have
[02:49.040 --> 02:53.560]  these values, and there's a spirit of sharing, which is why we're all here, and things are
[02:53.560 --> 03:01.040]  getting better. I think that some of the talks at foster are showing us this. That's the
[03:01.040 --> 03:07.120]  sort of point of where we're starting, but then we joined Mark and I. He's not here,
[03:07.120 --> 03:12.600]  but hi Mark. We joined Open Project in August 2021, and we were quite impressed because
[03:12.600 --> 03:19.400]  Open Project, for quite a small company, decided to invest in two UX designers, which was quite
[03:19.400 --> 03:25.080]  a big deal for an Open Source project of about 30 developers. We have a product team of the
[03:25.080 --> 03:29.760]  two UX designers and the CEO. We take product decisions, but then we also try to work on
[03:29.760 --> 03:34.200]  the user experience. The reason I joined Open Project, because I come from a background
[03:34.200 --> 03:40.120]  of working in agencies, communication agencies, different world, was all the values that you
[03:40.120 --> 03:45.280]  guys share, that we all share, and seeing that a company was willing to put the resources
[03:45.280 --> 03:50.960]  in. And the goal was to improve user experience. What does this mean for Open Project? To
[03:50.960 --> 03:53.560]  tell you this, I'd like to tell you a little bit about Open Project, because otherwise
[03:53.560 --> 03:57.520]  you won't know what I'm talking about. Open Project is an Open Source project management
[03:57.520 --> 04:03.360]  and collaboration software that looks, I'll show you the screenshots in a bit, but I thought
[04:03.360 --> 04:07.120]  I'd tell you how we're organized, so you get a sense of perhaps compared to other Open
[04:07.120 --> 04:13.680]  Source projects. We have about, I said we're a team of 30, about 15 devs, full stack, front,
[04:13.680 --> 04:19.160]  back, all that. We've got three product people, like I just said. We've got one QA, which
[04:19.160 --> 04:22.760]  I'll sort of connect to the user experience a little bit, because if we can't test, it
[04:22.760 --> 04:28.200]  doesn't quite work. Business marketing, some HR, and then sales and support. That's it.
[04:28.200 --> 04:32.240]  That's our entire ship. We've got two versions, the free community version that you can just
[04:32.240 --> 04:37.360]  download and install anywhere, and the enterprise with the support, quite a classic model. You
[04:37.360 --> 04:42.760]  can install it on premises, on the cloud. We also offer hosting within the EU, if you
[04:42.760 --> 04:47.720]  don't want your data sent anywhere else. You can see some of our major clients, including
[04:47.720 --> 04:55.200]  Berger-Bahn, who spoke earlier. The values that are very important to us are the privacy,
[04:55.200 --> 04:58.360]  the data security, digital sovereignty. These are things that we're very, very passionate
[04:58.360 --> 05:02.560]  about, as are a lot of other projects who are speaking today.
[05:02.560 --> 05:08.320]  It looks like that. List of work packages, tasks. This is actually what we're using to
[05:08.320 --> 05:12.600]  work on the new version that we're going to release in a couple of, well, we'll see when
[05:12.600 --> 05:19.640]  it gets released. It'll be released this month. We work publicly using open projects, obviously.
[05:19.640 --> 05:24.760]  You can see a bunch of features, some epics we're working on. You could filter by priority,
[05:24.760 --> 05:31.720]  by status. I think you get the idea. You could go into a bug report that I submitted. This
[05:31.720 --> 05:38.440]  is all public, by the way. If you find a bug, you can also submit one. You can see the description
[05:38.440 --> 05:44.440]  there, the activity where you can really exchange with other users. You can tag them. That's
[05:44.440 --> 05:49.120]  very important to us as well. Connect to other files. We talked about integrations. We have
[05:49.120 --> 05:54.560]  an integration with Next Cloud. If you upload files to Next Cloud, you can link to tasks
[05:54.560 --> 06:01.120]  and work packages in open projects. I think that's a very common view, a canvance view
[06:01.120 --> 06:06.080]  if you want to drag things around. We have that too. We have a team planner. If you want
[06:06.080 --> 06:13.960]  to organize your team and see who's doing what and reassign tasks, you can do that.
[06:13.960 --> 06:18.320]  That gives you a sense of what the product is. Let's go to UX at Open Project. Some things
[06:18.320 --> 06:23.440]  have happened since I joined, since Mark and I joined. We now have a design team. Previously,
[06:23.440 --> 06:27.280]  we didn't have one. It wasn't a priority. It was quite normal as well. Now, we have
[06:27.280 --> 06:34.880]  two UX designers and a test person, a QA person, Ivana. We used to do Markovs in PowerPoint.
[06:34.880 --> 06:38.760]  It did the job. Now, we're working in Figma. Hopefully, we can move to Penport at some
[06:38.760 --> 06:48.000]  point. We had a rudimentary style guide of HTML elements. Now, we have a growing design
[06:48.000 --> 06:53.240]  system with reusable components that we're going to look at in a bit. It was quite engineering
[06:53.240 --> 06:59.960]  driven. You can see that in the design as well. Now, we're working alongside devs to
[06:59.960 --> 07:05.080]  get some early feedback. We're not at loggerheads. It's not devs versus designers. We're trying
[07:05.080 --> 07:13.200]  to work from scratch and get early feedback. These are things that we are changing within
[07:13.200 --> 07:21.080]  our way of working. We all know the benefits of better UX, but for us, we realize that
[07:21.080 --> 07:26.440]  even clients that have used our software for a very, very long time, if we can optimizations,
[07:26.440 --> 07:31.080]  even minor, that's worth the time and effort. Of course, attracting new users is very important
[07:31.080 --> 07:36.840]  to us. We're not trying to only be the open source project management tool. We're also
[07:36.840 --> 07:43.240]  trying to compete as an alternative to the proprietary tools. The challenge is, if you
[07:43.240 --> 07:52.600]  read the abstract, that was something I promised and I will try to deliver.
[07:52.600 --> 07:56.960]  Us designers have a temptation to want to say, be helicoptered into a project and design
[07:56.960 --> 08:04.360]  everything from scratch. I see that. I'll put something on Figma. Let's do this. It's
[08:04.360 --> 08:09.200]  not that easy. I think you guys know this because when you're working with an open source
[08:09.200 --> 08:16.400]  project, there are certain contextual constraints, let's put it that way. It tends to be quite
[08:16.400 --> 08:20.840]  large open source applications, so you can't just change one thing and propagate it throughout
[08:20.840 --> 08:26.520]  the whole application. For example, the same element, say a drop down or a button, can
[08:26.520 --> 08:31.520]  appear very differently in different parts of the application, but not just visually.
[08:31.520 --> 08:35.840]  It might be implemented differently in all those places as well. Because again, multiple
[08:35.840 --> 08:40.720]  contributors over the years, no coherent design language. Sometimes you can even have
[08:40.720 --> 08:46.960]  different code layers. In our case, we have Angular and Ruby, which means the views aren't
[08:46.960 --> 08:52.000]  rendered quite the same way everywhere. The time, if you come up with a new design, it
[08:52.000 --> 08:57.840]  has then to be developed and that time, that's time and effort that's competing with new
[08:57.840 --> 09:05.480]  feature developments, with maintenance, with bug fixing, and general dev time. You can't
[09:05.480 --> 09:10.880]  just say, I've designed this, implement it, and we'll move on. You've got to balance it
[09:10.880 --> 09:16.160]  with all these other things. Of course, we realize that when you design a new feature,
[09:16.160 --> 09:21.040]  the requirements are very different between pro users and new users who are used to certain
[09:21.040 --> 09:25.680]  ways of working. You say, oh, no, we're going to change something completely. The risk of
[09:25.680 --> 09:29.880]  that is, of course, the classic XKCD, I don't know if you know this one. There are 14 competing
[09:29.880 --> 09:33.360]  standards that you're like, oh, you can't have that. We need to develop a one universal
[09:33.360 --> 09:38.640]  standard that works with everybody and then you end up with 15 standards. We don't want
[09:38.640 --> 09:45.680]  that. Of course, data analytics helps often. It helps you get a sense of what users are
[09:45.680 --> 09:52.080]  doing, what they want, whether they're getting stuck. You could use Google Analytics or you
[09:52.080 --> 09:57.080]  could not use Google Analytics like we do and not have the data because it's very important
[09:57.080 --> 10:02.000]  for us not to track our users. That makes our work slightly complicated because we don't
[10:02.000 --> 10:05.880]  quite know what people are doing, but it's very important to us that we don't do this,
[10:05.880 --> 10:12.560]  especially because, again, the data would not necessarily be within the EU.
[10:12.560 --> 10:17.920]  Having said that, we managed to ship our first big feature when we joined Mark and I. It
[10:17.920 --> 10:21.800]  was a notification center. We were very proud of it because we didn't have any process,
[10:21.800 --> 10:27.240]  no UX process, and we still managed to do it. Because before this, all notifications
[10:27.240 --> 10:33.840]  in OpenProject were email-based. If you sort of had a new work package, a feature, someone
[10:33.840 --> 10:37.880]  answered it, added a new requirement, you'd get an email alert. You couldn't follow it
[10:37.880 --> 10:43.920]  within the application. We designed this. Extremely proud of it. It did ruffle some feathers
[10:43.920 --> 10:48.360]  because we said, all right, now the emails are only going to be digests, not for every
[10:48.360 --> 10:53.520]  single notification, but some people will be used to this. We are extremely proud of
[10:53.520 --> 10:59.480]  this feature, but we also learned that you've got to ease users in with these big changes.
[10:59.480 --> 11:08.000]  Perhaps we need to start small. Small means sort of manageable, developable, maintainable,
[11:08.000 --> 11:16.000]  testable, don't scare existing usersable. That's sort of what we mean by small, reasonable,
[11:16.000 --> 11:20.760]  in other words. So when you want to change these things, there's a couple of different
[11:20.760 --> 11:26.200]  ways to go about it. You can change one thing everywhere in the application. So let's say
[11:26.200 --> 11:31.040]  a button. The button that we had doesn't quite work. We want to change it. We want to make
[11:31.040 --> 11:36.160]  it better. You could make that button the same, the new version, everywhere. But then
[11:36.160 --> 11:41.240]  individual pages would not be consistent, right? Or you could change everything in one
[11:41.240 --> 11:45.520]  page. It takes the settings page. We're going to update it with new components. We're going
[11:45.520 --> 11:51.120]  to make it standard. But then that standard, across pages, it's not very standard, is it?
[11:51.120 --> 11:56.240]  You just changed the problem a little bit. So the approach we've gone with is we want
[11:56.240 --> 12:01.440]  to standardize the elements first. Remember how I told you that the same elements could
[12:01.440 --> 12:06.040]  be implemented in different ways in different places? Well, what if we first standardize
[12:06.040 --> 12:12.840]  the implementation, the HTML, the actual code of that element, and then we can modify it,
[12:12.840 --> 12:17.880]  can we, once we come up with some sort of consistent way of doing it? That'll also help
[12:17.880 --> 12:22.360]  us understand how these elements are being used and the different variations we'll need.
[12:22.360 --> 12:28.840]  I'll give you an example. For a design presentation, this will be a lot of words, hasn't it? More
[12:28.840 --> 12:34.400]  images, please. This is the date picker that we used to have, and that's the date picker
[12:34.400 --> 12:40.400]  we have now. We changed it because we introduced a new feature, which was taking Workweek into
[12:40.400 --> 12:46.440]  account, so sort of being able to say that Saturday and Sunday are holidays or could
[12:46.440 --> 12:50.920]  be a Friday, depends on your company. So when we did this, we took the opportunity to upgrade
[12:50.920 --> 12:57.040]  it, and beyond this sort of aesthetic change, you'll notice that was an opportunity for
[12:57.040 --> 13:01.800]  us to then work on all these elements, to try to better define what a button should
[13:01.800 --> 13:05.840]  look like, what an action bar should look like, what the blue, when you time across
[13:05.840 --> 13:09.600]  the application and you're changing the focus, what that should look like, because that wasn't
[13:09.600 --> 13:15.520]  very consistent either. So we took this opportunity, sort of new feature development, to create
[13:15.520 --> 13:20.840]  these components, and not just things that are visible, but also things that are invisible
[13:20.840 --> 13:26.000]  like this, which we didn't quite have in the past. So that does mean that for now, you
[13:26.000 --> 13:29.240]  won't find this in all across the application. They're parts of the application that don't
[13:29.240 --> 13:33.800]  respect some of the things we've defined, but we're going iteratively one step at a
[13:33.800 --> 13:39.560]  time. And to do that, we need a design system. We call it the single point of truth. So
[13:39.560 --> 13:43.720]  it's a spot, and if there's a component that has not been included in the design system,
[13:43.720 --> 13:49.080]  we say it's not been Spotifyed. They can't really sue us. So what is a design system?
[13:49.080 --> 13:56.240]  For us, it's sort of a consistent, dependable, reusable and documented set of things. These
[13:56.240 --> 14:03.840]  things could be styles, colors, spacing, things I showed you. Could be components like buttons
[14:03.840 --> 14:10.720]  or text boxes, any of the little components that bigger interfaces are built out of. And
[14:10.720 --> 14:15.600]  then patterns that are a combination of these things. And the last bit is very important.
[14:15.600 --> 14:20.760]  You've got to then document it and tell people how to use it, when to use it, what to do,
[14:20.760 --> 14:25.160]  what not to do. And of course, as being an open source company, we publish all of it
[14:25.160 --> 14:30.400]  in our website. So anybody can go and look at it. So now when we say spacing to, everybody
[14:30.400 --> 14:35.640]  knows the developers, designers and the testers know what that spacing should look like. Same
[14:35.640 --> 14:40.640]  thing for action bars, with the different variants. And then we go to our website and
[14:40.640 --> 14:45.760]  then we try to explain those variants and how to use it. And this is public in our website.
[14:45.760 --> 14:49.040]  It's not complete yet. We're still working on our design system. So now all elements
[14:49.040 --> 14:56.600]  are there. But we are working on it. How's the speed? Am I speaking too fast for anyone?
[14:56.600 --> 15:03.280]  It's all right. Okay. Well, I'll take a bit for break and bring some water. You can appreciate
[15:03.280 --> 15:12.000]  our design system. So in some startups, they say build fast and break things. We can't
[15:12.000 --> 15:17.040]  afford to do that. That's not our mantra. Our mantra is to build slow, iterate and test
[15:17.040 --> 15:23.440]  things. I say test things. We've not quite done it yet. That's our goal for this year.
[15:23.440 --> 15:27.600]  So we want to balance UX optimizations with feature dev. But like I showed you with the
[15:27.600 --> 15:33.320]  date picker, perhaps if we spend 40% of our time with feature development, we take that
[15:33.320 --> 15:40.080]  as an opportunity as well to optimize and maybe choose five core elements and then sort
[15:40.080 --> 15:46.000]  of fold them into our design system and try to make those consistent. Which requires sort
[15:46.000 --> 15:52.160]  of that means that there will be imperfection and there will be inconsistencies within the
[15:52.160 --> 15:59.720]  application. Our goal is to accept that imperfection and to keep moving. Because again, the developer
[15:59.720 --> 16:04.560]  doesn't like when things are inconsistent or some developers want it to be pixel perfect.
[16:04.560 --> 16:12.200]  Well, sometimes it's not going to be. And for those of you who speak French, the better
[16:12.200 --> 16:17.880]  is sometimes the enemy of the good. And sometimes you got to accept the good enough to move forward
[16:17.880 --> 16:24.720]  to where you want to be. Very philosophic, I know. So the learnings for the past year
[16:24.720 --> 16:28.360]  and a half, it's very happy to be able to put that half symbol there. I thought it looked
[16:28.360 --> 16:35.840]  quite cool. So the first thing is you can't just join a project, be helicoptered in and
[16:35.840 --> 16:40.200]  magic won the whole thing and say, great, we want to just change everything. Let's do
[16:40.200 --> 16:46.720]  it. Upgrade it to 2024. You need incremental upgrades because you need everybody in the
[16:46.720 --> 16:53.200]  company to believe in what you're doing. Be convinced it's worth the effort. And luckily
[16:53.200 --> 17:02.120]  we have that sort of project. But it's not an easy thing to do because there are competing
[17:02.120 --> 17:09.760]  requirements, competing priorities and how companies should use its time. So that's important
[17:09.760 --> 17:15.920]  to accept, incremental. Standardizing things now means a lot of time spent now. But down
[17:15.920 --> 17:22.880]  the road it gives us more time to do more relevant work. It's less time because things
[17:22.880 --> 17:27.080]  are already standardized. If we change the color, if we change the design, it will change
[17:27.080 --> 17:31.880]  all across the application. We need to be pragmatic, try to make something a little
[17:31.880 --> 17:37.160]  better with every release, not go for everything in one release. But sometimes we do want to
[17:37.160 --> 17:40.800]  go for those big changes like we did with notification center. It might ruffle some
[17:40.800 --> 17:45.400]  feathers, but those changes are required because we have a vision for where the product needs
[17:45.400 --> 17:51.120]  to be. However, we've learned, perhaps the hard way, that we need to ease our users in
[17:51.120 --> 17:55.960]  who are used to the old system, help them understand why we're doing it. And in that
[17:55.960 --> 18:00.120]  regard, we also plan on communicating more from the product team, perhaps publishing
[18:00.120 --> 18:05.560]  the why and the how of how we work, why we take certain decisions. And finally, we could
[18:05.560 --> 18:10.800]  learn from other open source projects as designers, I mean, because developers do it quite a fair
[18:10.800 --> 18:15.560]  bit. I don't think we quite have that culture amongst designers. And we're currently working
[18:15.560 --> 18:22.040]  on theming, and I saw a presentation by Matthew, Matthew Brea from Proton, who was in Paris
[18:22.040 --> 18:26.400]  where it was last year. And he was explaining how his company worked on theming and all
[18:26.400 --> 18:29.840]  the things that he did that were wrong and where he learned from. And we were able to
[18:29.840 --> 18:36.560]  use that and learn from it, and that helped save us time, sort of get a better sense of
[18:36.560 --> 18:41.080]  what we were doing. So thanks to Matthew, who's not here, but I think that that sort of sharing
[18:41.080 --> 18:45.760]  is very important. We should do more of that. And we really hope that this presentation
[18:45.760 --> 18:52.840]  maybe hopefully one day can help someone as well. So what are our plans for 2023 then?
[18:52.840 --> 18:58.480]  More UX. Shocking, I know. So more UX, so more work on the design system, continue working
[18:58.480 --> 19:02.960]  on it rather. More testing, because we've not really done any testing now, we haven't
[19:02.960 --> 19:07.280]  had the resources, but that's one of our plans. Even a basic hallway test where we ask five
[19:07.280 --> 19:13.280]  people what they think and if they understand the feature, is some input. We want to integrate
[19:13.280 --> 19:18.280]  more with other tools. Part of doing that is to take the design system and make it easy
[19:18.280 --> 19:23.720]  for someone creating a plugin or trying to integrate with OpenProject to use those design
[19:23.720 --> 19:28.440]  elements as well. So that's one of the reasons we're working on the design system as well.
[19:28.440 --> 19:34.040]  And of course, better theming like I just mentioned, and accessibility is something that we have
[19:34.040 --> 19:37.440]  in mind, but we could do a lot more. We could be a lot better at that. So that's one of
[19:37.440 --> 19:43.000]  our goals. And of course, we've got the usual suspects, the ongoing optimizations, and new
[19:43.000 --> 19:48.520]  features along the way. The goal, of course, then is to have more users who say they picked
[19:48.520 --> 19:53.120]  up OpenProject for the UX, not just because it's open source. Of course, we want them
[19:53.120 --> 19:58.320]  to pick up OpenProject because it's open source, of course. But if they say we try to
[19:58.320 --> 20:03.440]  do a bunch of tools, we think you guys have really good UX, that's our goal. But why
[20:03.440 --> 20:08.920]  do I stop there? Let's go further. A broader goal, broader goal, is to build an alternative
[20:08.920 --> 20:14.960]  to Microsoft 365 with all the other actors, some of whom were here, fast and right. So
[20:14.960 --> 20:23.280]  next loud, OpenExchange, Elements, XWiki, Collaborer, with all these other players, let's give users
[20:23.280 --> 20:30.560]  an alternative that's respectful of their privacy, that is open source, and that respects
[20:30.560 --> 20:35.360]  data sovereignty. And if you're passionate about these things, I'm certainly not telling
[20:35.360 --> 20:40.680]  you that you should, you know, that these companies are hiring, but they might be. Just
[20:40.680 --> 20:44.720]  saying. Thank you very much for giving me some time. And if you have any questions, I'll
[20:44.720 --> 20:45.720]  take them now.
[20:45.720 --> 20:58.360]  Thank you. Yes. A lot of what you said reminds me of when I was at the OpenProject network
[20:58.360 --> 21:02.840]  doing some of the things that we were built on, like Spray, and it was very, like, component
[21:02.840 --> 21:11.320]  messy, change it here, but not change it here. My question is, how beneficial or not is having
[21:11.320 --> 21:19.600]  your CEO on your product team? That's a great question, actually, because it's, for us,
[21:19.600 --> 21:24.920]  it's, designers can also go too far. So we can also have, because we want to change things
[21:24.920 --> 21:29.720]  very, very quickly, but there are some very pragmatic questions that are also development
[21:29.720 --> 21:36.240]  related, but also, let's say, related to the product roadmap. We think it's quite helpful,
[21:36.240 --> 21:40.960]  because then we can have the discussion internally and align ourselves rather than be at loggerheads
[21:40.960 --> 21:46.280]  again with, because, like you can have designer versus developer, you can also have designer
[21:46.280 --> 21:57.040]  versus product. So we try to avoid that. So we think it works well. Yeah. Yes. Sorry.
[21:57.040 --> 22:04.640]  So the organization I work for, my university, I've been paying enterprise users to open
[22:04.640 --> 22:11.640]  projects, probably like a year and a half, two years. Glad to hear it. So I use it, like,
[22:11.640 --> 22:15.080]  every day. I really like it. Universally, 100% of the negative feedback I've received
[22:15.080 --> 22:20.680]  from my colleagues on OpenProject have been explicitly related to the UX. Yeah. And so,
[22:20.680 --> 22:26.880]  and then pretty much all the positive feedback I've gotten from my colleagues have been related
[22:26.880 --> 22:35.000]  to specifically the UX improvements that you showed like last, you know, 10 minutes. So
[22:35.000 --> 22:39.640]  these improvements are really important to us as an organization, but I realize that
[22:39.640 --> 22:47.320]  especially in open source products that are oftentimes very privacy focused, from my perspective,
[22:47.320 --> 22:52.920]  it seems like usually it's a very lab-first adopters. Yeah. Priority among all of the
[22:52.920 --> 22:57.240]  customers, regardless, because there's just not an easy way to measure. Do you have any
[22:57.240 --> 23:02.000]  suggestions as an organization that's paying for the product that really appreciates this
[23:02.000 --> 23:06.000]  work and wants it to be done by, I don't know, like your boss or someone that, you know,
[23:06.000 --> 23:10.520]  this work is important to us and matters and what. Okay. So I'll try to repeat the question.
[23:10.520 --> 23:15.720]  Yeah. So you said that one of the biggest complaints with OpenProject was the UX and
[23:15.720 --> 23:20.320]  some of the positives in the recent times have been related to the UX. And the question
[23:20.320 --> 23:26.240]  is, sometimes the early adopters tend to be the loudest and tend to get heard the most.
[23:26.240 --> 23:35.680]  So how do we get better at listening to the community in general? Yeah. Okay. Customers
[23:35.680 --> 23:39.360]  of OpenProject. So what recommendations would we have to them? Well, we have two things
[23:39.360 --> 23:45.680]  we can say. First of all, our community discussions are open. So if you feel very passionate about
[23:45.680 --> 23:51.480]  a feature or a certain optimization, we really welcome that feedback and we will engage with
[23:51.480 --> 23:58.720]  you. It can be sometimes a bit tough to be on all fronts. So sometimes it's true that
[23:58.720 --> 24:04.800]  feedback can be a bit lost. We tend to track it with both an OpenProject. But our biggest,
[24:04.800 --> 24:09.880]  perhaps a recommendation would be to engage with the community directly via, yeah, via
[24:09.880 --> 24:14.080]  community. And also if you have an idea, submit a pull request. That's also very, but that's
[24:14.080 --> 24:21.080]  not fair for a lot of people because, yeah. Well, thank you for using our project. Yeah.
[24:21.080 --> 24:28.520]  Yes, we will, we will test more. We'll start small with how we test. And this quarter actually
[24:28.520 --> 24:31.760]  we have quarterly goals and so I'll go to test more. And there's a question back there.
[24:31.760 --> 24:33.400]  Perhaps it's the last one. Hi.
[24:33.400 --> 24:39.360]  Do you respect the science to come to your projects being open source in the US? How?
[24:39.360 --> 24:43.160]  Oh, other designers contribute. Oh, we've not had that yet. That's a good question. We
[24:43.160 --> 24:48.120]  might have to talk about it. So we have our design system that's quite open and everything.
[24:48.120 --> 24:52.760]  I mean, you could submit a pull request for pretty much anything, including our design
[24:52.760 --> 24:57.160]  system, but we've not quite had external developers. We are obviously interested so
[24:57.160 --> 25:03.160]  we can talk. Yeah. Thank you. Do we have time for more questions or are we? One more question
[25:03.160 --> 25:07.160]  if there is. Oh, hi.
[25:07.160 --> 25:14.160]  Thank you. Thank you. I'm curious since you haven't done much user testing so far, you
[25:14.160 --> 25:20.160]  mentioned, how have you been able to prioritize or how have you decided on what, for example,
[25:20.160 --> 25:25.160]  things you want to release first like notifications? That's, that's, yeah, that's a good question.
[25:25.160 --> 25:29.160]  When we first arrived, there was a question of what the priorities should be. But there
[25:29.160 --> 25:33.160]  are a lot of issues with Open Project through feedback we've got from our users that we
[25:33.160 --> 25:38.160]  already know about. We already have a backlog that's, I wouldn't say considerable, but we
[25:38.160 --> 25:42.160]  do have a backlog of known issues. So we thought we'll work on those first because we know
[25:42.160 --> 25:47.160]  that customers have told us that there were certain improvements and notification center,
[25:47.160 --> 25:51.160]  which was a passion project actually initially within the company. But it was also because
[25:51.160 --> 25:56.160]  we got some feedback about improvements that we could do. And it was also a feature that
[25:56.160 --> 26:00.160]  I think was quite required. It's quite a basic feature as well. So we were very happy to work
[26:00.160 --> 26:05.160]  with it. Thank you, everybody. And if you have any questions, we can get them.