Interface

Interface

The UI is written entirely in CoffeeScript and uses Knockout.js. It is organized into components, which is good for code reuse and modularity ✔️.

Components

Each component is its own directory within interface/components. In each component directory (for most, if not all, components), you will find three files:

• index.coffee - component's logic, the knockout observable, methods, state
• index.pug - template for the component, with knockout bindings written in the tags
• index.styl - style code, written in Stylus

The top level component is tf-app. If you look at some of the template code, you'll see tags like this:

tf-component(params="key:value,a:'literal')

These look like ordinary jade tags (h1, p, span, ...), but in fact they refer to TaylorFit components. params is what gets passed to the viewModel() function. In this case, params would be an object with two keys, key and a, whose values would be computed in the context of the current view model. If this tag appeared in the template for tf-header, "value" would be replaced by the "value" property on tf-header's viewModel object (the object returned by the viewModel() function).

Knockout observables

Knockout observables are objects that, when updated, notify subscribers of the object. An example of this is model, which gets passed around to various components, some of which call

model.subscribe ( next ) -> # next is the new value for model

This way, whenever the model is updated anywhere in the code, this function will be called and whichever component is listening can respond accordingly.

These observables often refer to things that get new values when the UI receives a message from the engine saying, "here's a new model," or "here are the new candidate terms." Parameters such as exponents, lags, the dependent column, and so on are also observables, the subscribers of which send a message to the engine with the new values.

Hover-show design

One of the prominent design decisions made early on was to have panes for the separate parts of the application (data tables, model results, statistics, settings, etc.) always visible within the UI, so that changes could be made quickly and the effects seen immediately. However, given the vast amount of content in TaylorFit and the limited screen space of most devices, the panes are dynamically resized depending on where the cursor is. If the cursor is hovering over the data tables, that pane will consume most of the screen space while the others tuck themselves away.

This has some drawbacks regarding accessibility (future work), but allows users to stay on the same page while fitting and testing a model.

This design is mostly a result of the styling applied after template rendering and logic processing, which means that if a new design for the application is desired (barring an overhaul), the logic should be (mostly) unaffected.

Mobile

Support for mobile and other atypical screen sizes were not within the original scope of this project given the typical user, who is probably using a computer or laptop to do data analysis. Generally, people don't do data analysis on their phones. However, it would be nice to at least support mobile to some capacity, maybe using Cordova or your favorite app wrapper. Integrate with some data storage service and have shared access to models across devices.