Amid constant evolution, guidance from UX systems only hints at what’s possible. Enterprise components provide the functionality needed for complex workflows.
Developers are, in their endless goal of providing highly functional and high-availability applications, constantly introducing new frameworks into applications in order to improve them. Whether it’s simplifying support in the future, decreasing overhead, speeding up load times or reducing the overall complexity, those new platforms help improve the user experience in both direct and indirect ways. The downside is their nascent quality is reflected in their lack of documentation and examples, let alone demos with any real depth.
Enterprise components help address this deficiency by providing incredibly feature-rich and stable collections of functionality that assist developers in bringing user experience design to life with a much lower barrier to entry.
Any application is a conglomeration of components, with varying quantities of built-in (as part of the IDE/overarching framework) or sourced (from independent or third-party developers) components.
Before deciding on the recipe that will build our applications, we can identify the benefits and downsides to each category. Simple controls provide a great baseline of functionality and can be strung together to allow for the completion of practically any workflow, but will often hinder proper UX design by limiting the interactivity and usability of the interface due to their inherently shallow feature set.
Applications built in this vein tend to mirror hard-to-use and non-intuitive software from decades past. Complex components, which can be built from the ground up or created as composites of simple controls, provide infinitely more capabilities—the limitations are only bound by the underlying framework and the time that goes into their development.
Especially in any area that will communicate and manipulate data, like grids and charts, providing that interface to an end user necessitates a higher order of magnitude more functionality. That increase in functionality is proportional to the learning curve needed to understand the optimal ways to utilize those controls (if acquired), or in the overhead of properly planning out all of the features needed during the design process (if homegrown).
Understanding where your organization’s limitations and priorities lie will direct your choices—the more limited your time and budget, the heavier the reliance on out-of-the-box controls.
Once you know your need for complexity, the decision must be made: full design and development of every widget, or incorporating pre-built components from independent developers or third-party vendors.
The DIY approach provides your teams with the greatest latitude in how even the simplest portion of a workflow will be represented, e.g. do you want the columns of your grid to be pinnable via a menu or a toggle on the header?
That flexibility, as mentioned above, can significantly increase the overall project timeline, as each block of functionality can require its own planning cycle and development sprint.
If you’re building a grid control, you’ll want a complete picture from the UX team about the design of every grid across the application, in order to maximize the usage and minimize the duplicated work. That’s often not feasible, as it would require designers to complete their work for the entire application, which doesn’t lend itself to a world moving toward continuous integration/continuous delivery.
Even after the control has been built, it will be necessary to support those components in-house as well—bugs and feature requests will have to be incorporated into the long-term timeline, with a commitment of future resources.
As those resources are usually at a premium, jump-starting development through the use of enterprise-level components can save significant amounts of time, allowing you to get the application to market sooner. Bugs, feature requests, and general support become the responsibility of the vendor, and collaboration with the community can provide insights into getting the most out of those components. Functionality is a known quantity, and developers can properly educate designers on what can be done on a sprint-level basis.
Beyond the typical API, higher-end components provide the hooks necessary to allow developers to tweak those controls and get as close to the UX vision as possible.
That capability grants you the best of both worlds—the rapid development of a pre-built component, combined with the flexibility in design of a DIY control.
Taking everything above into consideration, knowing the best path forward comes down to the resources at hand against the deadlines and expectations that have been set. Staying true to design that provides end users with a useful and usable product requires complex controls beyond what the framework itself provides.
Users today are surrounded by applications that provide high-level functionality and carry those expectations with them everywhere—you won’t be able to meet their needs by relying on simple components.
In order to create something that adheres to design but doesn’t tax your sprints needlessly, leaning on controls built with enterprise development in mind will free your teams to focus on the workflows writ large, and not the atomic aspects in between.
Chris has spent the last decade working within the professional services area of software development, with a concentration in front-end technologies, working hand-in-hand with UX architects, visual designers, and developers of all levels of experience in order to provide clients around the world with solutions to drive their business.
Subscribe to be the first to get our expert-written articles and tutorials for developers!