Tobias Bernard – GNOME Design: A Report From the Trenches #FOSSDesign

Estimated read time: 1:20

Summary

In Tobias Bernard's talk at a FOSS design conference, he discusses his experiences and insights as a designer for the GNOME project. He highlights the evolution of design within open-source projects like GNOME over the last eight years, emphasizing the shift towards user-focused, design-driven software. Bernard provides a unique view of the challenges and successes faced when integrating design in free software projects, outlining the structural setups and cultural shifts necessary for fostering a productive design culture. He also discusses the current state and potential future directions for GNOME's design and user experience initiatives.

Highlights

Tobias Bernard shares his design journey at GNOME, full of interesting challenges 🎨
The growth of third-party apps in GNOME's ecosystem has been explosive 🚀
Design-driven software liberates users beyond the hacker community 🌍
GNOME sets a great example of design integration in open-source projects 💪
User-facing improvements in GNOME are attributed to a strong design ethos 🖥️

Key Takeaways

Design-first approach is crucial for broader software usability 🎨
Strong community and organizational culture support successful design integration 🏗️
The explosion of third-party apps shows the vitality of GNOME's ecosystem 🚀
Upstream first ethos helps tackle root problems, improving overall software quality 👏
GNOME's collaborative design culture offers lessons for other open-source projects 🔥

Overview

Tobias Bernard's engaging talk at a FOSS conference provides insights from his role in GNOME's design journey. As a seasoned designer since 2016, Bernard shares how GNOME integrates design into its culture, evolving it into a key part of the system's development alongside coding efforts. He reflects on the transformative impact design has had in making free software more accessible and appealing to a wider audience.

Bernard discusses the proliferation of third-party apps within the GNOME ecosystem, citing it as a major evolution over the past eight years. He credits a strong, designer-friendly community and an effective upstream-first approach with this success. The talk delves into how GNOME's design ethos has addressed significant structural and cultural challenges, bridging the gap between developers and designers and fostering a successful collaborative environment.

The presentation also touches on areas for improvement and future directions, including more focused third-party app support and tackling challenges in software readiness for users. Bernard's insights are invaluable for understanding how a thriving free software community can continuously improve its design strategies to benefit users and developers alike.

Chapters

00:00 - 10:00: Introduction and Context The chapter begins with a speaker being welcomed and expressing gratitude for the invitation. The speaker reflects on how attending and fitting this event into their schedule was a spontaneous decision but ultimately rewarding. They also comment on the previous talks and how they have noticed a similarity in the questions posed, though each talk offered a unique perspective.
10:00 - 20:00: Personal Background and Experience The chapter "Personal Background and Experience" provides an overview of the speaker's role and experiences within the Gnome project. The speaker identifies as a designer, which has naturally led them to take on responsibilities akin to a community organizer. This dual role stemmed from the necessity to drive initiatives within the self-organized setting of the project. The speaker has been involved with Gnome for a significant period, highlighting both their commitment and accumulated expertise in this open-source community.
20:00 - 30:00: Gnome Project and Design Philosophy The chapter 'Gnome Project and Design Philosophy' begins with a personal account from the narrator about their professional experiences since 2016. They mention working for Purism on mobile projects, including the development of liberta and other mobile platform initiatives. More recently, they have been involved in co-organizing a project with the sovereign tech fund, contributing to both organizing and some design work. The narrative sets the stage for discussing a talk the narrator gave in 2017, hinting at personal changes since then.
30:00 - 40:00: Impact of Design-Driven Approach on Gnome The chapter discusses a 2017 talk given at a free software conference in Italy where the speaker emphasized the importance of design in free software. The main point was that without a design-driven approach, free software may only appeal to nerds or companies that potentially restrict freedoms. For software to truly empower users, it must incorporate structures that support emancipatory design principles.
40:00 - 50:00: Challenges in Open Source Design Integration The chapter focuses on the challenges of integrating design into open source software, emphasizing the importance of considering the needs of users who are not hackers. It argues for design-driven free software that is practical and beneficial to a broader audience, beyond just the hacker community. The chapter also touches on the research conducted on how certain projects have managed to achieve this balance.
50:00 - 60:00: Gnome's Design Team Structure and Culture The chapter explores Gnome's design team structure and culture, highlighting various ways designers integrate into the team. Some join externally, while developers internally transition to design roles, influencing the culture. In the early 2000s, Gnome improved its design culture when it was in a critical state and needed to work effectively. Companies got involved by funding design and implementation efforts, which helped shift the culture positively.
60:00 - 70:00: Gnome's Ecosystem and Collaborative Efforts This chapter discusses the importance of having designers involved from the start of a project to ensure its success, using examples like the elementary project. It reflects on the progress made over an eight-year period, particularly in terms of the development and evolution of app ecosystems, highlighting how small app ecosystems have changed significantly over time.
70:00 - 80:00: Successful Initiatives and Contributions The chapter discusses the significant growth of third-party apps, particularly in the Gnome ecosystem. Over the past eight years, there has been a surge in high-quality, well-designed applications created by independent teams. These groups often follow upstream guidelines from Gnome, benefiting from external design work, reflecting a major structural change in the development landscape.
80:00 - 90:00: Future Directions and Strategic Considerations In the future directions and strategic considerations chapter, the focus is on existing software like Thunderbird. Although there is recognition of significant effort in organizing, fundraising, and recruiting, practical challenges persist. Despite improvements, issues such as duplicate tab bars and multiple widget implementations remain prevalent.
90:00 - 100:00: Discussion on Metrics and User Feedback The chapter delves into the complexities of legacy software and its resistance to change even under ideal conditions. It highlights issues in open source projects like LibreOffice, which still offers multiple user interface options that have remained unchanged for years and are described as not fully developed. This stagnation in UI updates is a significant point of discussion in terms of user feedback and software metrics.
100:00 - 110:00: Audience Q&A The chapter revolves around a Q&A session where the speaker reflects on a previous talk given in 2017, expressing that despite discussions with someone from LibreOffice at the time, no significant changes have occurred in software development in the eight years since. The speaker is, however, pleased with ongoing collaborations, particularly mentioning a positive interaction with Martin and the work with Inkscape.
110:00 - 115:00: Conclusion and Closing Remarks The speaker reflects on the improvements made over the last 8 years, acknowledging that many issues have been fixed but new features sometimes present challenges. They mention a tool for rounding a path that is both useful and confusing due to its settings dialogue. Overall, the speaker considers these changes to be a mixed bag, recognizing the progress while grappling with understanding new elements.

Tobias Bernard – GNOME Design: A Report From the Trenches #FOSSDesign Transcription

00:00 - 00:30 [Music] [Applause] uh welcome everyone Uh thanks for having me here Um I I'm actually very very happy in retrospect about the invitation It was kind of random and short term but I'm I'm happy that I made it work Um and uh yeah it's been very interesting to see like the previous two talks and sort of all all the very similar questions that that I faced at various points but like sort of from a different perspective So yeah thanks for that and
00:30 - 01:00 yeah today I'm here to talk a little bit about my experience uh doing design at the Gnome project Um a few words sort of about myself Um yeah as already said I'm a designer and I think through that um I've sort of often slipped into a bit of a community organizer role because like if you're a designer in a self-organized project sort of like someone needs to do that work and if you actually want stuff to happen you kind of end up doing that Uh I've been doing Gnome stuff since
01:00 - 01:30 around 2016 Um I've worked on a number of things since then For a while I was um working for Purism on mobile stuff We did liberta and like all of the sort of mobile platform things Most recently I've co-organized a project with the sovereign tech fund Um sort of both on the organizing side and also a little bit uh design stuff And yeah that's me Um and I want to talk this start this talk with uh a talk that I gave in 2017 Yeah I looked slightly different
01:30 - 02:00 back then Um but uh so I I gave a talk in 2017 at this free software conference in Italy um sort of trying to bring the good word of design to all these nice hackers Um and sort of I think my my basic um point was that uh without design free software it's just for nerds and like companies to sort of take away people's freedoms rather than you know giving people freedoms and if you actually want like emancipatory software you really need to sort of have structures that are able to take the
02:00 - 02:30 needs of people who are not hackers into account and sort of yeah all all the classic stuff like I don't think I need to explain this here uh and sort of my the thing I tried to to sell to people at the time was like we should do design driven free software which is you know uh like gives people freedoms but like really in a way that is sort of actually useful to more than just like whatever a few thousand hackers um and sort of the at the time it had done like a little bit of research on like how various projects um got to that state and these
02:30 - 03:00 are sort of the approaches that I observed in practice it's like either designers kind of joining from the outside um or developers from on inside sort of like getting into into design and sort of changing a culture that way Uh or often what happens and I think what also happened with Gnome in some ways in the early 2000s is that like a project like it's really in a bad state and like a company needs it to work They get involved They like pay some people both to do design and also to implement it and sort of kickstarts that culture Or or I think another approach that's also been often successful in practice
03:00 - 03:30 um although I think too rare is you just start a new project with some designers on the founding team and then it sort of like has that DNA from the start I think elementary is like sort of a classic example Um and I thought for this talk it would be interesting like as a general frame to look a little bit at like sort of where are we eight years later like sort of how have various projects sort of pro progressed I guess Um and I think for me the biggest uh sort of thing that has changed in this in the meantime is basically that like um the the app ecosystem of like small
03:30 - 04:00 to medium-sized third party apps especially around grome but I think also some other ecosystems has exploded like we've seen literally hundreds of new projects in those last eight years of like very well-designed uh very high quality apps maintained by like sort of completely independent teams and and and groups generally but like sort of following for example like upstream hig from Gnome um like benefiting from the design work done elsewhere So I think like that at a structural level is is like I think maybe the biggest thing has changed Um but then looking at some
04:00 - 04:30 other existing software uh I think the story is a little bit uh less less ideal Uh I looked at Thunderbird the other week Um and like I think it's an example of someone who like put in a lot of effort and like I think has done some really good work organizing um both like on the fundraising side and like sort of on bringing in new people like improving their structures at least from the outside I don't know But then like you look at it in practice and there's still like a lot of really messy stuff like there's still two tab bars like for every widget like you can see like three different implementations of it Um it's
04:30 - 05:00 I mean often like the nature of the beast is like that complicate that software is really complicated It's been there for a very long time It's hard to change even with like sort of ideal conditions And then you look at projects with like less ideal conditions Uh I think Libra Office being the classic one Um they still have this dialogue where like you can choose between seven sort of like different main UIs and they all still exist This has not really changed in the last eight years Um they're all like slightly halfbaked at least in sort
05:00 - 05:30 of I don't know uh it's yeah uh it's always tricky because and the funny thing is like the the talk that I gave in 2017 I had already made this this exact point and there was someone from Libra office there and we talked a little bit about it and I think like eight years later nothing has changed um but I think like uh yeah uh there's there's there's different um levels to which software has changed Inskscape I'm actually very happy that uh uh Martin was mentioning earlier that that you're like starting to work with them a little
05:30 - 06:00 bit Uh I think they've improved a little bit in the last 8 years They've fixed definitely a bunch of stuff but then sometimes they add new features that look like this Like this is the tool to like round a path and like I I it's useful like I use it all the time like we want to non-destructively like round a path Uh but like it has this settings dialogue which I do not understand and I use it all the time So um so yeah a mixed bag I would say Um but I think like something I've come to realize like after whatever looking at a
06:00 - 06:30 number of projects and so like trying to get involved in places is like a lot of projects just are not really like structurally set up to work in the design first way and actually like getting there is significantly harder than I think I maybe naively thought at the time uh like you don't just like go tell people like oh do design first and then just sort of happens like even if you like lay out pathways like it there's a lot of really difficult additional factors uh because I think like there's just like the the material reality that you're sort of often talking about like how people spend
06:30 - 07:00 their free time and it's I think very very difficult to tell people like you know how to do that um the the cultural like sort of affinity to design like sort of needs to at least a little bit be there otherwise you're like always going to be fighting a very uphill battle I think as the the previous talks have already uh have already sort of explained in more detail Uh I think often uh another problem is that like the stuff that people want to work on um is important
07:00 - 07:30 right like they need to clean up a lot of technical debt um they like are working with very few resources so they don't really care about the UI in the first place Um there's there's just like sort of a a really it's actually getting that kind of thing started for a designer coming in or like for someone even who's already in the project like sort of getting a a big sort of cultural change like that going is very difficult especially with no resources Um and I think that the cycle is sort of like you have a bad design someone tries to join
07:30 - 08:00 it's like too hard they like are like h okay I get maybe I'll go somewhere else where it's easier and then the people who are left are still the same ones and then sort of nothing really changes Uh but what what does also happen is that then those people go to the places where it does work and then you have like sort of this right like looking at the five examples from before you have this sort of like uh rich get richer situation where like some projects or some areas where stuff works like everyone just kind of accumulates there because that is where you get stuff done and then the other projects are yeah as we saw like
08:00 - 08:30 still the same as 8 years ago Um and so I thought like maybe for today like one helpful input here to the discussion although I don't know how how scalable to other situations is like what does a culture look like where it kind of does work because I think we have sort of seen this this accumulation effect around the Gnome project a little bit in the last eight years and yeah uh that was sort of uh my my general frame for for this part of the talk So I'm assuming most of you are familiar with the Gnome project Um but just in case
08:30 - 09:00 someone isn't um for context like it is a desktop environment So basically like most of the like visible parts of an operating system Um this is a screenshot um of one of their more recent versions Um the project is like very large and like has a lot of different different parts to it Um I think at the core of it it is a community of like a few hundred um people like who work in a self-organized way Um some of them are volunteers some of them are full-time Many are like sort of a mix of both Um
09:00 - 09:30 it's yeah as I said like sort of a complete independent operating system stack that has everything from uh the toolkit to like make the apps um to um like the low-level things that you need to like do input stuff to a compositor like a shell like all all of the things that you need And then there's a pretty large app ecosystem around that of like the core apps that come with the system uh circle apps that are sort of like the whatever uh verified third party apps and then just like other third party apps that are around that And I think
09:30 - 10:00 another part that's important uh like is that uh GMO developers um tend to intervene sort of across the stack if something is needed elsewhere to unblock something we need And so there's like a lot of connections to other adjacent projects um that's that are part of that stack Um our design structure is currently around 5 to 10 people depending on how you count Also a mix of like full-time and volunteers Um we do everything from like the operating system to the apps to
10:00 - 10:30 the websites the icons like everything Um and it's sort of like recognized to be our responsibility and like yeah I think I I think we're we're well integrated in uh all of the processes that are needed uh to like whatever make changes in the project um sort of like plan initiatives stuff like that Uh and I think another important part is that's a relatively stable group over time I think since 2017 or so like four people have sort of remained stable for that entire time Um a bunch of people like
10:30 - 11:00 have joined recently and sort of I think are are sort of getting into that that more more stable um uh more stable sort of I don't know uh long-term contributor position And so I think it's it's a healthy group from that point of view Um it's very difficult to sort of explain the the way the various groups inside the project sort of like interact with each other but I gave it a try Um so basically like at the core of everything are the modules like the individual software repositories right like the
11:00 - 11:30 compositor um the shell um the apps like all of those are modules and they have maintainers uh could be one or multiple people who like make the releases they like do the care work around like the repository reviewing stuff charging issues stuff like that And then you have like other people in the project or from outside who like contribute to those Um and then you have sort of like projectwide structures that um that coordinate specific areas For example you have the internationalization team that like does obviously internationalization Uh and then there
11:30 - 12:00 are like individual language teams under that There's a release team um that takes care of like yeah making releases twice a year um whatever making sure that like the freezes are are um being respected making sure that uh the dependencies build and stuff like this And then the design team does this for all the userf facing parts of of the of the project And so anything in the project that like affects the user experience in some way like the design team is involved with and sort of like everyone understands that to be the case
12:00 - 12:30 So like if someone wants to make a change there like they ask the design team or ping us on gitlab or whatever Um and like generally it is assumed that like if a larger sort of user affecting initiative happens um sort of they like the design team is involved from the start I guess Um a little bit about how we work um sort of I think generally um we we don't like do a ton of like fancy whatever tooling stuff I think we basically draw mockups in
12:30 - 13:00 Inkscape and then like sort of discuss them Uh but there are also people who like whatever draw their mockups on paper or like use penpot or Figma or whatever else Uh we don't super care about that because to us like designs are like an artifact of the discussion and those discussions are the important part So like that's usually like in a GitLab issue or in matrix or like on a design call and um sort of generally the the way stuff works is um like we have we have the mockup like repositories on GitLab as an archive more than anything
13:00 - 13:30 Um and that is that is sort of like our way of working here also because we don't really have enough designers to like actually keep mockups up to date or something It is always like an artifact of a of a discussion Uh and then I think generally another important part is that like we're um we're very well integrated in the development process So like when something is being developed like as a designer like I built the latest version of the merge request I give feedback like yeah I it's it's it's reviews like
13:30 - 14:00 anything else Um I think another very important part to like sort of why design works the way it works within Chrome is just the general project culture Uh even independently of design I think we have a very strong upstream first ethos which is sort of the idea that like if you see a problem somewhere you don't like work around it for yourself You look at like what is the root of the problem and then you go there and then you fix it Um you get involved in other projects if needed right like that's the sort of interventionism that that I mentioned earlier Um and there's there's really
14:00 - 14:30 like a strong dislike of of hacks and sort of short-term fixes and like always the idea of like okay but but how should this actually work sort of in the long run um I think something that we we inherited from like the the very early uh part of the project when everything was sort of yeah like a lot of independent modules that you could sort of like build your own desktop environment and like everything's really messy Um a bunch of like user researchers came in and were like uh there's five clocks here like what the no one understands this Uh and sort of it it there's like this famous blog
14:30 - 15:00 post called choosing our preferences from like 2002 that we still link to like every week uh which sort of like I think just yeah like presents this idea that like if you like add a bunch of preferences that's a trade-off like you're sort of creating that for yourself down the line um it's much better to fix the underlying default right we all know this I don't think I need to go into more detail here and then yeah like design first um in the sense that like um if something is supposed to happen that affects the user experience designers are involved from the start and it's not just like oh how does it look like how does it work no
15:00 - 15:30 it's like should we do this in the first place and I think that is sort of like a pretty uh I don't know like core thing that maybe sort of distinguishes us from from other from other free software projects and I think more generally there is like a culture um of like deferring to the expert I think this is an idea that I picked up from elementary like many years ago sort of that like in a discussion it's generally really helpful to like sort of look at like who are the people who like are the experts in this particular area and like is this is it my place to like whatever be annoying about this or like is it better
15:30 - 16:00 to like find consensus based on okay uh these are the people who like whatever have worked on this for way longer Um and I think especially that that sort of especially helps like bridge that that problem that was mentioned earlier right that we're like uh developers like don't trust designers I think we do have that trust and I think on on on that level it it really like improves collaboration Um I think another part that's that's important about is that it's like not itself a product with customers and so on and like there isn't a single group
16:00 - 16:30 that controls it Uh there are like a bunch of companies that are involved There are obviously like a lot of volunteers but um like Gnome is sort of like this ethereal thing like in the middle between like Redhead and and Endless and Canonical and so on And I think that really sort of like allows us to yeah be a bit more opinionated be a bit more um um yeah like user focused than like you would have to be maybe like if whatever you had customers Um and I think like there's it it also sort of like this this like diffused power
16:30 - 17:00 situation creates a situation where like people like move between companies but really what the thing they care about is the upstream project Um and so like the the employer that you have right now is not the one that we might have forever but this project never goes away Like Gnome is what stays right um and I think um sort of like uh talking about like the the general trajectory of the project over the last 15 years or so u the the main thing that we've been sort of focused on is like fixing the app ecosystem and like
17:00 - 17:30 actually creating an app ecosystem So I want to talk a little bit about that Um I think at the core of all of that is like the move from sort of distribution packages made by someone somewhere at some time schedule uh to developer like maintained flat packags on flatub because like then you can sort of ship an app today and like have apps downloaded tonight um and you know it's going to work and you know it's going to have all the dependencies and yada yada yada I don't think I need to explain this too much in depth but I think that's really unlocked like a whole
17:30 - 18:00 series of of things um for the app ecosystem Uh we have libert writer now which is our um like platform library that has all the custom uh all the the sort of default widgets Um so like in the past like if you wanted to make a list box you needed to like do a bunch of custom stuff with like uh CSS or whatever to just like get the standard list And now for that we have a widget as do we sort of as we do for like whatever 100 other things and lia has been I think a huge sort of improvement
18:00 - 18:30 in like making apps more consistent making them easier to build like improving the APIs to just like do all of the basic things that like you need to do to to build an app I think we've we've really seen the benefits of that in the past years Uh we also have a new app icon style or new I guess it's five years old now but it still feels new to me Um we we redided the app icon style a few years back and I think that's also been a huge success because it it's way easier to to do icons now and like we actually see app developers sometimes like get into it a little bit because they see like okay this is actually like
18:30 - 19:00 not that hard and sometimes they make okay icons just on their own but then like sort of as the designers you can just in way way way less time than before help them and like give them like a good icon and I think that's that's also improved things a lot Uh we have Gnome Circle now which is basically like a verification/ education program for third party app developers where basically we have a committee um that uh you can submit your app to and then you just like open a GitLab issue and then basically we we give them feedback um we
19:00 - 19:30 have a checklist of from everything from licensing to accessibility to uh like using the right design patterns like whether dark mode works whether like all all of the the things that you need to like have a really good app and we also focus a lot on education as part of this process um where like it's not just sort of we're not just trying to like fix this app we're also trying to um sort of um train someone to become a really good Chrome developers And currently we have around 65 apps in circle Uh although I yeah it could probably be 80 if we were
19:30 - 20:00 faster at reviews Um I need to get back to some reviews Um so um since I don't know like how many of you are like whatever following Linux like desktop stuff I thought I'd maybe include some examples of just like sort of apps that this process sort of has created in in the broader sense Uh and I just very quickly go through them Um there's a Wikipedia app called W Um there's this very nice resources uh like system resources monitor thing Um uh new slash is a very nice RSS reader Um there's
20:00 - 20:30 railway which uh like you uses the fact that like there's uh only one back end used by like most public transport companies and you can kind of like just use that that API and it works for like lobana It also works for like all kinds of like local uh whatever public transport things you can just like look for trains and stuff Um there's like a fretboard for looking up guitar chords Um Tuba has a master client um this very nice drum machine thing uh that I recently did the soccer review for and
20:30 - 21:00 uh yeah I don't know I I'm I'm just uh very excited uh that like people are making like fun little things to like make music with and stuff Um fragments is a sort of non-awful torrent client I would say Uh we have podcast app Um there's this thing which uh I really like uh sort of like there's a lot of like these small little tools for like for example web developers and stuff like that and I think this is a great example um which is like the thing to to like preview uh share cards uh for
21:00 - 21:30 social media platforms because otherwise you need to use some like awful website uh that that's whatever doesn't work half the time Um foliates um like ebook app um apostrophe is a very nice markdown app and so on just like some examples in in case people are not following this uh day-to-day Um a few sort of like takeaways successes uh failures and so on Uh I think a big success for us has been like having these easy points of entry I think for designers like having the app icons was
21:30 - 22:00 a really good sort of thing to get people started and then often like people start with that and then they get into more more stuff Uh and I think also third-party apps like you start with a very simple like third party app and then eventually you end up maintaining I don't know like the font rendering stack or whatever Um that's how it always works like sort of people start with something and and then they realize oh there's a much bigger thing here and actually there's other important problems around it I think since we're so self-organized um it's sometimes really good to have constraints For example like the freezes twice a year with a release Um or also
22:00 - 22:30 like if you have a grant sort of then you like maybe you could have done this on volunteer time but like also it's helpful to have um to have uh sort of that the extra little bit of motivation of like a timeline Um and then yeah I think we've seen that like good design attracts more uh design-minded developers um not just designers And that I think really helps because a lot of these people like to they know our hig maybe better than the designers and they like fix sort of just smaller like hig bugs across all the app ecosystem and that's really cool and
22:30 - 23:00 yeah I think developer tools like libert I think has been an absolute game changanger Uh some challenges I think in general planning has been difficult when we tried it I think for a while we tried to like have sort of calls throughout the cycle to like see if we can like coordinate stuff better But then in practice we noticed that like people either from their employer or like just on their their own time they already have their own agenda and you're not really going to influence that by like whatever uh having planning calls like sort of it's not really how it works unless you have resources behind it Um I
23:00 - 23:30 think scaling design reviews is something that we're still working on because there like I don't know we get pinged on GitLab a thousand times a day and uh yeah I think we we need to figure out how to like get that working more smoothly so people don't have to wait for weeks for a response sometimes Um I think there are some big initiatives where we have a plan but like we've never gotten it off the ground because it's like a huge amount of technical sort of like low-level work to actually unblock that For example tiling Um and um yeah I think we've we we need
23:30 - 24:00 to we need to figure out uh something to yeah maybe just like do more funding uh work to to get those kind of things off the ground Um and then yeah like another one that I personally want to do um eventually is uh encourage more large apps because I think we've seen a lot of small and mediumsized apps that are like very well-designed um and sort of like independently developed and so on but we haven't seen like the next Inkscape or something and that is something I would really like to see So yeah uh some some
24:00 - 24:30 learnings um I think focusing on the third party uh ecosystem really pays off because it just grows the developer base I think what we should also do as sort of a next step is like formalize the onboarding process more to like scale that better Um for really important stuff yeah just do the the work that's needed to find funding Um and then yeah maybe like there are problems with our developer story for large apps Like I don't know Uh but I I think maybe we need to find a large app Uh find we need
24:30 - 25:00 to start a new large app and like see what what that looks like Maybe it's going to improve the developer story as a result But uh yeah that's just like sort of some um learnings next steps for that Um so does any of this apply outside of Gnome i don't know Um I'm hoping that's at least an interesting example Uh there are a bunch of unique factors right like it's a huge community and like there's so many different parts of it Um the the tax stack is kind of like an island because like we make all of our own stuff and so like we're not super connected at that level with with
25:00 - 25:30 many other projects Um there's there's like a level of continuity in design that I think is rare Um there are designers like on the ground design team who've been doing this since the early 2000s Um and yeah have been employed full-time for most of that And so I think that is I'm not sure how well that translates uh to to other projects and yeah we have this very well established design culture that like in many other places difficult to to get to that level But I yeah I'm I'm I'm hoping that at
25:30 - 26:00 least like maybe on a strategic level something we can try the next eight years is uh instead of like trying to fix the apps where the design is really bad and like we don't really have a plan maybe we look to the places where like sort of the design side is figured out and we like grow those like maybe instead of uh I don't know like redesigning the current uh sort of Libra Office codebase we build a new like Libra Office front end in GTK using the rendering code I don't know Uh just an
26:00 - 26:30 idea Maybe that's not going to work out Maybe like the the real whatever solution is more organizing in those other projects figuring out the culture But yeah that that's that's sort of my strategic input Uh thanks so much Hi Um thank you Thank you very much It was very interesting Um I wanted to ask about how you what sort of metrics you use to measure when something's successful Like are you is it we don't
26:30 - 27:00 we don't even have a channel to users like we do research every once in a while but that's it Okay Right Like I mean we make a thing that is then used by Fedora to ship to people So like we there have been discussions about like doing some kind of metric system but as of right now nothing exists But like even like user feedback or anything like that from like the community or Oh sure Okay So that's basically Okay cool Thank you Actually uh that's a really
27:00 - 27:30 good question and it does open up actually I think a um a wider discussion it would be interesting to have Um just before I I I asked the question I will say that um I'm very disorganized personally even though I think I'm pretty organized as a designer I didn't actually know that someone from the Gnome Project was going to be speaking so I didn't just put that in my uh presentation because I knew you were coming up next Um uh like a really really good resource for uh for knowing whether a design is working or not is you know the dirty word telemetry right which is just getting um feedback about
27:30 - 28:00 what is clicked on what isn't clicked on Um is something actually being used or not And there are a couple of ways you can do that that are like uh open to the public that are you know you know not uh let's say going to attract lots of criticism but it is kind of a bit of a dirty word you know phoning home and asking people to you know opt in to you know to having what they're doing tracked even though in reality what comes back is usually just like you know 30% of users who open the app clicked on this 60% of users clicked on that it's
28:00 - 28:30 you know you could publish it openly for example I think is one way you could make it really transparent But I'm wondering do you have you had that discussion is that is like telemetry like a dirty word for your project as well i mean I think it is an active discussion like there are a few people who want to do it I know Endless has some kind of system like this uh downstream and they kind of want to upstream it Uh personally I'm I'm not sure because I I find that like there
28:30 - 29:00 are not that many cases where I'm like oh this is where some data like across all of our users would really help I think often what would help more is like more qualitative research but then also backed up by resources to address the issues because we have like done research exercises where like we still have findings sort of on the table from like years ago that we just don't have the resources to implement So I'm like I think there are definitely questions sort of on a day-to-day basis that where that would help but like to me that's not like an urgent issue Yeah I mean I
29:00 - 29:30 mean I think user test user testing getting feedback that stuff is like is absolutely crucial for me like telemetry is just more like identifying where there's smoke and then once you know you see that something's not being used at all You implemented some new system and you suddenly see a drop in usage for example or like session times reduce you know there's some instances where it can tell you oh there might be a problem here and from that then you can dig a little bit further but anyway um thanks for answering the question and really nice presentation as well with design um
29:30 - 30:00 with with UI kits in various programming languages there are often two different ways of creating an interface either you have a reactive type structure where you call functions in code and you nest those functions or you use something like um GT TK builder where you're using an XML file Do designers tend to have a preference to one or the other or is designer versus developer not a factor that comes into that preference i mean generally like the as the design
30:00 - 30:30 team like we this is the kind of decision that like we don't take uh right in the the sort of like spirit of deferring to the expert like if if the app developer like works best I don't know like uh doing things without a UI file I'm fine with that because I don't actually maintain the UI files like I sort of occasionally make changes to like minor things but I think mostly that's that's uh that's not our domain Okay Hello Um disclosure I'm from
30:30 - 31:00 Canonical so from Run of the Downstreams Um we um often talk about like quality when it comes to delivering a desktop to clients Um so I just wanted to know what's your internal perspective in the design team about like not just like providing um tools for people to improve the quality but also monitoring what gets out to users Um I mean like it's sort of tricky for
31:00 - 31:30 for us because generally like there are things that we can test easily right like anything built in flatp pack no problem open it in builder like test it today anything that's like deeper in the system sometimes you need to wait until like there's a dro that actually ships it usually that's like fedora raw height like whatever the week after the point0 and then like there the options you have for changing stuff are very limited because like you're even past sort of the the beta whatever freezes and so on Like you can't really change
31:30 - 32:00 strings anymore You can't really change UI and so like it it really depends on where in the stack that is For example right now like we have a thing with notifications um that like we landed whatever two months ago three months ago that like so like the feature is basically grouping notifications like visually in in like a stack sort of by by app Um and that's the kind of thing that you really want to test on your real system I can test in a VM but like that I don't get any notifications in the VM Um and so like I I think
32:00 - 32:30 ultimately long term what we need is like OS to become a thing that you can run dayto-day because then you can actually sort of like get those like day-to-day quality issues uh sort of catch them way earlier But until then I think yeah a lot of this stuff is going to have to be figured out basically in the DR integration uh process which is very far from ideal but uh it it is it is what it is at the moment Okay thank you everyone Can we get
32:30 - 33:00 another round of applause for all of our speakers today [Music] [Applause] [Music] [Applause]