A messy scenario to describe UIs 🗯️
Using preferred terms to describe UI components in a team setting could be confusing. John called it a pop-up. Caroline called it a popover. Andrew named it as a popper in the js. In a demo meeting for reviewing designs of a new feature, everyone comes to this multi-named UI and gets confused, “Wait for a second, are we talking about the same thing?”
That’s common. Product managers👨💼, engineers👩🔬, and designers👩🎨 use different languages. For product managers, a UI component is a visual piece that serves for a business use. For engineers, a UI component is an API hook. For designers, a UI component is a visual and interaction pattern that embodies a certain user behavior. The difference in our interpretations leads to different terms.
Is it easier to land on the same page among the same group of designers? Not really. The same UI component can be named differently in different design systems. A designer that follows Material Design guidelines may use a term that varies from a designer that follows OS design guidelines. Not to make the whole thing overwhelming, but it’s very helpful to align our terminology when we document UX requirements or create design guidelines for cross-functional collaborations.
Dive into UI terms 🏊🏻
1. What is a pop-up? How do I use it?
A pop-up is a modal view that can either take form as a pop-up menu or a pop-up dialog. To my understanding, when we use the word “pop-up”, what we want to express is the pop-up motion effect on the call-out of the UI treatment.
In the OS design system, a pop-up menu is used to display a list of mutually exclusive choices. In the Material Design system, a pop-up is a dialog to display critical information or provide choices. In the UWP (Universal Windows Platform) design system, a pop-up could be a dialog or a flyout. The difference is that a UWP pop-up dialog requires explicit action from the user as to a flyout is more peripheral and easy-to-dismiss.
2. What is a popover? How do I use it?
A popover is a transient view that shows on a content screen when a user clicks on a control button or within a defined area. In the OS design system, a popover is preferred in big screens (tablet size or bigger). A popover subject to the general rules about modality, which renders a temporary context to get user’s attention.
According to OS design guidelines, one pitfall we need to avoid is the modal-over-modal interaction. In a popover container, only one single action is granted — complete, confirm or cancel. Additional hover or press behaviors on a popover should be withdrawn to prevent confusion. When an additional action is needed, a user has to dismiss the first popover and perform the action on the next popover.
In Material design, popovers are a part of dialogs. They are also used for single-action interactions like confirm, accept, delete or cancel. A notable difference between OS dialogs and Material dialogs is that OS dialogs save the work when a user dismisses a dialog but Material dialogs don’t. This results in distinctive results when a user drops out of a task flow.
In other design systems like Shopify Polaris and Atlassian Design, popovers can be used together with form components like a pop-up menu, a dropdown menu or a time selector. It’s not a preferred user behavior in OS or Material design guidelines, but it benefits web-based users when users can dive into filter options on a popover to narrow down the view of a data table.
3. What is a popper?
A popper is an alternative UI component that builds on top of Material popovers. It allows a Material popover to overlay on top of a pressed button or an area. Generally, a popover appears with an arrow pointing to the pressed button so the user maintains the visibility constantly. When a Material popper drops the rule of relative anchoring, it may cause confusion regarding where the popover is called out.
Document UI terms
Establishing a UI glossary is a critical part of creating design guidelines. We put a lot of efforts in designing customized UI components, yet sometimes we neglect the importance of locking down on the terms we use. Understanding that different design systems have their UI terms is the first step to start our own documentation process and align a consistent design language across teams.
Related posts
