Skip to content

Latest commit

 

History

History
33 lines (19 loc) · 2.92 KB

File metadata and controls

33 lines (19 loc) · 2.92 KB

Product

Register

product

Users

HagiCode Docs serves four core reader groups: new users evaluating what HagiCode does, operators installing and configuring the stack, active users checking feature behavior or release changes, and internal contributors maintaining public documentation, translations, and presets. Most visits are task-driven, not exploratory. Readers arrive with a concrete question and need a fast answer in Chinese or another supported locale without losing context.

Product Purpose

This site is the public knowledge base for the HagiCode ecosystem. It explains product concepts, installation paths, operational guidance, tutorials, release notes, and downloadable presets in one canonical place. Success means readers can move from search result to trusted answer quickly, stay oriented across locales, and leave with enough confidence to install, configure, or update the product without hunting through marketing pages, repositories, or chat history.

Brand Personality

Clear, reliable, restrained. The site should sound like an expert maintainer who already did the hard sorting work for the reader. It should feel calm under pressure, precise with technical detail, and confident without hype. The emotional goal is trust first, momentum second: readers should feel that the path is stable, current, and safe to follow.

Anti-references

Do not make this feel like a neon cyberpunk AI brand site, a glassmorphism-heavy concept demo, or a marketing page that keeps interrupting documentation with oversized hero theatrics. Avoid dashboard-style card spam, decorative gradients as the primary voice, and motion that competes with reading. This is not a launch campaign and not a metrics-driven SaaS shell.

Design Principles

  • Reading beats decoration. Content structure, scanning rhythm, and bilingual readability come before novelty.
  • Orientation must stay visible. Navigation, locale switching, edit affordances, and release-note wayfinding should always feel dependable and easy to find.
  • Accents carry meaning. Blue and teal are reserved for action, focus, and confirmation, not ambient decoration across every surface.
  • One product, many locales. Language changes should preserve trust, layout stability, and conceptual continuity rather than feeling like separate microsites.
  • Serious but not severe. The interface can feel polished and modern, but it should never drift into theatrical, aggressive, or self-promotional styling.

Accessibility & Inclusion

Target WCAG AA as the default bar for contrast, focus visibility, semantic structure, and keyboard access. Respect reduced-motion preferences by disabling non-essential animation when users opt out. Preserve long-form readability with stable line lengths, clear heading hierarchy, and strong mixed Chinese-Latin typography. Never rely on color alone to communicate state, and keep locale selection, edit links, and utility controls usable on both pointer and keyboard flows.