With respect:
Your question “how does this work from here is there anything else i can do or say to lobby for this or something?” gets to the heart of how open-source projects like Ubuntu develop. The short answer is: bring data, bring designs, and bring code.
It’s very easy to sign up for a forum and tell developers (who already have enough to work on, often in their spare time) what you think they should do. While feedback is valued, simply stating a preference isn’t usually enough to change established designs. That’s not typically how impactful changes happen in open source. Here’s a breakdown:
Bring Data
It’s all very well to say “I think the cheese should be moved to the middle shelf of the fridge” without actually having any data to support it. Anecdotal evidence like “Some people think the cheese shouldn’t be in the salad drawer”, or “I think people who use other fridges prefer the cheese elsewhere” isn’t data. It’s opinion or hearsay.
To make a compelling case for change, you need evidence. This could involve:
- User surveys showing a significant number of users struggle with the current placement.
- Usability testing results demonstrating quantifiable improvements with the proposed change.
- Evidence from established Human Interface Guidelines (HIGs) that strongly supports your suggested placement over the current one.
You’re the one advocating for change, so the onus is on you to bring the receipts that demonstrate a clear benefit.
Bring Designs
How would this proposed change work in practice? A suggestion needs to be thought through from a design perspective.
- As @oac pointed out, what happens if a user moves their mouse to the top left for the Apps icon and overshoots, unintentionally hitting the Activities button? How is this interaction managed?
- How does this change fit with the overall GNOME desktop shell design philosophy and the Ubuntu customizations?
- Have you created mockups showing how this looks and functions, considering different screen resolutions or edge cases?
UI/UX elements like the Activities button and the Dash/Dock placement were thought about in great detail by both the upstream GNOME designers and historically by the Unity design team at Canonical. Changes aren’t made lightly or just because one person thinks it’s a good idea. There’s a design process, and proposals need to demonstrate they’ve considered the implications thoroughly.
Bring Code
Ultimately, open-source software is built by people writing code. Developers working on Ubuntu and GNOME have existing roadmaps, priorities, and bugs to fix. While suggestions are read, a concrete proposal becomes much more tangible and easier to evaluate if it’s accompanied by code.
- The most direct way to “lobby” for a change is often to implement it yourself.
- Submitting a patch or a merge request demonstrates feasibility, shows you’re invested, and drastically reduces the workload on the core developers.
- Even if the code isn’t perfect, it provides a starting point for discussion and refinement.
While we understand not everyone is a programmer, this is the reality of software development – ideas are great, but implementation requires effort.
In summary, to move your suggestion forward, you’d ideally need to gather supporting data, develop a well-thought-out design proposal (including mockups), and, ideally, contribute towards the code implementation. This is the kind of collaborative effort that drives meaningful change in open-source projects.
