DEV Community: Timo

Designing Better Plant Diagnosis: Turn a Photo Into a Useful Next Step

Timo — Mon, 03 Aug 2026 10:29:56 +0000

A photo is evidence, not a verdict

Plant diagnosis is a surprisingly good example of a product-design problem: users arrive with a visible symptom and an urgent desire for a single answer. “My leaves are yellow. What do I do?”

The difficult part is that the input is incomplete. Yellowing can follow saturated soil, a dry root ball, low light, pests, normal aging, a recent move, or several of those factors at once. A useful tool should not turn uncertainty into false certainty. It should turn one image into a better investigation.

Start with observations that change the decision

The highest-value first step is to collect details that actually alter the next action:

Is the affected leaf old or new?
Is the soil wet below the surface, not only at the top?
Does the plant have drainage and enough usable light?
Are there signs of pests under the leaves?
Did anything change recently—location, watering, temperature, or pot?

This is less dramatic than recommending a product, but it prevents the most common failure mode: applying every possible remedy at once. If a plant is struggling with excess moisture, more water and fertilizer are not neutral actions. They can compound the original stress.

Why image-led tools need an honest workflow

Computer vision is excellent at finding visual patterns. It is not a root inspection, a humidity sensor, or a complete watering history. The product job is therefore not simply “identify the disease.” It is to combine visible cues with a structured follow-up checklist.

A responsible flow looks like this:

Capture a close image of the leaf or symptom.
Capture a wider image that shows the plant, pot, and placement.
Return likely explanations as possibilities, not guarantees.
Explain the specific checks that help separate those possibilities.
Recommend one measured next step instead of a chaotic reset.
Invite a re-check after the change.

That workflow has a practical benefit: it helps people learn what to observe next time. The value is not only a label. It is a clearer decision with less guesswork.

The subtle relationship between light and watering

Many plant-care mistakes happen because advice is given in isolation. “Water every week” sounds simple, but it ignores light, temperature, pot size, soil density, season, and plant growth. A plant in a dim room may use water slowly; the same schedule that worked in summer can keep its roots wet for too long in winter.

That makes light a key diagnostic variable. Long gaps between growth, stretched stems, small leaves, and soil that remains wet can suggest that the plant is not receiving enough energy. It also means a watering fix alone may not solve the problem.

Design for calm, not panic

A good diagnosis experience should lower the temperature of the moment. The tone matters. Instead of “your plant is dying,” use clear language: “Here is what this symptom can mean. Here is what to check first. Here is when to take faster action.”

There are cases that need prompt attention—rapidly spreading dark, soft tissue; a severe infestation; or obvious root rot. But most yellow leaves do not require a weekend of repotting, cutting, and chemical treatments. A small, evidence-led adjustment is usually more useful.

Turning a symptom into a next step

At GreenLens Pro, the goal is to help plant owners pause before they guess. A scan can be a useful starting point, especially when paired with the context a photo cannot show on its own. It is not a substitute for observation; it is a way to structure it.

If you are building or evaluating plant-care tools, that is the standard worth aiming for: make uncertainty actionable without pretending it has disappeared.

Learn more about the product and its approach at GreenLens Pro.

Designing Random Choice UX That People Actually Trust

Timo — Sat, 01 Aug 2026 17:11:03 +0000

Randomness is easy to add to a product.
Trust is not.
A developer can write a random picker in a few lines of code. But if users do not understand what was selected, why it was selected, or whether the result can be accepted, the feature will feel arbitrary rather than useful.
That is why random-choice interfaces are more interesting than they first appear. They sit at the intersection of product design, interaction design, and a small amount of probability.
A picker, coin flip, spinner wheel, or team generator can solve a real user problem: people get stuck when multiple options are acceptable and no one wants to make the final call.
The important word is acceptable.
Randomness should not decide between outcomes with radically different consequences. It is most useful when the user or group has already narrowed the field to options they can live with.
The product problem is often deadlock, not choice
Consider a familiar product scenario.
A remote team is choosing a volunteer for a short demo. Five people are capable. Nobody has a strong preference. The discussion becomes awkward because selecting someone manually can feel personal.
Or imagine a group-planning app with three activities that fit the available time and budget. Every option is fine. The problem is not a lack of information. It is that the group has no lightweight way to end the conversation.
A random-choice interaction can help because it changes the social dynamic.
Instead of saying, “I choose Alex,” the group says, “We agreed on the options; now let’s let the tool pick.”
The tool is not smarter than the people in the room. It simply gives them a neutral tie-breaker.
Start with the right scope
Before designing the UI, define what the feature is for.
A random picker is a good fit for:
game mechanics
classroom activities
icebreakers
team rotation
low-risk task ordering
prize drawings where the rules are already defined
choosing from a set of equally acceptable options
generating prompts or creative constraints
It is a poor fit for:
financial decisions
medical, legal, or safety-related decisions
security-sensitive draws
any system where users need an auditable or cryptographically secure result
situations where the options have materially different consequences
This scope is not a disclaimer added at the end of the project. It should influence the entire interface. A product that presents a playful randomizer as if it were appropriate for high-stakes decisions creates the wrong expectations.
Three design principles for trustworthy random choice

Make the input inspectable Users should be able to see exactly what can be selected before the result appears. This sounds obvious, but many random interactions hide too much state. If a wheel contains twelve options, show all twelve. If an option has a weight, make the weighting clear. If duplicate entries increase an option’s chance of being selected, say so. Trust starts before the button is pressed. A good pre-selection state answers these questions: What can win? Are there duplicates? Are all options equally likely? Can I edit the list? What happens when there is only one option? What happens when the list is empty? The more visible the input is, the less the outcome feels like a black box.
Separate the result from the animation Animations are useful, but they should not become the source of truth. A spinner wheel can visually communicate a result. A coin can flip. A card can shuffle. These interactions make the experience more engaging and create a natural sense of completion. But the application should select the result first, then animate toward it. That approach avoids a common implementation mistake: trying to derive the winner from the final visual position after an animation. Visual state can be affected by frame timing, CSS transforms, rendering differences, and user interruptions. The selected value should be stable independently of how the interface looks. A simple implementation might look like this: type Option = { id: string; label: string; };

function pickOne(options: Option[]): Option {
if (options.length === 0) {
throw new Error("At least one option is required.");
}

const index = Math.floor(Math.random() * options.length);
return options[index];
}

const winner = pickOne(options);

// Then animate the UI toward winner.
For a casual feature, Math.random() is generally appropriate. It is not appropriate when the result has security, legal, financial, or gambling implications. In those cases, the product needs a different random source and a stronger audit model.

Make the outcome easy to accept The winner should be unmistakable. Do not rely only on a subtle change in colour or a wheel resting at an ambiguous angle. State the result in text. Highlight it. Give users a clear next action: “Start again,” “Remove winner,” “Copy result,” or “Create teams.” This is especially important for accessibility. A visually rich wheel can be fun, but a screen-reader user still needs a direct announcement such as: Selected: Pizza

The same principle applies to keyboard navigation. The interaction should not depend entirely on dragging, shaking, or watching an animation.
A reliable result state has three layers:
a visual signal
readable text
an accessible announcement
Weighted randomness needs explanation
Weighted selection is useful when options should not all have the same probability.
For example, a game may have common, rare, and legendary rewards. A content tool may want some prompts to appear more often than others. A team exercise may want to avoid repeatedly selecting people who have already been chosen.
But weighted randomness changes the user’s mental model. If people expect every option to be equal and one result appears more often, they may assume the tool is biased or broken.
The interface should therefore explain the rule in plain language:
“All options have an equal chance.”
“Higher-weight options are more likely to be selected.”
“Previously selected names have a lower chance this round.”
Avoid hiding probability behind a decorative animation. If the weighting matters, it should be visible.
Randomness is not fairness by default
A random result can be fair, but only under defined conditions.
If every option is included once and each has the same probability, an equal random picker may be fair enough for casual use. If some entries appear twice, if weights are applied, or if the list itself was created unfairly, the result may still feel unfair even when the algorithm behaves correctly.
This distinction matters for product language.
Do not tell users that a feature is “fair” unless you can explain what fairness means in that context. Often, more precise language is better:
“Selected randomly from the listed options”
“Each option has an equal chance”
“Weighted according to the values shown”
“Names are shuffled before teams are created”
Clear language earns more trust than a broad promise.
Test the interaction, not only the algorithm
A random feature can pass unit tests and still fail in the product.
Test the experience with questions like these:
Can users understand the options before selecting?
Can they recover from an accidental click?
Is the result readable on mobile?
Does reduced-motion mode still communicate the outcome?
Can a keyboard user complete the flow?
Is the result announced to assistive technology?
Does the interface explain unequal probabilities?
Does the team generator handle an uneven number of people clearly?
For the random function itself, do not write brittle tests that expect a specific winner. Test boundaries and invariants instead:
import { expect, test } from "vitest";

test("pickOne always returns an item from the provided list", () => {
const options = [
{ id: "a", label: "Alpha" },
{ id: "b", label: "Beta" },
];

for (let i = 0; i < 100; i++) {
const result = pickOne(options);
expect(options).toContainEqual(result);
}
});
The point is not to prove that randomness is perfectly distributed in a small test sample. The point is to ensure that the product never returns an option that was not available, never fails on expected input, and communicates the result clearly.
The best randomizer gets out of the way
A successful random-choice interaction does not make people admire the algorithm.
It helps them move on.
That is its product value: it turns “we are still deciding” into “great, let’s do that.” The implementation can be simple, but the experience must be transparent, accessible, and appropriate to the stakes.
For a small browser-based example of this kind of interaction, see this coin flip tool.

Generate a QR Code for Every Preview Deployment

Timo — Sat, 01 Aug 2026 16:10:16 +0000

A preview URL is only useful when somebody can open it.

That sounds obvious, but it is a recurring friction point in reviews. A developer posts a link in a pull request. Someone opens the PR on a phone, copies the URL, switches apps, pastes it, and hopes the preview still exists. The link is correct, but the path to it is needlessly long.

A QR code is a small improvement here: generate one alongside the deployment artifact, attach it to the workflow, and let reviewers scan it from the pull request on a second screen.

The workflow

The input is a preview URL. The output is a PNG or SVG that a CI workflow can upload as an artifact.

With QR Master CLI, the core command is deliberately small:

npx qrmaster-cli "https://preview.example.com/pr/42" --output ./preview-qr.svg

The SVG format is useful when the code may appear in a report, a release note, or another asset that needs to scale cleanly. PNG is fine for a fast artifact.

A GitHub Actions example

name: Create preview QR code

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  preview-qr:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Generate QR code
        run: npx qrmaster-cli "https://preview.example.com/pr/PR_NUMBER" --output ./preview-qr.svg
      - name: Upload QR artifact
        uses: actions/upload-artifact@v4
        with:
          name: preview-qr
          path: ./preview-qr.svg

Replace PR_NUMBER with the deployment identifier your workflow exposes.

The command can encode any URL or text payload. For review flows, the useful rule is simple: keep the code close to the thing it opens.

A few practical details

Test the code on a phone before you make it part of a release workflow.
Keep the preview URL accessible to the people who scan it; a QR code does not bypass authentication.
Prefer SVG if the artifact will be reused in documentation or printed.
Label the artifact clearly so a reviewer knows which environment it opens.

QR codes do not replace a clickable link. They give a second, low-friction route when the link is being viewed away from the device that should open it.

For static codes generated locally and dynamic codes with editable destinations, see QR Master.

What small review step would you remove if a second-screen scan were one command away?

What a Small Offline Plant-Care CLI Can Teach Us About Useful Developer Tools

Timo — Sat, 01 Aug 2026 15:42:32 +0000

Most command-line tools earn their place by removing a tiny piece of friction. A plant-care lookup is a good example: instead of opening five tabs to check a Monstera’s light, watering, humidity, and pet-safety guidance, a single command can return the essentials.

That is the idea behind the GreenLens Pro CLI. It ships with a local catalog for common houseplants and supports four focused commands:

greenlens care "Monstera"
greenlens diagnose "yellow leaves"
greenlens identify "Zamioculcas zamiifolia"
greenlens light-meter 1500

The interesting design constraint is restraint. The CLI does not pretend an image filename is a real visual diagnosis, and it does not hide uncertainty behind a single magic answer. It offers a practical starting point, then points people toward richer camera-based tools when that is the better fit.

For developers, the lesson is straightforward: local-first tools are most useful when they answer one common question quickly, make their limits clear, and work without an account or setup ceremony.

Learn more about GreenLens Pro’s plant identification experience: https://greenlenspro.com/plant-identifier-app

What is one tiny lookup you would rather run in a terminal than search for in a browser?

Restaurant QR Codes Are a Change-Management Problem

Timo — Fri, 31 Jul 2026 11:15:48 +0000

A restaurant menu QR code looks like a tiny design task. It is not.

Once it is printed on a table tent, window sign, receipt, or takeaway insert, it becomes part of an operational system. That system has a predictable failure mode: the menu changes, but the physical QR code does not.

This is why many restaurant QR projects feel fine on day one and become frustrating later. The code scans. The PDF opens. Everyone moves on. Then a price changes, a seasonal dish disappears, the ordering platform updates its URL, or a new menu file replaces the old one. Suddenly a printed asset has become a maintenance task.

Start with the right model

A static QR code stores its final destination in the pattern itself. If the encoded link needs to change, the pattern must change too. That is a reasonable choice for information that is genuinely permanent.

Restaurant menus rarely meet that definition.

A dynamic QR code separates the printed code from the final destination. The guest scans the same code, but the restaurant can update the destination behind it. That could mean swapping a menu PDF, changing a menu page, updating an ordering link, or pointing guests to a current specials page.

The important idea is simple: print should be stable; content should be changeable.

Treat a QR code like a deployed endpoint

Teams that build software already know this pattern. You do not hard-code a changing configuration value into every client if you can avoid it. You create a layer that can be managed centrally.

A restaurant can apply the same thinking:

The table card is the deployed client.
The QR code is the stable interface.
The menu, PDF, or ordering page is the destination.
The dashboard is the control layer for updates.

This framing makes decisions clearer. Before printing, ask: “If the destination changes next month, how will we update every guest-facing touchpoint?”

If the answer is “we will reprint,” the workflow is carrying unnecessary risk.

Build a small inventory before you print

The most useful restaurant QR workflow is not complicated. It starts with a simple inventory.

For every code, record:

Placement — table tent, counter, window, flyer, receipt, or takeaway insert.
Purpose — menu, ordering, feedback, reviews, loyalty, or event details.
Destination owner — the person responsible for keeping the linked page current.
Update rule — what changes require a new destination?
Test date — when it was last checked on a real phone.

This prevents a common problem: one generic code gets reused everywhere, then nobody knows which printed asset is driving scans or which one still points to an old page.

Use separate codes when the question is different

Not every placement needs a different destination. But it often deserves a different code.

A table QR and a window QR might both lead to the menu, yet they answer different questions:

Are guests checking the menu while seated?
Are passers-by looking after hours?
Did the lunch-flyer placement generate interest?
Does the takeaway insert lead people back to the restaurant?

Separate codes create useful comparison without changing the guest experience. They also make future changes safer: one placement can be updated or tested without disturbing another.

Test for the real environment

A QR code that scans on a laptop screen is not necessarily ready for a restaurant.

Test the printed version in the conditions guests will actually face:

normal table distance, not two centimeters away;
bright daylight and dim evening light;
more than one phone;
a destination that is easy to read on mobile;
a clear call to action beside the code.

The code should not be the only instruction. “View today’s menu,” “Order at your table,” or “See lunch specials” gives the guest a reason to scan and sets the right expectation.

The practical decision rule

Use a static code only when the content is truly permanent and you do not need to know what happens after the scan.

Use a dynamic code when menus, prices, PDFs, promotions, or ordering links may change after printing—or when the placement itself is worth measuring.

For a practical restaurant workflow that keeps the printed code stable while menu destinations can change, see QR Master’s restaurant QR guide.

The QR image may be small. The maintenance decision behind it is not.

I Built a German Decision-Making Tool for My Girlfriend, Then Shared It

Timo — Thu, 30 Jul 2026 07:37:03 +0000

For our anniversary, I wanted to make my girlfriend something personal that would also be genuinely useful in everyday life. Not another item to wrap, but a small digital tool we could use together.

That idea became Entscheidomat, a German-language website that turns small, everyday decisions into quick and playful moments. It is free, requires no sign-up, and works directly in the browser.

The original problem was familiar: What should we eat? Which film should we watch? Who picks first? Sometimes the decision itself is tiny, but the back-and-forth takes far too long. A little randomness is not meant to replace good judgment; it is simply a useful nudge that gets things moving.

What Entscheidomat does

Entscheidomat is built for those low-stakes moments when you want a clear answer without adding friction. The landing page at entscheidomat.com is intentionally straightforward: choose a tool, customize it if needed, and start.

The site is currently in German, because that is the audience and everyday context it was designed for. The tools themselves are universal:

Yes/No generator for quick gut decisions
Coin flip for classic two-option choices
Wheel of fortune for custom options such as dinner ideas, outings, or chores
Dice roller for games and spontaneous choices
Random number generator for any range of numbers
Magic 8-Ball for a playful answer
Name picker for groups, teams, and game nights

The interaction pattern stays consistent: pick a tool, enter your own options where useful, and let the result happen. For example, you can put restaurants or date ideas on the wheel, or add names to the picker. Instead of returning a dry line of text, the result is supported by small animations and optional sound—so the choice feels like a moment rather than a database response.

Four things I learned while building it

1. A personal project still needs a sharp use case

The anniversary was the emotional starting point, but a personal idea only becomes a useful product when it solves a clear problem for other people, too.

For Entscheidomat, that problem is simple: help people make small decisions quickly, without making the experience feel cold or mechanical. This became a useful filter for every feature: does it make the moment faster, clearer, or more enjoyable? If not, it probably does not belong in the first version.

2. The first useful result should happen in seconds

A randomization tool should not need an onboarding flow. The value is in the first click: going from “we cannot decide” to an answer.

That is why the experience is designed to work immediately on phones, tablets, and desktop browsers. The core actions are close to the surface, and customization is available when it helps rather than blocking the start.

3. Motion can make a result feel meaningful

Technically, a random result could be shown as plain text. But a spinning wheel, a rolling die, or a flipping coin makes the process legible and enjoyable. In this context, animation is not just decoration—it communicates that a decision is being made right now.

The app is built with Next.js, React, and TypeScript. For movement and feedback, I use Framer Motion, GSAP, and small sound effects. The most important question was never “which animation library is best?” but “does this feel immediate and understandable?”

4. Privacy can be a product advantage

Not every small web tool needs an account. Entscheidomat keeps settings and custom options in the visitor’s browser, so people can start instantly and stay in control of their data. That approach fits the product: it is meant for spontaneous, lightweight moments.

A small tool can start with a very personal question

Building Entscheidomat reminded me that a meaningful side project does not have to begin with a huge market thesis. Sometimes it starts with a simple question: What could make our everyday life a little easier or more fun?

A website made as an anniversary gift became a German-language tool that other people can use for their own small decisions. If you find yourself stuck between two options, give Entscheidomat a try—maybe a little randomness is the push you need.

What tiny everyday decision would you like a mini-tool to solve?

AI-Ready QR Campaigns: A Developer’s Checklist

Timo — Tue, 21 Jul 2026 12:42:48 +0000

AI-Ready QR Campaigns: A Developer’s Checklist

AI can improve what happens after a scan: personalized landing-page copy, smarter content suggestions, and faster campaign analysis. The QR code itself still needs a dependable delivery layer.

Checklist

use a dynamic redirect rather than encoding a final campaign URL directly
generate a separate identifier for every print asset
keep destinations mobile-first and fast
log only the analytics that are actually needed
update destinations deliberately and test the scan path before printing

QR Master combines branded QR codes, editable destinations, bulk generation, and real-time analytics: https://qrmaster.net

Use AI to improve the experience; use a managed QR workflow to make the connection reliable.

Dynamic QR Codes: The Redirect Layer Behind Editable Campaigns

Timo — Tue, 21 Jul 2026 12:32:33 +0000

Dynamic QR Codes: The Redirect Layer Behind Editable Campaigns

A static QR code contains its final data directly. A dynamic QR code usually contains a short managed URL that redirects to the current destination.

That extra redirect layer is what makes a printed code editable after distribution. It also creates a clean place to collect aggregate scan events, manage destinations, and keep a campaign organized.

A practical implementation checklist

Generate a unique redirect identifier for each asset.
Store destination changes as versioned records.
Return a fast HTTP redirect to the destination.
Keep scan analytics privacy-conscious and aggregated.
Test the code with several phone cameras before printing.

For teams that need branded QR codes, bulk workflows, dynamic destinations, and analytics, QR Master brings these pieces together: https://qrmaster.net

The important design choice is simple: treat a QR code as a durable identifier, not a one-off URL.

Building a QR Code Generator: Dynamic vs Static Architecture

Timo — Thu, 08 Jan 2026 16:46:40 +0000

Content
I recently needed QR codes for a client project and discovered a fundamental architecture decision: static vs dynamic. While they look the same to a user, the engineering behind them is vastly different.

The Architecture of Static QR Codes
Static QR codes are serverless. The data (URL, text, vCard) is directly encoded into the matrix pattern. Once generated, it's immutable.

How it works:
Input: "https://example.com"
Encoding: The string is converted to binary and Reed-Solomon error correction is added.
Rendering: Binary data is drawn as black/white modules.
javascript
// Simple Static Generation (Node.js)
import QRCode from 'qrcode';
const generateStaticQR = async (url) => {
return await QRCode.toDataURL(url);
};
Pros: Zero infrastructure, works offline, free. Cons: Cannot be changed, no analytics.

The Architecture of Dynamic QR Codes
Dynamic QR codes are essentially "short links" printed as graphics. They allow you to track scans and change the destination URL without reprinting the code.

System Components:
Generator Service: Creates a unique short ID (e.g., qrmaster.net/abc1234).
Database (PostgreSQL): Stores the mapping abc1234 -> https://target.com plus metadata (owner, created_at).
Redirect/Edge Server (Node.js/Redis): Handles the incoming request, logs the scan, and issues a 302 Found redirect.
javascript
// Dynamic Redirect Logic (Express + Redis)
app.get('/:shortId', async (req, res) => {
const { shortId } = req.params;

// 1. Check Cache
const cachedUrl = await redis.get(qr:${shortId});
if (cachedUrl) {
// 2. Async Logging (Fire & Forget)
logScanAnalytics(shortId, req);
return res.redirect(cachedUrl);
}

// 3. Database Fallback ...
});
Data Modeling for Analytics
To provide meaningful insights (like "Scans by Device" or "Scans by City"), you need to capture request headers and IP info during the redirect phase.

Conclusion
If you're building a simple contact sharing app, stick to static codes. But for any marketing or enterprise use case where data matters, the dynamic architecture is worth the infrastructure investment.

Building a QR Code Generator: Dynamic vs Static Architecture

Timo — Mon, 05 Jan 2026 20:37:19 +0000

Why I Built a Dynamic QR Code System
I recently needed QR codes for a client project and discovered a fundamental architecture decision: static vs dynamic.

Static QR Codes
The URL is encoded directly in the QR pattern.

javascript
// Static: URL baked into QR
const qr = generateQR("https://example.com/page");
// Can never change after printing!
Problem: Once printed, you can't change the destination.

Dynamic QR Codes
The QR contains a short redirect URL that you control.

javascript
// Dynamic: Redirect through your server
const qr = generateQR("https://qr.io/abc123");
// Server handles redirect + logging
app.get('/abc123', (req, res) => {
logScan(req); // Track analytics
res.redirect(destinationUrl); // Can update anytime!
});
Benefits:

✅ Change destination without reprinting
✅ Track scans (location, device, time)
✅ A/B test landing pages
✅ Smaller QR pattern (shorter URL)
Real-World Use Case
For restaurant menus, you need dynamic codes. Menu changes? Just update the redirect - no reprinting 1000 table tents.

I've been using QR Master for testing this pattern - it's free and has a clean dashboard for generating trackable codes.

Key Takeaway
If your QR code will be printed or permanent, always use dynamic. The 5 minutes extra setup saves hours of reprinting later.

What architecture patterns have you used for QR systems? Drop a comment! 👇