Myth #2 - I’ll build my admin in one week!
People who develop a web application know they will need an admin interface. What most of them don’t know is how long it will take to actually develop the admin.
If you believe that a good admin brings great value to a project and its team, this article is for you. It explains what makes admin development time-consuming and why the related costs and workloads are often not well anticipated.
The basic features of an admin interface are often under-evaluated. It’s only when you start coding that you realize you only thought about the top of the iceberg. Building a great admin takes time. And as well as your project, it requires a long-term vision.
A powerful admin goes far beyond basic CRUD features.
Building an admin looks easy
Most developers will instantly think about those three things:
- I need to be able to see data. This means having the right views (details and index). Some people will think they can do this quickly with front-end frameworks such as Bootstrap.
- I need to operate on data. This means creating the logic for all CRUD operations. A RESTful API should do the job pretty easily.
- I need to control the access to the admin. This often means having a method protecting the admin and allow admin users only. It is common to call this method “isAdmin()”.
With that in mind, we’re ready to go and start coding the admin!
Building an admin is not that easy
Here are a few things you realize when you start to code the admin:
Dealing with data display is a pain. The most common feature of an admin interface is to display data in an html table element. For anyone who’s familiar with basic front-end development, you know that this is never easy. You realize that you need to think about which fields you want to display, as well as the order, the formatting or the sorting. And once everything starts to look better, you realize that you also need pagination to browse through your large set of data without crashing your browser.
You need a search bar. It’s nice to be able to display data, but you also need to be able to find a specific element in a reasonable amount of time (today this means instantaneously). So here comes the search bar and all its related use-cases. You want to search on all your data attributes at the same time, with case-insensitive search function. You want to search for specific conditions on different types of attributes and realize you need operators such as “greater than” for integers or “contains” for strings. You think it would be nice to be able to define filters and be able to save them. And it’s only at this point that you realize that you need to do all those things for the most scary of all data types: timestamps. Yeah, you need to be able to find the list of users who signed up today, or last week, or X days ago. You get the point: the possible expectations for a great search are endless.
You don’t have mockups for your admin. “Hey, I finally managed to get a decent search bar up and running. But where should I put it?” Most people in software development agree on the fact that it’s a good idea to start with interface design and mockups (see the chapter about interface design in Getting Real from the Basecamp team). Unsurprisingly, it is highly likely that you don’t have a mockup for your admin interface. But aren’t admin interfaces just another type of applications? Not giving any concern for the UI/X is quite unfair for the end-users of the admin. It explains why many companies are often making fun of their (ugly) admin interface.
You can’t always use the same logic that you use in your main app. Let’s say that when a user deletes his account in your main app, he receives a confirmation email. You chose to call the method that sends the email within the method that deletes the account. Fair enough. But in your admin interface, you want to be able to delete a user account without sending any confirmation email.
Those points are examples of the many things you might not think about at first sight. It is only when you sit down and start developing an admin interface that you realize how much work is required to build a good admin.
Building a good admin takes time
Because of all the complications listed above, many admin interfaces end up being developed using a ready-to-go admin template for the front-end. They don’t have a proper search bar. The UX is bad. Yet, it does the job! Or at least for basic CRUD operations. Unfortunately, admin interfaces can bring way much more value than performing simple CRUDs. Due to limited resources and time scheduled for the admin development, all other useful features are left for the future, when more time can be devoted to the admin interface.
The truth is: you will never have more time to devote to the admin.
Most admin interfaces are always lagging behind the main app, sometimes to the point that it becomes a black-box that no one wants to use or maintain. This becomes a real issue when your business is growing.
Quick-and-dirty admins are a short-term solution
Here are the three main reasons why a quick-and-dirty admin interface represents a real technical debt for your project:
- Frustration from admin users. As daily users of modern apps, we have developed high expectations for great UI/X. Admin interfaces are stand-alone applications. Don’t you think that your team deserves more than an app coming back from the birth of web 2.0? Keep in mind that most of the admin users are non-tech people focused on operations that are key activities for the business. The quality of the UI/X will impact their operational efficiency. If you start with a poor admin, you will quickly get bad feedback. You will hear things like “Why can’t you just add a decent search bar?! We have the same thing in our main app!”.
- Continuous development and maintenance. As soon as developers start spending time on satisfying those requirements, more will come. The more you give, the more they want! You want to start with a solid basis to be able to continue building your admin and avoid having to re-build it from scratch later.
- Growing complexity of operations. It is difficult for companies (especially startups) to anticipate the increase in complexity of their operations. Having a good admin from day one on a project can bring great operational value and avoid a lot of huge and unnecessary costs as the business grows. This is especially true when companies are reaching an important milestone, such as fundraising, and need to dramatically change its operations. Complexity of operations grows naturally with company maturity. You want your admin architecture to be flexible enough to be able to adapt quickly.
Great apps deserve an admin with a long-term vision
As with any application, building a great admin interface takes time and requires a vision.
We know it is difficult for developers to achieve this while improving their software products. We also know that a great admin interface can bring huge value to teams working on an app project.
This is why we decided to start the Forest project. We noticed that a lot of developers are building admin interfaces. They are all facing the same issues and are constantly reinventing the wheel. Forest’s framework is here to finally solve all those issues. Forest is quick to set up and is flexible enough to match any specific needs.
Since the admin interface is our main product, we build Forest with the big picture in mind, always anticipating the evolutions of business operations.
Forest is completely free to use. It works on any project, no matter what technology was chosen to build the app. Our objective is to give developers no excuse not to chose Forest for building their admin.
If you like the concept, feel free to try it out! We’re excited to see what you will build with Forest.
If you found this useful, please click that ❤ below :)
Thanks for reading — I’m Timothée Astier, a French entrepreneur passionate about startups, tech, Chinese culture, chess and rock-climbing. Making mistakes is how I learn new things. Feel free to share your ideas or suggest modifications. Wish you pleasure and success in your projects!