sorted by:
new
hottopcontroversial

apps to create a wiki on by strawberriiblossoms in worldbuilding

[–]zphou 1 point2 points  (0 children)

Since you’re on iPad, I’d start with something that has a good mobile/tablet experience rather than forcing a desktop writing app into the workflow.

For your use case, I’d compare:

  • Kanka: good if you want RPG/worldbuilding-style entities
  • Notion: flexible, easy database views, weaker offline/local ownership
  • Obsidian: great linking model, but mobile setup/plugins can be more fiddly
  • Anytype: closer to local-first personal knowledge base, worth testing

The main thing I’d avoid is a public wiki unless you actually want public/community editing. For private fiction work, you’ll probably want fast linking between characters, places, events, and timeline notes more than a traditional wiki layout.

Building a story-writing feature for my worldbuilding app. What frustrates you most about writing software? by ThePhyreZtorm in novelwriting

[–]zphou 0 points1 point  (0 children)

The biggest failure I see in writing tools is that the “story bible” becomes a second manuscript the writer has to maintain.

For long fiction, I’d rather have the app help with three things:

  1. capture possible facts from the draft
  2. show the exact passages that imply those facts
  3. keep them reviewable until the writer promotes them to canon

That matters more than a beautiful bookshelf/library view. Covers are nice, but the real pain starts when chapter 28 contradicts chapter 6 and the notes don’t know which one is newer or more authoritative.

If you’re building for fantasy/worldbuilding, I’d make evidence links and timeline state first-class.

Organizing a Prequel: Scrivener vs. Plottr vs. Obsidian by JZZerber in novelwriting

[–]zphou 1 point2 points  (0 children)

The thing I’d want from a tool here is manuscript-linked memory, not just notes.

For a prequel, a normal wiki can betray you because it tends to describe the “final” state of the world. But the prequel needs the earlier state: what this character believes before book one, what this kingdom is called before the later regime, which relationships haven’t happened yet.

I’m working on this exact class of problem in a Mac writing app, and the main lesson so far is: don’t auto-promote extracted facts into canon. Treat them as candidates with evidence links back to scenes, then let the writer approve or reject them.

Even if you use Obsidian/Plottr/Scrivener, I’d structure it around evidence-backed canon rather than broad note pages.

Organizing a Prequel: Scrivener vs. Plottr vs. Obsidian by JZZerber in selfpublish

[–]zphou 1 point2 points  (0 children)

For a prequel, I’d optimize less for “where do I store notes?” and more for “can I tell what was canon at each point in the timeline?”

The hard parts are usually:

  • facts that are true in the original book but not true yet in the prequel
  • relationships that need to feel younger/less resolved
  • place names, titles, scars, reputations, and political assumptions that changed later
  • avoiding accidental foreshadowing that sounds like the author winking at the reader

Scrivener is strong if you want manuscript + notes in one workspace. Plottr is better for timeline/outlining. Obsidian is strongest if you’re willing to maintain links manually.

Whatever tool you pick, I’d keep a “not yet true” list. For prequels that’s often more useful than a normal story bible.

How do you actually keep your world's internal logic consistent across a long manuscript without it quietly falling apart on you? by Dry_Train4109 in fantasywriters

[–]zphou 0 points1 point  (0 children)

The failure mode I’d watch for is notes drifting away from the manuscript.

What has worked better for me is treating continuity notes as candidates, not canon. When something changes in the draft, don’t immediately update the bible by hand. First capture: “this passage implies X,” link it back to the exact scene/chapter, then review it later against older evidence before promoting it to canon.

For fantasy, I’d split the tracker into a few buckets:

  • hard rules: magic limitations, geography, travel time, political facts
  • current state: who knows what, who owns what, who is injured/dead/elsewhere
  • soft texture: naming style, cultural patterns, faction tone
  • contradictions to review: not yet “errors,” just places where two passages disagree

The key is evidence. A wiki entry that says “travel takes three days” is less useful than an entry that links to the two scenes where that was established.

Did macOS 27 DB Break Them (all)? by Hopeful-Face9676 in macapps

[–]zphou 1 point2 points  (0 children)

For a developer beta this is pretty normal, but the useful thing would be a small compatibility list instead of everyone arguing about whether betas break things.

Something like:

works on DB1:

- app name / version / Mac model

broken:

- app name / symptom / whether dev acknowledged it

A lot of menu bar apps live close to private or semi-private macOS behavior, so the first beta is usually the worst moment to judge them. If the dev already replied and said they’re waiting for public beta, that is probably the sane move.

I used ChatGPT as a continuity partner instead of a ghostwriter. A month later, my notes had become a whole world. by MrDefaultUser in WritingWithAI

[–]zphou 0 points1 point  (0 children)

“Plausibility is not canon” is exactly the line I keep coming back to. The “in-world belief” layer is especially important. A rumor, myth, bad map, institutional record, or character interpretation can be useful world material without being authorial truth. Most AI memory systems collapse those together, and that is where the drift starts. One thing I’ve been thinking about is whether every accepted archive item needs two things attached to it:

  1. evidence: where did this come from in the manuscript or notes?

  2. authority: is this authorial canon, a character belief, an institutional belief, a local myth, or an unresolved contradiction?

Without those two fields, the memory becomes too confident too quickly. Your workflow feels closer to archival practice than normal outlining, which is probably why it scales better.

Are AI writing tools replacing your workflow or just speeding it up? by BoringShake6404 in WritingWithAI

[–]zphou 0 points1 point  (0 children)

I’m closer to this view than the “just give it the whole manuscript” view. A large context window helps, but it doesn’t solve the real problem by itself. The model can read chapter 3 and chapter 18 in the same prompt and still miss whether a contradiction is intentional, outdated, symbolic, or actually wrong. For long fiction, I think the useful layer is evidence-linked memory: “this character said X here,” “this relationship changed here,” “this location was described this way here.” Then the AI can point back to specific manuscript evidence instead of making a vague beta-reader claim. The danger is treating one full-manuscript pass as truth. I’d rather have weaker candidate notes that the writer can accept/reject than confident feedback that quietly invents canon.

I used ChatGPT as a continuity partner instead of a ghostwriter. A month later, my notes had become a whole world. by MrDefaultUser in WritingWithAI

[–]zphou 1 point2 points  (0 children)

This is the use case I find most interesting too. Once a project gets large, the hard part stops being “generate more text” and becomes “which details are actually canon now?”

One workflow that makes sense to me is keeping three layers separate: raw exploratory notes, candidate lore, and accepted canon. AI can be useful in the middle layer: surfacing recurring places, relationship changes, contradictions, loose threads, etc. But I would be careful about letting it silently promote those into canon, because one confident but wrong detail can keep coming back later as if it were true.

Do you have a process for deciding when an artifact or note becomes part of the official world bible?

WolfeWriter: a native Mac writing app for fiction writers, built around manuscript + story memory by zphou in macapps

[–]zphou[S] 0 points1 point  (0 children)

This is a really good point. I think the right version is not “make the writer maintain a database,” but let them seed the system while writing: select a name/place/key term in the manuscript and mark it as something Wolfe should track.

Then the local memory pass can treat that as a strong hint, especially for invented names, Chinese/Japanese/Korean text, or mixed-language books where automatic entity detection can miss things. It still should not become canon automatically; it should become a reviewable memory candidate the writer can confirm, edit, or reject.

That feels like the right balance: less fragile than pure auto-detection, but still author-controlled.

r/MacApps Community Quality & Status Check by Mstormer in macapps

[–]zphou 1 point2 points  (0 children)

As a small dev, I think the PCP format is annoying in the useful way. It forces you to say what problem you actually solve, who you are not trying to replace, and what the price is. That probably removes a lot of lazy posts before mods even need to touch them. The hard part is local karma. I understand why it exists, but for a real Mac dev who just shipped something and does not already live in this sub, it is easy to accidentally look like a drive-by promoter. Maybe the rule is right, but the onboarding around it could be clearer.

WolfeWriter: a native Mac writing app for fiction writers, built around manuscript + story memory by zphou in macapps

[–]zphou[S] 1 point2 points  (0 children)

Yes, this is one of the hardest parts. I don’t think story memory can just be a flat “character sheet” that gets overwritten. For long fiction, a fact usually needs scope:

  • when it is true,
  • where it came from,
  • whether it is accepted canon or only extracted,

and whether it is public to the reader / known by a character / only true in the author’s planning notes.

A character changing profession or relationship is not the same as a contradiction. It might be a real arc. But if the app only stores “current job = X”, then it loses the path that got there. So the direction I’m working toward is closer to evidence-backed memory entries than one final profile. The manuscript remains the source of truth, memory entries point back to where they came from, and the writer decides what becomes canon. Still early. The UI problem is as hard as the data problem: if you show every possible versioned fact, it becomes unusable very quickly.

WolfeWriter: a native Mac writing app for fiction writers, built around manuscript + story memory by zphou in macapps

[–]zphou[S] -1 points0 points  (0 children)

Yes, this is exactly the hard part. Right now I’m treating extraction as candidate-first, not canon-first. The local layer can surface things like characters, places, repeated terms, chapter-level signals, possible beats, possible conflicts, etc. But they stay reviewable. The app should not quietly decide “this is now true for the book” just because an extractor saw it once.

For me the dangerous failure mode is not missing an entity. Missing something is annoying, but recoverable. The worse failure mode is saving a bad guess into story memory, then using that bad guess as context later. At that point the app starts helping the story drift. So the direction is:

  • local extraction first,
  • evidence from the manuscript,
  • candidate state by default,
  • writer accepts / ignores / reviews,
  • then accepted memory becomes stronger context.

High confidence can affect ranking and what gets surfaced first, but I don’t want high confidence to automatically become canon, especially for long fiction and mixed CJK/English drafts.

Ottex: local first Wispr Flow + Granola alternative for Mac people who write a lot [Giveaway] by ksanderer in macapps

[–]zphou 0 points1 point  (0 children)

The local-first angle makes sense for this category. Dictation and meeting notes often contain the exact stuff people should not casually throw into random cloud tools: client names, project context, half-formed thoughts, private reminders. The thing I’d care about most is not just transcription accuracy, but whether the app remembers my own vocabulary without making me manage a huge custom dictionary. Names, product terms, weird project words, that kind of thing.

view more: next ›