Practical UX at OpenProject
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | 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. | |
| Identifiers | 10.5446/61930 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
SoftwareOpen sourceForceConsistencyModeling languageMetric systemDigital signalInformation privacyProduct (business)Digital rights managementCollaborationismDeutscher FilmpreisEnterprise architectureClient (computing)Information securitySoftware bugPhysical systemComponent-based software engineeringSigma-algebraElement (mathematics)Normal (geometry)PowerPointPosition operatorSoftware maintenanceCodeDifferent (Kate Ryan album)TelecommunicationElectronic mailing listOpen setSoftware developerElectronic program guideDigitizingQuicksortMarkup languageProjective planeEnterprise architecturePattern languageDigital rights managementGoogolSoftware testingSoftwareKanban <Informatik>Physical systemProduct (business)FacebookCodeFreewareDifferent (Kate Ryan album)Client (computing)Component-based software engineeringDampingExterior algebraBitINTEGRALFeedbackArithmetic meanSoftware bugCollaborative softwareFormal languageTraffic reportingMereologyOpen sourceTask (computing)Cartesian coordinate systemMathematicsPoint cloudEndliche ModelltheorieRevision controlPosition operatorMultiplication signConsistencyStandard deviationPoint (geometry)Computer fileConnected spaceDescriptive statisticsData analysisWebsiteView (database)Diagram
09:55
Server (computing)TrailMathematicsConsistencyWeb pageElement (mathematics)Functional (mathematics)CodePoint (geometry)Single-precision floating-point formatAcoustic shadowComponent-based software engineeringComputer configurationEndliche ModelltheorieGroup actionPhysical systemBuildingIRIS-TCore dumpMathematical optimizationChemical equationOpen sourceSoftware testingDisintegrationProduct (business)Shared memoryQuicksortElement (mathematics)MathematicsMultiplication signPhysical systemPresentation of a groupConsistencyBitSoftware developerDecision theoryMachine visionCodeSet (mathematics)Combinational logicInterface (computing)WordSingle-precision floating-point formatMathematical optimizationComponent-based software engineeringMereologyPlug-in (computing)outputGroup actionSoftware testingProjective planeBounded variationCartesian coordinate systemWeb pageDifferent (Kate Ryan album)BuildingWater vaporWebsitePoint (geometry)Arithmetic meanEmailSymbol tableGoodness of fitChemical equationOpen sourceProgram flowchart
19:45
Software testingPhysical systemComponent-based software engineeringDisintegrationCollaborationismInformation privacyExterior algebraOpen source
20:41
Mathematical optimizationMultiplication signPosition operatorBoss CorporationProjective planeProduct (business)Physical systemInformation privacySelf-organizationFeedbackPerspective (visual)Software developerOpen sourceSoftware testingBit
26:06
Program flowchart
Transcript: English(auto-generated)
00:05
So, this is the second talk related to OpenProjects. I don't know if anyone went to the talk about integrations yesterday. Anybody? All right, designers, I get it. This is Practical UX at OpenProjects. I've been working there for a year and a half, and these are musings about the
00:22
things I've learned, things we've gone through. It will all become clearer in a second. I'm Parimal, and that's a very elaborate site to tell you my name is Parimal, and I'm a UX designer at OpenProjects. I think we can all agree that the UX in open source could use a little bit of work.
00:43
I think it's fair enough to say that, right? We know the reasons, but very quickly, some of the challenges we've had. Data design. When you have data design in software, and open source tends to have this sometimes, it is not necessarily intuitive, which makes it less attractive to new users, because they're
01:04
comparing with a lot of other newer tools, and they tend to have all this shiny stuff, right? There tends to all sometimes be inconsistent behavior. The good thing about having contributors, all sorts of contributors over the years, is that it's open, anyone can do things, can add new features, but if you lack a
01:22
consistent coherent design language, then you do have the problem of inconsistency over time. There's also a lack of investment in designers. Now, this is, I think in general in open source, there's a lack of resources in general, right? Not always, but there tends to be this problem, and design does not tend to also be the
01:41
priority for a lot of projects. There's also this tendency of open source projects being engineering driven. Not necessarily a problem, because this can generally mean a very fully functional, very free, feature rich software, let's say, but that does not necessarily translate to
02:00
beginner friendly software, as we don't manage to, again, attract new users. UX and accessibility tend not to be immediate concerns of developers, if they're not necessarily topics that concern them directly. This also means that these tend to not be prioritized for that same reason.
02:21
However, there are some positives to UX and open source, and that's that UX has also taken this dark turn through all the Facebooks and the Microsofts and the Googles where there's a lot of dark patterns, and UX designers and a lot of companies are encouraged to produce these dark patterns. We tend to not have this in open source, because we tend to want to create things
02:42
that people like, and we're sort of bound by these values. I think the fact that we're in Of Fostum means we have these values, and there's a spirit of sharing, which is why we're all here, and things are getting better. I think that some of the talks at Fostum are showing us this.
03:01
That's the point at which we're starting, but then we joined, Mark and I, he's not here, but hi Mark. We joined Open Project in August 2021, and we were quite impressed, because Open Project, for quite a small company, decided to invest in two UX designers, which was quite a big deal for an open source project of about 30 developers.
03:24
So we have a product team of the two UX designers and the CEO. We take product decisions, but then we also try to work on the user experience. The reason I joined Open Project, because I come from a background of working in agencies, communication agencies, different world, with all the values that you guys share, that we all share, and seeing that a company was willing to put
03:45
the resources in, and the goal was to improve user experience. What does this mean for Open Project? To tell you this, I'd like to tell you a little bit about Open Project, because otherwise you won't know what I'm talking about. Open Project is an open source project management and collaboration software that looks, I'll show you the screenshots in a bit,
04:03
but I thought I'd tell you how we're organized so you get a sense of, perhaps, compared to other open source projects. We have about, I said we're a team of 30, about 15 devs, full stack, front, back, all that. We've got three product people, like I just said. We've got one QA, which I'll sort of connect to the user experience
04:21
a little bit, because if you can't test, it doesn't quite work. Business marketing, some HR, and then sales and support. That's it. That's our entire ship. We've got two versions, the free community version that you can just download and install anywhere, and the enterprise with the support. Quite a classic model. You can install it on-premises, on the cloud.
04:40
We also offer hosting within the EU if you don't want your data sent anywhere else. You can see some of our major clients, including Burchibun, who spoke earlier. The values that are very important to us are privacy, the data security, digital sovereignty. These are things that we're very, very passionate about, as are a lot of other projects who are speaking today.
05:04
It looks like that. List of work packages, tasks. This is actually what we're using to work on the new version that we're going to release in a couple of... Well, we'll see when it gets released. It'll be released this month. We work publicly using open projects, obviously. You can see a bunch of some features, some epics we're working on.
05:23
You could filter by priority, by status. I think you get the idea. You could go into a bug report that I submitted. This is all public, by the way. If you find a bug, you can also submit one. You can see the description there, the activity where you can really exchange with other users.
05:41
You can tag them. That's very important to us as well. Connect to other files. We talked about integrations. We have an integration with Nextcloud, so if you upload files to Nextcloud, you can link to tasks and work packages in open projects. I think that's a very common view,
06:00
a Kanban scrum view, if you want to drag things around. We have that too. We have a team planner, so if you want to organize your team and see who's doing what and reassign tasks, you can do that. That gives you a sense of what the product is. Let's go to UX at open projects. Some things have happened since I joined, since Mark and I joined.
06:21
We now have a design team. Previously, we didn't have one. It wasn't a priority. It was quite normal as well. Now we have two UX designers and a test person, a QA person, Ivana. We used to do markups in PowerPoint. It did the job, but now we're working in Figma, and hopefully we can move to Penpot at some point. We had a rudimentary style guide
06:43
of HTML elements, and now we have a growing design system with reusable components that we're going to look at in a bit. It was quite engineering driven, so you can see that a bit in the design as well. Now we're working alongside devs to get some early feedback.
07:02
We're not at loggerheads. It's not devs versus designers. We're trying to work from scratch and get early feedback. These are things that we are changing within our way of working. We all know the benefits of better UX, but for us,
07:20
we've realized that even clients that have used our software for a very, very long time, if we can offer optimizations, even mine now, that's worth the time and effort. Of course, attracting new users is very important to us, because we're not trying to only be the open source project management tool. We're also trying to compete as an alternative to the proprietary tools.
07:42
The challenge is, if you read the abstract, that was something I promised, and I will try to deliver. Us designers have a temptation to want to say, be helicoptered into a project and design everything from scratch. I see that, I'll put something on Figma,
08:01
let's do this. It's not that easy, I think you guys know this, because when you're working with an open source project, there are certain contextual constraints, let's say. Let's put it that way. It tends to be quite large open source applications, so you can't just change one thing and propagate it
08:20
throughout the whole application. For example, the same element, say a dropdown or a button, can appear very differently in different parts of the application, but not just visually, it might be implemented differently in all those places as well. Because again, multiple contributors over the years, no coherent design language.
08:40
Sometimes you can even have different code layers. In our case, we have Angular and Ruby, which means the views aren't rendered quite the same way everywhere. The time, if you come up with a new design, it has then to be developed, and that time, that's time and effort that's competing with new feature developments, with maintenance,
09:00
with bug fixing, and general dev time. You can't just say, I've designed this, implemented it, and we will move on. You've got to balance it with all these other things. Of course, we realize that when you design a new feature, the requirements are very different between pro users and new users, who are used to certain ways of working.
09:22
You say, oh no, we're going to change something completely. The risk of that is, of course, the classic XKCD. I don't know if you know this one. There are 14 competing standards, and you're like, oh, you can't have that. We need to develop a one universal standard that works with everybody, and then you end up with 15 standards. We don't want that.
09:41
Of course, data analytics helps you get a sense of what users are doing, what they want, where they're getting stuck. You could use Google Analytics, or you could not use Google Analytics like we do, and not have that data, because it's very important for us not to track our users. That makes our work slightly complicated
10:01
because we don't quite know what people are doing, but it's very important to us that we don't do this, especially because again, the data would not be necessarily be within the EU. Having said that, we managed to ship our first big feature when we joined Mark and I. It was a notification center. We were very proud of it because we didn't have
10:21
any process, no UX process, and we still managed to do it. Before this, all notifications in OpenProject were email-based. If you had a new work package, a feature, someone answered it, added a new requirement, you'd get an email alert. You couldn't follow it within the application, so we designed this. Extremely proud of it,
10:42
but it did ruffle some feathers because we said, all right, now the emails are only going to be digests, not for every single notification, but some people will be used to this. We are extremely proud of this feature, but we also learned that you've got to ease users in with these big changes. Perhaps we need to start small.
11:03
Small means sort of manageable, developable, maintainable, testable, don't scare existing usersable. That's sort of what we mean by small, reasonable, in other words. When you want to change these things, there's a couple of different ways to go about it.
11:23
You can change one thing everywhere in the application. Let's say a button. The button that we had doesn't quite work. We want to change it. We want to make it better. You could make that button the same, the new version, everywhere, but then individual pages would not be consistent. Or you could change everything
11:41
in one page. The settings page, we're going to update it with new components. We're going to make it standard. But then that standard, across pages, it's not very standard, is it? You've just changed the problem a little bit. The approach we've gone with is we want to standardize the elements first. Remember how I told you that the same elements
12:01
could be implemented in different ways in different places? Well, what if we first standardized the implementation, the HTML, the actual code of that element, and then we can modify it, can't we? Once we come up with some sort of consistent way of doing it. That'll also help us understand how these elements are being used and the different variations
12:21
we'll need. I'll give you an example. For a design presentation, it's been a lot of words, hasn't it? More images, please. This is the date picker that we used to have, and that's the date picker we have now. We changed it because we introduced a new feature which was taking work week into account, so being able
12:42
to say that Saturday and Sunday are holidays, or it could be a Friday, depends on your company. When we did this, we took the opportunity to upgrade it, and beyond this aesthetic change, you'll notice that was an opportunity for us to then work on all these elements to try to
13:00
better define what a button should look like, what an action bar should look like, what the blue, when you tab across the application and you're changing the focus, what that should look like because that wasn't very consistent either. We took this opportunity of new feature development to create these components and not just things that are visible, but also things that are invisible
13:21
like this, which we didn't quite have in the past. That does mean that for now, you won't find this all across the application. They're parts of the application that don't respect some of the things we've defined, but we are going iteratively one step at a time. To do that, we need a design system. We call it the single point of truth, SPOT, and if there's a component
13:42
that has not been included in the design system, we say it's not been Spotify'd. They can't really sue us. What is a design system? First, it's a consistent, dependable, reusable and documented set of things. These things could be styles, colours, spacing,
14:00
things I showed you. It could be components like buttons or text boxes, any of the little components that bigger interfaces are built out of. And then patterns, a combination of these things. The last bit is very important. You've got to then document it and tell people how to use it, when to use it, what to do, what not to do.
14:22
Of course, as being an open source company, we publish all of it in our website. Anybody can go and look at it. Now when we say spacing2, everybody knows, the developers, the designers and the testers know what that spacing should look like. Same thing for action bars with the different variants, and then we go to our website and then we try to explain
14:42
those variants and how to use it. And this is public in our website. It's not complete yet, we're still working on our design system so not all elements are there. But we are working on it. How's the speed? Am I speaking too fast for anyone? It's alright? Okay, well I'll take a bit of a break and bring some water.
15:02
You can appreciate our design system. So in some startups they say build fast and break things. We can't afford to do that, that's not our mantra. Our mantra is to build slow, iterate, and test things. I say test things, we've not quite done it yet.
15:21
That's our goal for this year. We want to balance UX optimizations with feature dev, but like I showed you with the date picker, perhaps if we spend 40% of our time with feature development we take that as an opportunity as well to optimize and maybe choose five core elements and then fold them
15:41
into our design system and try to make those consistent. Which requires, that means that there will be imperfection and there will be inconsistencies within the application. Our goal is to accept that imperfection and to keep moving, because again the developer doesn't like
16:01
when things are inconsistent or some developers want it to be pixel perfect but sometimes it's not going to be. For those of you who speak French le mieux et les enemies du bien the better is sometimes the enemy of the good. Sometimes you've got to accept the good enough to move forward to where you want to be. Very philosophic, I know.
16:23
The learnings for the past year and a half, it's very happy to be able to put that half symbol there. I thought it looked quite cool. So the first thing is you can't just join the project, be helicoptered in and magic won the whole thing and say, great, we want to just change everything, let's do it.
16:41
Upgrade it to 2024. You need incremental upgrades because you need everybody in the company to believe in what you're doing, be convinced it's worth the effort and luckily we have that sort of an project but it's not an easy thing to do because there are competing
17:03
requirements, competing priorities and how a company should use its time, so that's important to accept, incremental. Standardizing things now means a lot of time spent now, but down the road it gives us more time to do more relevant
17:21
work. It's less time because things are already standardized, if we change a color, if we change a design, it'll change all across the application. We need to be pragmatic, try to make something a little better with every release and not go for everything in one release but sometimes we do want to go for those big changes like we did with Notification Center. It might ruffle some
17:41
feathers, but those changes are required because we have a vision for where the product needs to be. However we've learned, perhaps the hard way, that we need to ease our users in who are used to the old system, help them understand why we're doing it and in that regard we also plan on communicating more from the product team perhaps publishing the why and the how
18:01
of how we work, why we take certain decisions and finally we could learn from other open source projects, as designers I mean because developers do it quite a fair bit and I don't think we quite have that culture amongst designers and we're currently working on theming and I saw a presentation by Mathieu Mathieu Bue from Proton
18:20
who was in Paris where, it was last year and he was explaining how his company worked on theming and all the things that he did that were wrong and what he learned from and we were able to use that and learn from it and that helped save us time sort of get a better sense of what we were doing so thanks to Mathieu who's not here but I think that sort of sharing
18:41
is very important, we should do more of that and we really hope that this presentation maybe hopefully one day can help someone as well so what are our plans for 2023 then? More UX, shocking I know so more UX, so work on the design system, continue working on it rather, more testing
19:00
because we've not really done any testing now we haven't had the resources but that's one of our plans, even a basic hallway test where you ask five people what they think and if they understand the feature, is some input we want to integrate more with other tools part of doing that is to take the design system and make it easy for someone creating a plugin or trying to
19:20
integrate with OpenProject to use those design elements as well so that's one of the reasons we're working on the design system as well and of course better theming, like I just mentioned and accessibility is something that we have in mind but we could do a lot more, we could be a lot better at that, so that's one of our goals and of course we've got the usual suspects
19:40
the ongoing optimisations and new features along the way the goal of course then is to have more users who say they've picked up OpenProject for the UX not just because it's open source of course we want them to pick up OpenProject because it's open source of course, but if they say we tried a bunch of tools, we think you guys have
20:00
really good UX, that's our goal but why stop there let's go further, a broader goal is to build an alternative to Microsoft 365 with all the other actors some of whom were here at Fostum right, so Nextloud, OpenExchange Elements, XWiki, Collabora, with all these other players
20:22
let's give users an alternative that's respectful of their privacy that is open source and that respects data sovereignty and if you're passionate about these things I'm certainly not telling you that you should, you know, whether these companies are hiring, but they might be just saying
20:41
thank you very much for giving me some time and if you have any questions, I'll take them now yes thank you, all those things
21:06
my question is, is having your CEO on your product team too? that's a great question actually, because for us, designers
21:21
can also go too far so we can also have, because we want to change things very very quickly, but there are some very pragmatic questions that are also development related, but also let's say related to the product roadmap we think it's quite helpful, because then we can have that discussion internally and align ourselves rather than be at
21:41
loggerheads again like you can have designer versus developer you can also have designer versus product, so we try to avoid that, so we think it works well yes, sorry a few years
22:07
the UX improvements that you showed
22:31
last year as an organization but I realized that especially in open source
22:41
products, very privacy focused from my perspective it seems like usually it's a very lab first adopters priority among all of us there's just not an easy way to measure do you have any suggestions as like an organization that's paying for the product
23:00
that really appreciates this work and wants it to be known by your boss or someone like that this work is important to us ok, so I'll try to repeat the question so you said that one of the biggest complaints with the open project was the UX and some of the positives in the recent times have been related to UX, and the question
23:20
is, sometimes the early adopters tend to be the loudest and tend to get heard the most so how do we get better at listening to the community in general? yeah ok, customers of open projects so what recommendations would we have to them? well, we have two things we can say first of all, our community
23:42
discussions are open, so if you feel very passionately about a feature or a certain optimization we really welcome that feedback and we will engage with you it can be sometimes a bit tough to be on all fronts so sometimes it's true that feedback can be a bit lost, we tend to track it with both an open project
24:02
but our biggest perhaps our recommendation would be to engage with the community directly via by a community and also if you have an idea submit a pull request, that's also very that's not fair for a lot of people but thank you for using our project
24:23
yes, we will test more, we'll start small with hallway tests and this quarter actually we have quarterly goals so I'll go to test more there's a question back there, perhaps it's the last one other designers
24:40
contribute, oh we've not had that yet that's a good question, we might have to talk about it so we have our design system that's quite open you could submit a pull request for pretty much anything, including our design system, but we've not quite had external developers, we are obviously interested, so we can talk thank you do we have time for more questions?
25:01
one more question, if there is oh, hi great talk, thank you
25:24
that's a good question when we first arrived, there was a question of what the priorities should be but there are a lot of issues with OpenProject, through feedback we've got from our users that we already know about, we already have a backlog that's I wouldn't say considerable, but we do have a backlog of known issues, so we thought we'll work on those
25:41
first, because we know that customers have told us that there were certain improvements, and notification center, which was a passion project actually initially, within the company, but it was also because we got some feedback about improvements that we could do and it was also a feature that I think was quite required, it's quite a basic feature as well, so we were very happy to work on that
26:02
thank you everybody, and if you have any questions you can get there