After working on a 12+ week project looking at how to express in the varied UI's of three package repositories (npm, pypi and RubyGems) we can now see more clearly what developers, across skill and knowledge levels, use in package repository pages to make a decision on the security of an OSS located on a registry. These decisions are critical for better understanding trust, value, social proof and the knowledge of secure practices across developers and helps answer the question: how much do developers know about the security of their software supply chain?
This talk will cover: 1. The essential user research findings from the project, 2. How user research informed the UI style guide design build 3. What gaps and opportunities are here to continue design in the SBOM, Attestations and securing software repositories topics.
https://github.com/ossf/wg-securing-software-repos/tree/main/docs/attestations-style-guide
We spend enormous amounts of time and money auditing code for security holes. Whole industries are built around it. But for all that effort, we rarely look at the part of the system that is actually clicking the buttons and interpreting the warnings. The person with Dorito dust on their fingers and a coffee ring permanently branded on their desk, someone just trying to get things done in a tool that may or may not be helping them make safe decisions. A surprising number of real-world security failures happen not because the code is flawed, but because the interface leaves too much room for dangerous misunderstandings.
Drawing on our work at Ura with security-critical and open source projects, this talk explores how the user experience itself can introduce or amplify security risks and why these issues often slip through traditional code-focused reviews. We will look at memorable examples of user-driven failures, outline common UX surfaces where security risks emerge, and show why auditing the human side of the system is just as critical as auditing the code.
Open source thrives on collaboration, yet many people with disabilities remain excluded from fully participating due to inaccessible communication, documentation, and community practices. “Debugging Exclusion” invites open source leaders, educators, and advocates to rethink how accessibility is built into community culture, not just code. This talk focuses on solving the technical, social, and systemic barriers to disability inclusion in open source. Through practical frameworks and CHAOSS community success stories, participants will learn how to design inclusive contribution pathways, write accessible documentation, and measure inclusion using open metrics. Together, we’ll explore how accessible collaboration empowers creativity, broadens participation, and makes open source truly open for everyone.
*Learning Outcomes: -Recognise systemic accessibility issues in open source communities. -Understand the accessibility barriers faced by contributors with disabilities. -Learn to integrate accessibility testing tools and automation into open source workflows.
Gephi Lite is a web-based open-source network visualization tool built by a three-person engineering team. After two years of development, we had a functional application—and a nagging feeling that our interface wasn't working for users. The problem: we lacked the skills to diagnose what was wrong, let alone fix it. So we brought in Arthur Desaintjan, a design intern, to help us figure it out.
In this talk, we'll share how we approached design at a pivotal moment in our project's life—first by stepping back to clarify what Gephi Lite should really be, then by running user interviews that revealed just how far our assumptions were from reality. We'll walk through the specific findings that surprised us, the design decisions that followed, and what small open-source teams can learn from our experience about investing in design when you don't have designers.
Design systems evolved the process by which UI graphics are made, full with automation and deep integration. However, Open Source communities were left out of this bandwagon as most of the applications providing these capabilities were for pay or very limited for users.
Fortunately, a new wave of design system applications, led by PenPot, has made an appearance with a bold strategy and Open Source at its core. As such, KDE Plasma saw an opportunity to build something unique to develop the Plasma desktop faster and with higher fidelity to user experience standards.
This is the talk about the journey and current state of implementation at the KDE Plasma Deskop. In this talk we discuss graphics, colors, typography, graphical components and much more. How the journey took us from a limited application for pay to a fully Open Source system.
Open source thrives on contributions from developers, testers, and community builders, but design often gets left behind. With far fewer dedicated designers in FOSS than in the commercial tech world, usability issues go unaddressed, and end users feel the friction. The good news: you don’t need a design degree or a new job title to make a difference. In this talk, I’ll show how any contributor can use simple, practical design methods to identify and solve UX issues in their favorite open source projects. I’ll try to break down “design” into simple steps anyone can try, noticing where people get stuck, asking the right questions, sketching ideas on paper, and trying them out with friends or community members. No special skills or software needed: just curiosity and a willingness to make things easier for others. If you’ve ever thought, “I see the problem, but I’m not a designer” - this talk will give you the mindset and tools to step up and become one.
Understanding your users should be an important step of software development. In recent years, many end-user facing FLOSS communities integrated at least some aspects of design into their development. Unfortunately, most developer-centric projects still haven't started to even think about it.
This talk concludes two years of user research in Forgejo, a Git-backed software forge and collaboration platform. Forgejo can be self-hosted or used on a public instance like Codeberg.org to create software together, from sharing and reviewing code to tracking user problems, doing project management and doing design work.
Key points include:
The talk considers usage of eye trackers to track usability issues in FLOSS. The use of consumer-grade hardware eye trackers is considered for cases when there is an SDK for Linux available, and when there is not. A webcam-based software eye tracking approach is considered as well and compared with hardware eye tracking using illustrative examples. Visualization of short-term and long-term eye tracking data series is explained with sample code for Graphviz and GNU Octave. Examples of eye tracking heatmaps and their usage scenarios are discussed, as well as using mouse heatmaps as supplementary data.