Improving The LLM Wiki Setup Wizard And Public Guidance - Source Excerpt 02 - User feedback and benchmark patterns

Back to Improving The LLM Wiki Setup Wizard And Public Guidance

Summary

This source excerpt begins near User feedback and benchmark patterns and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Improving the LLM Wiki Setup Wizard and Public Guidance.md.

**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Improving the LLM Wiki Setup Wizard and Public Guidance.md

| Area | Current state | Assessment | Evidence |
|---|---|---|---|
| Content | Strong conceptual guidance on the homepage, “Start Here,” metadata, structure, ingest, governance, and authority boundaries. | Strong foundation; needs simplification, sharper audience segmentation, and more task-first copy. | citeturn4view0turn4view2turn4view3turn4view4turn11view1turn11view2turn12view2 |
| Structure | Public handbook is organized into major topical lanes, but related pages still rely heavily on repeated global route blocks. | Good macro-structure, weak page-level hierarchy expression. | citeturn4view0turn3view0turn5view3 |
| Navigation | Header + menu + source-map rail repeat across pages; breadcrumbs are shallow. | Overexposed nav chrome, underdeveloped local navigation. | citeturn4view1turn4view2turn4view3turn4view4turn29search6turn29search18 |
| Accessibility | Skip link is present. Public text does not expose user-facing validation/error copy for the wizard. Inline option lists are very dense. | Some positive basics, but high risk around reflow, labels/instructions, keyboard effort, and error recovery. | citeturn4view1turn4view2turn29search0turn29search15turn36view0turn36view2turn35view3 |
| SEO | `llms.txt` exists, homepage advertises discovery files, but `robots.txt` points to `wp-sitemap.xml` while homepage links `sitemap.xml`; canonical strategy is described in prose more than surfaced in metadata policy. | Discovery intent is strong; implementation signals need tightening. | citeturn3view2turn5view3turn6view0turn6view3turn30search0turn30search1turn30search3turn30search6 |
| Mobile and responsive | No public responsive benchmark was available in this audit. The wizard’s visible content is highly dense and appears likely to stress small-screen reflow. | High structural risk; requires manual responsive QA and simplified step screens. | citeturn35view3turn29search0turn29search3turn29search10 |
| Performance | No public Lighthouse or CrUX score was located. Structurally, repeated navigation and very long inline content blocks increase page complexity. | Performance should be measured before and after redesign; likely gains available from simplification. | citeturn35view3turn27search2turn28search13 |
| Error handling | Draft persistence is local-only; “Clear draft” exists; public “not supported” boundaries are explicit; hosted import validation is not supported. No visible validation/error messaging surfaced in extracted copy. | Boundaries are clear, but recovery and validation UX are underdeveloped. | citeturn36view4turn5view2turn36view1turn36view0turn36view2 |
| Onboarding flow | Seven-step wizard, packet generation, optional direct setup paths and query parameters, but advanced branches appear early. | Needs presets, earlier wins, and more progressive disclosure. | citeturn5view0turn5view1turn5view2turn36view1 |
| Internationalization | Homepage explicitly says multilingual support is not currently claimed. | Honest boundary, but no visible i18n readiness model yet. | citeturn4view0turn5view3turn30search2turn28search19 |

The most important audit conclusion is that **the wizard is not failing because it lacks capability**. It is failing because the same page is currently trying to be a public explainer, an expert architecture worksheet, an AI-agent digest, a packet generator, and a boundary-policy statement all at once. Those functions should be separated more deliberately in both content design and interaction design. citeturn4view1turn5view2turn36view1turn29search2

There is also a **cross-domain clarity issue**. wiki.fftac.org explicitly tells readers that LLMWikis remains the handbook source, but wiki.fftac.org still publishes topic indexes, recovered summaries, source proxies, and concept-adjacent pages that overlap with handbook intent. That is not necessarily wrong, but it increases the need for explicit canonical rules, clearer page typing, and noindex/canonical decisions for pages whose primary purpose is provenance rather than primary-topic coverage. citeturn0search1turn0search2turn0search3turn8search3turn8search5turn30search1

## User feedback and benchmark patterns

I did **not** locate direct public forum threads, issue reports, or social conversations specifically about `llmwikis.org/tools/llm-wiki-setup-wizard/`. For the current public LLMWikis wizard itself, feedback is therefore **unspecified**. What is available is adjacent ecosystem feedback from public issue trackers, forums, GitHub repositories, and social channels around “LLM Wiki” implementations. That ecosystem feedback is highly relevant because it points to the same kinds of setup friction the LLMWikis wizard is trying to solve. citeturn25view2turn25view1turn25view0turn26search4

The strongest recurring signals are these. First, users and builders want **fewer setup steps and fewer scattered prompts**: one Hacker News launch post explicitly contrasts its previous setup—“three prompts scattered across GitHub gists”—with a packaged marketplace/plugin install. Second, builders want **reliable resumability**: a public issue in `obsidian-llm-wiki-local` reports that `olw ingest --all` could not resume after an intermittent failure and required a time-consuming forced rerun. Third, there is persistent demand for **local-first privacy and low-friction setup** in the Obsidian ecosystem. Fourth, users are frustrated by **provider and plugin fragmentation**, with separate AI integrations requiring separate configuration. Those are precisely the problems a setup wizard should reduce. citeturn25view1turn25view2turn25view0turn26search2turn26search4turn26search11turn26search14

The benchmark set below focuses on comparable open-source projects, documentation platforms, and CMS guidance. Because most official docs do **not** publish funnel completion rates, the “onboarding metric” column uses the best published proxy available: step count, quick-start time estimate, or first-success command.