Hanzi Design
Concept open

open · expand

Gate + Two Hands

Opening is transition from closed to accessible. It is not merely revealing what was hidden but creating passage where barrier existed. The door opens, the file opens, the mind opens—all describe state changes that enable flow. Design systems manage countless open-close transitions: menus, modals, accordions, drawers. Each transition should be purposeful, reversible, and clear. Opening should answer: what becomes accessible, what remains protected, how to close again. The open state is not final but temporary accessibility requiring eventual closure.

🚪➡

Threshold Crossing

Opening creates passage through boundary. The closed door is impassable barrier. The open door is permeable threshold. The state change converts wall into portal. This binary transition—closed or open, barrier or passage—is fundamental to access control.

Interface elements exhibit similar binary states. Closed menus hide options; open menus reveal them. Collapsed sections hide content; expanded sections show it. The transition is usually complete: the menu is either open or closed, rarely halfway. This binary nature makes the state clear but creates abruptness.

The design challenge is managing transition between states. Instant open-close creates jarring experience. Animated transition provides temporal cushion that makes state change perceivable and less startling. The animation doesn't change functionality but makes the transformation comprehensible.

Permission and Invitation

Opening grants permission. The locked door denies entry; the unlocked door permits it. But permission alone doesn't guarantee invitation. The door may be unlocked but entering may be inappropriate. Opening is necessary but not sufficient for access.

Interface permissions work similarly. An enabled button can be clicked but clicking may not be appropriate. An unlocked feature can be used but using it may be wrong for current context. Permission (technical ability to access) differs from invitation (contextual appropriateness).

Good design distinguishes permission from invitation. The technically accessible option that's contextually inappropriate should be styled differently than truly recommended options. Grayed-but-enabled communicates "you can but maybe shouldn't." Highlighted communicates "this is the recommended path." The open state should clarify whether access is merely permitted or actively invited.

Reversibility

Opening implies future closing. The opened door should be closable. The expanded section should be collapsible. The reversibility is part of the contract. Users should not fear that opening creates permanent change.

Irreversible opens are state transitions, not temporary access changes. Account creation opens access that cannot be un-opened without deletion. Accepting terms opens obligations that cannot be un-accepted without legal process. These should not be styled as simple open actions but as commitments.

The visual and interaction patterns for reversible opens (click to expand/collapse) should differ from commitment actions (accept/decline). Users should understand from affordances whether opening is temporary accessibility or permanent state change.

Progressive Disclosure

Opening enables progressive disclosure: revealing complexity only when needed. The simple interface with all advanced options collapsed maintains clarity while preserving power. Users open advanced options when ready, keeping them closed otherwise.

This pattern respects varying user expertise. Novices see simple interface; experts can open complexity. The opened state doesn't replace the simple state but augments it. Both simple and complex states remain accessible.

The failure mode is progressive disclosure that hides essential features. Advanced doesn't mean optional. If users need hidden features for basic tasks, the disclosure strategy has failed. Opening should reveal additional capability, not hide necessary capability.

Spatial and Temporal Opening

Opening occupies space or time or both. Spatial opening (expanding panel) requires screen real estate. Temporal opening (modal dialog) requires user attention duration. Both are resources that must be allocated.

Small screens make spatial opening expensive—expanded content pushes other content away. Limited user attention makes temporal opening expensive—modal dialogs interrupt current task. The cost determines appropriate opening strategy.

When space is constrained, favor temporal opening (modals, overlays) that don't displace other content. When attention is fragmented, favor spatial opening (inline expansion) that doesn't demand modal focus. Match opening mechanism to available resources.

Cascading Opens

Opening one element may trigger others to open. Expanding a menu section may auto-expand submenus. Opening parent category may reveal children. These cascading opens amplify the initial action.

Cascading can helpfully reveal related content or problematically overwhelm with information. The question is whether cascade serves user goal or creates noise. If users typically need cascaded content, cascade is helpful. If cascade reveals mostly irrelevant content, it's noise.

Controlled cascade allows users to choose. Open immediately reveals direct children. Further expansion requires explicit action. This balances convenience (one click to see primary content) with control (cascade doesn't overwhelm).

The Opened State

The opened state is different operating mode. Opened menus intercept clicks that would otherwise go to content. Expanded modals prevent interaction with background. Opened file locks against concurrent modification. The open state creates temporary different rules.

Users must understand they're in opened state and how to exit it. Clear visual indication (backdrop, borders, focus states) communicates opened mode. Clear close mechanisms (X buttons, cancel actions, background clicks) enable exit. Opened states that don't clearly communicate their special mode or how to exit create confusion.

The opened state should also time out appropriately. Menu that stays open forever blocks content unnecessarily. Modal that never auto-dismisses may trap users who don't see close button. Appropriate timeout (explicit user action to close) versus auto-close (timeout or focus loss) depends on content importance and typical interaction duration.

Partial Opening

Some interfaces support partial opening: window partially expanded, panel halfway open, menu showing first level only. This granular control provides intermediate states between closed and fully open.

Partial opening creates complexity—more states to manage, more transitions to design. The benefit is finer control for users who want to peek without full commitment. The cost is increased interaction complexity and potential confusion about what state the element is in.

The decision should be based on whether users actually need partial states. If users typically want either fully closed or fully open, intermediate states add complexity without value. If users frequently want "just a preview," partial opening is justified.

Closing Force

Some open elements close automatically (dropdowns on click-away), others require explicit closing (modals with X button), still others persist until deliberate action (expanded sections stay expanded). The closing force determines how carefully users must manage opened state.

Auto-close elements are convenient but can frustrate when they close prematurely. User must maintain interaction to keep element open. Explicit-close elements give user control but can create clutter if users forget to close them. Persistent elements maintain state reliably but require user to remember what's open.

Matching closing force to element purpose helps. Transient information (tooltips, dropdowns) can auto-close. Important content (expanded sections, opened documents) should require explicit close. Critical blocking content (modals, alerts) should require explicit acknowledgment before closing.

Access Patterns

How frequently the element needs opening determines appropriate mechanism. Frequently-opened elements should be easy to open and maybe default to open. Rarely-opened elements can require more effort and should default closed.

Analytics inform these decisions. If feature is opened by 80% of users, make opening easy and consider defaulting to open. If opened by 2% of users, hide behind more deliberate opening action. The access patterns should drive visibility and access mechanics.

But frequency should not be the only factor. Rare but critical features (error recovery, account settings) must remain accessible despite infrequent use. The opening mechanism should balance frequency (how easy to open) with importance (how critical if needed).