VICILOOK MINIVIEW™ ENGINE (VME)

VICILOOK MINIVIEW™ ENGINE (VME)

Technical & Non-Technical Technology Documentation

Technology Name: Vicilook MiniView™ Engine
Abbreviation: VME
Technology Classification: Native DOM Snapshot and Miniature Webpage Rendering Technology
Technology Creator / Author: Dickson Cliff Okechukwu
Technology Owner / Ecosystem: Vicilook
Current Implementation: Vicilook MiniView Engine Plugin
Document Type: Technology Overview, Architecture & Technical Specification
Status: Initial Implementation and Development

Tagline: See the page. Without opening the page.

PART ONE: NON-TECHNICAL DOCUMENTATION

1. Introduction

Vicilook MiniView™ Engine (VME) is a locally operated webpage representation technology developed to reproduce miniature views of previously visited webpages without having to reopen those webpages or load them inside embedded browser frames.

The technology addresses a familiar problem in digital browsing: conventional browsing-history systems generally represent previously visited pages through their titles, URLs, website icons or featured images. These representations provide limited visual information about the actual content of the visited pages.

MiniView introduces a different approach.

Instead of representing a visited webpage using its featured image or a generic thumbnail, MiniView captures a representation of the webpage’s visible content and reconstructs that content into a miniature, independently rendered view.

This allows users to recognize previously visited webpages through their actual visual composition.

The technology is designed to operate primarily on the user’s device, reducing dependence on server-side screenshot generation and external screenshot services.

2. The Problem MiniView Solves

Traditional browsing-history systems have several limitations:

  • They primarily depend on page titles and URLs.
  • Featured images do not necessarily represent the actual page layout.
  • A page may have no featured image at all.
  • External screenshot services introduce additional infrastructure and processing costs.
  • Iframe-based previews can be blocked by website security policies.
  • Reopening every previously visited page to display its preview creates unnecessary network requests and loading delays.

These limitations make it difficult to provide a genuinely visual browsing-history experience.

MiniView approaches this problem by capturing and reconstructing the visible structure of visited webpages locally.

3. The MiniView Concept

MiniView works on a simple principle:

A webpage can be represented visually by preserving and reconstructing its rendered document structure, rather than requiring a newly generated screenshot from a remote server.

When a user visits a supported webpage, MiniView examines its visible document elements and selected computed styling properties.

It then creates a simplified, static representation of that visible page section.

The representation is saved locally and can subsequently be rendered inside a miniature preview tile.

The result is a visual browsing-history experience in which each tile resembles a miniature version of the page it represents.

4. How It Works in Everyday Language

The process involves five major stages:

  1. Page observation: MiniView observes the webpage currently being viewed.
  2. Visual capture: It collects visible page elements, text, image references and selected styling information.
  3. Mini-page construction: It reconstructs those elements into a compact HTML representation.
  4. Local storage: It saves the representation in the browser’s IndexedDB storage.
  5. Miniature display: When the browsing-history widget is opened, MiniView renders the stored representation inside the corresponding tile.

The original webpage does not need to be opened again just to display its saved preview.

5. What Makes MiniView Different?

MiniView is conceptually different from conventional webpage thumbnail systems.

Conventional approach Vicilook MiniView
Uses featured images Reconstructs visible webpage content
Often displays page titles Displays a miniature page representation
May require remote screenshot services Captures and stores locally
May depend on iframes Does not use iframes
May require repeated page loading Reuses saved local representations
Primarily image-based previews HTML-based miniature reconstruction

MiniView does not attempt to reproduce a webpage as a fully functional browser window. Its purpose is to preserve enough of the visible appearance to make a recognizable miniature representation.

6. Primary Benefits

6.1 Visual Recognition

Users can recognize pages through their actual visible content rather than relying exclusively on names or featured images.

6.2 Reduced Server Workload

The snapshot construction and storage process takes place on the user’s device. The WordPress server does not have to generate and store a separate screenshot for every visited page.

6.3 Reduced Dependency on External Services

MiniView does not require a paid screenshot-generation service or a dedicated screenshot-processing server.

6.4 Faster Repeat Display

Once a snapshot has been saved, MiniView can retrieve it from local storage instead of reconstructing the original page on every history-widget visit.

6.5 Device-Level Storage

Visit history and miniature representations are maintained locally in the user’s browser storage.

6.6 Reusable Technology

The MiniView concept can be extended beyond browsing history into other applications that benefit from miniature representations of digital content.

7. Potential Applications

Although the initial implementation is integrated into Vicilook Visit History, the underlying concept has potential applications in several areas.

A. Digital Browsing History

Visually represent previously visited webpages.

B. Tab and Window Management

Display miniature representations of open or recently used webpages.

C. Digital Workspace Management

Represent previously accessed digital workspaces and application screens.

D. Community Information Discovery

Provide visual representations of previously visited community pages, institutions, organizations and local information resources.

E. Digital Content Collections

Create visual collections of saved webpages.

F. Application Navigation

Provide miniature visual previews of previously accessed application sections.

These are potential extensions, not claims that every application is already implemented.

PART TWO: TECHNICAL DOCUMENTATION

8. Technical Definition

Vicilook MiniView™ Engine is a client-side DOM snapshot and miniature rendering system that captures a selected viewport representation of a rendered webpage, reconstructs its visible document structure and selected computed styles, stores the resulting HTML representation locally, and renders it within a constrained miniature viewing surface.

The current implementation uses:

  • JavaScript for DOM inspection and reconstruction.
  • HTML for the reconstructed page representation.
  • CSS for preserving selected visual properties and scaling.
  • IndexedDB for persistent local snapshot storage.
  • LocalStorage for visit-history metadata.
  • Shadow DOM for isolating the miniature rendering environment.
  • WordPress PHP for plugin integration, configuration and page identification.

9. Technical Architecture

The architecture consists of six primary components.

9.1 WordPress Integration Layer

The WordPress PHP component identifies supported public singular content, including:

  • Pages.
  • Posts.
  • Viewable custom post types.

It identifies the current content’s URL, title and post type.

It also registers the plugin’s frontend scripts, styles, administrative settings and shortcode.

9.2 DOM Observation and Capture Layer

The JavaScript capture engine examines the currently rendered document.

It obtains the browser viewport dimensions and current scroll offsets.

It then inspects the document body and traverses its visible child elements.

Elements outside the selected viewport are excluded where the implementation can identify them through their bounding rectangles.

9.3 Computed Style Reconstruction Layer

MiniView retrieves selected computed CSS properties from the original elements.

The properties include:

  • Display.
  • Position.
  • Dimensions.
  • Margins and padding.
  • Borders and border radius.
  • Background colours and images.
  • Typography.
  • Flexbox properties.
  • Grid properties.
  • Alignment.
  • Overflow.
  • Opacity.
  • Visibility.
  • Transformations.
  • Object positioning.
  • Shadows.
  • Z-index.

These properties are applied to the reconstructed elements.

This provides a visual approximation of the original page’s layout and appearance.

9.4 Mini-Page Construction Layer

The cloned elements are assembled into a standalone HTML structure.

The reconstructed body is positioned according to the captured scroll offsets.

A viewport-sized wrapper clips the representation to the captured screen dimensions.

The resulting HTML is stored as the mini-page snapshot.

Importantly, the current implementation does not convert this representation into a screenshot or SVG image.

9.5 Local Storage Layer

MiniView uses two browser storage mechanisms.

LocalStorage

Stores browsing-history metadata, including:

  • Page URL.
  • Page title.
  • Content type.
  • Visit timestamp.

The current history implementation retains up to 50 entries.

IndexedDB

Stores the reconstructed mini-page HTML, viewport width, viewport height and snapshot timestamp.

The snapshot database is:

VicilookVisitHistoryMiniPages_v14

The object store is:

mini_pages

The database is maintained independently of the WordPress database.

9.6 Miniature Rendering Layer

When the history widget is displayed, MiniView retrieves the relevant snapshot from IndexedDB.

It creates an isolated Shadow DOM rendering surface.

The stored HTML is inserted into this surface, with active elements and potentially executable content removed.

The reconstructed page is scaled to fit the tile.

This allows the miniature representation to be displayed without loading the original page inside an iframe.

10. Operational Workflow

The following diagram describes the current implementation.

flowchart TD
    A[User visits a supported webpage] --> B[WordPress identifies page]
    B --> C[JavaScript observes rendered DOM]
    C --> D[Identify visible elements]
    D --> E[Collect selected computed CSS]
    E --> F[Reconstruct static HTML]
    F --> G[Save snapshot in IndexedDB]
    G --> H[User opens Visit History]
    H --> I[Retrieve saved snapshot]
    I --> J[Render inside Shadow DOM]
    J --> K[Scale to miniature tile]
    K --> L[Display page title in footer]

11. Snapshot Capture Mechanics

11.1 Viewport Measurement

The engine measures:

  • window.innerWidth
  • window.innerHeight
  • window.pageXOffset
  • window.pageYOffset

These values establish the dimensions and position of the captured viewport.

11.2 Element Selection

The capture engine traverses the document body.

It excludes elements that are not suitable for static reconstruction, including scripts, iframes, embedded objects and other active content.

It also filters elements that fall outside the selected viewport.

11.3 Styling

The engine obtains computed styling through the browser’s getComputedStyle() interface.

It copies selected visual properties onto the corresponding cloned elements.

This approach reduces the need to load the original page’s entire stylesheet inside the miniature rendering environment.

11.4 Image Handling

Visible image elements are reconstructed using their available image URLs.

Canvas elements are handled separately where the browser permits conversion to an image.

External images may remain dependent on their original URLs and availability.

11.5 Snapshot Serialization

The reconstructed HTML is serialized and stored as a string.

The current implementation rejects snapshots exceeding approximately 1.5 million characters.

This is an application-level size safeguard, not a guarantee of a fixed storage requirement.

12. Miniature Rendering Mechanics

The rendering engine retrieves the saved HTML and places it inside a Shadow DOM container.

The Shadow DOM provides style isolation between the miniature page and the surrounding WordPress page.

The miniature is scaled using the dimensions of the original viewport and the available tile dimensions.

The current implementation uses cover-style scaling, which prioritizes filling the available preview area.

Consequently, some parts of the original viewport may be cropped to maintain the tile’s proportions.

Tile Composition

The current design reserves:

Tile section Space
Miniature webpage representation 80%
Page title footer 20%

The title footer uses:

  • Black background.
  • White text.
  • Center alignment.
  • Automatic wrapping.
  • A maximum of two visible lines.
  • Ellipsis or clipping for excessively long titles.

The footer is positioned inside the same tile.

13. Security and Isolation

MiniView is designed to create a static visual representation rather than a second executable version of the original webpage.

The current implementation removes or excludes several categories of content, including:

  • Script elements.
  • Iframes.
  • Embedded objects.
  • Forms.
  • Active event-handler attributes.
  • Navigation links and form actions.

The miniature rendering surface is isolated using Shadow DOM.

These measures reduce the risk of the reconstructed content behaving like an independently active webpage.

However, DOM reconstruction is not equivalent to a complete security sandbox. Future versions should include additional URL validation, sanitization and resource restrictions.

14. Performance and Infrastructure Considerations

A major architectural objective of MiniView is to avoid introducing substantial screenshot-processing workloads on the WordPress server.

Server-side responsibilities

The server:

  • Identifies supported content.
  • Provides page metadata.
  • Registers the plugin’s scripts and styles.
  • Supplies administrative configuration.

Client-side responsibilities

The browser:

  • Observes the rendered document.
  • Reconstructs visible elements.
  • Collects selected styling.
  • Saves snapshots.
  • Retrieves saved representations.
  • Renders miniature previews.

The current architecture does not require a dedicated screenshot server, image-rendering server or screenshot-generation API.

It does, however, require client-side processing and browser storage.

Performance will depend on the complexity of the visited page, the number of visible elements, device memory, browser performance and image-loading conditions.

PART THREE: TECHNICAL LIMITATIONS AND ENGINEERING CONSIDERATIONS

15. Current Technical Limitations

MiniView is a reconstruction technology, not a native browser screenshot engine.

Its current implementation has important limitations.

15.1 Complex CSS

Some visual effects may not be faithfully reproduced because the engine copies selected computed properties rather than the complete browser rendering environment.

15.2 Pseudo-elements

CSS-generated content such as ::before and ::after is not explicitly reconstructed as DOM elements.

15.3 External Images

Image references may depend on the original resource remaining available.

Cross-origin restrictions and authentication requirements may affect some images.

15.4 Web Fonts

Some typography may differ if the required font resources are unavailable in the miniature rendering environment.

15.5 Dynamic Content

Animations, video playback, JavaScript-generated interfaces and changing live content are not preserved as fully functional experiences.

15.6 Browser Compatibility

The implementation depends on browser support for IndexedDB, DOM APIs and Shadow DOM.

15.7 Storage Boundaries

Browser storage can be limited, cleared or evicted by the operating system or browser.

15.8 Viewport Cropping

The cover-scaling approach may crop portions of the captured viewport.

These limitations should guide future engineering improvements rather than be presented as solved capabilities.

16. Privacy Model

MiniView is designed around device-local storage.

Its browsing-history metadata and reconstructed snapshots are stored in the user’s browser rather than being uploaded to a dedicated screenshot-processing server.

This means:

  • Different devices do not automatically share snapshots.
  • Clearing browser storage can remove saved representations.
  • Private browsing environments may have different storage behaviour.
  • The current implementation does not provide cloud synchronization.

External image resources may still be requested by the browser when a saved preview is rendered.

The privacy model therefore distinguishes locally stored snapshot data from external resources referenced by the reconstructed page.

PART FOUR: FUTURE DEVELOPMENT ROADMAP

17. Proposed MiniView Evolution

The following improvements represent opportunities for future versions.

Phase 1: Capture Reliability

  • Improve DOM reconstruction accuracy.
  • Improve mobile browser compatibility.
  • Improve capture timing.
  • Handle lazy-loaded images more reliably.
  • Improve page-builder compatibility.
  • Add capture diagnostics.

Phase 2: Visual Fidelity

  • Better pseudo-element reconstruction.
  • Improved CSS inheritance handling.
  • Better font preservation.
  • Better background and image reconstruction.
  • More accurate positioning of fixed and sticky elements.
  • Improved responsive-layout handling.

Phase 3: Storage Optimization

  • Snapshot compression.
  • Duplicate snapshot detection.
  • Snapshot expiration policies.
  • Storage quotas and management.
  • Incremental snapshot updates.
  • Better cleanup of unused snapshots.

Phase 4: Advanced MiniView Capabilities

  • Configurable capture regions.
  • Full-page miniature representations.
  • Multiple viewport snapshots.
  • Snapshot refresh mechanisms.
  • Support for additional digital content types.
  • Reusable integration interfaces for other Vicilook applications.

Phase 5: Independent Technology Integration

MiniView can potentially become an independent rendering and preview component available to other Vicilook products.

This would allow multiple applications to benefit from the same underlying miniature representation technology.

PART FIVE: TECHNOLOGY IDENTITY AND POSITIONING

18. Official Technology Identity

Name: Vicilook MiniView™ Engine

Abbreviation: VME

Full technical description: Native DOM Snapshot and Miniature Webpage Rendering Technology.

Creator: Dickson Cliff Okechukwu

Technology ecosystem: Vicilook

Technology category: Client-side Web Rendering and Visual Representation Technology.

Tagline: See the page. Without opening the page.

19. Technology Positioning Statement

Vicilook MiniView Engine introduces a device-local approach to representing previously visited webpages through miniature reconstructions of their visible content.

Rather than relying on generic thumbnails, remote screenshot-generation services or embedded browser frames, MiniView reconstructs selected portions of a webpage’s rendered document structure and styling into a compact HTML representation.

The resulting representation is stored locally and rendered within a miniature viewing environment.

Its architecture is designed to reduce server-side screenshot-processing requirements while enabling more visually informative digital navigation experiences.

20. Intellectual Contribution

The defining engineering idea behind MiniView is the combination of:

  1. Viewport-oriented DOM inspection.
  2. Selective computed-style reconstruction.
  3. Static HTML mini-page construction.
  4. Device-local snapshot persistence.
  5. Isolated miniature rendering through Shadow DOM.
  6. Scaled visual presentation within constrained interface tiles.

Together, these elements establish the current MiniView implementation architecture.

Any future intellectual-property or patent assessment should evaluate the novelty of the specific technical implementation against existing DOM-cloning, webpage-preview, browser-rendering and snapshot technologies.

The name, documentation and implementation should also be treated separately when considering intellectual-property protection.

PART SIX: IMPLEMENTATION REFERENCE

21. Current Software Implementation

The current reference implementation is:

Software: Vicilook MiniView Engine WordPress Plugin
Version: 1.5.0
Author: Dickson Cliff Okechukwu

WordPress integration

  • Plugin administration through WordPress settings.
  • Frontend JavaScript integration.
  • Configurable tile appearance.
  • Support for singular pages, posts and viewable custom post types.
  • Existing shortcode compatibility.

Existing shortcode

Your Visits History

Preserved configuration

The current implementation retains the previous Visit History settings option:

vicilook_visit_history_options

It also retains the existing history storage key:

vicilook_visit_history_v1

The mini-page snapshots use:

VicilookVisitHistoryMiniPages_v14

These identifiers are implementation details and can be changed in a future migration with appropriate compatibility handling.

22. Conclusion

Vicilook MiniView Engine represents a new direction in how digital interfaces can present previously visited web content.

Its central idea is to move beyond conventional page thumbnails and create miniature representations from the actual rendered document structure of the visited webpage.

By combining DOM reconstruction, selected computed styling, local browser storage and isolated miniature rendering, MiniView provides an alternative approach to visual browsing history.

Its initial implementation establishes a foundation for further development into a reusable Vicilook technology.

The long-term opportunity is to make MiniView a general-purpose visual representation engine that can support multiple applications and digital experiences across the Vicilook ecosystem.

VICILOOK MINIVIEW™ ENGINE

See the page. Without opening the page.

Created by Dickson Cliff Okechukwu
Part of the Vicilook Technology Ecosystem

×