Our Products

OurProducts

You are here

Encircle

Encircle

Description

Encircle is a cross-platform imaging toolkit that affords a natural user interface for 3D image visualization, 3D reconstruction, arbitrary slicing, and much more. Encircle is a novel technological foundation that allows for the generation of state-of-the-art 3D imaging applications.

Encircle is the harmonious integration between a high-performance 3D imaging toolkit and a user interface widget library. Patented technologies form this union by aligning design paradigms between the two. This saves the software developer substantial time and allows them to focus on scientific problems at hand when developing complex high-performance applications. This saves time, money, and makes our software developers more efficient at solving difficult real-world software problems.

Measuring the complexity of a user interface is challenging. Tangible metrics such as lines of code and required level of understanding are both reduced using the Encircle platform. However, it is the intangible issues that contribute to complexity in difficult to measure ways. Consider these questions in regard to your current platform of choice and how they contribute to your everyday workload:

How do you position widgets in a UI layout?

How is the UI context (i.e., a list box selection state) accessed by application data structures and algorithms?

How do widgets get their data?

What percentage of your time is spent on (re-)wiring UI elements to data structures compared to high-value time spent on data structure and algorithm development?

Furthermore, consider how each of these issues affect late-stage UI design changes. Typically, these issues result in several hours/days of work for minor UI changes, such as moving a button or changing the window hierarchy.

Features

Cross-platform development: Windows and OSX.

Integrated multi-processor threading support.

OpenGL integration and substantial support for hardware accelerated graphics.

Patent pending centralized selection context for handling selection state throughout a software application.

and more...

User Interface Layout Technology

Encircle Layout Technology

Stratovan Relay™ is a patent-pending resolution independent layout technology that bases runtime widget resizing and positioning on two source layout designs. The UI designer specifies a small and large layout so that the widgets are positioned correctly for each size. During runtime, Relay automatically determines the size and position of each UI element based upon the runtime width and height of the layout.

The following images show an actual UI designed using Relay technology and the corresponding runtime layouts (click on each image to enlarge):

How much effort is required to change a UI layout several years into product development?

Is your layout system resolution independent?

Conventional layout technologies:

Are based on one design layout and cannot resize (at all) during runtime.

Are based on one design layout and require hand-coding to achieve runtime resizing

Are entirely hand-coded.

Use widget edge-relationships to establish resize logic.

Use fixed dimensions or ratios of the width/height to determine size and position.

Require hours of work to change.

Never seem quite right during runtime.

Are NOT resolution independent.

Selection Management and Data Binding

Centralized Selection Context

Stratovan Encircle™ integrates a patent-pending centralized selection context for widgets. The technology pulls the selection state for each widget out of the widget itself and places it in a centralized storage that can then be queried, updated, or listened-to from any portion of the application.

Centralizing the runtime UI selection context has a profound effect on reducing the complexity of data binding between the UI widgets and your data structures and algorithms. The following image shows a diagram of the conventional selection context in relation to data binding:

Under this paradigm, the application developer must mediate between the widgets and data structures and algorithms (data storage). The mediator must query widgets for selection state, retrieve the appropriate data, and then provide that data directly to each widget. This results in several direct connections to widget objects. These direct connections are the main source of complexity that prevent late-stage UI changes.

Some widget toolkit vendors recognized the difficulty with providing data to widgets and added direct data binding to alleviate the issue:

While direct data binding alleviates the issue of getting data into a widget, the application developer must still query widgets directly to obtain their selection state in order to determine which data the widget displays. Thus, direct connections to widgets are still commonplace under this modified paradigm.

Encircle combines direct data binding with a centralized selection context in the following manner:

This paradigm eliminates all direct connections between widgets to internal data structures and algorithms. Flexibility is obtained by connecting through generic direct data binding interfaces in addition to connecting to the central selection context. This results in a less complex mediator and minimizes the maintenance of the "wiring" between widgets and data. Since the UI connections are simplified, late-stage UI changes (i.e., moving widgets around based on user studies and requests) are now easily incorporated.

Conventional Selection Management

Consider these questions for your current widget platform:

How is the UI context (i.e., a list box selection state) accessed by data structures and algorithms?

How does one widget access the selection context of another widget?

Does the toolkit developer or the application developer (you) manage the UI selection context?

Does the widget/window hierarchy play a role in selection management/access/routing?

Is there a delineation between commands and selection state changes?

How do custom controls share/access selection context information?

Conventional paradigms are widget-centric in that widgets "own" their selection state. This requires the application developer to query each widget when the selection state is needed. Consider how a list box maintains selection state and how it must be queried to obtain it within an application. A widget-centric paradigm results in:

Direct connections from widgets to data structures and algorithms.

Multiple copies of selection state in different widgets that indicate the same selected data.

Complex handlers for selection state changes as well as direct connections to widgets.

Complex relationships in window hierarchy and selection state update routing.

Inflexible logic for coping with widget selection state changes.

Direct connections to other widgets for the purpose of propagating selection

Conventional Data Binding

Consider these questions for your current widget platform:

How do widgets get their data?

How are widgets connected to data?

Does the widget/window hierarchy play a role in data binding?

How does UI selection context affect widget data?

Does your current widget toolkit dictate internal data structures?

How are widgets attached to hierarchical/nested data?

How are widgets notified when their underlying data has changed?

Notifications

Stratovan Encircle™ utilizes a class-centric notification mechanism. It is class-centric in the sense that the specific notifications (messages, connection points, etc.) are defined relative to a specific class. This is counter to conventional paradigms that tend to use a numeric counter or ID, which can easily lose integrity in large software projects.