liquid-admin – Concept [discontinued]

Problem Definition

Startups and digital business models can be reduced to processing and representing data that is of value to someone who is willing to pay for it.

A startup has enough to do with processing the superficial presentation of the data. But there is also a team that applies operations and corrections to the data.

Each startup writes its own solution for this and with each feature the admin interface must always be followed. The result: Features launches are delayed and increased effort is required, because you develop once for the customer as well as once for your own team. Admin interfaces of startups and agencies are therefore always patchwork.

In the last 6 years I have launched more than 500 apps for Facebook and iOS directly as a developer or indirectly as a technical responsible and seen a lot of bad things. I finally want to solve this problem.

How should this project solve the problem?

The solution is a simple admin interface that allows a configurable view and editing of data for the team.

The appearance of a database column in the frontend can be defined by only a few properties:

  • Is the corresponding column displayed at all?
  • Name and description of the database column What is the data type of the content?
  • Freitext
  • Date
  • number
  • Yes/No (Boolean)
  • Status variable/selection from a set of fixed values
  • Transversal connection to another table (Foreign Key)
  • May this content be manipulated? If yes: how?
  • Input Text
  • Input Number
  • Input Array
  • Textarea
  • Radio Button (Yes/No)
  • Select Box (a single value)
  • Checkboxes (multiple values)
  • Date selection

This configurability is important. No company or developer wants to allow the team direct access to the database. On the one hand because it is dangerous, on the other hand because it would also be too complex for the team members, because they do not have the knowledge about the connections of the data.

Most existing tools like phpMyAdmin, which allow a complete manipulation of data, are therefore not suitable for end users.

target group

Target group are startups, agencies and freelance programmers.

Startups: Startups quickly develop new features and want to bring them to market quickly. When a feature is ready, it should be launched immediately. Thanks to the Liquid Admin only the configuration has to be extended by new database fields. You don’t have to program forms and basic CRUD operations in your own admin interface. This time is better invested to actually work on the product.

Agencies and freelance programmers: Clients usually only pay for the services actually rendered, e.g. the homepage or the app. In this sense, a backend does not contribute to added value and must therefore be kept to a minimum anyway. My goal is to eliminate this effort completely.

Current status

Lastly, my personal suffering in this matter was so high that I have already implemented the mechanics described here in the context of a larger project once myself.

The frameworks Symfony with Doctrine used there turned out to be too much overhead for such a dynamic requirement. I’m currently working on a rewrite to develop the project independently and free of dependencies.

An optimized configuration file could already be derived from the learnings. Here is an example of such a configuration file: https://github.com/klausbreyer/liquid-admin/blob/master/config.yml

In addition, rough wireframes exist to make the mechanics clearer in the course of this application:https://github.com/klausbreyer/liquid-admin/tree/master/wireframes

Milestones

  • Start with MySQL and manually configure via a config file with simple Translated with www.DeepL.com/Translator

Leave a comment

Your email address will not be published. Required fields are marked *