oka-project documents decisions, failed approaches, primary sources, and measured behavior—not just finished products. These are the rules I use to decide what to publish, update, and leave out.
Contents (11)
Finished products hide most of the decisions that make them useful.
At oka-project, I build browser tools, small services, interactive experiments, and media projects. The finished work appears in Works and on the Tools site, but those pages mostly show the result.
They do not show why I chose one approach over another, what I tested and abandoned, where an assumption failed, or which source changed my mind. Those details disappear quickly, and after enough time I forget them too.
This blog exists to keep that reasoning.
What I publish
I mainly write four kinds of things:
- Development logs — decisions made while building something, and why
- Technical notes — behavior I confirmed by actually running the software, including edge cases and failures
- Thinking — project principles, tradeoffs, and how I evaluate choices
- Release notes — the context behind something when it becomes public
The common rule is that the article should contain something I can explain and support, not just a topic that happens to be searchable.
The standard I want to keep
I try to write from things I have actually tested, observed, or verified.
If I have not tested something, I would rather say that clearly than present an assumption as a fact.
Failed approaches are worth keeping too. For an independent development record, knowing what did not work can be as useful as seeing the final implementation.
Before publishing, identify what this article uniquely adds
A scheduled date is not enough reason to publish an article.
Before publication, I want to be able to explain in one sentence what a reader can get here that they would not get from a generic summary of search results.
A standalone article should usually contain at least one of these:
- a controlled test or measurement I ran myself
- a difference found by tracing a claim back to a primary source
- real data from oka-project
- an original comparison with fixed criteria
- a failed approach and the decision that followed from it
- a troubleshooting path another person can reproduce
If I cannot add any of those, and the search intent substantially overlaps an existing article, the better choice is usually to merge the material instead of creating another URL.
Word count is not a completion criterion. An 800-word note can be worth keeping if it precisely documents an important change in an official specification. A 7,000-word article can still be weak if it mostly repeats generic advice.
Strengthen an existing article before creating another one
I do not want to publish simply to maintain a posting frequency.
When a closely related article already exists, the first question is whether new measurements, source material, comparison results, or failure cases can make that page stronger.
A new URL should exist only when the reader's intent and the information gained after reading it are meaningfully different.
For example, instead of splitting image compression into several generic explanations, I would rather compare the same source images as JPEG, PNG, and WebP under fixed conditions and keep the file size, transparency, visual differences, and failure cases together.
The same principle applies to Markdown transfer. A controlled test that sends the same source through Google Docs, WordPress, note, and Word is more useful than several nearly identical articles that only paraphrase each platform's behavior.
What I avoid publishing
I do not want this blog to grow by adding generic articles only because a keyword appears to have demand.
In particular, I avoid:
- describing a product or feature as if I used it when I did not
- quoting percentages, performance claims, or other numbers that I cannot trace to a source
- rewriting secondary articles without checking the underlying material
- making time-sensitive claims without saying when they were checked
- writing comparisons whose real purpose is simply to push an oka-project tool
If an operating system, browser, CMS, or platform already has a native feature that solves the job with less friction, I want to say that first.
My own tool should appear only when it is actually a reasonable option.
Research articles should preserve both sources and limits
For topics involving the web, AI, software behavior, or standards, I try to work backward to primary material when possible: official documentation, RFCs, W3C specifications, research papers, or statements from the organization that operates the service.
A primary source does not automatically make a conclusion universal.
An article may still depend on conditions such as:
- a narrow test population
- one machine or browser configuration
- a community report rather than a formal specification
- behavior observed in 2026 that may change later
Those limits belong in the article.
“Unknown” or “this source is not enough to conclude that” is a valid result.
For tool-related articles, check native features first
oka-project publishes browser-based tools, but that does not mean every article should lead to one.
If someone only needs to resize one image, an operating system's built-in tools may be enough. If Google Docs is the only destination for Markdown, Google's own Markdown features may be the shortest route. If the goal is to see how a README will render on GitHub, GitHub itself is often the best final check.
An oka-project tool becomes a stronger option when the native path still leaves repeated work—for example:
- several operations need to be combined
- the same task happens repeatedly
- one source needs to reach several publishing destinations
- the file should not be sent to a remote conversion server
That distinction matters more than forcing a product mention into every article.
When the underlying product changes, update the old article
Web services and AI features move quickly.
When an official specification or product behavior changes, I would rather correct an existing page than leave a stale explanation online and publish another article beside it.
I pay particular attention to changing areas such as:
- Google, Microsoft, and WordPress editing features
- AI search, crawlers, and robots directives
- image requirements and platform limits
- browser APIs
- security and privacy behavior
For these topics, the date of verification and the quality of the source matter.
This blog should not become a product manual
The tools are important entry points, but a useful site should not depend only on how many products it has.
Some of the most interesting questions come from building something and then following the question beyond the product itself.
Why can a browser process local files and run increasingly complex applications? Why has robots.txt survived for decades? How much of the web disappears over time?
When I research questions like these, I do not want to force the conclusion back to Yomu, Karuku, or another tool. If a project is genuinely related, I link it. If not, the research itself should still be worth reading.
Examples of the policy in practice
A few published articles show the distinction:
- Why ChatGPT Formatting Breaks When You Copy and Paste starts with the destination's native behavior before suggesting another tool.
- Preview Markdown in Your Browser — No Install, No Upload separates GitHub, local editors, Markdown Viewer, and Yomu by purpose instead of declaring one universal choice.
- Make “Nothing Leaves the Browser” a Technical Property explains the claim through CSP, network behavior, and browser-side processing rather than asking the reader to trust a privacy slogan.
- When Did the Browser Become an Application Platform? follows several primary technologies and specifications instead of attributing the change to one invention.
These pages can still change when better evidence or newer specifications appear.
What I ultimately want to preserve is the reasoning
Tools will change. Interfaces will be redesigned. Some technologies will stop being useful.
The more durable record is:
- what problem I was trying to solve
- which sources I checked
- what I compared
- why I selected one approach
- what I actually verified
- what remains uncertain
That is useful when I return to the project months later, and it can also help someone who reaches the same problem through search.
That is what I want this blog to keep.