Design Guidelines
The main design goals are (in this order)
Ease of Use
Regarding the rapid development of new ideas, ease of use comes at a premium. The goal is to reduce the amount of lines-of-code needed to get an idea up and running to a bare minimum. Several guidelines help us achieve this goal:
- simplicity - We generally try to keep things as simple as possible but no simpler. If it is not possible to actually make it simple - some things in life just aren't - we will hide complexity behind a reasonably simple interface. This can, e.g., be done by convention over configuration (see below).
- conceptual integrity - There is one (design) solution to a given problem and this solution is compatible to the solution for other, related problems.
- convention over configuration - We assume "best-of-breed" defaults, e.g. in the choice of specific rendering implementation, wherever feasible. Yet, we carefully balance this assumption against the goal of extensibility and avoid shady "automagic".
Quality over Completeness
The idea here is very much to do few things really well rather than offering a mediocre experience for many. If we can "buy" functionality from the outside with reasonable (integration) cost, favor this over a home-grown implementation here. If we can't, provide the best possible realization - within the given constraints of time et al. - in Phoenix. If at any point old functionality/design decisions/... stand in the way of new stuff, make a conscious decision of whether to fix the old stuff, drop it, or drop the new ideas. In this way, we ensure that the system undergoes constant rejuvenation - as its name suggests.
Flexibility and Extensibility
This being a research platform, defaults should be reasonably easy to override; new ideas and techniques should be flexibly integrable. In order to support the transition from research prototype to production use, the architecture has to be reasonably open without being over-engineered. This is a tough call to make. As a rule of thumb: if there's a realistic user story for a given piece of architecture, try addressing it. We acknowledge that this system will change, and change often. As such, we try to keep the cost of change low, e.g., by providing automated tests - wherever reasonable - in order to ensure proper function even after major surgery.
Reliability
Quickly sketching out a research idea and running a production visualization run, both, require a certain amount of stability. Functionality should not "just break". Stuff which is there should work as expected. Stuff that no longer works should either be fixed or scratched from the project; a decision on which way to go has to be made ASAP. We use smoke tests and automated builds to ensure that stuff does not break arbitrarily.
Performance
Performance is critical to the point that we aim to run applications in immersive VR. Hence, they have to conform to fundamental performance numbers, which are stricter than those for classical desktop setups:
- frame rates should be 60Hz (or better depending what your output hardware gives you)
- end-to-end latency for direct user interaction (e.g., head tracking) should be below 100ms.
We acknowledge these goals, yet we are aware that optimizing beyond these critical thresholds might interfere with the aforementioned goals. Hence, performance takes a back seat to them as long as basic needs have to be addressed.