What are Functional Components? Your keys to the software kingdom.

It all begins and ends with functional components.

When we start doing design in the first sprints of the project we start in the code editor. Our process includes white-boarding and low quality wireframes as communication tools to get the core functionality understood and our process excludes delivering high quality design mockups from static design tools like Sketch or Photoshop. Why do we exclude them? We can be as fast in the browser as we can be in Sketch, the difference is that in the browser we will have built the functional components that can form a prototype and in Sketch we will be far from a prototype.

What are functional components?

Web pages are built from documents. Web applications are built from components. Form inputs are the easiest components to recognize; a date input that has a calendar to choose the dates; a text input that makes suggestions on what to search for based on what you have started typing. These are components that can be used and reused in an application in multiple places. Another type of component is a display component; graphs and charts that take in data of a certain format and display the results; cards that show a user’s profile information that can be swiped from left to right to remove it from the screen. These components may appear in different places in the application to give users data they need to see.

Where do functional components fit in the development process?

On our development team, we have a role called “Design Technologist.” This engineering role specializes in building the parts of the application that the user sees and interacts with. A Design Technologist is capable of building most of a prototype without reaching into skillsets like data management or application deployment. The components a design technologist builds are the same components as a front-end developer uses to make the application usable.

In the process of building functional components design patterns like color, spacing, and typography begin to take root in the application. With the reality that an application needs to be consistent from view to view the design technology builds consistent patterns into the application from the start. As in, when building functional components the design technologist is laying the foundation of the application’s look and feel. These are done with design tokens.

How do functional components compare to high fidelity mockups?

Mockups

• Still need to be turned into functional components
• Are not written in the same language as web developers work in
• Can be built without respect to what is achievable or implementable

Functional Components

• When they work in the prototype they work in the usable application
• Make use of the technology that is available in the web browser
• Are written in the same language and therefore can be built collaboratively with developers

Comparing Functional Component Options

Off the shelf

Off the shelf components are either free or paid software libraries. Often the paid ones are not as good as the free ones, simply because the free ones are more widely used, receive more scrutiny, and are subject to more environments. Paid options can be better when specific functionality is highly complex and requires significant investment.

The best paid, off the shelf component is ag-grid. The makers know it, marketing their product as, “the best javascript grid in the world.” The grid costs over $1,000. When used in financial applications that handle the flow of billions of dollars of transactions, it makes sense. In the Angular development environment, there is no better general-purpose off the shelf set of components than Angular Material. These components are freely available for usage in any application and are developed by Google engineers as well as community contributors. They also happily meet all standards for accessibility (usable by blind and deaf people).

Custom

Custom components are built from nothing to serve the application they are being used in. Building custom functional components can mean duplicating functionality available from off the shelf component libraries with the customization being primarily to the styling. Custom components can also mean creating unique functionality that your application requires that off the shelf components do not provide. An example custom component that I have built is a “typeahead,” also known as an “autocomplete.” The project it is used in has complex data types that are being searched for and the autocomplete needs to display a list of that data as the user is typing. Off the shelf autocomplete components are not made to handle complex data and a custom component is necessary.

Deciding between off the shelf and custom components

Every project is different and every situation bears review before making a choice.

Off the shelf components

• Good for prototypes to get something in front of users as fast as possible
• Good for internal enterprise projects where the return on investment is prioritized
• Good for companies that do not rely on the project to represent their brand

Custom components

• Good for projects that have highly individual user interaction needs
• Good for companies for whom the project is a core part of their brand
• Good for public-facing consumer projects where the look-and-feel is synonymous with the product