BasicUI Boot Camp

BasicUI is a complete re-thinking of UI. As such, you will need to learn some new concepts in order to use it effectively. Designing an app with BasicUI is relatively simple - it's mostly point and click, with intuitive, immediate feeedback. But the underlying concepts that govern how the app behaves when it is rendered can require some time to master.
The effort is worthwhile because the end game is lucrative. Rapid Application Design (RADes) and Hyper-responsive web development (h-RWD) rendering will radically and permanently alter your approach to software development. BasicUI is a launchpad into a new design paradigm that will dominate software development for years to come.

Squares

All BasicUI designs are rendered visually on a device using an alignment system that is based on grid of squares that resembles graph paper.
The width and height of the base square for a particular target device is fixed and abstract (as opposed to being defined in inches, elements, or pixels). This base square unit is calculated in advance.
Generally speaking, the size of the square is determined by discovering the smallest size that is also large enough to be comfortably touched with a finger (on a touchscreen device) or clicked with a mouse (on a mouse-driven device) or visually located (on a remote-drive or hardware button-driven device). No element on the display is allowed to be rendered smaller than a 1x1 square.
Editor's note on rationale: To allow maximum comfort/useability. We can't use inches or pixels because tvs are viewed from far away, small devices like watches and phones are viewed close up. Users might want/expect larger and smaller unit sizes.

Elements

Everything in BasicUI is comprised of elements. Elements are strung together in collections and/or nested inside of one another. Literally everything that BasicUI can create, from webpages to mobile apps to IoT device interfaced, is created from the same common set of elements that the designer has arranged and defined.

The Basic Element

At this time, there is only one type of element: The Basic element. This remarkably versatile element has been carefully crafted in such a way that it can meet virtually all UI use cases including websits, mobile apps, televisions, wearables, and IoT device displays. The manifistations of element designs can vary wildly, but they are all still the same Basic element underneath. Designers craft Basic elements to suit their needs, and arrange, combine, and nest them into configurations that are meaningful and useful to the end user.

Basic Element Parts

To keep the system simple, used or unused, all of the Basic element's attributes, or "Parts," are always encapsulated in every instance of the element. Here are the Basic zParts:
Editor's note on rationale: This list has been carefully crafted to handle the majority of use cases in an app.

Basic Element Layouts

There are two layouts for the Basic element:
Editor's note on rationale: Keeps the system simple and accounts for most app use cases.
The layout is specified by the designer and is considered pretty important to honor, relative to the designer's original wishes. Ocassionally, however, the rendering engine may elect to compress a vertical into a horizontal, usually only if absolutely needed.

Basic Element Field Types

The Field part of the Basic element is special and one if its purposes is to hold a data value which the user may or may not be able to edit. All data values are stings and may be saved to persistent storage, if the designed has indicated as such. The Field part can also act as a container for other Basic elements. Here are the three interchageable forms that the Field type can take:

Rendering Engine

At runtime, a sophisticated rendering engine determines the ideal sizing, layout and placement of all elements, and renders it to provide the absolute best UI experience, taking into consideration the capabilities and form factor of the device in use at the time. Since the rendering engine guarantees absolute optimal UI for every user experience, the designed does not have to check any devices individually.
The rendering engine takes into consideration:

Design Decisions

The designer can only specifies design decisions which indicate (really, only suggest or hint, to varying degrees) how the elements are intended to be rendered. The designer cannot completely control or be guaranteed what decisions the rendering engine makes at runtime. See Appendix A, Design Decisions for a list of design decisions.

Badges

Since there may not be sufficient screen area to display a the minimum required parts of a given element while still honoring the minimum square size for the rendered device, the given element might need to be displayed as a badge. A badge is a graphical representation summarizing what can not be fully displayed. When this occurs, the element is said to be badged. The badge can be default or specified by the designer. It might be a representation of the element that lies underneath, or a general icon that indicates there is much more that just one element the badge (think hamburger icon). The decision to render the element as a badge or not is ultimately governed by the rendering engine at runtime.

Zooming

Any element that the rendering engine might compress to be smaller than a single square will be displayed as a "badge." At this smallest size, the element is allowed to display things smaller than the square, but only for non-interactive, visualization purposes. When an element is badged it is not useable for user interactions until it can be made larger.
Typically, the user will interact with the badge via the zoom action (see Actions below). At that point, the element will be zoomed, or displayed at a larger size, either as a popup of varying specified size, or as a full screen element. Any given element may not have enough space to render at any given time, so all elements will have the potential to be badged and/or zoomed. Also, elements may be expanded to be larger, even when not badged, to take advantage of available screen space, depending on the given design decisions. An element may be useable after being zoomed out of a badged state, but the designer may still opt to allow further zooming for maximum useability, if the device allows it.
Editor's note on rationale: This is to enforce maximum comfort/useability. Visual elements can provide indication of what is underneath. We refrain from overwhelming the user by keeping a pace on how much information is displayed and can be acted on in any given area.

Levels

The first element that is requested is said to be displayed at Level 1. The rendering engine attempts to utilize all available space it was given when the request was made. If a element cannot be displayed fully at level 1, an error has occurred and the app is not useable on that device. For that reason, the square size for a given device is usually never less than 1/5th of the width/height of a device. That gives enough room for a typical single Basic element to display fully. In practice most devices are carved up into much more than a 5x5 grid (a design using a Basic element of one atom is theoretically possible, but in almost all cases not very useful).
When a Basic element ...

Basic element Horizontal Layout Rendering at Different Levels

Basic element Vertical Layout Rendering at Different Levels


Appendix A - Design Deicisions