We’re being careful to say “test” our app instead of “download” our app.

We’ve talked a lot about how user expectations helped shape our implementation. There are times when it’s incredibly valuable to listen to your users, but there is also a time when you need to manage those expectations, too. As we got closer to launching the project more fully onto the floor, it became clear to us that if we were considering this an iterative project we needed to start doing a better job of communicating that to our users.

One thing that we’ve looked at is our language; how are we positioning the app to our audience? In early drafts, we were using a lot of wording that everyone uses. Things like “download our app” and “use our app to ask us questions” were commonplace. We started a significant shift to always say “try our app” and “test our app.” Also, when speaking about the app on the floor, we want to introduce the idea that we are in early stages and “your feedback will help us shape our app.” This was surprisingly easy to do once we started to view our messaging through a testing lens.

Testing with iPhones first hinting at more to come.

On large signage, you’ll also find that we are including language that acknowledges we’re deploying on iPhones first. That was a clear path after seeing that 83% of our smartphone carrying visitors were on the iPhone; in an iterative process, we wanted to start simply by releasing and perfecting on one device before we move on to others. However, we’ve still got many visitors on other platforms and we need to manage the expectation that while we may be releasing on the iPhone first, we’re thinking about all of our users. (In the meantime, anyone can ask a question using our iPad kiosks located in select galleries throughout the institution.)

The app store icon that was not to be had.

It’s interesting that the one idea we had, which would have been the most clear to users, couldn’t be done. We wanted to put a “beta” ribbon over our app icon, so at the point of use it was reinforced that we were in testing. Know what? Apple has a rule where you can’t have anything “beta” in the store, so this was a no go.

Starting tomorrow our project will hit the floor for our soft launch. At every turn, we ask ourselves how we can impart to users that this incredibly iterative program is in its very earliest of days.

We adored this in concept; taking inspiration from old desk calendars, the signage could be “flipped” to switch to various signs.

Then we reconvened to see scale prototypes. All I have to say is thank goodness for prototyping because once we saw this solution in the space, we quickly realized it wouldn’t work. It was simply too small in scale. We were focused on the furniture and the need for mobility that we neglected to see the bigger role graphics needed to play in the reconfigured space.

Prototyping revealed that as much as we loved the concept, the reality was too small to see from across a busy lobby.

This reality check caused us all to pause and take a look at the entry experience with fresh eyes. How could graphics help make choices clearer? How could they help us be more welcoming? How could they help fill the space? MTWTF went back to the drawing board with this bigger picture in mind came back with more layered approach.

Large messaging at our entrance identifies where you are. We are using the existing canopy for the additional signage, seen here in a prototype.

Beginning with large messaging at our entrance that says Brooklyn Museum (we didn’t say this anywhere on the exterior previously) and a large “welcome” banner hanging high in the brick arcade. This pairing nicely echoes the welcome sign we have at the north entrance and does a number of things: it confirms that you’re in the right place, adds a nice splash of color to the exterior and for the arcade banners in particular, sends a nice message that doubles as a visual cue to help pull visitors to the center of the arcade {link to traffic post} and through into the lobby.

A welcome sign running throughout the brick piers helps guide you toward ticketing area in the main lobby.

In the lobby, we needed a way make the tall ceilings feel comfortable as opposed to cavernous, so MTWTF proposed hanging large banners from the second floor mezzanine advertising our special exhibitions. These banners, working in conjunction with a painted wall treatment, will draw attention to the south wall, where ticketing will be located, and visually fill the space. A dedicated banner (and ticketing bar) for Membership gives them a larger presence as part of the entry experience.

A ticketing area is defined with large exhibition banners and a blue wall to help draw you across the main lobby.

At the more human scale, an updated approach to wayfinding and signs stays true to our need for flexibility and mobility, but provides clearer choices for our visitors. The graphic treatment for shop/art/eat was moved from the wall to the doors in order to help ameliorate confusion around entry points into the rest of the building.

Signage for “art,” “eat,” and “shop” has been moved to the doors for better wayfinding. We also used two color vinyl so the signs will be visible in both day and night situations.

Signs for various ticketing scenarios stacked on stands provide flexibility to change out messaging based on need. Point size for the typeface was selected only after seeing scale print outs in the lobby, so the layers of messaging are clear at the right moments. For example, “Admissions” will be visible for most visitors from the arcade. As they walk closer, the admissions price becomes legible, about the center of the lobby, right at the spot before having to commit to standing in line.

Prototyping included text sizes for admissions signs, seen here.

Finally, we’re working on a new museum directory so that visitors can see all their options at once. The directory itself will be rather large and prominently placed so that it’s purpose is clear from afar, however the listing of what’s on view will require visitors to approach more closely.

A new directory will show visitors all of their options just as before they enter through the “art” doors.

We have left ourselves some flexibility (no surprise there) in that we have the option for larger messaging on the directory as well in order to advertise programs like Target First Saturdays, Thursday Late Nights, and, of course, Bloomberg Connects.

The team at Arup would help us evaluate our current traffic patterns, look at the proposed changes and flexible furniture coming in, and help think about pedestrian traffic as part of the project. The goal was to intelligently place the various components and their associated functions—ticketing, security, ASK team hubs—to help visitors navigate the space and understand their options. As we’ve talked about before, exactly how these components work together for the best possible visitor experience is something we need to determine through testing. Arup’s recommended placements are the first set we will test.

In an early pilot, we tracked visitor traffic patterns in our lobby using pencils and photocopies.

We had a feel for the general traffic pattern in the lobby because one of our early pilot projects involved tracking and timing visitors in the lobby to see what a typical entry sequence was like—where visitors stopped to speak with staff, what path most people take through the space, popular gathering points, etc. Happily, our conclusions matched up pretty well to Arup’s assessment of our existing patterns (score BKM).

Arup’s version after their own analysis was very similar to what we had found during the pilot.

As I mentioned in my last post, while we were originally aiming to test placement of each component, we ended up having to “fix” the location of ticketing in order to proceed with design. Naturally, this decision also affected traffic planning by limiting the number of variables. Arup was able to focus on how best to move people through the space to ticketing using the info desk, security desk, hubs, and benches as guides.

Info and security desk placement will help guide visitors to the center of the brick arcade, so they are lined up with ticketing when they enter the lobby.

A key component of a good visitor experience is clear choices; it’s important for people to see and understand their options. Think of all the questions you ask yourself when entering a museum for the first time–where are the restrooms, where do I get tickets and how much are they, what can I see, etc. Ideally architecture, furniture, and wayfinding, all work together to help visitors understand their options at key decision points. Our architecture is such that there is little (or no) line-of-sight from the main entrance into the lobby. This means visitors have two moments of orientation: one when the enter the revolving doors and one once they pass through the brick arcade. To help with this, Arup focused on clear pathways using security and info desks centered on the brick arcade to draw visitors over. Info is placed ahead of ticketing in case visitors have any questions before they commit to purchasing a ticket. The info and security desks are centered with the goal of drawing people to the center of the arcade so that they enter the lobby through the middle of the space. Once inside the lobby, ticketing is straight ahead.

Movable furniture in the form of power benches and hubs can help further direct traffic. Circles show areas of gathering spaces.

After ticket purchase the next decision point is what to see, so we are placing a new museum directory at a natural gathering spot beyond the point of sale. In another effort to make choices clearer, we moved our previous SHOP/ART/EAT graphic to the doors as we noticed some confusion around which door led to which, particularly since there are two entrance to the galleries. This is one way we’re using graphics to help communicate options; I’ll discuss this a bit more in a future post.

New graphics and adjustments to existing graphics help guide visitors. In the case shown here, our old “art,” “shop,” and “eat” are being moved from walls to the actual doorways. Additionally, they are reoriented higher so they are visible over people’s heads.

A big challenge for us is the fluctuating nature of the space—not only does traffic vary based on exhibition season, time, and day of the week, but we are constantly holding programs, performances, special events, and even film shoots in the pavilion and lobby. We have to be able to adjust set-up based on our needs of the day, but still help visitors navigate the space and this is really where Arup’s insight has been most useful. They have offered us several placement scenarios: a typical day, a busy lobby day (long queuing needs), a busy pavilion day (event), and Target First Saturdays.

Traffic patterns differ when we need more room for ticketing lines like on busy days or at Target First Saturday. The benches toward the brick piers are the key move here so we can create more room in the lobby proper.

Interestingly, the maximum number of hubs Arup ever recommends placing in the lobby is four, not the full six. Instead, they recommend deploying two hubs elsewhere in the building to take advantage of traffic patterns to special exhibitions and/or other gathering areas in the building for the purpose of reminding visitors about this “thing” they saw in the lobby. This got Shelley’s and my attention since we’ve always wondered a bit if the lobby is too early in the entry experience for really engaging visitors around ASK.

We’ll definitely try Arup’s route—two or four at a time—and see how it goes, but as I said, this is only a first set of placements to try out. We’ll need to adjust as we go and take time to land on the set that works for our varied needs.

We’re holding on pre-visit information being displayed in the app until a later release. For now, visitors can use our old-school mobile website.

You may remember we were aiming to tie pre-visit information into the app and present it to users based on their location. This gives our app dual functionality; outside you get what you need about getting here, inside the app is focused on the activity of seeing art. While this is a needed feature, it became clear that we could launch with a single purpose ASK app and add the pre-visit functionality in a future release. Why did we make this call?  Well, that timeline problem hit us again…and that user expectation problem hit us, too. It’s an interesting confluence of a lot of the things I’ve been blogging about lately.

Let’s look at the timeline problem. Alongside ASK development we’ve been in a massive clean up of our back end systems. We’ve been migrating our website to a new CMS (Expression Engine) because our own home baked CMS (yeah, that’s right, we made the excellent fail years and years ago to try and roll our own) was a total disaster. Knowing a website redesign would be in our near future and the goal to integrate ASK content into the pages at some point, we needed to get our website off our current systems and onto something less like a house of cards; this meant moving content into a new CMS, designing slightly more modern layouts, and thinking about responsiveness.

This website migration was on a parallel timeline with ASK and this presented us with problems when deploying the pre-visit information in the app. The best way to do a project like this is to launch the website migration first with an API behind it, then launch the app which uses that API to draw the pre-visit info. In our case, the website migration couldn’t quite happen fast enough, so the mobile application timeline started to become affected.

For now, we’re going to release a single purpose ASK app and tie the pre-visit information into a later release after our website migration gives us the API calls to do so as native elements.

Our first thought, as a stopgap, was to reskin our existing mobile website. Currently, if you hit our website from a mobile device, we give you an old-school (this predates responsive design) slimmed down version of what you need—exhibitions, events, directions, hours. The thought was, let’s put the geofencing in the app and let’s give the user a web view of the mobile site. This made sense in theory, but in practice we hit the user expectation problem.

A web view in a native app feels slow and buggy. Users accept that glitchy feeling on mobile web—we’ve come to expect it—but inside an app the story is totally different. That feeling of slower response becomes immediately apparent and glaring. We tried to speed things up, change the way elements loaded, but the base problem was still there; our shortcut just didn’t make sense.

So, we had to adjust. The mobile app will launch in June as a single in-person experience. Then we’ll finish our website migration with an API and soon after bake the pre-visit stuff back into the app for a future release. We don’t expect this process to be a long one and likely this functionality will be added by the end of the summer if not sooner, but the problems were obvious.  No matter how much we wanted this info there from the start, the scaling back made the most sense.

For now, we’re aiming to do a good job of ASK. Then, we’ll aim to do a good job of pre-visit information.

A series of furniture designed by Situ that we could use in a modular and reconfigurable fashion. The design of the components helps differentiate function.

There were several parameters we knew going into the design process:

• We need to be able to clear the lobby and pavilion of furniture for programming or special events on a fairly regular basis, but have no good place to store the furniture elsewhere in the building.
• Security is a required part of the entry experience, but we wanted to somehow make it more inviting, more integrated.
• We have need for a separate information desk, particularly during busy times when admissions staff is focused on ticketing and don’t have as much time to devote to answering general queries.
• The furniture components themselves needed to help communicate that there are different services going on, i.e. the ticketing desks need to look different from the Audience Engagement team “hubs” to help underscore the different functions.

Seeing prototypes in the space has been incredibly helpful.

Throughout the design process, there was much back-and-forth as we hammered out the particulars. As we discussed traffic flow (more in a future post about this) and began to really delve into our needs for the space, we were able to narrow down the components and their functions.

However, finalization of the design only happened after we made the decision to place the ticketing bars in a row against the south wall. This placement was based on previous configurations of the lobby (pre-circular desk) and in consultation with the traffic folks. Turns out that modularity and flexibility only get you so far in planning. You have to put a stake in the ground for that flexible solution to anchor to or there’s no consistency. The ticketing bars themselves are still moveable, but as you’ll see in a future post, we’re centering messaging and traffic flow decisions around this location so while we could move them, we hope they work there.

The ASK team is working using a temporary setup, but we’ve found that being together as a team has been important. Often, they need to lean over and ask each other questions.

Unfortunately, what we are finding now is that in at least one instance, the furniture is suffering from the same agile fail that Shelley just wrote about. By necessity, furniture design had to progress ahead of staff hiring, which means the hubs as designed may not meet the needs we are now seeing. We envisioned the hubs as individual desks for ultimate flexibility in placement, which means the Audience Engagement team members work individually at their desks. But now that we have the team in place, what we’re seeing is that they work as just that—a team. They are currently at a table together and so far during our app testing sessions, they speak with each other and in some cases crowd-source the answer from among the team members. This will be difficult to do with the current hubs. What’s more, this team process is fascinating to watch. And since one of the main goals of placing the team in the lobby to begin with is drumming up interest in ASK, we can’t ignore the draw of the team’s working process.

The hub design, the place where the ASK team will be working in the lobby, had to be finalized prior staff hiring. The design is reflective of one person working on their own when the reality is they are working as a group.

All is not lost, however, and we are working with the traffic consultants to see how and if we can group the hubs together in a way that works. At the very least we can pair the hubs so team members are always partnered. And although the team works a certain way now, as we continue to test the app, see how visitors use it, and where they are interested in engaging with us around it (might not be in the lobby), the individual hubs may end up being exactly what we need.

Comparing the first version of the ASK logo with our latest where we are going a bit more active and less restrained.

This first thing a person sees is our branding and we wanted a look and feel for ASK that reflected a personal touch. Our first attempt, which you’ve seen on this blog quite a bit, used handwriting to convey that personal interaction. In our most recent incarnation—the one we’ll launch with—we’ve taken this one step further. The ASK that you see now has moved toward something a little less restrained and a bit more active; we hope our new ASK is more spontaneous just like the messaging interactions in the app itself.

A new onboarding process presents a series of messages that introduce the team.

The next thing we adjusted was the onboarding process. Previous user testing sessions had shown us that our start question—What work of art are you looking at right now?—worked well. Users immediately made a beeline for the nearest object and actively started using the app to answer that question; we didn’t need any instructions or those pesky tutorial screens because the question itself functioned as the tutorial. This question alone, however, couldn’t convey that there was a team of people ready to connect with you about art. While this would eventually be accomplished through the team’s responses to a visitor’s question—all varied and with a personal style—that was coming too late in the game. So, we adjusted the onboarding to include a couple of messages that would introduce the team to the user before the question that gets them started.

Another adjustment involved the protocol of the ASK team. They had already been working with less formal language, but user testing sessions demonstrated how critical that initial contact was. With our first response, especially, the team has been experimenting with a more friendly approach often encouraging the user with “that’s a great question” or providing an indiction of their own personality, “I love that object.” One critical lesson the ASK team learned was to admit when they didn’t know an answer. In some cases, saying “actually, we’re not sure, but we do know this about the object” is better than trying to redirect the conversation without the admission; turns out, admitting when we don’t know is about the most human thing we could do. Subsequent user testings have shown these shifts to be working quite well with testers specifically citing the team’s tone and responses as feeling personal and nowhere near automated. The team continues to do a lot of experimentation around language, directed and open questions, and tests of our start message. Monica will be blogging more about those lessons learned in the coming weeks.

We’ve ditched the scale that indicated wait time in favor of inline messaging.

We have an unavoidably tricky bit with ASK because you are connected to a real person on the other end; no matter what there’s going to be some wait time. The reality is we answer questions as they come in and we can only type so fast. In early days we tried to tell users where they were in the queue—total fail because users didn’t parse the small notification. In a second incarnation we decided to implement a wait scale, but users found this equally confusing and the scale itself felt automated. It was pointed out to us quickly that even the word “queue” made very little sense.

A friendly message is more human; it’s also something users don’t need to learn.

In the end, we switched to inline system messages. If your wait is too long, we’ll fire off a nicely worded system message in the chat. Now, you have an idea there’s a wait, but you don’t have to learn an architecture (a scale, a position number)—the message is something you already know and have been using. A friendly message is just more human.

In our case, we’re going with Google’s “so and so is typing” instead of the three dots to reinforce there are real people behind the answers.

In addition to finding a friendly and not-so-automated way to tell you about wait time, we also needed to give users an indication that there was activity going on—that someone is working on a response—and the three dots are what users expect. In our implementation, we’re going the Google “so and so is typing” route and we’ll be using the first name of the ASK team member that you are connected with. This is a great example of pairing the need to be more human with a our technical implementation. By using the name instead of just three dots were solving user expectation and doing so in a way that we hope makes the experience a more personal one.

Some of these changes (and others) came on the heels of a visit from Genevive Bell, who I was fortunate enough to meet at Webstock, where we were both speaking. Genevive was intrigued by ASK and was generous enough to come by to talk with our team and test the app. Her visit came at a pivotal moment for us.

The awesome and inspiring Genevive Bell speaking at Webstock 2015.

We had been testing ASK with small groups and we were just moving into the phase of testing on the floor more widely. During those early testing phases we had been given plenty of feedback from users, but we we were also holding on a lot of implementation in the name of agile. When Genevive came in, she zeroed in on the major issues we had been grappling with and she could articulate those things so clearly that it put much of the earlier feedback from user testing into perspective for us. We were incredibly fortunate in both the timing and the person—thank you, Genevive—because we were inspired to keep solving difficult problems.

I wouldn’t go so far as to say we’ve got all these issues solved, but if feels like we’ve got a decent start.

That sounds great in theory, but it rubs up some serious user expectation problems because users don’t know anything about MVP—they just see what we give them and they assess that product based on the technologies they use every day. There are two features in ASK that were a clear user expectation agile collision.

One feature was “the three dots.” You know the three dots, right? If you use iMessage or WhatApp those little three dots appear when someone is typing a response for you on the other end. They are an incredibly important indicator that something is happening and they’ve become the de facto standard in messaging clients. Google handles this a bit differently by saying, “so and so is typing,” but it’s the same feature. The three dots, however, are incredibly difficult to implement and in the early days of our development we decided to table it. Given the complication of implementation and the time it would take, we figured we should let our users tell us if they needed it. They did and they were loud and clear about it.

Most messaging clients use the three dots to indicate activity on the other side.

The other feature was the “push to resend.” In this case, if your message does not go through the app usually gives you an indication and then you push, swipe, or pull down to initiate a resend.  In the early days of our app, we thought we’d be more helpful. We’d show you an exclamation point indicating a problem with the message and then in the background we’d do some jumping jacks to try and resend ourselves. Users didn’t know what to make of this because every other implementation that they were familiar with did the opposite; the user is required to try the resend and those apps make it a simple push, swipe, or pull down to do so.

As seen on Instagram, “push to retry” is functionality users have grown to expect.

There’s a careful balance here that we’ve learned from. You want an agile process, but you also need to think about what users are expecting and in some cases you should go ahead and just bake it in. Why? Well because in cases where there’s a high degree of how something should work based on popular example, you can’t fight it. While you can wait (yay, agile), the result is you can end up fighting massive fires when users are frustrated and then you end up needing to push this complicated stuff out quickly.

The other massive learning is don’t try and reinvent the wheel. If something is being used out in the world in overwhelming ways, copy it with the best of them. Anything else is fighting an uphill battle of user training that you just don’t need; we learned this very early on when after a testing session with incredibly frustrated users one member of my team came back into the office asking, “What’s the budget code for therapy?”

User expectation has hit us in other ways not related to agile and this problem is still ongoing as we move the project to the floor. Simply put, visitors don’t seem to expect much from a museum app. I hate to say that, but it’s true. In test after test, we would show them the app home screen and ask what they thought our app did. Without really looking at the screen to assess what was in front of them, they would tell us what they expected a museum app would do. Guess what? They gave us answers about finding exhibition information, events, and playing audio/video. The thought that a museum app might actually do something different was not in the vocabulary.

This says much more about the state of technology in our industry than anything else and it presents us with an uphill battle moving forward. On some days this has left me feeling like we should have gone the route of developing something that had no existing vocabulary, but most days I think this is a darn good fight to have.

For the most part, we are extremely proud of implementing agile across the project. We’ve used this learn-as-you-go planning methodology not just for software development, but also concept development and project workflow. Agile has given us critical discipline; everyone here thinks in terms of honing in and reduction in an attempt to create a minimal viable product that is fully user tested. At every turn, we’ve asked questions, A/B tested solutions, and responded to product use. As a team (which includes staff throughout the institution), I can definitively say we’ve come an extraordinarily long way; the project creation cycle demonstrated by ASK is very different than that of past projects I’ve been involved with. As valuable as the agile process has been, we’ve learned so much in where we’ve failed at agile principles that they are specifically worth exploring.

Most often, we failed at agile when timelines started to collide. On a project as large as changing the visitor experience from entry to exit, there are many parts of the project, all related, and all running on parallel timelines. Once something happens to one timeline, everything else has to shift accordingly. That’s easier said than done and snafus in timelines are often unavoidable.

The technical timeline started back in April 2014; we had come off a series of pilots which determined what we were going to build, so we could immediately get started on mobile; no problems here. Issues started to crop up, however, when we started the dashboard build. The dashboard is what the audience engagement team uses to field incoming questions via the mobile app. On the technical side we needed to build both the dashboard and the mobile app on parallel tracks because the two products inform each other. The breakdown began when the audience engagement team hiring process got delayed; it took us longer than we thought to get the leads in place and then the team hired. Getting the right people for these positions was critical and this delay was unavoidably worthwhile. Not having the ASK team in place sooner, however, meant that we didn’t have our user base at the critical build stage. If we were going to make our technical timeline, we had to take our best guess on what the dashboard should do and how it would be used.

We took our best guess in architecting the dashboard, but that wasn’t always the right one.

Our best guess was a good one, but I can count the number of things we should have waited on. In looking back, we should have just worked to get messaging working seamlessly and delayed other aspects that added to dashboard complexity. Some of those aspects included ways for the ASK team to break down larger conversations into “snippets” of usable content. Snippets could be forwarded to curators when they couldn’t answer questions. Snippets could be used to train the ASK team by giving them a way to access that content later; snippets are tagged with object IDs for easy reference when future users are asking about the same object. Snippets, also, can be used throughout the building and on our website in the form of FAQs—a critical integration that’s part of our eventual project scope.

All of these things are vital parts of the project and would have to be done eventually, but in looking back only one of them—snippets for staff training—was critical right now. After all, we could use email to forward unanswered questions to curatorial. While that’s not efficient, it would allow us to see how this functionality needed to work prior to building it into the dashboard infrastructure. Ditto for worrying about the eventual integration which isn’t needed until later years of the project and will require much discussion with cross departmental staff. It’s just better to wait on that until we know how we want to use the content.

So, we implemented all of this functionality because we had the time months ago to do so, but when the audience engagement team came in and started using it we had a problem. How this staff needed to use the dashboard differed quite a bit from how we designed the dashboard. As a result, we’ve had a period where we’ve had to make a lot of adjustments and changing things quickly, as we all know, gets more difficult the more complex the product happens to be. Our dashboard now had log-in, activity (messaging queuing), snippet creation and categorization, forwarding, archiving, beacon results, etc. Every adjustment affected every component….and you get the idea.

So, we started to scale back and reduce functionality to streamline the process of getting things working smoothly for the team who needs to use it. Now, we’ll have to go back in and re-add that functionality later. The good news is that code is done, it’s just a matter of shifting the implementation. The bad news is we could have probably waited all along and that’s where we failed agile.

Timeline issues have come into play in other non-technical ways, too. One of our more critical hires was the Curatorial Liaison—the staffer who would coordinate communication with the curatorial staff and work with them to help train the ASK team. Without this person on board sooner, we had a technical timeline running in the building faster than the communication timeline. As I’m sure you can imagine, this did not go over well; we had a lot of people wanting to help shape the project with no outlet to help make that happen.

In the end, this problem was resolved as soon as we hired Marina Klinger, but it has meant she (and all the curators) have had to work on a faster timeline given our June launch was right around the corner from her February hire. I will take the time right now to thank the curatorial staff who have done everything to help make this project happen on this unavoidably worthwhile tight timeline. This is a key example of an agile fail—in an agile setup, the methodology makes it possible to start the technical side prior to the content side integration, but these two things should be running in parallel.

So, if you hear me talking up agile at conferences, you find I’m a believer, but I will also tell you that agile can’t stop you from making bad calls. That, you have to do yourself and, for us, that’s been a continual learning process knowing we’re not perfect. Luckily, agile also makes it possible to reshuffle the deck of tasks fairly quickly, so when you don’t make the right call you can self-correct much more easily.

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.