Skip to content
Approach

Design Principals

Approach Interfaces consider visual Elements, visual “Props”, visual Components as building blocks which compose layouts of a Screen. Each Composition has/is a Stage with several Screen; While not bound to this precise structure they are:

  • Compositions
  • Components
  • Props

These have special meaning to both code and design.

Composition

The actual document being composed, including all its assets, code formatting, scripts, styles, URI, context, etc This would entail most the html document

Component

A visual entity grouping some cohesive data, mapped by the backend and/or frontend scripting into some screen. Similar to an MVC view or Bootstrap component + data. Components always appear in groups, even if only a single Component is rendered. Doing so a this precise inflection point in the DOM allows drastically reducing the use of wrapper containers within Components

Props

Modals, Toolbars, Decorative visuals - generally things which are out of flow in a sense. They are tools which may be almost as complex as components. A form control is arguably the most common prop, but they may be complex or single elements. They may have tokenizable data points and attributes. Props are generally stored in #Stage #Offscreen.Screen #PropLibrary

Why it was created

None of these specific markup requirements .. are actually required for the Interface system. However the Interface system was created to

  • To faciliate treating Component Groups as a stream of Components
  • To help Props move through their activity lifecycle, from the designer point of view rather than the developer
  • Avoid writing JS, but leave everything hookable so a developer can tie in their logic on response or tweak things preflight on request
  • Above all to depcrecate HTML form controls in favor of custom forms elements with their own Shadow-DOM and modular behavior
  • Exploit the understanding that all code functionality boils down to two thing:
    • Resolving a command scope
    • Supplying supporting arguments to that command scope
  • Support clueing in the server about what the client is trying to achieve, so response can change or simply forward this may seem redundant, but does allow more flexibility in server response.
  • Easier to create client-side “servelet” which mimics the server application from XML/JSON feed caches on a CDN
  • Takes inspiration from Video Ad standards such as VPAID and systems like KODI in order to abstract interactions and encourage navigation