I'm John, an independent web developer exploring clear interfaces and software with a practical purpose.
Explore the projects
I enjoy turning loosely defined ideas into simple, understandable interfaces.
I started with small websites and personal scripts. What kept me interested was figuring out what a tool actually needed: a readable screen, a predictable interaction, a useful default.
These days, I'm especially interested in personal utilities, writing tools, and lightweight web applications. I like working close to the browser and thinking through the interface before choosing the framework.
Away from the screen, I enjoy photography, secondhand bookshops, and long walks without a particular destination. A notebook usually comes along.
Three self-directed project studies. These are concepts and intended behaviours, rather than released products or client engagements.
A quiet place for short observations, without turning every note into a form to fill out.
Quick ideas are easy to capture and surprisingly difficult to find again. The concept centres on a single writing view, a chronological list, and optional tags. Titles are optional.
The design question: how much organisation helps before maintaining the system becomes another task?
Next step: build a local-first prototype with plain-text export.
A forecast organised around everyday decisions, with the next few hours first.
What should a forecast show when someone simply wants to decide when to leave the house? Rain timing, temperature changes, and the age of the latest update take priority.
The interface should also make it clear when information is stale or unavailable. The preview above uses illustrative data.
Next step: connect a weather data source and test real forecast variations.
A simple work session that begins with a duration and an optional task name.
The interface keeps the remaining time visible and makes pausing or ending a session straightforward. Session history is intended to stay on the device, with no account required.
The technical question is how to recover after a sleeping device or inactive browser tab, using elapsed time rather than a perfectly regular countdown.
Next step: test a working prototype across desktop and mobile browsers.
A few principles that guide the work.
What does someone bring to the tool, what do they do, and what should they leave with? Get that journey clear before growing the feature list.
Empty lists, missing information, failed requests, keyboard navigation. These states deserve as much attention as the main screen.
Use familiar patterns, useful defaults, and straightforward language so someone can return after a few weeks and find their way.
Short notes on making software a little easier to use.
Before adding settings, describe the smallest useful journey through a tool. That description is often more useful than an early feature list.
A tool's first screen often has no content. It still needs to explain what belongs there and make the next action obvious. A short sentence and a clear button can do a lot.
An interface can feel obvious while you're building it. The better test is coming back after a few weeks. Labels, defaults, and saved state should help someone resume.