App interfaces shall be organized into a hierarchical sub-view structure.
The structure of this hierarchy shall be defined only by the relative positions of view wrapper elements in the DOM.
Views shall have no knowledge or dependency on their parents except for listening to events broadcast by them.
Views shall have state attributes who's values are reflected in the DOM (for styling purposes) and when these attributes are changed, events are broadcast to the view's children.
Parents may bind to their children's events.
All DOM updates shall be handled manually, not to punish the developer, but to ensure full control for high-performance applications.
Views shall be be recycled automatically using an Object Pool to prevent memory leaks and improve performance.
Given a DOM element, one should be able to get it's corresponding view.
Initialization functions should not fire until the document is ready since views deal with the DOM by their very nature.
Applications shall aptly render server-side and views can be bound to their DOM wrapper elements client-side without redrawing the application.
By following these principles, I expect to build a flexible, highly modular view framework that can be used with a variety of models and controllers (see my on3.js controller suite). In combination with a dependency management solution such as Browserify (my preference) or RequireJS, I believe that subview.js will represent close to absolute modularity for web user interface components.
onRoute.js: Simple URL routing in the browser & on the server (work in progress)
With the increasing amount of inconsistency between web browsing interfaces, standard event bindings (DOM level) are not sufficient for creating consistent user experiences across devices. Sure there are libraries like jQuery that abstract DOM APIs to provide API consistency, but their APIs correspond directly to DOM events (i.e. click, mousedown, mouseup, touchstart, touchend, etc.).
on3.js is designed to provide an interaction-level API for common browser IO. This allows developers to bind directly to specific user actions in a simple, intuitive way:
Its the little things that make or break a web application. The basic Sign In and Sign Up process are perhaps the most devilish details. It seems like something that should just work—to both the user and to the designer. How hard can it be?
Good interface design and good software architecture share one thing in common: good organization. I originally had the Sign In and Sign Up processes in two different pages on the site, with two different sets of code. To make matters worse, they were accessed from totally different places. Sign In was always in the upper right corner, but Sign Up was accessible on the home page and on the Sign In page. Even the labels "Login" and "Sign Up" were inconsistent.
The DRY (Do Not Repeat Yourself) principle can be applied just as well to user interfaces as it can to code. It ensures that things stay consistent and that's huge for usability. With that in mind I merged the Sign In and Sign Up pages into one and separated them with tags so that users could quickly switch to the other if they had somehow ended up in the wrong place. I put both Sign In and Sign Up in the upper right corner while leaving links to Sign Up on the home page. Already this was a huge improvement.