On the Criteria To Be Used in Decomposing Interfaces into Components and Modules

--> Portuguese version

Starting Point

In a 2D interface, everything you see exists within a hierarchy. Each level contains the next, like nested boxes.

Level 0: Window — The Observer

What it is: The browser viewport. Your screen's viewing frame.

Critical distinction: Window is not part of the interface structure. Window is the medium through which you observe the interface.

Analogy: Book vs Eye

- Complete book = Page (may have 100 pages of content)

- Your field of vision = Window (sees 2 pages at a time)

- Turning page = scroll

The relationship:

• Page has 3000px height


• Window has 800px height


• You see ~27% of Page at once


• Scroll reveals Page \ Window (the unseen part)

Remember: Window ≠ Page

Level 1: Page — The Universe

What it is: The largest indivisible unit. The total content space.

Key property: A Page is indivisible as an entity. You don't "split a Page into two Pages". You organize a Page using Regions.

<div class="page-home">

  <!-- Everything here is THE Page -->

  <!-- Not "two pages", but ONE page with divisions -->

</div>

Important distinctions:

Structural (HTML delimited):

<div class="page-home">

  <!-- Explicit structure in markup -->

</div>

Conceptual (CSS delimited):

.page-home {

  display: grid;

  grid-template-columns: 1fr 1fr; /* left/right division exists only in CSS */

}

Both are valid. One is explicit (structural), the other is implicit (conceptual).

Z-index layers:

Page (z-index: 0)  ← Base layer

Page (z-index: 1)  ← Overlay (modal, dropdown)

Page (z-index: -1) ← Background layer

A Page can have multiple Layers.

Think of them as transparent sheets stacked on top of each other.

Page is the combination of these layers when there is more than one.

Level 2: Region — Spatial Divisions

What it is: A Page contains Regions. Regions organize space, not replace the Page.

The divisibility principle:

❌ Wrong thinking:


"Page splits into left and right, creating two new Pages"

✅ Correct thinking:


"Page contains left Region and right Region"

Example:

<div class="page-home">

  <div class="region-top"></div>    <!-- Region 1 -->

  <div class="region-bottom"></div> <!-- Region 2 -->

</div>

Structural vs Conceptual:

Structural:

<div class="region-left">

  <!-- Explicit HTML element -->

</div>

Conceptual:

.page-home {

  display: flex;

  /* Left "region" is first 300px, right "region" is remaining space */

  /* No explicit HTML elements, but regions conceptually exist */

}

Space between Regions:

<div class="page">

  <div class="region-top"></div>

  <div class="region-bottom" style="margin-top: 30px"></div>

  <!-- 30px gap is PART OF THE PAGE, not a third region -->

</div>

The available space is not a region. It can be occupied by a region.

Level 3: Section — Functional Divisions

What it is: A Region contains Sections. Sections organize by purpose/function.

Difference from Region:

• 
  Region = spatial organization ("where on screen": top, left, right, bottom)


• 
  Section = functional organization ("what it does": header, nav, content)

Example:

<div class="page-home">

  <div class="region-top"> 

    <div class="section-header">Header content</div> 

  </div>



  <div class="region-bottom">

    <div class="section-left">Sidebar navigation</div>

    <div class="section-right">Main content</div>

  </div>

</div>

Structural vs Conceptual:

Structural:

<div class="section-navigation">

  <!-- Explicit element -->

</div>

Conceptual:

.region-sidebar {

  display: flex;

  flex-direction: column;

  /* Top 100px is conceptually "nav section" */

  /* Remaining space is conceptually "content section" */

  /* No explicit HTML, but sections exist conceptually */

}

Level 4: Component — The Complex Part

What it is: A Section displays Components. Components are operational units that can have state and behavior.

<div class="section-header"> 

  <app-header>Header component</app-header> 

</div>

Component Types

Here's where it gets interesting. There are multiple ways to classify Components:

Classification 1: By Space Division

Simple Component:

<div class="card">

  <img />      <!-- Element -->

  <h3></h3>    <!-- Element -->

  <p></p>      <!-- Element -->

</div>

No spatial divisions. Just a set of Elements.

Formal Component (Micro Pages/ Fractal Pages):

<div class="card-complex">

  <div class="region-header">    <!-- Has Regions -->

    <div class="section-title">  <!-- Has Sections -->

      <h3></h3>                   <!-- Has Elements -->

    </div>

  </div>

  <div class="region-content">

    <!-- ... -->

  </div>

</div>

Contains full structure: Regions → Sections → Elements (instead of Components).

The classification is contextual and dynamics, not fixed.

Classification 2: By Composition

Composite Component:

<div class="user-profile">

  <app-avatar />     <!-- Sub-component -->

  <app-user-info />  <!-- Sub-component -->

  <app-actions />    <!-- Sub-component -->

</div>

Made of other Components (Sub-components).

Sub-component: Any Component displayed inside another Component.

Classification 3: By Use

Composite Component (componente composto):

<div class="sidebar">

  <app-button name="home" /> <!-- Subcomponente -->

</div>

<div class="menu">

  <app-button name="options" /> <!-- Subcomponente -->

</div>

<app-button name="start" /> <!-- Element -->

When an element is used in multiple components, it can be considered an Element. And it can belong to an element library, not a component library.

Classification 4: By Complexity

Complex Component:

<div class="data-table">

  <app-table-header />   <!-- Sub-component -->

  <app-table-body />     <!-- Sub-component -->

  <app-pagination />     <!-- Sub-component -->

  <!-- Each sub-component is also a complex component -->

</div>

Formed by multiple Sub-components that work together.

Level 5: Element — The Atom

What it is: The smallest functional unit.

Examples:

• 
  <button> — one button


• 
  <input> — one input field


• 
  <a> — one link


• 
  <img> — one image

Important: Elements can also be Simple or Formal.

Simple Element

<button>Click me</button>

Just text. No internal structure.

Formal Element

<button class="complex-button">

  <div class="region-left">

    <svg class="icon"></svg>         <!-- Section: icon -->

  </div>

  <div class="region-center">

    <span class="text">Click</span>  <!-- Section: text -->

  </div>

  <div class="region-right">

    <svg class="dropdown"></svg>     <!-- Section: dropdown icon -->

  </div>

</button>

It has structural or conceptual Regions and Sections.

The classification shift:

When a item stop being an Element and become a Subelement or Component?

Context determines it:

<button>Click here</button> <!-- Element -->

<button class="icon-button"> <!-- Element -->

  <span>Text</span> <!-- Subelement -->

</button>

This is an Element (atomic interaction unit).

When it shows a menu:

<button class="dropdown-button" @click="showMenu">

  <svg></svg>

  <span>Text</span>

  <svg class="arrow"></svg>

</button>

<div class="dropdown-menu" v-if="menuVisible">

  <!-- Menu items -->

</div>

Now it's a Component (has state, behavior, manages sub-elements).

When used inside another component:

<div class="toolbar"> <!-- Component -->

  <icon-button />  <!-- Now it's a Sub-component -->

  <icon-button />

  <icon-button />

</div>

Now it's a Sub-component (Component inside Component).

The Dynamic Nature of Classification

Example: Icon Button Evolution

Stage 1 - Simple Element:

<button>

  <svg></svg>

</button>

Classification: Element


Reason: Atomic unit, no internal divisions

Stage 2 - Formal Element:

<button>

  <div class="section-left"><svg></svg></div>

  <div class="section-center"><span>Text</span></div>

  <div class="section-right"><svg></svg></div>

</button>

Classification: Element (still) or Component (depends on context)


Reason: Has internal structure, but still one functional unit

Stage 3 - Simple Component:

<icon-button icon="search" input-text="Search" />

Classification: Component


Reason: Can be broken down into more than one functionality

Stage 4 - Sub-component:

<div class="search-bar">

  <icon-button icon="search" />  <!-- This one -->

  <input />

  <icon-button icon="clear" />

</div>

Classification: Sub-component


Reason: Component used inside another Component

Stage 5 - Complex Component:

<icon-button-with-dropdown 

  icon="more" 

  @click="toggleMenu"

>

  <dropdown-menu v-if="open">

    <menu-item />

    <menu-item />

  </dropdown-menu>

</icon-button-with-dropdown>

Classification: Complex Component


Reason: Manages state, has Sub-components, complex behavior

Visibility Control

Any level can show/hide:

// Hide Region

page.regions.top.hide()



// Hide Section

page.regions.main.sections.sidebar.hide()



// Hide Component

page.regions.main.sections.content.components.userCard.hide()



// Hide Element

page.regions.header.sections.nav.components.menu.elements.loginButton.hide()

Example:

<div class="page">

  <div class="region-top" v-if="showHeader">     <!-- Can hide entire Region -->

    <div class="section-nav" v-if="showNav">     <!-- Can hide Section -->

      <app-menu v-if="isLoggedIn">               <!-- Can hide Component -->

        <button v-if="canEdit">Edit</button>     <!-- Can hide Element -->

      </app-menu>

    </div>

  </div>

</div>

Complete Hierarchy with Examples

Window (browser viewport: 1920×1080)

  ↓ observes

Page (total content: 1920×3000)

  ↓ contains

Region (top: 1920×100, main: 1920×2800, footer: 1920×100)

  ↓ contains

Section (in main region: sidebar-left: 300×2800, content: 1620×2800)

  ↓ contains

Component (in sidebar: navigation-menu component)

  ↓ contains (if Simple Component)

Element or Subcomponents (menu-item button)

Modules and Sub-modules — Functional Grouping Across Structure

What it is: A different classification axis. While hierarchy is about spatial containment (what's inside what), Modules are about functional cohesion (what works together).

Key insight: Components can be spatially separated but functionally united.

The Cross-Cutting Nature

Hierarchy says: "This Component is inside this Section"


Module says: "These Components, wherever they are, belong to the same feature"

Example: Code Editor Module

<div class="page">

  <div class="region-left">

    <div class="section-sidebar">

      <file-tree />              <!-- Part of Editor Module -->

      <search-panel />           <!-- Part of Editor Module -->

    </div>

  </div>



  <div class="region-right">

    <div class="section-main">

      <code-editor />            <!-- Part of Editor Module -->

      <status-bar />             <!-- Part of Editor Module -->

    </div>

  </div>



  <div class="region-bottom">

    <div class="section-terminal">

      <terminal-panel />         <!-- Part of Editor Module -->

    </div>

  </div>

</div>

All these Components are spatially separated (different Regions/Sections) but functionally united (Editor Module).

Module Definition

A Module is:

• A collection of Components that work together


• Can span multiple Regions/Sections


• Shares state, data, or behavior


• Implements one complete feature/functionality

Sub-modules

What it is: Modules can contain Sub-modules for finer functional granularity.

Example: Editor Module with Sub-modules

Editor Module

├─ File Management Sub-module

│  ├─ file-tree (in left sidebar)

│  ├─ file-tabs (in top bar)

│  └─ file-actions (in context menu)

│

├─ Code Editing Sub-module

│  ├─ code-editor (in main area)

│  ├─ syntax-highlighter (inside editor)

│  └─ autocomplete (overlay)

│

└─ Debugging Sub-module

   ├─ breakpoint-gutter (in editor margin)

   ├─ debug-toolbar (in top bar)

   └─ variables-panel (in right sidebar)

All components in "File Management Sub-module" share state:

• Opening a file in file-tree updates file-tabs
  


• Closing a tab in file-tabs updates file-tree selection


• 
  file-actions operates on state from both

Distinction from Other Classifications

Component vs Module:

Example: Authentication Module

<!-- Spatially: different locations -->



<!-- In top-right Region -->

<user-avatar />          <!-- Auth Module Component -->



<!-- In dropdown overlay -->

<login-form />           <!-- Auth Module Component -->



<!-- In settings Section -->

<account-settings />     <!-- Auth Module Component -->



<!-- In modal -->

<change-password />      <!-- Auth Module Component -->

All these Components belong to Authentication Module despite being in completely different parts of the interface.

Module Communication

Modules can:

• Share global state


• Communicate via events


• Access shared services


• Coordinate behaviors

Example:

// Editor Module components communicate

fileTree.onSelect(file => {

  codeEditor.open(file)        // Different Component, same Module

  statusBar.update(file.path)  // Different Component, same Module

  terminal.setContext(file.dir) // Different Component, same Module

})

Module vs Component Hierarchy

They're orthogonal concepts:

Spatial Hierarchy:

Page → Region → Section → Component



Functional Grouping:

Module → Sub-module → Component

A Component exists in BOTH:

<file-tree />



Spatial location:

Page → region-left → section-sidebar → file-tree



Functional membership:

Editor Module → File Management Sub-module → file-tree

Practical Example: Dashboard

Spatial structure:

<div class="page-dashboard">

  <div class="region-header">

    <notification-bell />

    <user-menu />

  </div>



  <div class="region-main">

    <div class="section-widgets">

      <sales-chart />

      <revenue-card />

      <activity-feed />

    </div>

  </div>



  <div class="region-sidebar">

    <date-filter />

    <export-button />

  </div>

</div>

Functional modules:

Analytics Module:

├─ sales-chart (in main section)

├─ revenue-card (in main section)

├─ date-filter (in sidebar)

└─ export-button (in sidebar)



Notifications Module:

├─ notification-bell (in header)

└─ activity-feed (in main section)



User Module:

└─ user-menu (in header)

Notice:

• 
  date-filter and export-button are in same Section (sidebar) but could be in different Modules
  


• 
  sales-chart and activity-feed are in same Section (main) but different Modules
  


• 
  notification-bell and activity-feed are in different Sections but same Module
  

When to Use Modules

Use Module classification when:

• Components need to share state across Regions/Sections


• You're organizing by feature, not by layout


• Multiple Components implement one user-facing functionality


• You need to enable/disable entire features

Example: Feature toggles

if (user.hasFeature('advanced-editor')) {

  enableModule('Editor')  // Activates all Components in Editor Module

  // This could span: file-tree, editor, terminal, debugger, etc.

}

Module Size

Modules can be:

Large (Application-level):

E-commerce Module

├─ Product Catalog Sub-module

├─ Shopping Cart Sub-module

├─ Checkout Sub-module

└─ Order History Sub-module

Medium (Feature-level):

Shopping Cart Module

├─ Cart List Component

├─ Cart Summary Component

└─ Cart Actions Component

Small (Workflow-level):

Checkout Module

├─ Shipping Form Component

├─ Payment Form Component

└─ Confirmation Component

Key Differences Summary

Hierarchy (Spatial):

"Where is it located?"

Page → Region → Section → Component → Element

Module (Functional):

"What feature does it belong to?"

Module → Sub-module → Component

Component Classification (Structural):

"How is it built?"

Simple / Formal / Composite / Sub-component

All three classifications apply to the same Component simultaneously:

<file-tree />



Spatial: Page → region-left → section-sidebar → file-tree

Functional: Editor Module → File Management Sub-module → file-tree

Structural: Composite Component (contains tree-item Sub-components)

Why This Matters

Without Module thinking:

// Components tightly coupled to their spatial location

sidebar.fileTree.onSelect(file => {

  mainArea.editor.open(file)  // Hardcoded locations

})

With Module thinking:

// Components loosely coupled via Module

Modules.FileManagement.onFileSelect(file => {

  Modules.CodeEditing.open(file)  // Location-independent

})

Benefits:

• Easier to reorganize UI (move Components between Sections)


• Clearer feature ownership


• Simpler enable/disable of features


• Better code organization

Practical Rules

1. Modules are invisible to users
   
   
   Users see Components, not Modules. Modules are a developer concept.




2. Modules can overlap
   
   
   One Component can belong to multiple Modules if needed.




3. Modules don't have visual representation
   
   
   Unlike Regions/Sections, Modules have no HTML container.




4. Modules follow features, not layout
   
   
   If you reorganize the UI, Modules stay the same.




5. Sub-modules create functional hierarchy
   
   
   Like folders organize files, Sub-modules organize related Components.

Remember:

• 
  Hierarchy = spatial structure (where things are)


• 
  Modules = functional grouping (what works together)


• 
  Component types = structural classification (how it's built)

All three perspectives describe the same interface from different angles.

Practical Decision Guide

When building an interface, ask:

Is it a Component or Element?

It's an Element if:

• Single interaction point


• Cannot be meaningfully split


• No internal state management


• Example: <button>, <input>, <a>
  

It's a Component if:

• Has internal structure


• Manages state or behavior


• Example: <search-bar>, <user-card>, <data-table>
  

Is it a Region or Section?

It's a Region if:

• Primarily spatial division


• Answers "where?" (top, left, right, bottom)


• Layout-focused

It's a Section if:

• Primarily functional division


• Answers "what?" (navigation, content, header)


• Purpose-focused

Is it Structural or Conceptual?

Structural:

<div class="region-sidebar">

  <!-- Explicit in HTML -->

</div>

Conceptual:

.page { 

  display: grid;

  grid-template-columns: 300px 1fr;

  /* Left area is conceptually "region-sidebar" */

  /* No explicit HTML element needed */

}

Key Principles

1. The window defines the space, not the content
   
   
   Window ≠ Page. Window shows Page.




2. Indivisibility means entity integrity
   
   
   Page doesn't split into two Pages. Page contains Regions.




3. Classification is contextual
   
   
   Same UI can be Element, Component, or Sub-component depending on usage.




4. Structure can be explicit or implicit
   
   
   HTML structure or CSS layout both create valid divisions.




5. Fractality exists
   
   
   Components can contain full Page-like structure (Regions → Sections → Elements).




6. Visibility is hierarchical
   
   
   Hide a Region → all its Sections/Components/Elements hide too.

Common Mistakes

❌ "My page has two pages: left and right"


✅ "My page has two regions: left and right"

❌ "Window is the page container"


✅ "Window is the viewport that observes the page"

❌ "This button is always an element"


✅ "This button is an element in this context, component in another"

❌ "All divisions must be in HTML"


✅ "Divisions can be structural (HTML) or conceptual (CSS)"

❌ "Components can't contain regions"


✅ "Formal components are micro-pages with full structure"

Final Checklist

Building an interface? Verify:

• [ ] Window: What viewport sizes do I support?


• [ ] Page: Does content fit? Need scroll? Multiple z-index layers?


• [ ] Region: How do I divide space? (Structural or conceptual?)


• [ ] Section: What functional areas exist in each region?


• [ ] Component: What's reusable? Simple or formal? Composite?


• [ ] Element: What are the atomic interaction points?


• [ ] Classification: Is my naming contextually accurate?

End. You now understand the complete structure of an interface 2D, from viewport to atom.

References:

PARNAS, David L. On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, Vol. 15, No. 12, pp. 1053 – 1058, 1972.

DESCARTES, René. Discourse on method. 2. ed. São Paulo: Martins Fontes, 2001. 102 p.

(“Divide each of the difficulties I examined into as many parts as possible and as necessary to better resolve them.”)