Bugfender 2.0 - Behind the Scenes

This article was original posted on our blog.

As developers at Mobile Jazz, we know the headache of finding, reproducing, and fixing bugs in mobile apps. Several years ago, we got so fed up debugging mobile apps remotely that we started building a solution for ourselves. We did it by creating a way to remotely access the logging facilities of users’ devices. We built a makeshift server for application logs that allowed us to fix bugs across devices and continents.

At that time, we had no idea that the solution we found for ourselves might one day evolve to become a viable product in its own right.

Since we made Bugfender open to the public, it is now used in over 9404 apps, installed on over 46 million devices and are logging over 120 million daily log lines—giving developers a quick way to fix frustrating bugs that can literally make or break an app.

Bugfender started as an internal experiment, so we didn’t give much thought to UI when we made it. But after chatting with real users across our spectrum of plans, we realized we had some limitations and flaws in the Bugfender architecture. As a bootstrapped, fully-remote company, we’re committed to listening to real user feedback before writing a single line of code.

With months of critical conversations and feedback from users, we knew we couldn’t settle for the status quo.

It was high time for a redesign.

Bugfenders new design.

Though it’s generally recognized that gradual changes are better than massive deployments, for Bugfender 2.0, we decided to just go for it. We completely rebuilt Bugfender's UI instead of making incremental improvements. (Don’t worry, we’ve learned our lesson. More on that below.)

The original interface was an MVP that we created for function, without much thought to form. So it wasn’t exactly the prettiest, because developers aren’t overly sensitive about internal UI—we just want a product that works well. This is a roundabout way (excuse?) of saying that we initially skipped the design process altogether.

As the platform evolved and customers gave us smart ideas for new features to add, we added features without giving much thought to the most organic or suitable place to put them. As we progressed, we realized that some really key new features would require a major redesign, but we couldn’t invest a lot of time in the beginning.

But as we’ve added users and just about reached break-even on this product, we recognized the need to redesign Bugfender’s architecture to sustain the trajectory we want for this product. It was critical for us to make this redesign completely based on real customer needs—and the users have spoken.

Bugfender's old and new UI.

We recognized that the old UI showed too much information at once. All that info is still accessible, but we’ve revised the hierarchy to prioritize the information users want to see first.

Frontend Improvements

“Any darn fool can make something complex; it takes a genius to make something simple.” - Albert Einstein

We chose to rebuild Bugfender in Angular. This framework is a better choice for our frontend architecture because we can build new features much faster.

Angular is perfect for data-driven applications like Bugfender, allowing us to build a single-page web application. We did this for two main reasons:

1. It’s snappier. It requests the markup and data independently, rendering pages directly in the browser. This makes it easier and more comfortable for the user.
2. Separating the frontend and backend is a huge architectural improvement involving cleaner code and less coupling. This separates the backend functionality with an API—which we can eventually open for our customers. (More on that below too.)

What Were the Objectives of the Redesign?

Our goal was to add the top features requested by the developers who use our product, so we started by building a modern application with a better overview of apps, teams, and the log viewer. We improved the search function. We also brought the aesthetic more in line with new website.

Bringing the app inline with our new website.

Faster Searches

To improve the general UX, we began by adding faster and improved searches. We added the possibility to associate a device with a particular user (name or id). This makes it easier to search for the device of a specific user if they are experiencing a problem. Though this was partially available in the previous UI, we have made it easier to use by making the user name visible in the list of devices, for example.

We've introduced crash reporting into Bugfender.

Crash Reporting

We added crash reporting (backported to BF1), which was previously lacking since we focused on collecting logs only. We integrated crashes in the log viewer by highlighting issues and crashes with different styling so they can be seen easily.

Bugfenders old and new log viewer.

Log Viewer Improvements

We improved the hierarchy to prioritize the log viewer over other secondary functions. We introduced custom log views and improved log filters.

The improved log viewer, though still somewhat in progress, will offer indentation and columns so that log lines will be viewable in a table-style view.

Previously logs were broken up into sessions, but we found that sessions were a difficult concept for some people to understand. Session information could be useful for some developers, so we made sessions less prominent but still accessible. We also made it possible to view all sessions for a single device in one go.

The newly designed team screen.

Simpler Teams

We also wanted to improve the user profile and team profiles pages so it’s easier to know the plan your team has. We also wanted to show your team’s actual usage so that you can tell if a different plan (i.e. smaller or larger) is more optimal for needs. We made it easier to invite new team members.

Adding Requested Functionality

We added the feature so users can download logs in a .csv format. We simplified notifications to be more meaningful and billing so it’s more straightforward.

While most of this functionality was available previously, we’ve now made it more intuitive and easy to find based on user feedback.

Backend Improvements

By separating backend and frontend, we were able to rebuild the log storage, resulting in faster and more powerful searches. We are using redundant storage for high availability and easier system administration.

These architectural changes mean that Bugfender is now more scalable: this reduces our costs and will give users a faster product without the hassle of downtime or slowness.

We’ve also made these changes with an eye to the future: we’ve set ourselves up to deploy future changes without affecting our users. We will be able to add or remove more server instances to cope with more or less users at any given time.

We have also rebuilt parts of the API, making it much lighter and faster. This will allow us to open it for public usage at some point in the coming days and months.

What We’ve Learned

We built out the new UI + storage format changes at the same time, which is a fancy way of saying we found a high-cost way of giving ourselves an extremely complicated few months of work.

Our choice to deploy two big changes at once is not something we plan to do again in the future. The takeaway here is that we really should quit being overachievers and commit to only one “big” task at a time on a given product.

In retrospect, we regret that we didn’t create an overview upfront: a map of every change we wanted to make. If we had done this, we could have broken down the list into separate, manageable tasks… like reasonable people.

Though this approach might have taken the same amount of time or even longer, it would have caused less headaches. We recognize that it’s helpful to show your users that you’re listening to them and are actively developing the product. While we were doing both, the way we chose to do it meant users had to wait a long time for change to come.

If we had deployed faster, smaller updates, users would have benefited from changes throughout the last year, but instead, they saw very few visible improvements for the past year. (Sorry, guys!) But of course it is our hope that BF2 is a super positive and welcome surprise in the end.

One last thing about the merits of smaller deployments (just so we really remember next time):

Slower, more incremental deployments would have given us time to gather more feedback from users over time in manageable chunks, whereas now we’re experiencing feedback on so many areas—which is extremely valuable—but we’re now having to assess our priorities.

A Note About Our Team

We wanted to give a shout-out to the additional team members in from Mobile Jazz who came in to help build the new UI: Adam, Aleix, Pablo, Luciano, and Asier. Thank you guys for all the amazing hard work you put into this to make it happen.

Transitioning from BF1 to BF2

If you’re wondering, here is our roadmap for the transition between interfaces:

1. In the early stages, individual users were privately invited to the beta to gather feedback on specific functionalities we were improving.
2. We then offered the possibility to use the new UI, but the old interface was still the default option for users.
3. Now we’ve removed the “beta” label from new UI and made it the default interface. Older users are still be able to use the old interface for a while if they wish.
4. We’ll keep BF1 online for the next couple weeks to help previous users transition and learn how to use the new UI. (And we’re always available for a chat!)
5. Et voilà... we will then retire the old interface for good.

Conclusion

Thanks for sticking with us. At the end of the day, we’re hoping these changes make Bugfender much more workable for our users. Redesigning Bugfender has allowed us to set the groundwork for future changes to meet the needs of our growing user base.

These big structural changes are our way to invest in Bugfender for the long-term. Separating our frontend and backend will ultimately reduce our costs because we’ll have the ability to extend and build upon the platform quicker than ever before. (Of course, we’re not reducing costs while BF1 and BF2 are simultaneously live, but once old BF1 goes into retirement we will see the costs go down.)

We still have so much room for future growth including continued improvements to the log viewer as well as adding the functionality to download logs in different formats. We’ll keep giving our users more options—and we hope you’ll keep giving us the critical feedback to make it happen.

Want to see what all the fuss is about? Learn more about Bugfender.

This article was original posted on our blog.