UI Component development — a tale of two cities

Hmmm…

Recently, our team was tasked with developing a UI component, passed in by the the design team. This was to be, in the future, used across our app.

Requirements:

Since the design specs clearly states the properties and the expected behavior, I went ahead and created the component with one input — multiple output pattern (bunch of callbacks for the UI interactions).

All was implemented and worked perfectly.

Conflict!

On consulting another developer, thought this could be more modular and suggested pattern giving more options for the end developer.

AHA!

It was only then It dawned on me that designing a UI component can be thought of in 2 ways, in regards to the complexity:

• Closed components:

Think of it as 1 UI element, which will only have to be supplied 1 input data, with simple UI interaction callbacks.

Callbacks include when item tapped, “more” tapped, item appearing on screen.

Not to be entirely closed, we expose the property to control the number of items to show before showing more.

• Configurable components:

Think of the requirement as a composition of multiple views, where we provide the ability to change different parts, by exposing more properties, callbacks

Callbacks, for example, callbacks can include a custom data source, ala iOS’ UITableView data source, where the owner of this component can supply their own cells, sizing properties, etc.

Advantages of closed components:

• With the less options, the user of this component is freed from managing the data source, so that they focus on other tasks.
• Less code to get the component working.
• Need not concern about adherence to designer requirements (The component has passed QA).
• Need not worry about the logic to implement the behavior expected by the design team (THIS IS HUGE!).

Advantages of Highly configurable components:

• More properties that can be set, and possibly more callbacks.
• Makes the library more extensible

Disadvantages of closed components:

• Not extensible. The new requirement has to be passed to the UI library developers, and have to wait for the component to be updated.

Disadvantages of Highly configurable components:

• End developer needs to implement more code, and increase development time
• May have to be concerned with the design team requirements on various parameters.
• Have to implement the component behavior according to the design doc. (again, THIS IS HUGE!).

…wait! there’s a third city!

The best solution is a combination of both, a no-compromise solution, at the expense of the initial time for development for the component.

Step 1: Create a highly modular, highly customizable component.

Step 2: Create a closed component, atop the highly configurable one created, adhering to the design team’s expectations, hiding the setup steps.

The end developer can choose to go for the abstraction, or go ahead and take control using the lower level component.

Thanks for reading!