Shoji Architecture

At its most basic form, the Shoji Architecture is designed to resemble a Japanese sliding door/window known as a shoji. This architecture is designed to allow developers the ability to fit complex interfaces into a compact space without sacrificing the useability, readability of the interface, or user experience.

It does this by allowing the user to dynamically allocate more space to widgets by either pressing the hotkey < ~ >, < space > or by simply moving the slider. We won't be talking about the slider as that functionality is fairly common in modern interfaces. When the user presses the predefined hotkey, the widget will consume all of the available space of its siblings. This operation can be undone, and the space can be returned to its siblings simply by pressing < esc >.

In the example below, we can see how a Shoji Layout works in its simplest form. By pressing < ~ > or < space > the widget consumes more space. Conversely, pressing ESC returns the space consumed by a widget back to its siblings.

However, this by itself does not warrant much attention as the gains to the user experience are quite negligible. We can start to see the potential power of this architecture when we start to embed Shoji Layouts inside of each other, creating a more complex interface as seen below.

This method of layering Shoji Layouts inside of each other forms a toolbox for users that resembles a tansu. As we start to see Shoji Layouts embedded inside of each other, we can start to envision the potential power that they can provide to users.

However, as we can start to see here, by combining multiple Shoji Layouts together, the level of visual complexity starts to accelerate at an alarming rate. In order to combat this, two strategies are used. The first is to place an overlay over each widget, thus allowing users to easily differentiate between different portions of the toolbox.

As we can see in the example below, images of basic shapes have been placed over different Shoji Layouts. When the user's cursor hovers over one, the contents of that specific layout are revealed.

The second strategy is to allow the user to determine which widgets they wish to display using a list or tree view. This is called a Shoji Model View Widget (Shoji MVW), as it combines a Model View Widget (MVW) with the Shoji Layout. This means that every item in the MVW will have a widget or widget type associated with it. So that when the user clicks on an item, the widget (type) associated with that item is displayed to the user in the Shoji Layout.

With the Shoji MVW, the developer can use a few different strategies to determine how items are linked to widgets. The first strategy is called static mode and it allows the developer to define a widget for each individual item. The second allows the developer to define a single widget type, that will be dynamically created when the user clicks on an item. When in this dynamic widget creation mode, the developer can still assign a unique widget to each item to override the dynamic propagation.

In the example below, we can see a Shoji MVW in static mode displaying a few different widgets. As we can see, as the user selects items on the left, the widgets associated with those items are displayed on the right.

Furthermore, the view containing the items is not required to be on the left of the display and can be moved to any of the four sides.

A great example of the Shoji MVW can be seen below in the Node Graph Pins tool. In this tool we can see a Shoji MVW set on dynamic creation, creating Shoji MVW's which are set on dynamic creation and are creating parameter/node displays.

Node Graph Pins

Play Video