October 10, 2025
Random News

Paradise Solution Newspaper

Best News Website

Author Info

Author Name

Find Me On

Trending News

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

psitbdUser024 mins


–> 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
Enter fullscreen mode

Exit fullscreen mode

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.

 class="page-home">
Enter fullscreen mode

Exit fullscreen mode

Important distinctions:

Structural (HTML delimited):

 class="page-home">
Enter fullscreen mode

Exit fullscreen mode

Conceptual (CSS delimited):

.page-home {
  display: grid;
  grid-template-columns: 1fr 1fr; /* left/right division exists only in CSS */
}
Enter fullscreen mode

Exit fullscreen mode

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
Enter fullscreen mode

Exit fullscreen mode

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:

 class="page-home">
  
 class="region-top">
    
  
 class="region-bottom">
Enter fullscreen mode

Exit fullscreen mode

Structural vs Conceptual:

Structural:

 class="region-left">
Enter fullscreen mode

Exit fullscreen mode

Conceptual:

.page-home {
  display: flex;
  /* Left "region" is first 300px, right "region" is remaining space */
  /* No explicit HTML elements, but regions conceptually exist */
}
Enter fullscreen mode

Exit fullscreen mode

Space between Regions:

 class="page">
  
 class="region-top">

  
 class="region-bottom" style="margin-top: 30px">
Enter fullscreen mode

Exit fullscreen mode

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:

 class="page-home">
  
 class="region-top"> 
    
 class="section-header">Header content
 
  


  
 class="region-bottom">
    
 class="section-left">Sidebar navigation

    
 class="section-right">Main content
Enter fullscreen mode

Exit fullscreen mode

Structural vs Conceptual:

Structural:

 class="section-navigation">
Enter fullscreen mode

Exit fullscreen mode

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 */
}
Enter fullscreen mode

Exit fullscreen mode



Level 4: Component — The Complex Part

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

 class="section-header"> 
  Header component
Enter fullscreen mode

Exit fullscreen mode



Component Types

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



Classification 1: By Space Division

Simple Component:

 class="card">
   />
Enter fullscreen mode

Exit fullscreen mode

No spatial divisions. Just a set of Elements.

Formal Component (Micro Pages/ Fractal Pages):

 class="card-complex">
  
 class="region-header">    
    
 class="section-title">  
      
                   
    

  

  
 class="region-content">
Enter fullscreen mode

Exit fullscreen mode

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

The classification is contextual and dynamics, not fixed.



Classification 2: By Composition

Composite Component:

 class="user-profile">
   />     
   />  
   />
Enter fullscreen mode

Exit fullscreen mode

Made of other Components (Sub-components).

Sub-component: Any Component displayed inside another Component.



Classification 3: By Use

Composite Component (componente composto):

 class="sidebar">
   name="home" /> 



 class="menu">
   name="options" /> 


 name="start" />
Enter fullscreen mode

Exit fullscreen mode

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:

 class="data-table">
   />   
   />     
   />
Enter fullscreen mode

Exit fullscreen mode

Formed by multiple Sub-components that work together.



Level 5: Element — The Atom

What it is: The smallest functional unit.

Examples:

Important: Elements can also be Simple or Formal.



Simple Element

Enter fullscreen mode

Exit fullscreen mode

Just text. No internal structure.



Formal Element
Enter fullscreen mode

Exit fullscreen mode

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:

Enter fullscreen mode

Exit fullscreen mode
Enter fullscreen mode

Exit fullscreen mode

This is an Element (atomic interaction unit).

When it shows a menu:



 class="dropdown-menu" v-if="menuVisible">
Enter fullscreen mode

Exit fullscreen mode

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

When used inside another component:

 class="toolbar"> 
   />  
   />
   />
Enter fullscreen mode

Exit fullscreen mode

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



The Dynamic Nature of Classification



Example: Icon Button Evolution

Stage 1 – Simple Element:

Enter fullscreen mode

Exit fullscreen mode

Classification: Element

Reason: Atomic unit, no internal divisions

Stage 2 – Formal Element:

Enter fullscreen mode

Exit fullscreen mode

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

Reason: Has internal structure, but still one functional unit

Stage 3 – Simple Component:

 icon="search" input-text="Search" />
Enter fullscreen mode

Exit fullscreen mode

Classification: Component

Reason: Can be broken down into more than one functionality

Stage 4 – Sub-component:

Classification: Sub-component

Reason: Component used inside another Component

Stage 5 – Complex Component:

 
  icon="more" 
  @click="toggleMenu"
>
   v-if="open">
     />
     />
Enter fullscreen mode

Exit fullscreen mode

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()
Enter fullscreen mode

Exit fullscreen mode

Example:

 class="page">
  
 class="region-top" v-if="showHeader">     
    
 class="section-nav" v-if="showNav">     
       v-if="isLoggedIn">
Enter fullscreen mode

Exit fullscreen mode



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)
Enter fullscreen mode

Exit fullscreen mode



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

 class="page">
  
 class="region-left">
    
 class="section-sidebar">
       />              
       />           
    

  


  
 class="region-right">
    
 class="section-main">
       />            
       />             
    

  


  
 class="region-bottom">
    
 class="section-terminal">
       />
Enter fullscreen mode

Exit fullscreen mode

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)
Enter fullscreen mode

Exit fullscreen mode

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:

Component Module
Single UI piece Multiple UI pieces
One place in hierarchy Can spans multiple places
Contained in Section Cuts across Sections
Example: Example: “Authentication” feature

Example: Authentication Module




 />          


 />           


 />     


 />
Enter fullscreen mode

Exit fullscreen mode

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
})
Enter fullscreen mode

Exit fullscreen mode



Module vs Component Hierarchy

They’re orthogonal concepts:

Spatial Hierarchy:
Page → Region → Section → Component

Functional Grouping:
Module → Sub-module → Component
Enter fullscreen mode

Exit fullscreen mode

A Component exists in BOTH:



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

Functional membership:
Editor Module → File Management Sub-module → file-tree
Enter fullscreen mode

Exit fullscreen mode



Practical Example: Dashboard

Spatial structure:

 class="page-dashboard">
  
 class="region-header">
     />
     />
  


  
 class="region-main">
    
 class="section-widgets">
       />
       />
       />
    

  


  
 class="region-sidebar">
     />
     />
Enter fullscreen mode

Exit fullscreen mode

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)
Enter fullscreen mode

Exit fullscreen mode

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.
}
Enter fullscreen mode

Exit fullscreen mode



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
Enter fullscreen mode

Exit fullscreen mode

Medium (Feature-level):

Shopping Cart Module
├─ Cart List Component
├─ Cart Summary Component
└─ Cart Actions Component
Enter fullscreen mode

Exit fullscreen mode

Small (Workflow-level):

Checkout Module
├─ Shipping Form Component
├─ Payment Form Component
└─ Confirmation Component
Enter fullscreen mode

Exit fullscreen mode



Key Differences Summary

Hierarchy (Spatial):

"Where is it located?"
Page → Region → Section → Component → Element
Enter fullscreen mode

Exit fullscreen mode

Module (Functional):

"What feature does it belong to?"
Module → Sub-module → Component
Enter fullscreen mode

Exit fullscreen mode

Component Classification (Structural):

"How is it built?"
Simple / Formal / Composite / Sub-component
Enter fullscreen mode

Exit fullscreen mode

All three classifications apply to the same Component simultaneously:



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)
Enter fullscreen mode

Exit fullscreen mode



Why This Matters

Without Module thinking:

// Components tightly coupled to their spatial location
sidebar.fileTree.onSelect(file => {
  mainArea.editor.open(file)  // Hardcoded locations
})
Enter fullscreen mode

Exit fullscreen mode

With Module thinking:

// Components loosely coupled via Module
Modules.FileManagement.onFileSelect(file => {
  Modules.CodeEditing.open(file)  // Location-independent
})
Enter fullscreen mode

Exit fullscreen mode

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:

It’s a Component if:

  • Has internal structure
  • Manages state or behavior
  • Example: , ,



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:

 class="region-sidebar">
Enter fullscreen mode

Exit fullscreen mode

Conceptual:

.page { 
  display: grid;
  grid-template-columns: 300px 1fr;
  /* Left area is conceptually "region-sidebar" */
  /* No explicit HTML element needed */
}
Enter fullscreen mode

Exit fullscreen mode



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.”)



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *

Related News