Our approach

From research to a useful interface.

We want readers to see how a reference becomes a deliberate Starlit decision.

Start with the task

Identify what a person is trying to do, the information they need and the barriers they might meet. Choose a pattern because it helps that task. Decoration comes after a clear reading order, meaningful names and an understandable next action.

Research and adaptation

Our research considered EvansWiki’s reading preferences, PayCal’s interface practices, public accessibility projects, and the Starlit template collection. We recorded useful patterns and chose which ideas fit our own products.

For example, Fluid UI Options demonstrates separate reading adjusters. We folded that modular approach into our own thinking: twelve independent components share a scoped controller, so a site can use a small toolbar or a complete preferences centre.

Each component distinguishes the source idea, Starlit’s adaptation and the actual browser code. An inspiration credit does not imply endorsement or a code dependency.

Interface principles

Clarity before novelty
Use familiar controls, visible labels and descriptive links. Let hierarchy explain what matters.
Content before decoration
Keep text real, let layouts reflow and retain a usable page when enhancements fail.
Control without assumptions
Offer reversible preferences without guessing a disability. Respect device motion settings and deliberate playback.
Honest feedback
Explain loading, empty, error and success states. A local demonstration must say it has not sent or purchased anything.
Consistency with context
Reuse the foundation, then adapt the layout to the person and task. Avoid installing unused controls simply to fill a checklist.

Our usage pattern

  1. Define the task, audience and relevant constraints.
  2. Inspect the component’s research, tradeoffs and live example.
  3. Use its semantic HTML and required browser assets.
  4. Connect real authored content, application state and preference tokens.
  5. Verify keyboard flow, focus, narrow layouts, enlargement, contrast and reduced motion.
  6. Record the integration’s tested scope and unresolved limits.

On sltd.ca, the header gear uses an adapted preferences centre. The homepage uses the text moment stylesheet for short gold accents. Other library components are available as studies; their inclusion does not claim deployment across all our products.

Guidance and standards

Our web implementation uses semantic HTML and W3C accessibility guidance. Apple’s Human Interface Guidelines inform clarity, hierarchy, consistency and user control. We adapt those principles to browser conventions, rather than treating native platform measurements as universal CSS requirements.

The reading palette uses a project target of 5:1 for measured reading pairs. WCAG has separate requirements for different kinds of content. A palette result is not a whole page conformance result.

Scope and limitations

This portal documents interface patterns and browser interactions. PHP examples show server rendering and escaping; they do not implement production mail, payments or account workflows. DYWS commerce and delivery capabilities are outside this library’s runtime scope.

Read the verification limits and review the sources and credits.