DEV Community: Owen Burns

Ramen 2026.09.1: A New UI

Owen Burns — Wed, 23 Sep 2026 19:37:49 +0000

I’ve just released Ramen 2026.09.1, and this one feels like a pretty big step forward for the project.

Most of the work in this release went into how Ramen looks and feels. I rebuilt the application UI, reworked the branch selector, fixed a number of terminal issues, and added a small feedback form so it’s easier to report things directly from the app.

This release is less about adding a long list of new features and more about making the parts of Ramen that you use every day feel better.

A completely new UI

The biggest change is the UI redesign.

The dialogs, editor chrome, title bars, workspace layout, navigator, and light and dark themes were all rebuilt. I also took the opportunity to clean up some of the older UI decisions that had accumulated as the application grew.

The result is a much simpler layout with less visual noise and more space for the things that actually matter when you're working.

Along with the redesign, I also fixed a few editor and LSP issues, including completion popup handling, diagnostics, and LSP lifecycle problems.

I also removed the workspace and project title text blocks from the interface. They were taking up space without adding much, and removing them helped the new layout feel cleaner.

The branch selector got a complete rewrite

The other big piece of work in this release is the branch selector.

The old dropdown has been replaced with a much larger popup inspired by the branch workflows found in IDEs like Rider.

It took several passes to get this right. I wanted it to be useful when you have a handful of branches, but also hold up when a project has a much larger and more complicated branch list.

Branches can now be grouped into folders based on their names. For example, branches such as feature/auth, feature/settings, and feature/editor can be grouped under a feature folder.

Nested folders are supported too.

The current branch is shown first in each section, and the popup also includes upstream tracking information and a Recent section based on the Git reflog.

There is also a search field that filters the branch list and automatically expands folders when matching branches are found.

Creating a branch is now possible without leaving the popup as well. The new branch field validates the name and shows an error directly in the popup when something isn't right.

I also added full keyboard navigation. You can move through branches with the arrow keys, expand and collapse folders, move between sections, create a branch, and close the popup without reaching for the mouse.

The branch data is refreshed every time the popup opens, and checkout and branch creation now go through the Git service properly.

After getting all of that working, I spent some extra time going back over the popup for performance and usability. There were a few places where the first version worked but didn't feel quite right, so this part of the release went through several iterations.

Terminal fixes

The terminal also got some attention in this release.

One of the more annoying issues was on macOS, where Command key shortcuts weren't being handled correctly. Command was never being mapped properly, which meant shortcuts could end up typing letters into the terminal instead.

That is now fixed.

On macOS:

Cmd+C copies
Cmd+V pastes
Cmd+A selects the full scrollback
Ctrl+C sends SIGINT as expected

Ctrl+V paste also now works across platforms.

There is also an option for copying text automatically when selecting it in the terminal.

Sending feedback from Ramen

I also added a small feedback form under the Help menu.

The new Send Feedback... option lets you submit feedback directly from the application and choose what kind of feedback you're sending, whether that's a bug, an improvement, or an adjustment.

It's a small feature, but I wanted there to be an easy way to send feedback without having to leave Ramen and figure out where to report something.

A few other fixes and cleanup

There were also a few smaller changes that aren't as visible but were worth doing.

The branch popup had a bug where its chevron could disappear after expanding and collapsing sections. That's fixed now.

I also removed the .idea/ folder from source control and cleaned up a number of duplicate files that had been created by iCloud, including duplicate build scripts, styles, and wiki pages.

There was also a leftover comment in Ramen.csproj that got cleaned up along the way.

Version 2026.09.1

The release is now pinned to 2026.09.1 throughout the application.

The version in the project files, macOS Info.plist, and About window all match, so the version shown inside Ramen should now always line up with the version shown by Finder.

The macOS release is packaged as:

Ramen-2026.09.1-macos-arm64.dmg

It's a self-contained Apple Silicon build that is ad-hoc signed and verified.

Because the app is ad-hoc signed, macOS may show a warning the first time you open it. Right-click the application and choose Open to launch it.

What's next

This release was a good chance to step back and spend time on the foundation of Ramen's interface rather than constantly adding more to it.

There is still plenty I'd like to improve, but the new UI gives me a much better base to build on. The branch popup in particular was one of those features that started as a simple dropdown and gradually turned into something much more useful.

Ramen 2026.09.1 is available now.

I'm looking forward to using this version myself and seeing what starts standing out now that the bigger UI work is out of the way.

ramen.owenburns.co.za

Ramen - My Own Creation

Owen Burns — Sun, 20 Sep 2026 16:34:06 +0000

I've always been a builder.

Even as a child, I would take apart old toys and attach pieces of them to other toys. I'd modify things, upgrade them, and try to figure out what I could make them do.

Looking back, that's probably what eventually led me into Software Engineering.

I've always enjoyed taking something apart, understanding how it works, finding the problem, and figuring out how to make it better.

Over the years, that skill grew.

I taught myself how to write software. I learned how to track down those obvious-but-somehow-frustrating bugs. I moved through different areas of technology, including QA, Automation, and Software Engineering.

And eventually, I started building Ramen.

When I first published Ramen, I thought the hard part was building the application.

Turns out, that was only the beginning.

Building something is only half the job

Once Ramen was out in the world, I started using it differently.

I wasn't just looking at it as a project I had built anymore. I started looking at it as a QA tool.

And when you start looking at something from the perspective of the person actually using it, you notice things you simply don't see while you're building it.

The interface worked, but it didn't quite feel like the environment I wanted Ramen to be.

Some workflows made sense to me because I knew how the application worked internally, but that didn't necessarily mean they were intuitive.

Some parts of the UI were functional, but didn't communicate what they were actually doing.

And that made me realise something:

I needed to stop looking at Ramen as its creator and start looking at it as its user.

So I started taking it apart.

Not literally this time, but in the same way I've always approached things.

What works?

What doesn't?

What's confusing?

What can be simplified?

What can be rebuilt?

Making Ramen feel like a development environment

That process led to a fairly significant rethink of the Ramen experience.

One of the biggest changes has been the interface itself.

I wanted Ramen to feel more like an actual development environment.

Not because I wanted to copy an existing IDE, but because developers and QA engineers already have certain expectations about how these environments work.

The way projects are organised.

The way source control is represented.

The way different parts of a workspace interact with each other.

The previous design was functional, but it didn't quite have that feeling yet.

So I started rebuilding it.

The Git experience was redesigned to actually resemble a Git container rather than simply presenting Git-related information in a UI.

The branching system was redesigned.

Various parts of the interface were reworked to make the overall experience more intuitive and cohesive.

None of these changes are necessarily huge features on their own.

But together, they change how Ramen feels when you're actually using it.

And that's something I've become much more conscious of while building this project:

Functionality is only part of building a good tool.

The experience around that functionality matters just as much.

Building with users, not just for them

The other major change isn't really a visual one.

It's how I want Ramen to evolve.

I've added a feedback system that allows users to provide feedback directly from within Ramen.

Because I don't want to build Ramen in isolation.

I don't want to disappear into a room, decide what I think people need, build it, release it, and then repeat the process.

I want the people actually using Ramen to have a voice in what it becomes.

If something is confusing, I want to know.

If something is frustrating, I want to know.

If something works really well, I want to know that too.

The goal is for real-world usage to become part of the development process itself.

And this became particularly important once I released 0.1.0-preview.1.

Putting Ramen into the hands of other people

The preview release was an important step for Ramen.

Until that point, a lot of the testing was happening from my perspective.

I knew how Ramen worked.

I knew where things were.

I knew what certain controls were supposed to do.

That makes it surprisingly easy to overlook problems.

Someone using the application for the first time doesn't have that context.

They don't know what I intended.

They only know what the application communicates to them.

And that's exactly what I needed to learn.

Where do people get confused?

What workflows feel natural?

What feels unnecessarily complicated?

What breaks?

What features do they immediately understand?

And perhaps most importantly:

Does Ramen actually feel useful?

Releasing the preview wasn't about declaring Ramen finished.

It was about getting it out of my head and into the hands of people who could actually challenge the assumptions I'd made while building it.

And once that happened, the process changed again.

Taking it apart again

This is probably the part of building software that I enjoy the most.

Taking something apart.

Figuring out why it isn't working the way it should.

Finding the frustrating parts.

Understanding the problem.

Then rebuilding it.

Ramen has given me another opportunity to do exactly that.

Except this time, I'm not taking apart an old toy.

I'm taking apart a product I've built myself.

The difference now is that I'm not doing it entirely on my own.

I'm building.

I'm testing.

I'm listening.

I'm learning.

And then I'm rebuilding.

That's become the development cycle for Ramen.

And it has changed how I think about the project.

I'm not just trying to add more features.

I'm trying to make the features that already exist feel better.

I'm trying to make the workflows more natural.

I'm trying to remove friction.

I'm trying to understand what people actually need from a Quality Development Environment rather than assuming I already know.

The next release

That brings me to the next release of Ramen.

I'm moving away from traditional semantic versioning for Ramen and towards a date-based versioning system.

The idea is simple: the version should tell you when the release belongs to, while the release and patch numbers identify the iteration.

So rather than continuing with 0.1.0, 0.1.1, and 0.2.0, Ramen is moving towards versions such as:

2026.09.20.1

It's a small change, but it reflects how I want to approach Ramen going forward.

Ramen isn't a project where I'm trying to hit some arbitrary number before I can call it "real".

It's going to keep evolving.

Releases will happen as the product develops, and the version should provide a simple reference point for where that release sits in the history of Ramen.

And this release represents another step in that process.

This is still just the beginning

There is still a lot to do.

There are features I want to build, workflows I want to improve, rough edges I want to smooth out, and plenty of things I haven't even thought of yet.

But that's part of the fun.

Ramen started as an idea for a Quality Development Environment for QA testers.

It became an application.

Then it became something I could put into the hands of other people.

Now it's becoming something that can evolve with the people using it.

And I think that's the biggest change I've seen in Ramen so far.

I'm still taking it apart.

I'm still rebuilding it.

I'm still finding things that don't work the way they should.

But now there's a feedback loop.

Build.

Test.

Listen.

Rebuild.

Repeat.

The building isn't over.

It's just getting started.

Ramen - A Quality Development Environment for QA Testers

Owen Burns — Sat, 05 Sep 2026 16:43:45 +0000

Why I Built Ramen (and Why QA Needed a QDE)

A month ago I wrote a post that had been sitting in my head for a while, mostly unformed, until I finally forced myself to write it down. The question behind it was simple: why do developers get entire environments built around how they work, while QA engineers are still expected to stitch a pile of unrelated tools together and hold the whole thing in their head?

That post turned into an idea. This week, the idea turned into something people can actually install and use. Ramen 0.1.0-preview.1 is out. Before I talk about what it is, I want to talk about why it exists, because the why is the part I actually care about.

The problem I kept running into

I work across QA automation and full-stack development, so I get to see both sides of this pretty regularly. On the development side, tooling is a solved problem. Open an IDE, and it already understands your project, your Git history, your terminal, your build process, your dependencies. Everything is built around one thing: the software you're building.

QA doesn't get that. A QA engineer's day might start with a requirement, move into reading a product guide, jump into inspecting the frontend, then into writing automation, then into a terminal to run a Docker container, then into a browser to check a locator, then back into an IDE to fix the test that just failed for reasons that have nothing to do with the actual bug. None of these tools know about each other. The browser doesn't know what branch you're on. The terminal doesn't know what element you just inspected. Docker doesn't know what suite is about to run against it.

That's not really a tooling gap in the sense of "we're missing a tool." It's a gap in shared state. Every tool a QA engineer touches in a day knows something useful, and none of that knowledge is visible to the others. You end up being the integration layer, manually, every single time.

Why I didn't just build another test tool

There's no shortage of test automation tools, AI test generators, or wrappers around Playwright and Selenium. I wasn't interested in adding one more to the pile, and I don't think that's actually what was missing.

What kept nagging at me was a much more basic question: if you designed a development environment around Quality Engineering from the ground up, instead of adapting a developer IDE to fit QA after the fact, what would it actually look like?

The answer I kept arriving at was that the system under test needs to be the centre of the project, not the source code. A QA workspace isn't just a folder of test scripts. It's the requirements, the product knowledge, what you know about the frontend, the environments you test against, and the tests themselves, all living in the same place, understanding they belong to the same context.

That context turns out to matter a lot once AI gets involved. Telling a model to "generate a Playwright test for this feature" without giving it any of that surrounding knowledge is asking it to guess at conventions it has no way of knowing. Give it the workspace instead of just a prompt, and the generated test actually looks like something your team would have written.

I called this idea a QDE, a Quality Engineering Development Environment, on purpose, because I think QA deserves the same category of tool developers have had for years. Not a QA IDE with a few extra buttons. An environment built around the actual job.

Who this is actually for

I built Ramen with a fairly specific person in mind, because I've spent a lot of time being that person. Someone doing QA automation who is tired of context-switching between five disconnected tools to do one task. Someone who wants the browser they're testing in to actually be part of their workflow instead of a separate window they alt-tab to. Someone who's excited about AI-assisted testing but has felt the ceiling of what a bare prompt can actually produce without real context behind it.

It's not aimed at replacing anyone's stack. If you use Playwright, keep using Playwright. If you use Git, Docker, or Claude Code, keep using all of them. Ramen isn't trying to be the twentieth tool in the pile. It's trying to be the thing that finally understands how the other nineteen relate to each other.

What the last month actually looked like

Writing the idea down was the easy part. Turning it into something real was a different exercise entirely, and I want to be honest that it didn't come out fully formed. A month ago this was a concept and a handful of half-working experiments. Since then it's become an actual application, with workspaces, system-under-test context, browser execution built into the environment, an integrated terminal, run configurations, and real testing workflows sitting on top of all of it.

There were a lot of decisions along the way that I'm still not sure I got right. How much structure to impose on a workspace versus how much to leave open. How tightly to couple the browser and the inspector to locator generation. How much of the AI integration should assume a specific framework versus staying framework-agnostic. Some of those answers are probably going to change as more people actually use this and tell me where it breaks.

Why release it now, in this state

I could have kept building quietly for another few months before showing anyone. I decided against that on purpose. I don't want to present Ramen as a finished answer to a problem I only fully articulated a month ago. I'd rather put out something real, rough edges included, and find out from actual usage whether the core idea holds up.

Maybe it doesn't. Maybe the existing pile of disconnected tools really is the right approach and I'm solving a problem that isn't as painful for other people as it is for me. But I don't think anyone has seriously tried building an environment around the Quality Engineer instead of retrofitting one meant for developers, and I'd rather find out by shipping something than by thinking about it for another six months.

Ramen 0.1.0-preview.1 is out today. If you do QA automation and any part of this has annoyed you as much as it's annoyed me, I'd genuinely like to know what you think.

ramen.owenburns.co.za