This decision was informed by the lessons Brian and I learned at General Assembly’s Mobile Prototyping Bootcamp. Though the workshop was centered on mobile apps, we picked up some cross-disciplinary techniques like creating prototypes out of paper and code. We learned that prototypes were a great way to test out an idea without investing too much time and resources to learn if we were correct in our assumptions and to answer any questions we might have about the project’s design. Also with the prototypes we made in the workshop, we had a common language with which we can talk about features and user flows. You would be surprised at how designers and web developers can describe and think of the same action in completely different ways. Prototypes can help bridge disciplines.

As I briefly mentioned in my last post, I created prototypes to evaluate each framework to learn what we were getting into. Two questions I wanted to answer were: “How easy it is use to this framework?” and “Does this framework have everything we need to build the dashboard?” I figured the best way to answer these questions was to use the frameworks to build the same web app and then to compare and contrast.

My approach to creating a prototype was to pick a critical user interface element and to quickly build it out. As I mentioned previously, I picked the chat window.

My goal was to quickly build it out; which meant that I can disregard best practices and settle for an ugly design. A prototype is not meant to be released publicly since the feature being prototyped could be immature or the code could be buggy. It is for demonstration purposes, for “drafting” a feature or for testing an idea. If the chat window was usable, it was a working prototype.

By making a prototype I learned that if we picked Backbone.js, we would have more code to maintain because unlike Angular, Backbone.js is a minimal framework that doesn’t have as many features that Angular has.

After we chose our code framework, I built another prototype, this time using our chosen framework, Angular. In addition to implementing the chat window, I also prototyped the queue and the “research pane,” where hosts could tag conversations with related art objects.

Prototype of our dashboard web application.

While visual designs could give us an idea of the look and feel of the dashboard, a working prototype could gives us an idea on how what it would be like to use the dashboard. Visual designs are static while prototypes are interactive; interface elements like buttons and text dialogs are clickable.

The dashboard app in action during a recent user testing session.

A side benefit of making prototypes is that they can serve as documentation that could help us plan and communicate how the dashboard worked. For example, Brian and I were discussing an animation that occurs when a user selects a name. After a user selects a name, a confirmation dialog should pop-up with an animation. I wasn’t too sure what direction he wanted to go in, so I quickly coded a few examples.

Another example is when we were designing the snippet creation flow. Brian had designed the following user experience: The user is presented with a conversation and they are able to select individual messages to create a snippet of that conversation. I wanted to confirm that Brian and I were on the same page in terms where the user was able to click and what would happen after the user clicked a message. You can view this prototype here: http://codepen.io/amycheng/full/cLIBw/.

Visual designs and code prototypes were being created concurrently, which led to one influencing the other. This also prevented designs and code prototypes from going too far in the wrong direction. Working this way helped us answer questions like: Does this user flow make sense? Is the screen too busy? Is this functionality too complicated?

At one point in the project, Brian was in the process of finalizing designs for the activity tab and I was in the middle of building a quick prototype of the activity tab. We discovered that the activity tab, which could potentially contain the conversation queue, a conversation window, and a research pane with any number of related art objects, could look cluttered on narrower computer monitors (Brian was designing on a much wider computer screen than mine). This discovery allowed us to come up with strategies to mitigate the differences between screen sizes.

It was a good idea to create prototypes because it helped us to clarify our thinking about the user experience and code architecture.

For the dashboard, we had to develop it in a timely manner and still be able to make changes to the codebase without breaking it (think Jenga). Also, we wanted the app to be easy to maintain over time, since it would be a web app that we would be using for years. The best case scenario is an app that was coded in such a way that it is quick to build, is easy to maintain and is easy to adapt to any unforeseen needs. The worse case scenario is unruly legacy code—codebase that degrades over time—and spaghetti code—a disorganized code base.

Legacy code degrades because people forget how to use the code. This could be due to the lack of documentation about the code base or obtuse application architecture. With spaghetti code, it becomes more of a chore to find the causes of bugs and implementing a new feature becomes more involved and troublesome, since introducing a new part into a disorganized system might cause problems with existing parts of that system. Spaghetti code inevitably leads to legacy code.

There are a few ways to mitigate legacy and spaghetti code. There could be a dedicated effort to write good code documentation and to establish a logical app architecture. We pledged to ourselves to do those things, but also thought it be a good (and a smart idea) to use a framework (in the case of the dashboard, a Javascript framework). Coding frameworks provide guidelines and conventions for how code is structured and organized.

Avoiding the mess of legacy and spaghetti code by leveraging frameworks in developing our dashboard—the web application our audience engagement team will use to answer incoming questions.

Using a framework is an easier way for a team to provide organization to their codebase. In addition to a kind of application blueprint, some frameworks also provide abstractions and functions for common development tasks (ie. communicating with an API, implementing animations, data modeling, rendering data to the user). Developers will not have to start from scratch and write their own, idiosyncratic functions for common tasks. Instead, team members would be using the same library of methods and variables. Some frameworks (especially free, open-source ones) also have large communities of developers supporting each other in using that framework. Using a framework, would allow us to draw upon that community as a resource.

It seems like every day there is a new JavaScript framework popping up, but I focused our search to two frameworks: Backbone.js and Angular.js. I chose to look at those two because both frameworks are being used in live web apps by large web companies. Both have good documentation (which makes the framework easy to learn) and large communities.

The way I judged Backbone and Angular was by building a quick and dirty prototype in each. I chose to build a feature that we knew would be in the final version of the dashboard app: a chat window. This chat window allows the user of dashboard to choose a visitor who is waiting in a queue. Then the user of the dashboard can continue the conversation with the visitor. After building the same feature in both frameworks, we decided that Angular was best suited to our needs.

Angular has been criticized for being “highly opinionated,” which means that the framework has a strict application blueprint. For us, Angular having opinions and conventions for application structure meant that we can build something really quickly because we did not have to spend too much time in the planning stages. Angular’s guidelines for building a web app were strict, but not too rigid. Angular strongly encourages developers to write modular code, which means pieces of code can be re-usuable and dropped in when its needed. Every kind of function and variable has its place, which helps with fighting spaghetti code.

Angular also includes a large library of functions for a lot of tasks that we hope to accomplish with the Dashboard app. Tasks like animating user interface elements and interacting with our custom API. With Backbone, we would have had to write a decent amount of boilerplate code (that will likely become legacy code). With Angular, developers won’t have to spend time re-inventing the wheel and they won’t have to spend time re-learning how and why their team mates wrote a certain function.

In addition, unit and integration testing are core features in Angular. Unit and integration testing ensures that any feature implemented in the future does not break existing features. Tests are actually bits of code that makes sure other bits of code are working properly. Angular makes writing tests easier, which makes it more likely for developers to write them (thus preventing legacy code). Tests can also serve as documentation on how the code base works.

Using a framework does not guarantee completely against legacy and spaghetti code, but they can provide a strong foundation for building large apps, like our dashboard.