My First Large Scale App Experience

Since my development career began, I had the itch to contribute to a large-scale app. You know? The kind that involved a big team, lots of meetings, deep coordination. Reading about it intrigued me, but it wasn't nearly enough to prepare me for what was in store.

I got my chance to work on my first large-scale, international, fully responsive web app while working at Vodori. Not only did I learn a lot about my own craft, experimenting with different media query objects, using custom breakpoints, and even ways to structure our file imports, I also learned a lot about how a large app is managed. Below are some of the key components.

• Budget
• Staffing
• Timeline
• Process
• Client Dynamic
• Business Goals
• Budget

Being a medium-sized company, and having a good long-standing relationship with the client, the leadership team was able to procure a contract that had a large enough of a budget to comfortably include a team of developers, designers, project managers, and business analysts.

Budget plays an important role in the consideration of how to approach responsive design in that it determines how to phase the development. With a small budget, you may have to optimize in phases. One approach could be to optimize for the two most important viewports (based on analytics and business goals) first, then in another round of funding, perform the remainder of the optimization.

Staffing

The exercise of knowing how many people you need, for how many hours of the work week, while maximizing capacity is no easy task. Vodori was (thankfully) able to hand-pick people for various roles. Although, throughout the project, we were seeing people being very cross-functional and stepping outside of their traditional roles in order to keep the project moving (a truly awesome thing to see).

A lesson learned about staffing in my experience at Vodori was to involve the right people at the right time. As an example: involving front-end developers at the beginning stages when the Experience Design (XD) team was crafting mood boards, mockups, interactive prototypes, information architecture, and making user experience decisions would have saved a lot of time, and budget.

This was a classic case of "staff chunking", where you have different discipline teams working in a silo, then hand off their work to another discipline team, without any further interaction. It makes complete sense to do this when planning such a large project, however after executing it, we learned that if we had allocated time a bit differently (disciplined teams spending their time across the project instead of in one large chunk), the project would have gone more smoothly.

Timeline

The work was slated to be completed within a matter of only a few months. This timeline was quite aggressive for a website of this scale and complexity.

Similar to budget, the timeline plays an important role in how to phase the development. The timeline also can drive the decision to use a framework, or to build one from scratch. It's also worth discussing with the client whether the timeline is arbitrary, or must be set in stone. Hard-fast deadlines that are close in calendar time may warrant using a responsive framework, and other pre-build components.

Process

Webflow

The XD Team, while being well-versed in the vocabulary and considerations of responsive design, did not have a lot of practical experience with it in the context of a large-scale application. (None of us really did!) We all had a lot to learn, and quickly! We thought that one way to get over that learning curve a little easier was to use Webflow to create responsive and interactive prototypes.

Our first thought, to save on budget and stay on target for our deadline was to bring in Webflow's frontend code into the production environment. Being the middle-man between the XD team and the developers, I made the mistake of bringing in Webflow's HTML and CSS into the project and going through the exercise of parsing what we needed and purging what we didn't.

While we were able to get templates off the ground quickly, we ran into trouble when we had to make tweaks to the HTML and CSS. The project specific CSS imported from Webflow was quite verbose and bloated, which made it difficult to find the classes/selectors we needed to modify, without affecting something else. Regression city!

The verbose and non-semantic markup was part Webflow's default CSS being bloated, and part a result of our XD team not having enough knowledge (or time!) with coding best practices. This was was not their fault. In retrospect, we should have used Webflow's CSS/HTML as a guide for development: cherry picking CSS rules we needed while writing our own HTML and class names.

Working in Silos

Working with an aggressive timeline, and with seemingly endless JIRA tickets, our developers were working in silos. In retrospect, the team would have benefitted from more interaction to solve some of these very complex front-end, and back-end puzzles. (While the back-end was very complex, it was planned in a way that made it easier to get off the ground. The front-end work ended up being the larger time-sink.)

There were many instances where I needed a sanity check to see if that code that I had been working on for nine-straight hours was viable. Unfortunately, this did not happen, and as a result, I had to go back and refactor many lines of code when I came back to it the next day with a fresher mind.

As an example: About four hours into the development of a feature, I wanted to discuss an approach with another developer before I submitted it for a pull request. Unfortunately, our team had no availability (even to block out fifteen minutes!), so I spent another four hours finishing the feature and submitting the pull request. I was hoping our tech lead could guide me through any revisions within the pull request dialogue, but she was also unavailable (this was not her fault as she's overseeing this gigantic app, while being in meeting for most of the day). She ended up coming over to my desk and informed me about another feature that was being implemented, which would make my code problematic. (I'm amazed that she had enough time to even do this! I consider myself lucky because most tech leads do not have the same level of awareness with such a large app. She's awesome! :))

Turns out, if I would have known this when I had originally asked a developer for a consult, I would have saved four hours of development time.

Now, I'm not blaming anyone for this inefficiency. In fact, the team I worked with was truly fantastic and awesome to work with. It's nobody's fault that the work was done so siloed, and from a project planning perspective, it was the best option we had. However, I do feel as though we, as a team, could have implemented a workflow that allowed for more internal consulting time. What I took away from this was that it's important to plan for developer to developer consulting time. In this case, it would have saved me four hours!

Client Dynamic

Our relationship with the client was generally very positive. We had been working with this client for a long time (about 8 years). However, this client was at times not very easy to work with, for many reasons (multiple stakeholders, lack of consolidated opinions/direction).

We ended up conceding on a number of design and development approaches, mostly because we weren't able to educate them on certain aspects of the project (time constraints as a result of staying on budget and timeline). The other reason we ended up in this boat was because we were working with a third party that was developing the ecommerce component of their product in parallel with the main app that we were building. This agency had strong opinions about certain technical implementations and were able to push their weight around to influence certain aspects of the project.

While we were working on two completely different apps, both parties had to ensure that our technology and design decisions were aligned since these two apps were under the same brand (rebrand). This proved to be very challenging when it came down to the approach for responsive implementation. It was difficult to coordinate on how we were changing elements on different viewports, but our Project Managers did a great job of communicating these strategies, and helping to come up with compromises on both ends.

Unfortunately, these types of politics will come with the territory, especially on larger projects. What I took away from this was that it is important to understand the client dynamic early on, and to plan for interactions that involve taking a firm stance, and to remind the client that the decisions made are for their benefit.

Business Goals

I've talked about the importance of knowing your client's business goals as a developer. This was especially important for this project and client. The approach to responsive design, and development was created based on the business goals: "we want an immersive experience that tells the story of our brand, while providing a simple path to purchasing our products." This is of course a summation, but it was a good high-level concept to keep in mind during development.

One example of how we approached development based on the client's goals:

Back story: The topic of conversation and contention was around a particular element on the site: A container that exists at the top of most pages that contains a hero image, a heading, and in same cases: a subheading with calls to action. The third party vendor was in favor of dropping text below images on smaller viewports to allow for more text. We felt differently. This was my stance, and defense of implementing an approach to keeping text on top of images, and to maintain this design pattern even as we experience the site on smaller viewports.

We believe that part of creating a system is having parameters around more than just data, but also having parameters around maintaining design integrity. Allowing a variable amount of text in the hero container compromises the integrity of the design. To better understand why we feel this way, let us explain the design process.

As we went through the process, we were finding that the vision we were striving for depended heavily on the combination of compelling imagery matched with rich copy. In order to create that immersive experience, we needed to ensure that the all the content was working together in way that would tell the brand story. In many cases, letting the image scale down across viewports, and dropping the text below the image did not lend itself well to that vision, so we decided to take the more difficult development path in order to deliver this vision. While this was a more difficult path from a development perspective, it actually opened up more doors for design.

The other topic of conversation was around a method of cropping we utilized for maintaining a central focal point for images that are implemented with the img tag. We were using css to center the focal points of key images in certain templates across our required viewports. Again, the third party vendor took issue with this approach, stating that it was too difficult to maintain and it would be easier to change the layout of the templates so that the image is displayed fullwidth, and shrinks down naturally with the browser/device. Again, this was an issue because some of the images had an aspect ratio that would render the image very short on smaller viewports. This was one of the reasons we decided to go with cropping instead of scaling. We explain:

Using our image cropping method allows for more flexibility in how we display our content. As an example, one of our design patterns is that we use min-heights on containers of content in order to provide enough whitespace for the copy to breathe, and to have control over the visual weight of the background imagery. The background images (among many other components) play a very key role on how the user digests the content. If we have control over how large the images are across our viewports, we can more effectively tell the story.

In the end, the client went with both maintaining the text over image design pattern, and our cropping approach. (hoozah!) While it took a little bit more development work, it ended up aligning with their business goals, which the client greatly appreciated. This example shows how if you map your decisions with your client's goals, you have much more ground to stand on.

Being a Team Player

When the deadline approaches, and the days get longer, it's important to be a team player. As an example: one of our project managers offered to take on some of my own project management work (for a different client) in order to free me up for development work (you rock, Dan!). This allowed me to be heads down on some of the development work that would have been difficult to finish quickly had I tried to balance both the PM and Development work.

The Large Takeaway

Working within a team for an application of this size is totally different than smaller projects. What I learned:

• There are more stakeholders
• More team members
• Organization and workflow planning is very important (it's borderline disastrous to ad hoc!)
• Communication between developers is critical
• Plan for for internal consultations between all disciplines
• Involve developers in the processes of establishing design, ux, ia, and wireframing early on in the project. If you, as a developer, feel you should be part of meeting, find a way to inject yourself!
• Be mentally ready to deal with politics. Things will not always go the way you want!
• Read up on all the documentation related to the client goals and relationship with your agency
• Don't be afraid to ask a lot of questions!
• Be Patient! Project managers, tech leads, and business analysts have a lot on their shoulders. Be cognizant of this.