UI Frameworks: 7 Tips for Developers

Ben Tillman July 25, 2018

image credit: Photo by Scott Rodgerson on Unsplash
image credit: Photo by Scott Rodgerson on Unsplash

As a developer working with a UX team, you might be facing some tough choices: which design framework to use, whether to switch, or even whether to use a framework at all. Full-stack developer Ben Tillman describes his team’s decision to switch from the Bootstrap to the Material UI Framework and shares seven tips for project success.

Archy Ramakumar and I are on a Trineo project team with a mission: to help a medical QA company deliver digital reports to pathology labs in over 60 countries via a well-designed, highly functional app. Archy’s role is to design an outstanding user experience; my role is to implement her work.

Inheriting Bootstrap but moving to Material

This project had already kicked off when Archy and I joined the team, and we inherited the Bootstrap framework. This served its purpose well in the early days, but as the project progressed and we got into the detailed design stage, Archy started creating designs that drew heavily from Material Design patterns.

From a development perspective, the Bootstrap and Material frameworks have different approaches. With Bootstrap, you attach styles to predefined classes. If you want to override a style, you override that class or you add in a new class. The Material UI framework implements the Material design pattern. In that case, you define the theme, and inject it into the components. It provides interactions for those high level components such as sliding drawers, dialogs boxes, modal overlays, and button-type interactions. There are some advantages with Material, for example, you can isolate style changes to specific components and avoid accidental overrides.

It made sense for us to switch frameworks

Since we were working with Bootstrap but actually applying Material design techniques, we had to customize a lot of the out-of-the-box components: taking what the framework provided and ripping away pieces before adding the bits we wanted.

It was a lot of work to try to make the framework deliver what Archy was trying to achieve. It wasn’t the right fit. And since the project was still at a fairly early stage, we were within the window of opportunity to switch over. So we went for it.


Seven Design Framework Tips for Developers

Whether you’re just getting started with choosing a framework or are debating a switch like we did, there are some factors to consider first. Our cutover went smoothly, and we are enjoying the process of creating a great experience with our client.

But if we were to start from scratch, there are some tips that I would like to share. With some planning, you will set yourself up for a successful project, and may avoid unnecessary work down the road.

1) Partner developers and UI designers from the start

Before writing any code, it’s really helpful to have your user experience expert(s) present an initial sketch and share what they’re aiming for on your project. As a developer, you’ll get an early sense of which frameworks might align well with the broad design goals.

2) Be transparent about what different frameworks provide

By educating your designers on the out-of-the-box features of the frameworks you are considering, it’s possible that you’ll avoid having to design and build custom solutions to many common design problems, instead being able to use the patterns the framework provides. If the design team can use the patterns that the framework provides as much as possible, then that’s a big win in terms of both design and development effort.

3) Choose a framework that fits your project’s design sensibilities

This is pretty obvious, but worth stating. There are many framework options out there. The key deciding point: How well does the framework you’re considering align with the design you’re trying to build?

4) When choosing a framework, consider its ecosystem

Like any code decision, you want to avoid jumping over to something new just because it looks shiny. You have to consider whether the framework in question has not only the functionality you need, but also whether it has depth. Is there a community of support around it? Without a solid ecosystem, you may encounter a lot of pitfalls that nobody has solved yet.

5) Sometimes no framework is the right answer

If you can choose an appropriate framework and use it to its full potential, then that’s a win. Frameworks provide a lot of functionality out of the box, but the results can look cookie cutter. If you are trying to build something extremely custom, or highly differentiated, then you might be better off building it from scratch.

6) Know the pros and cons of running two frameworks in the short term

If you are considering a switch, consider how much code has already been written. If it’s very early in your project, then you might consider just switching frameworks completely, like we did. Otherwise, you might bring up a second framework and slowly migrate over a bit at a time. This should only be a stopgap measure to minimize pain.

The problems associated with running two frameworks are numerous. The big ones:

  • Two frameworks means more memory, download time, and a less responsive interface. Load times skyrocket.
  • You also have potential for actual conflicts between the frameworks. You can get visual artifacts because they can literally override each other.

The bottom line: keep two frameworks running only for as short a period of time as possible.

7) Mitigate development risk by communicating clearly

If you do decide to switch frameworks, then mitigate risk by communicating very clearly. What is changing? How is it expected to change? What should the team avoid working on while the switch occurs? Communicating clearly ensures that someone on your team isn’t making changes while the underlying structure is getting pulled apart.

A note: If you have a small team, it’s easier. Do it early and do it quickly.

Ultimately, don’t be afraid to consider switching out your framework

If you end up in a situation like we did, it can make complete sense to switch frameworks and end up with a more efficient, and more effective experience implementing your design team’s hard work. It can look daunting, but it can turn out to be painless. It took us a week, which is a best case experience. And now we have the right framework to support this project.

Ben Tillman

Ben Tillman