On that last point, whilst GNOME already has Automatic Screen Brightness, and it is a good feature, dmy3k’s extension goes further on the specific machines with cool hardware: steadier behaviour with changing light, smoother transitions and brightness curves you can tune. One of the things I’ve been exploring with extensions recently is ’this feature, only more so’ and adaptive brightness is a good example.

Living far from the equator, evenings happen. The room goes grey, the window stops being a useful light source and GNOME is still cheerfully in light mode because I told it to be bright at the time one takes screenshots. Night Light is already doing its bit by then. The display has warmed up, which is nice, but the rest of the interface lacks the level of ‘darque’ required. I wanted the normal GNOME appearance preference to follow the day as well: light while it still feels like day, dark once the evening has properly arrived. Users of other operating systems may be aware of this feature, but for the purposes of this blog post let us pretend that everything below is entirely unique.

So I hacked up Sunset Appearance, a small GNOME Shell extension for GNOME Shell 45 to 50. At civil dusk it writes the same setting GNOME Settings uses:

org.gnome.desktop.interface color-scheme = 'prefer-dark'

At civil dawn it sets it back to:

org.gnome.desktop.interface color-scheme = 'default'

My dad was an aviator, so I got to hear a lot of exciting words growing up, such as ‘civil twilight’, which always makes me think of Romeo and Juliet. Sunset turns out to be a surprisingly slippery concept, and very longitudinally mediated. In London in summer there can be plenty of useful light after the sun has dipped below the horizon, and the desktop does not need to go ‘darque’ the moment the sun touches the skyline. Nautical and astronomical twilight are too late for an interface preference, and in some places at some times of year they can fail to happen in the normal way at all.

Civil twilight is when the centre of the sun is 6 degrees below the horizon and when it really does feel like the world has changed character.

Location is awkward too, because civil dawn and dusk need latitude, longitude and date. There’s some interesting fallback logic to infrequently get a coarse location (good enough for a city) and then fall back to cached data if available as Night Light already needs much the same information. Frequent readers will remember my concerns over London, Ontario being above London, England in many search boxes so there is no virtue in making the user type London into another small box. If neither source has usable coordinates, nothing changes.

Manual override behaviour is another thing that avoids annoyance. If the extension sets dark mode at dusk and I then change GNOME back to light mode, I meant that. After any override, it waits until the next scheduled dawn or dusk transition before touching the setting again.

Solar time code has an unreasonable number of edges for something everyone thinks they intuitively understand. Keeping with my aggressive policy on internationalisation the tests keep London as the ordinary case, then poke at time zones, date line longitudes, DST changes, Antarctic stations, Arctic towns, awkward offsets such as Lord Howe and Chatham and cases where civil dawn or dusk may not exist at all. My time reading brr and pretending to be in New Zealand to solve work bugs was not poorly spent.

Right now Sunset Appearance can be built from source. At some point I may choose to distribute it more widely, or even see if someone has already solved my problem better.

So I have been working on fuzzy time for a while. The first version I made was for the Pebble, which remains one of those devices that makes later technology feel slightly ashamed of itself. A small always-on screen, good battery life, physical buttons and just enough personality. It’s not tokyoflash after all.

The current versions are Fuzzy Time GB, a Wear OS watch face, and Fuzzy Clock GB, a GNOME Shell extension.

The Android version is quite a funny object internally. It is a Watch Face Format v2 face, so the APK has no app code:

android:hasCode="false"

The face itself is declarative XML. Since writing thirty-six thousand lines of watch face XML by hand would be a cry for help, there is a generator which writes the cases out from the same fuzzy time rules. For every hour and every five-minute bucket it emits the condition, text and separate interactive and ambient versions.

That sounds excessive until you look at the details; and then it still sounds excessive. There are lots of pernickety things that give this the correct GB locale to my ears. “Five Past Midnight” is a real phrase. 23:58 should say “Midnight”, and if the date is visible it should be tomorrow’s date. 11:58 should say “Noon”. “O’Clock” wants different spacing and weight from “Twenty-five To”. Ambient mode wants smaller, quieter text. A round watch face leaves less room than you think it does. The watch face has a few small choices rather than a settings cathedral: warm white, cool white, soft green, dim amber; system font or Arvo; optional radial complication slots above and below the text. The range complications are deliberately arcs around the edge rather than little widgets in the middle. They can show useful things, but they should not make the face stop being mostly words and calm black space.

The GNOME version is the same idea on a different surface. It finds the existing clock label, listens to the same wall clock, respects the existing “show date” and “show weekday” settings, and changes the text. I have wanted to build something like this for years, partly because of Emmanuele Bassi’s word clock extension. That extension was great, but not quite the thing I wanted, so eventually I got around to making my own.

One of the few design decisions left that I helped on in main GNOME (which is much better now) is that the shutdown and logout dialogue only updates its timing every so often. It could update every second; the computer is quite capable of counting. But it’s much more pleasant when the number doesn’t twitch constantly while you are trying to decide whether you meant to press the button.

You can build both projects from source. I may choose to distribute them in a more structured fashion in future. The Android one is a minimal Wear OS watch face, and the GNOME one is a normal Shell extension that currently supports GNOME Shell 45 to 50.

Since then the app has become a bit less narrow. But it now does enough more that the launch post undersells it, and in a couple of places sends people looking for the wrong name.

The app is now called Agile Rates. The application ID is still com.nedrichards.octopusagile, because changing stable app IDs is not exciting for anyone, but the name changed because Agile is no longer the whole story. Thanks to code from Andy Piper, it can also work with Octopus Go and Intelligent Go tariffs. Intelligent Go needs an API key because those prices are account-specific, but plain Agile and Go can still be set up manually.

That was the first larger change: setup had to become a thing.

The original app assumed you knew your tariff and region, or at least were willing to rummage in preferences until the graph stopped being wrong. That is fine for a scratch-your-own-itch project and a bit rude for an app on Flathub. The current version opens with a setup assistant. You can connect an Octopus account with an API key and account number, in which case the app tries to detect the active electricity tariff. Or you can keep it simple and choose the tariff and region manually.

The second change is the one I actually use most: finding the cheapest slot.

The launch version showed a graph and left the planning to the human. That works for quick glances, but most of my real questions are more specific:

When should the dishwasher run?
When should the washing machine run?
Is there a cheap three-hour block before tomorrow afternoon?

So there is now a “find cheapest time” tool. Pick a duration and it searches the available forecast window for the cheapest continuous block. The chart now scrolls to the chosen time instead of making you squint along the bars like you are reading a very dull railway timetable.

The graph itself has had a lot of tweaks. It has grid lines, clearer day boundaries, better current-price highlighting, less terrible dark-mode contrast, and layout rules that behave on narrower screens. The preferences window and main window are adaptive now too. Handy if you split your screen or have a Linux phone.

The biggest recent addition is usage history. If you connect an account, the app can fetch recent smart meter consumption data, cache it locally, and show a Usage view. That includes kWh history, a seven-day trend, an estimated monthly usage figure, and charts. It also tries to estimate spend by matching historical usage to tariff rates and standing charges.

Underneath that, the project has become more like a real small application. There are unit tests for pricing, tariff selection, adaptive layout, usage insights, and historical cost calculation. The development Flatpak manifest runs the Meson tests inside the GNOME SDK, which catches the class of bugs where the host Python environment was accidentally being too kind. Ruff is in the loop for linting. The app moved to the GNOME 50 runtime. Screenshots, AppStream metadata, branding colours, and icons have all been tidied up.

So the current description is: Agile Rates is a small GNOME app for UK Octopus Energy customers who want current and upcoming smart tariff rates, a cheap-time finder, and, if they connect their account, recent usage and estimated spend history. It is independent and is not affiliated with, endorsed by, or sponsored by Octopus Energy. I hope you find it useful.

I’ve been seeing a drum beat of interest in the internals of USB-C. Darryl Morley’s macOS WhatCable, Chromebooks exposing lots of lovely info about emarkers, USB cable testers and a bit more. Very infrastructure club topics. So I made a small GTK app also called WhatCable which is intended to show what Linux knows about your USB ports, cables, chargers and devices, but written as a GNOME/libadwaita app and using the interfaces Linux exposes through sysfs.

The hope was fairly straightforward: plug things into my Framework 13, ask Linux what is going on, and present the answer in a way that doesn’t require remembering which bit of /sys to poke. In particular I wanted cable identity and e-marker details. These are the useful little facts that tell you whether a cable is what it claims to be, or at least what it claims to be electronically. Given the number of USB-C cables in the house whose origin story is “came in a box with something”, this felt like a public service, or at least a satisfying evening.

The first bit is pleasantly sensible. Linux has standard-ish places for this information:

/sys/bus/usb/devices
/sys/class/typec
/sys/class/usb_power_delivery
/sys/bus/thunderbolt/devices

When those are populated, a normal unprivileged app can learn quite a lot. It can show USB devices, Type-C ports, partners, cables, roles, power data, Thunderbolt and USB4 domains. That’s exactly the sort of thing a small Flatpak app should be good at: read some public kernel state, translate it into something at least moderately human friendly and then depart.

On my Framework 13, the USB device and Thunderbolt sides were useful. The Type-C side was not. /sys/class/typec existed but had no ports. /sys/class/usb_power_delivery existed but was empty. This is a slightly annoying result, because it means the nice standard API is present as a signpost rather than a destination.

The next clue was that the machine clearly does have USB-C machinery, and not just because I could look at the side of the device. It is a Framework 13 with the embedded controller and Cypress CCG power delivery controllers doing real work. The relevant kernel modules were loaded, including UCSI and Chrome EC pieces. There was also an ACPI UCSI device at:

/sys/bus/acpi/devices/USBC000:00

but ucsi_acpi did not appear to bind to it and create the Type-C class ports. So the hardware and firmware know things, but they were not arriving in the standard Linux userspace shape.

Framework’s own tooling gives another route in. I built framework_tool from FrameworkComputer/framework-system and asked the EC what it could see. The Framework-specific PD port command did not work on this firmware:

USB-C Port 0:
[ERROR] EC Response Code: InvalidCommand

and similarly for the other ports. That’s not very poetic, but it is at least clear.

The Chromebook-style power command was more useful. With a charger connected it reported, for example:

USB-C Port 0 (Right Back):
  Role:          Sink
  Charging Type: PD
  Voltage Now:   19.776 V, Max: 20.0 V
  Current Lim:   2250 mA, Max: 2250 mA
  Dual Role:     Charger
  Max Power:     45.0 W

That’s good information. It’s not cable identity, but it is the kind of port state people actually want when they are trying to work out why a laptop is charging slowly, or not charging, or doing something else mildly USB-C shaped.

framework_tool --pd-info could also talk through the EC to the Cypress controllers and report their firmware details:

Right / Ports 01
  Silicon ID:     0x2100
  Mode:           MainFw
  Ports Enabled:  0, 1
  FW2 (Main)   Version: Base: 3.4.0.A10,  App: 3.8.00
Left / Ports 23
  Silicon ID:     0x2100
  Mode:           MainFw
  Ports Enabled:  0, 1
  FW2 (Main)   Version: Base: 3.4.0.A10,  App: 3.8.00

Again, useful. Again, not the cable.

Much of this investigation and app code was written with AI tools in the loop. That was useful for chasing down boring plumbing and generating probes. The decisive test was asking the Chrome EC for the newer Type-C discovery data directly. The EC advertised USB PD support, but not the newer Type-C command set. EC_CMD_TYPEC_STATUS and EC_CMD_TYPEC_DISCOVERY both came back as invalid commands on all four ports.

That means that on this Framework 13 firmware path I cannot get Discover Identity results, SOP/SOP’ discovery data, SVIDs, mode lists or e-marker details through Chrome EC host commands. The cable may well be telling the PD controller interesting things, but those things are not exposed through a stable unprivileged interface I can sensibly use in a desktop app.

This is the main lesson from the whole exercise: USB-C inspection on Linux is not one API. It is a set of possible stories. Sometimes the kernel Type-C class tells you lots of things. Sometimes Thunderbolt sysfs tells you a different useful slice. Sometimes a vendor EC can tell you power state, but only as root. Sometimes the information exists below you somewhere, but not in a form you should build an app around.

So WhatCable needs to be honest. It should show the sources it can read, and it should say when a source is unavailable rather than pretending absence means certainty. “No cable identity exposed on this machine” is a very different statement from “this cable has no identity”. The former is boring but true. The latter is how you end up lying with an icon (it is not a nice icon).

The current shape I think is right is:

• use USB, Type-C, USB PD and Thunderbolt sysfs whenever they are available;
• show raw values as well as friendly summaries;
• explain missing sources in diagnostics;
• treat Framework EC data as an optional extra, not a default dependency;
• if EC access is added, put it behind a narrow read-only helper rather than teaching a Flatpak app to fling arbitrary commands at /dev/cros_ec.

That last point matters. On the host /dev/cros_ec exists, but it is root-only. Making a normal app require broad device access would be a poor bargain. A small privileged helper that answers a few known-safe questions might be acceptable. A graphical app with arbitrary EC command execution would be exciting in the wrong way.

This is not quite the result I wanted when I started. I wanted to show a friendly “this is a 100W e-marked cable” label and feel very clever about it. What I have instead is a more modest app and a better understanding of where the bodies are buried. That’s still useful. A tool that tells you what your machine actually exposes is better than one that implies the USB-C universe is more orderly than it is. Given this, I’m not going to be sharing this one more widely, but fork away if you wish, or come back with a better idea.

It’s very easy to run with GNOME Builder, so just check out the source and ‘press play’ or get an artifact out of the Github Actions. If you run WhatCable on a different laptop and see rich Type-C data, lovely. If you run it on a Framework 13 like mine and mostly see USB devices, Thunderbolt controllers and a note that Type-C data is missing, that is also information. Not as glamorous as catching a suspicious cable in the act, but much more likely to be true.

The snag was not having an easy way to see upcoming prices on my Linux laptop. To scratch that itch, I built a small GTK app: Octopus Agile Energy. You can use it yourself if you’re in the UK and have this electricity tarriff. Either install it directly from Flathub or download the source code and ‘press play’ in GNOME Builder. The app is heavily inspired by the excellent Octopus Compare for mobile but I stripped the concept back to a single job: what’s the price now and for the next 24 hours? This felt right for a simple desktop utility and was achievable with a bit of JSON parsing and some hand waving.

I wrote a good chunk of the Python for it with the gemini-cli, which was a pleasant surprise. My workflow was running Gemini in a Toolbx container, building on my Silverblue desktop with GNOME Builder, and manually feeding back any errors. I kept myself in the loop, taking my own screenshots of visual issues rather than letting the model run completely free and using integrations like gnome-mcp-server to inspect itself.

It’s genuinely fun to make apps with GTK 4, libadwaita, and Python. The modern stack has a much lower barrier to entry than the GTK-based frameworks I’ve worked on in the past. And while I have my reservations about cloud-hosted AI, using this kind of technology feels like a step towards giving users more control over their computing, not less. Of course, the 25 years of experience I have in software development helped bridge the gap between a semi-working prototype that only served one specific pricing configuration, didn’t cache anything and was constantly re-rendering; and an actual app. The AI isn’t quite there yet at all, but the potential is there and a locally hosted system by and for the free software ecosystem would be super handy.

I hope the app is useful. Whilst I may well make some tweaks or changes this does exactly what I want and I’d encourage anyone interested to fork the code and build something that makes them happy.

Things that are great

Always the first thing to comment on with a new Endless release but the upgrade process driven by ostree is still class leading. A quick download, reboot and you’re in. And the reassurance of a quick and reliable rollback as well, always handy when testing a beta!

The star of the show is the GNOME 3.36 improvements, which have been well covered elsewhere. Many of these features have been on the Endless plan for years, some of them, like the login screen I remember discussing in the London Design Hackfest in 2017. It’s really exciting to see these kinds of long term projects delivering.

The aforementioned new Login is the first change you’ll see, the new design means no animation judders in reveal on HiDPI screens. Revealing inline password peeking answers a big user need. It’s just a much slicker experience end to end.

The new App Grid is just plain marvellous. It keeps the direct access to content of the initial design but the implementation now has a real solidity and materiality. With multiple pages the two finger scroll animation is a joy and it’s equally good on a touchscreen. The new folder position, reveal and hide animation is good as well. Similar to the login screen this animation enhances the visual stack metaphor and is a more predictable and scalable animation which thus performs better and adds to the overall tightness.

The process of manipulating app folders has also improved, although it’s still a little difficult to see when the app has been ’lifted up’, I recommend an additional animation that makes that clear and ideally warping the app icon to the center of the mouse cursor, as carrying around an icon that’s off center but having the effect of the icon being on the cursor breaks immersion.

Here and on the login screen you can really see the payoff for the literally years of upstream performance work that Endless engineers have put in across all areas of the stack. Not to disparage others but the Endless crew don’t always get the credit they deserve.

I love the new settings app, it has a much clearer layout and addresses some longstanding bugbears like easier linkage into OS updates on the About pane.

Parental controls worked very well. Having experienced them in other operating systems, the effort taken to make this consistent across the whole stack - down to the CLI - is a big differentiator. I love how the age categories react to your locale. The investment in OARS was a good thing. It’s a good idea to have them as a standalone app as well as a control center panel, although the panel looks a little bit sad as a standalone. Some width constraints for the central column would help a lot. Also, the target for the ‘Restrict Applications’ action looks like it should be the whole row, not just the arrow button on the edge.

Metered data seemed to work well. Still sad that there’s a fair bit of work ‘on the shelf’ for that to really flesh out the vision around logging, revealing and prioritisation but what’s there delivers to protect users.

Automatic app updates seem more reliable and there’s much less jank in the App Center. The category filtering and sorting controls work well. Amazing that we now have enough apps that just throwing them all at a screen doesn’t work any more! Flathub, another long term bet, has paid off beautifully there. There are still some issues with state ‘sticking’ (I seem to have a perpetually updating Scribus in my Installed pane which doesn’t show that state on the item page for instance) but this is a substantial improvement.

Moving the system tray from TopIcons to Ubuntu’s AppIndicators was a good move as well. Pragmatically some kind of tray is absolutely required for key customer apps like Dropbox and AppIndicators is the most polished end user execution of the concept. There are changes I’d make, but this isn’t an area that Endless can or should focus on.

I didn’t go through the first run experience, although I can see from the release notes that there are changes there. I can only say that in my experience motivated users aren’t swayed either way by a competent first run experience (check out the iPad first run if you disagree) and it was already competent.

Things to get better

We’re still all in on X11, which is still the pragmatic choice based upon resources and differentiation, however it’s starting to get obvious that the air cover a product like Endless gets from other parties investments in the graphics stack is breaking down. New features like Firefox’s video playback acceleration are starting to come to Wayland only and you’ve got to imagine that 20.04 will be the last Ubuntu release that has an X11 session by default. This isn’t a leap that needs to be made immediately but I’d be looking at resurrecting that testing branch we had a couple of years back to see any quality gaps and starting to include that in new device testing.

The in browser Exploration center is still A Bad Thing and the fact that the in toolbar Feedback path goes via there continues to irritate.

There’s a flash of unexpected content launching the Discovery feed which is a shame as it’s one of my favourite features, although, absent a way of keeping this more dynamic and integrating 3rd party apps I question the ongoing investment.

There’s not enough contrast in the alt-tab overlay at low screen brightnesses, Endless users care deeply about battery life and often run with low brightness, coupled with overall higher ambient light levels in their environments.

Search panels lack contrast in some corners whilst having too much in others. The interaction between the panel and the scroll bar (which will almost always be there on an Endless system as there’s so much more content) is ugly, give that a bit more space to breathe, even if it means being slightly asymmetric it’ll even up perceptually.

My conclusions

I feel incredibly satisfied with this release, even in an early state. Whilst I haven’t worked for Endless in more than a year this beta is pretty much where we wanted to be all along with regards to slickness and material coherence. It’s once you have that solid base that you can appreciate the differentiating features in the Endless experience.

Operating systems are a marathon, not a sprint. Coordinating features and experiences can take marshalling multiple communities, many years and a lot of effort. With 3.8 you can see a lot of the longer term bets Endless made a few years back paying off, I look forward to carrying on using this every day.

It was a great conference with a diverse crew of people who all care about making apps on Linux better. I particularly enjoyed Frank’s keynote on Linux apps from the perspective of Nextcloud, an Actual ISV. Also worth your time is Rob’s talk on how Flathub would like to help more developers earn money from their work; Adrien on GTK and scalable UIs for phones; Robin on tone of voice and copywriting; Emel on Product Management in the context of GNOME Recipes and Paul Brown on direct language and better communication. There were also great lightning talks including a starring turn by one of my former colleagues Martin Abente Lahaye who showed off the work he’s been doing to make the Sugar educational applications more widely available with Flatpak. After a bit of review and some polish in the cafe they’re now starting to appear on Flathub. All of these videos are available to watch in the YouTube livestream playback, and I’m sure individually soon when appropriately processed.

I gave a talk entitled Product Management In Open Source. Astute readers will recognise the title from the similar talk I gave last year at GUADEC, however the content is actually fairly different. Emel’s talk that I mentioned above covered quite a lot of the basic material so I concentrated more on how individual app developers could use Product Management techniques to make their own practice a bit more deliberate and help them guide and prioritize their work.

If you’d like to watch the video then you’re more than welcome, although I must warn you that I managed to lose my voice a couple of days before so my delivery isn’t exactly what I would wish for. Still, I think you’ll find it worthwhile.

The talk begins like so: I’m Nick Richards. I’ve been a GNOME User for 20 years and a contributor and Foundation Member - 10 years (off and on). These days, the Free Software project I’m most passionate about is Flathub.

These days I’m a Product Manager at Endless. Endless OS ships a customised, forked version of GNOME shell and a plain version of the rest of the GNOME platform. It’s currently based on 3.26 but with plenty of activity going on upstream.

What is a Product Manager? Christian Knows!

“Product managers are responsible for taking information and feedback from everywhere and converting that into a coherent project direction and forward looking vision. They analyze common issues, bug velocity, and features to ensure reasonable milestones that keeps the product functional as it transforms into it’s more ideal state. Most importantly, this role is leadership.”

It’s often a role you grow into; Product Managers rarely start there. In the past I’ve been a User Advocate, Interaction Designer, User Tester, Localiser and messed about with Development and Operations. Having a diverse background helps you empathise with all the people you have to interact with although most Product Managers are deep experts in one area.

What does a product manager actually do?

• Integrate all the things. You should know everything about your project, know a bit about everyone’s job and be able to help wherever there’s stress.
• Maintain Standards everywhere. You don’t have to approve everything and become a bottleneck, but you should be able to keep on top of things and be aware if dubious code is about to be released.

A lot of this often boils down to saying no in an encouraging way. Doesn’t this sound like a free software maintainer? So why should you care? You do this already. Christian, again:

“For the past 3 years I’ve been working very hard because I fulfill a number of these roles for Builder. It’s exhausting and unsustainable. It contributes to burnout and hostile communication by putting too much responsibility on too few people’s shoulders.”

You might want to get Product Management involved so you can spend more time doing the things you joined the project to work on.

Which projects need Product Management? Not everything does, but if you’re working on these kinds of things it can help:

• Cross cutting initatives (GNOME Goals) like the App Developer Experience or Privacy. The kind of areas where you need a strategic vision and co-ordination
• “Big” projects likw the shell, builder, anywhere where really getting close to the details makes a difference or where a large team of regular contributors help out.

Your project may not yet have the ambition to be “Big”, which is OK. I love constrained scope too and the growth of small ‘single serving’ apps is one of the most interesting recent developments on the Free Desktop.

Product doesn’t work alone, Product is part of a software team. Here’s a quick rundown of some of the roles that you might find on a software team: Developers, Interaction Designers, Quality Assurance, User Support, Graphic Designers, Security Engineers, User and Developer Advocates, User Researchers, Tech writers, Build engineers, Operations people, Release managers, Standards Committee Members, Public Relations, Hackfest Organisers, Localisers, Internationalisers, and more… Very few projects will have all of these but expand your mind, what could your project do if it had some people working on one of these roles?

Product without other people is lonely and pointless. Solving complex problems requires a diverse team and often doesn’t admit simple solutions. A perennial problem for open source is attracting people with skillsets you don’t know about. You can’t just sit around and wait for them to turn up and start working, you need to invite them in by name. Maybe also start by taking their tools seriously. Yes, that probably means GNOME should have a Discourse forum. There’s been some really encouraging recent progress on modernising our infrastructure but GitLab is a great first step, not the end. The tricky, tricky bit once you’ve got these people involed is making sure they don’t go away. This doesn’t mean ‘do everything they say’ but it does need some open mindedness. The promise of Free Software is thatby having control over the software they run it will better fit peoples needs. Reducing the barrier between producers and consumers has always been a critical part of this and lowering it further by welcoming the skills of those who can help can only make our software stronger.

How do you decide what to do? The best way to decide is by focusing on a mix of internal drive and user satisfaction. I never want to underestimate internal drive and product feel, it’s what gives your software its unique flavour and can help create fanatically devoted and delighted users and contributors but if you want a large number of users then listening to feedback can be helpful.

Some good sources of feedback are: In person, GitLab (or bugzilla), IRC, Telegram, press reviews, blogs, forums, user testing. Just plain listening on bugzilla is kind of unhelpful, you need to look at your user support channels to feel the pain, and then translate that into a good engineering journal solution.

Endless has metrics which tell us some anonymised things about how people use our software (this is controversial). But they are very useful when used responsibly, for example they can tell me that Nautilus was GNOME app that Endless users opened most in the last month. But it’s not clear we can just roll this out. GNOME has strong privacy guarantees and intermediating forces (like Endless!). It’s not normally helpful to have people between yourself and the user if you want to react to their problems and provide solutions. Where possible, disintermediate (this means you should be using Flatpak for your apps).

User research and going onto the ground to talk to users and stakeholders is also really important. It’s great to talk to people who were motivated enough to come to GUADEC but you get a whole different view by meeting people in their own context. This is something that Endless has been fanatical about, and has really influenced our product developement process and is an area GNOME can also do well in with its distributed community.

At the end of the day, great products never listen in just one way and a key role for Product Management is to weigh the feedback from each channel and merge it together into a coherant product direction. That’s the real trick, good luck!

Summing up:

• Everyone is making a product - you may not need dedicated management right now but using the techniques can help.

• If you want new people you have to do something to make it happen.

• Get a diversity of feedback - but be discerning with how you listen to it.

Flatpak is actually very helpful here, since the libraries required are rapidly becoming antique, and carrying them around on your base system is gross as well as somewhat insecure. There isn’t a GUI to create or open files, and it’s somewhat awkward to use if you’re not already an expert, so I didn’t submit the app to Flathub, however you can easily download and install the bundle locally. I hope the two people for whom this is useful find it as useful as I did to make.

A few years ago Intel and Nokia selected Gitorious to host the source code for their MeeGo Operating System. With the upcoming shutdown, that code was about to go offline. Since I have a sentimental attachment to MeeGo I’ve copied the repos for the MeeGo Netbook UX (source code) and MeeGo Tablet UX (source code) to GitHub.

Both of these projects are totally abandoned so don’t expect Pull Requests to be merged or issues to be looked at, but it would be a shame if this just disappeared into a black pit of indifference.

There hasn’t been an official release for a little while and a few useful patches have built up on the master branch. I’ve packaged a git snapshot and created a COPR repo for Fedora so you can use these snapshots yourself. They’re good.

This is especially relevant to GNOME given the recent release of 3.0, a slightly divisive major version which provides a whole new base to iterate on top of. I argued that we can use the new extensions framework in 3.0 to deliver a more personalised and adaptive interface to users which allows the community to target more users and helps to ease the pathway for new contributors into the project.

I was particularly keen to stress the importance of the existing design and goals led approach which has created such distinctive software, whilst trying to balance it with a slightly more anarchic playfulness. A lot of this shouldn’t exactly be news to those who follow a number of today’s leading software thinkers, or who’ve looked at how top open organisations such as Mozilla deliver software platforms but hopefully it was brought together in an interesting way.

The talk was given in (and partly about) Pinpoint, a tool for making hackers give excellent presentations, and as such a plain look at the slides won’t help very much as I won’t be there to witter on over the top. But they are available if you’re interested.

In a great example of potential iteration within the tool the PDF export doesn’t include the rather voluminous speaker notes which would be a good feature to add and if we do I’ll update the post. Sadly, although the session was recorded on video there was an issue with the storage and it appears to have been lost. As such, I’ve taken a little while to try and transform my notes into something a little more literary. Obviously, it’s worth reading along with the pictures as the jokes will hopefully be funnier, and you’ll get to enjoy many more of Pippin’s beards. Anyway, and without further ado:

GNOME: Iteration’s what you need

Despite working on GNOME it appears that I’m the face of a recent release of KDE, so, welcome all to the ecumenical desktop summit. I work for Intel’s OTC in London. Which is cool as according to MATHS we write a lot of Linux.

I am a designer. As a designer, my job is to try and meet people’s needs and solve problems. As we know, GNOME is people so this talk should be full of overlap.

Or, to put it another way, my job is to work out how can you make people happy. Not by doing everything they say they want. At the same time people aren’t (all) toddlers, you can’t look or talk down to them. You’ve got to get onto their level and often, humbly, admit they know more than you do about how to solve their problems.

This is one of the great strengths of open source, harnessing the energy of users and turning them into contributors, so for the future of your project you want to say yes as often as you can. So, this talk is going to be about ways that we can say “yes, but” more often rather than just plain no.

GNOME 2 was great (but it got there over 9 years). A few other things happened 9 years ago: The Euro, Water on Mars and Attack of the Clones. Not all of these have aged as well as GNOME 2. GNOME 3 is great (and it’ll get better), 6 months at a time, on the same time based cycle that 2 did. But how do we get to awesome? And more quickly this time because we really need to be getting better at software after all this time.

Do we listen to the hackers, who want to launch lots of terminals? (turns out their workload looks uncannily like normal people wanting to launch lots of web browsers.) Or do we listen to this guy?

Maybe we already did. The latest versions of GNOME and OS X are uncannily similar in visual and interaction terms, so maybe we should just follow the word of Steve Jobs. I reckon we say no, it is possible to do better than OS X, as anyone whose seen people use it for the first time will atest. But Apple’s actually a really good case of iteration, both visual and interaction. They’ve refeshed their experience, whilst staying pretty close to their core goals which is a success in my book.

How do designers iterate? Badly, and often on paper. Our tools suck for this currently, we need things which have the power of a dvcs to experiment and play with (example, I really need multiple pages in Inkscape).

Often we work by sketching a complete redesign, usually missing key features. Developers, do not be alarmed by this. It’s just a way of finding out by feel what the key parts of the application are and can be a good way to remove cruft. We usually make sure we add all the stuff back in afterwards unless the point of an iteration is to remove a feature.

Here’s a cool thing, it’s an adaptation of the GIMP to add version control. This is exactly the kind of awesome, ground breaking feature we need in open source to enable the kind of open collaboration that developers currently enjoy to work more easily for people who code less.

There is currently a surfeit of design wanted, compared to designers available in GNOME, which is great but sadly I’m here to tell you that designers don’t scale very well. There are quick wins available for improving software, but not as much as all that, as you need deep domain knowledge to create really cool stuff. So please, come and work with us. The great advantage of GNOME for designers who want to get into an open source community is that there are already some of us here, so you’ve got people to chat to and that the developers are keen to collaborate, work with you and make great stuff together.

Iteration isn’t a rewrite from scratch, you have to have the solid base existing to iterate on top of. But still, no sacred cows. GNOME is defined by the design goals, not specific instantiations of them. If the data leads you to do something drastic, then do something drastic. To me, these design principles are the most important document in the project. short enough to understand, opinionated enough to create a flavourful experience. This is the core around which iteration takes place, a guide to future goals and a quick test if something’s ‘gnomey’.

Extensions lead to the possibility of cobranding. How would we feel about a Twitter enhanced GNOME product? How would we feel about a Kernel endorsed gnome product. Fedora has been ahead of the curve here with their spins and at intel we’ve got a really cool thing called yocto which could be really interesting to manage a bundle of these extensions. Also we like automator. if we really embrace this kind of mass customisation, then we need a way to move users from mastery to ownership. Tools to build your own are a big theme for me and a big hole in our current setup.

Creating iteration should be a structured process of play: Structured in that you need a current benchmark to ensure you get no worse; Playful in that you should explore the problem space in unusual and interesting ways. Test before; test after, then you’ll have some ammunition for going through a review process. We need design and code review. On this, I’m very excited by the ui-review keyword in bugzilla it’s very important conceptually to stop bad things happening but of course, the maintainter still owns their code so you’re in an advisory position as a standard designer.

Feedback is the hard bit. As a company I would give you the standard designer answers (test with users, test with users, also, test with users). But as GNOME, the situation is different. After a bit of thought I feel that most bits of functionality should be tried as extensions first, and made available for installation and review. You then rely on the extension installer being a thing for normal people like it is on firefox. This will take investment.

Now, an example of iteration. I’ll tell a story about pinpoint, which is a tool started by my friend Pippin. In many ways this is a very standard open source story.

A person has a problem, in this case giving a presentation, so they write some software to fix that problem. And because they’re a talented hacker, just turning out a new one isn’t a problem, so they write it again and again, slightly different each time.

I’m going to talk to you about Monty Panesar, he plays cricket for England. He started very well, but tailed off badly. And Shane Warne (another cricketer) said something very perceptive. He hasn’t played 30 tests, he’s played the same test 30 times. This is not iteration. So this was the most amazing and exciting thing, that rather than writing a new tool for every presentation. He started adding features to an existing tool. And why?

Because it rocked. Pinpoint has a view. it hates powerpoint, it hates most presentations that hackers give at conferences like this and it wants to make it so easy to give better presentations that you’d be stupid not to. Its self defintion says it all, it’s “a tool for making hackers do excellent presentations”.

He got some friends who wanted to use it too and who agreed with the plan. And they added a load of features. Hopefully you saw (or caught later) a couple of the awesome talks that my colleagues, Damien, Neil, Emmanuele and former colleague Chris put on to see some of the crazy features we have in pinpoint now such as webcam backgrounds, an embedded terminal and live update ad view of file changes.

But still, it’s remained simple. Pinpoint a simple presentation tool that hopes to avoid audience death by bullet point and instead encourage presentations containing beautiful images and small amounts of concise text in slides.

And why? It’s simple because features have to meet the opinionated design in order to get in. You’re not allowed to make it any worse at its core, or add needlessly to the ‘format’ but other than that - go for it!

So, we’re coming in to land: ☃ Have a strong identity ☃ Adapt around that core ☃ Share those changes Thanks.

I read this on the internet today. It’s pretty good and made me think I should probably share some of the work I did for Moblin Netbook the year before last. Note: this does not apply to MeeGo. Moblin is different. This is what you always need to remember when translating it into another language. Moblin is not OS X, GNOME, Windows or a phone.

Moblin is not you, we do not use ‘My’ anywhere. As Moblin is your friend we use ‘Your’ this should be an informal you if your language has differences in status.

Moblin is your friend. She’s one of our design personas - a single woman approx 30 years of age with a teenage son. She speaks informally and demotically to you, but not disrespectfully. You are treated as a partner throughout.

Moblin is not creepy. It doesn’t remember embarassing things. It is always polite.

Moblin is funny, but not too funny. As an extension of the informality occasionally the interface will make a culturally specific pun or joke. This is intentional and should be replicated to your translation. Not specifically in the same place and not the same joke. Consider the many translations of the excellent Asterix comic book series where the jokes are culturally specific, everyone feels like they’ve been told the same joke - but they actually share a joke space where everyone feels included despite having a seperate experience.

We aim only to use humour as a double indicator, where the user has another way of finding out the correct context. A great example is the volume control where the user can see their position on the slider and use the slider to control the volume. In English the descriptions of the slider positions are jokes based on Music and audio that is understood by the target market e.g. ‘Turned up to 11’. We aim for a maximum of 20% humorous labels in a multiple choice box. Be thoughtful.

Moblin is a symbiosis between hardware and software, collectively referred to as the ‘computer’. Moblin takes responsibility for successes and failures across the system.

Have fun writing for Moblin and it’s quite likely that your users will have fun using it.

So we set about putting our money where our mouth was and started building something. Starting today you can see where we’ve got to so far with the beta release of the Moblin 2.0 for Netbooks User Experience. Just go to moblin.org, download it, burn it onto a nearby USB stick and you can either just run it live or install it to pretty much any netbook with an Atom chip. I think you’ll like it.

During this project I’ve had the good fortune to work with a whole group of people whose immense technical skills, personal charm and good humour I respect and admire wholeheartedly. Everything that is good about or project is there because they envisioned, supported or improved it in countless ways. Most of these people will not be mentioned in press releases so I’d like to take a moment to thank as many of them as I can personally for making this last little while the most thrilling, tiring and satisfying period of my professional life. So thanks (in no particular order) to: Darren Wilson, Claire Alexander, Hylke Bons, Matthew Alum, Ross Burton, Tomas Frydrych, Mark Skarpness, Paul Cooper, Øyvind ‘Pippin’ Kolås, Michael Meeks, Srini Ragavan, Chris Lord, Neil Roberts, Rob Bragg, Cyrene Domogalla, Jason Casseza, Arjan van den Ven, Anas Nashif, all the guys and girls in PRC QA, Iain Holmes, Damien Lespiau, Josh Lock, Jussi Kukkonen, Patrick Ohly, Thomas Wood, Emmanuele Bassi, Geoff Gustafson, Robert Staudinger, Sharon Murphy and of course, Rob Bradford. Thanks guys, I really couldn’t have done it without you. It’s been fun but it doesn’t end here.

We’re going to continue iterating this platform to knock off as many of the sharp edges as possible (we’re well aware that there’s quite a few) and continue taking our design philosophy to other platforms. Now that our UI is public and properly open source we’d love to chat. I hope you enjoy it.

Love,

Nick