Boxary adheres a few Software Design Principles and does not interfere with Visual Design Principles.


Boxary is controlled by manifests, specifying attributes and properties, their slots, auto tags.


Boxary, as the engine, uses a proxy class to interface to the installed portal software.


Boxary uses a drawing area for the graph nodes, also called the WorkArea. A Lexicon class specifies the current context.


Templating features building app's without php coding. Boxary accepts several syntaxes: {...}, [-], (:...:). Markup is accepted thru plugins.

Elementary Elements.

  • Boxary uses Graphs.
  • Boxary uses Graph Notation.
  • Boxary consists of a compact kernel and a collection of plugs.
  • Boxary is loosely typed; data types are number, string, timeStamp and blob. No floats.

  • Boxary Themes are based on a pattern library.
  • Boxary Skins are css3 only.

Key Jargon.

Boxary uses a EAV model? for structuring data. For most people these terms (entity, attribute, value) have different meaning: one should consider that these terms are often used while different context is applied and therefor have a hidden meaning. This does not evaporate with a visualising paradigm.
Read about slots vs nodes, values and instances?, attributes vs properties, shapes and stamps.

  • Boxary ontonomy uses terms like binder, blend, slot to cope with data models.
  • Boxary uses names like bundle, facet, trove to facilitate walking the ontonomy graph (data model).
  • Boxary taxonomy uses terms like joint, trait, enum to cope with categories.
  • Boxary uses names like category, rubric, bag to facilitate walking the taxonomy graph (data model).
  • Boxary entelechy separates apps by naming jargon with terms like trunk, trove, bunch.


The architectural view of Boxary is expressed through a tetractys.
The platform - in software terms - is developed with a Cybernetics approach.