Component Development Guide > Guidelines & Best Practices

General Principles

Below are some general design principles to which all Flite components should adhere. These principles are general enough to be relevant for UI and application design in general, and are important in the context of Flite components in particular.

Defensive design: Build your UI in a way that prevents errors. This goes both for the component itself and its config parameters. If you want the user to enter a 5-digit zip code into a text box, then make that as obvious as possible, and do your best to prevent the user from doing anything else – create a text box that is 5 characters wide, Label it “Zip code”, set the maximum number of characters to 5, make sure the textbox accepts numbers only, and so on.

Aesthetic integrity: Design your component in a way that enables the task that it is meant to perform. This is not to say that the component should be completely utilitarian, but the decorative elements should not interfere with the component’s functionality.

Familiarity: Give your component an interface and workflow that users will be familiar with. Users will often have an existing mental model of how something should work, and your component should conform to this model. For instance, if your component contains video functionality, use standard icons to control video playback; if your component has buttons, then make them look like buttons; and so on. If your design and workflow is familiar, users will intuitively understand what to do with your component.

Simplicity: Design an interface that is simple and easily understandable. Your service may be very complex and have hundreds of configurable parts, but there is no need to expose every piece of functionality to the user. It is often a good idea to sacrifice choice and configurability for the sake of usability and simplicity. If you design an interface that is extremely flexible, that won’t do much good if users cannot understand it. This goes both for component and config parameter design. While you want the component to be highly configurable, it is not necessary to expose every little detail to the ad developer. Design for the 80% use case.

Consistent interface: Familiarize yourself with how parameters are laid out in the built-in Flite components, and make sure your component’s parameters are consistent with Flite’s UI. Ad developers will be using your components within Flite’s Ad Studio, and should be ensured a consistent, seamless experience. This guideline is primarily for your component’s config parameters, rather than the component itself. It is up to the ad developer to configure the actual component in a way that is consistent with their branding.

Dynamic feedback: Make sure your component acknowledges user actions. There are many ways to do this – change a button’s color when the user mouses over it, highlight a control that’s been activated by the user, etc. The idea is to give visual feedback to the user when they engage with the component. This feedback can (and often should) be very subtle, just enough to let users see the results of their actions. It is also important to make sure this feedback is immediate. If users don’t see any response to an interaction for more than a few seconds, they will think the component is broken. For lengthy operations, make sure to provide status updates or a loading spinner, so the user understands some processing is going on in the background.

Separation of form and function: A component should separate form from function as much as possible. It should provide some vital functionality, while giving each advertiser control of how this functionality actually appears in the ad. For instance, suppose your component has a text box where a user can input their email address, and a submit button to send this information to a server. This functionality will always work the same way, but the way it is displayed should be configurable, including the font that is used; the call-to-action text; the size, text and color of the submit button; etc. This allows the ad developer to have the desired functionality, while making it conform to their own branding and aesthetic.

Documentation: Any component you build should include a complete documentation set, including a high-level summary of the component’s capabilities and uses, a detailed explanation of all configurable settings, an explanation of all metrics tracked by the component, any relevant support information, and so on. The goal of this documentation is to make sure ad developers clearly understand your component’s purpose, and are able to use it effectively out of the box.