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.
In the summer of 2011 I was working at an EPA laboratory in Cincinnati, Ohio mathematically modeling biofilms. I was frustrated with the way I had to do this research. One of the major problems was that all of the formulas, constants and data for modeling were locked away in journal articles. This meant that I needed to manually comb through hundreds of articles and summarize them before I could implement any part of my model. And there were a lot of parts. To make matters worse, in these specialized areas of study there was no standardization of units, or even standardization of unit conversions, so I was spending many hours just trying to interpret what I was finding.
I had been thinking a lot about this problem when I flew to Tuscon Arizona for the National Udall Conference. After a number of conversations late into the night, I realized that this problem was not just mine. Upon my return to Ohio, I decided that I was going to do it—create a standardized repository of scientific models, later named The Numerical Network. I spent the next week with my head buried in a basic web programming book and by the time I was headed back to school in September, I had begun to build what would become FastFig.
I threw out most of that early code, but it was the start of a wonderful journey into the world of software and startups. I was obsessed with the project my Senior Year of College, where I was studying Civil Engineering. I would code in class. I would code before going to parties. I would code instead of doing homework. I eventually ended up dropping my Senior Thesis to keep working on FastFig.
By the end of the summer of 2012 the first version of the site was ready to launch and I did it live (with a big red button) at the Lehigh Valley Tech Meetup. After the launch I decided that I needed a partner in the venture and so I recruited Jay Hotaling, a friend from high school who remains the CEO to this day. He and I applied to the startup accelerator DreamIt and were miraculously accepted into the Austin class that winter. DreamIt asked us if we could find another programmer to bring down to Austin, so we called up another friend from high school Alex Potts and he put aside his studies to join up. We also invited Greg Heller-LaBelle to join on. I had met Greg through Lehigh Valley Tech and he had a knack for business development.