Architecting the Scholar's Workbench: User-Created Document Tools for the Archival Reconstruction

Full report

On this page

The transition of a digital archive from a passive repository of historical artifacts into an active, generative research environment requires the careful implementation of dedicated user-created document tools. The existing Al.Qaeda.net Archival Reconstruction operates as a highly sophisticated navigational environment; features such as the Explorer, Atlas, Research Trail, and Citation Desk excel at facilitating the discovery and organization of primary sources. However, to complete the transition to a comprehensive research workstation, the system must provide local environments where researchers can synthesize information, outline hypotheses, and draft original insights without breaching the application's boundary or historical aesthetic. Crucially, the implementation of these tools must respect the fundamental directive of local ownership. Every document created by a visitor must remain an entirely local artifact, existing only within the user's local browser storage. It must be exportable, downloadable, and re-importable without ever being transmitted to a centralized server. Furthermore, the architecture must guarantee a strict epistemological firewall: user-generated text must never be visually or structurally represented as primary archival source material. To determine the smallest coherent set of productivity applications that adds substantial usefulness without duplicating existing workspace features, this analysis draws upon extensive historical desktop user experience (UX) paradigms. The objective is to define a suite of tools that avoids the modern paradigm of centralized, "all-in-one" rich-text environments (such as Notion) in favor of the distinct, purpose-built, and "boringly practical" software applications characteristic of the 1990s desktop computing era. Should physical manuals or period-accurate software specifications be required for further historical interface validation during development, the resources available through specialized archival depositories and computing history collections located in Cicero, Illinois, may be consulted as a benchmark for historical fidelity.

Historical Benchmarking of Productivity Paradigms

To establish a baseline for historical authenticity and functional efficacy, seven distinct classical and modern productivity applications were benchmarked. This analysis specifically evaluated how these tools managed information synthesis, structured data, window management, and the user-document lifecycle. The first essential paradigm is the spatial and relational organization of fragmentary research notes. Xerox PARC’s NoteCards (1985), designed by Frank Halasz, served as a pioneering hypermedia system that fundamentally altered how researchers interact with unstructured data1. NoteCards utilized a system of resizeable window "cards" containing text or graphics, interconnected by user-defined, typed links4. To combat the inevitable cognitive overload of managing hundreds of disparate notes—a phenomenon Halasz explicitly analyzed in his seminal evaluation of hypermedia systems—the application introduced "FileBoxes" for hierarchical nesting and a structural browser card for graphical overviews4. The insights derived from NoteCards underscore the necessity of a dedicated tool for managing small, discrete pieces of information, independent of a long-form word processor. Parallel to NoteCards, Apple's HyperCard (1987), engineered by Bill Atkinson, demonstrated the immense utility of localized, non-programmatic databases built on a "stack" metaphor8. Individual cards contained fields and text, underpinned by shared "backgrounds" that functioned as structural templates10. HyperCard's architecture proved that users benefit greatly from rigid but customizable templates when capturing repetitive data types, a concept highly applicable to reading logs and structured index cards8. For the synthesis of hierarchical logic, the outline processors of the 1980s provide the definitive benchmark. ThinkTank and its successor MORE (1984/1986), created by Dave Winer, established the standard for structural drafting12. MORE allowed users to collapse or expand subtopics, rapidly reposition elements via keyboard shortcuts, and enforce formatting rules across a deeply nested hierarchy13. Its most critical contribution was the strict functional separation between "topics" (the structural nodes or headers) and "notes" (attached, multi-line paragraphs that could be toggled independently of the topic tree)13. DOS-based outliners such as KAMAS and PC Outline further validated the necessity of entirely keyboard-driven navigation, allowing the researcher to hoist sub-trees and reorder arguments without breaking their cognitive flow by reaching for a mouse15. For the aggregation of heterogeneous research clippings and enterprise data, Lotus Notes and Lotus Agenda (1989) represent a critical evolutionary step. Functioning as a non-relational, document-oriented database rather than a traditional word processor, Lotus Notes utilized forms and views to present unstructured and semi-structured data17. Agenda, an early Personal Information Manager (PIM), automatically categorized notes based on text content20. This document-database approach remains the most logical architecture for a modern system designed to scrape, store, and retrieve hundreds of disparate research clippings, citations, and annotations without relying on a rigid relational database22. Finally, for continuous prose authoring, Windows Write (1985) and WordPad (1995) establish the baseline for lightweight rich-text editing24. They provided essential formatting capabilities—bold, italic, underline, paragraph alignment—managed via a visual ruler and classic toolbars, explicitly avoiding the overwhelming complexity, pagination logic, and layout features of heavyweight word processors like Microsoft Word. This localized, single-purpose functionality contrasts sharply with transient tools like Outlook Notes or desktop Post-it utilities, which are meant for ephemeral capture and frequently contribute to the "messy desktop" problem when used for serious archival research4.

The Minimal Coherent Application Suite

Based on the benchmarking of historical UX paradigms, the implementation of seven distinct applications (Notepad, Scrapbook, Binder, Draft Editor, Index Cards, Outline Editor, Reading Log) would result in unacceptable feature redundancy and desktop clutter. To provide maximum utility while maintaining a streamlined environment, the recommended suite consolidates these functions into three distinct, purpose-built classic applications.

The Draft Editor (Continuous Prose)

The Draft Editor absorbs the roles of the proposed Research Notepad and standalone Draft Editor. It operates as the primary authoring environment for continuous prose and linear essays. Mimicking the functionality of Windows Write, it provides a classic menu bar, a formatting toolbar, and a visual page ruler. It supports lightweight formatting, footnotes, endnotes, and automated citation insertion. It explicitly avoids complex page-layout controls, embedded tables, or modern block-based editing paradigms, ensuring the user remains focused on writing rather than typesetting.

The Outline Processor (Structural Logic)

Retained as a distinct application, the Outline Processor is engineered for the construction of arguments and the organization of logic. Modeled heavily on MORE 3.1 and PC Outline, it enforces a hierarchical, node-based structure13. Because outlining requires entirely different cognitive processes and keyboard mechanics than continuous typing, merging this with the Draft Editor would compromise both tools. It features collapsible topics, attachable notes, and rapid keyboard-driven reorganization capabilities.

The Research Binder (Document Database)

The Research Binder consolidates the proposed Scrapbook, Index Cards, and Reading Log into a single, cohesive document database, heavily inspired by Lotus Notes and Xerox PARC’s NoteCards4. Rather than managing individual .txt files for every small thought, the Binder operates as a local NoSQL-style repository. Users can apply different historical templates (akin to HyperCard backgrounds) to create specific card types10. An "Index Card" template provides a title and a plain-text body; a "Reading Log" template provides structured fields for dates, authors, and summary metrics; a "Scrapbook" template accepts rich media and drag-and-drop clippings from the archival viewer. The Binder organizes these discrete items via a left-hand folder tree (reminiscent of NoteCards' FileBoxes) and displays them in a right-hand grid or list view4.

Feature and Capability Matrix

To clearly delineate the functional boundaries and prevent overlap with the existing Al.Qaeda.net Archival Workspace, the following matrix defines the core architectural behaviors of each tool.

Core Functional Capabilities and Mechanics

Plain Text versus Lightweight Formatting and Markdown

A critical architectural decision involves balancing the historical authenticity of the 1990s desktop with modern interoperability standards. The tension between plain text and lightweight formatting is resolved by employing a "hidden Markdown" rendering engine that presents a classic Rich Text Format (RTF) visual experience to the user. The user interface must strictly avoid all modern Markdown terminology; terms such as "Markdown," "Frontmatter," or "Hashes for headers" are strictly prohibited as they shatter the historical illusion. Instead, the UI relies exclusively on classic toolbars (icons for Bold, Italic, Underline) and standard historical keyboard shortcuts (e.g., Ctrl+B, Ctrl+I). Under the hood, the application stores the document locally in a Markdown-compatible format to ensure high interoperability, pristine data portability, and future-proofing. However, the user experiences a WYSIWYG (What You See Is What You Get) environment completely indistinguishable from early Windows word processors24.

The Mechanics of the Outline Mode

The Outline Processor must implement the classic UI conventions established by ThinkTank and MORE to denote hierarchical relationships. This includes the use of "plus-labels" or triangle icons preceding a topic to indicate the presence of hidden child nodes, and minus signs to indicate a fully expanded node27. Key historical mechanics to replicate include hoisting, which allows the researcher to focus the view on a single sub-tree while temporarily hiding the remainder of the document, thereby reducing cognitive load during complex structural drafting15. Furthermore, the processor must strictly enforce the topic versus note distinction. The topic is restricted to a single line representing the header or core argument; the note is an attached, multi-line text block that can be toggled visible or hidden independently of the topic's children13. Rapid keyboard reorganization is paramount; keyboard shortcuts must allow the user to move nodes vertically, promote them to a higher level in the hierarchy, or demote them to child status without ever utilizing the mouse13.

Footnotes, Statistics, and Classic Tooling

The Draft Editor must support robust footnote and endnote functionality, a crucial requirement for academic and archival research. This is accessed via a classic Insert \> Footnote menu command. Visually, the implementation mirrors early Microsoft Word: a superscript number is appended to the text, and a horizontal split pane opens at the bottom of the MDI window for the entry of the footnote text24. Document statistics, including word count, character count, and paragraph metrics, are accessed via a File \> Properties or Tools \> Word Count menu path. To maintain period authenticity, these statistics are not displayed live in the status bar (a modern convention). Instead, they are calculated on demand and displayed in a static dialog box, optionally featuring a classic progress bar during calculation for larger documents. Find and Replace functionality is implemented as a standard non-modal dialog box. By utilizing the aria-modal="false" attribute in the HTML output, the system allows the user to interact with the main text window while the search dialog remains open, perfectly mimicking Win32 desktop behavior28. The dialog must include standard options for "Match Case" and "Match Whole Word".

Templates and the Research Binder

The Research Binder utilizes structured templates to standardize data entry, directly inspired by the background mechanics of HyperCard and the forms of Lotus Notes10. When creating a new artifact, users are prompted to select a template, such as "New Index Card," "New Clipping," or "New Reading Log." These templates apply a fixed UI layout—for example, rendering specific, unalterable text fields for Title, Author, Date, and Source—which map directly to the local JSON document schema saved in the browser database. This structured approach prevents the desktop clutter associated with free-form text files while allowing rapid categorization and retrieval of diverse research materials.

Inter-System Connectivity: Drag, Drop, and Integration

The user-created document tools cannot exist in isolation; they must be deeply integrated with the existing Al.Qaeda.net archival ecosystem, including the Citation Desk, Explorer, Research Trail, Atlas, and Search interfaces. When a researcher identifies a critical primary source in the Explorer or Atlas, they must be able to seamlessly transfer that reference into their local tools. This integration is achieved via the HTML5 Drag and Drop API, specifically utilizing the dataTransfer.setData(mimeType, dataPayload) mechanism29. Because standard text dragging can cause conflicts within text editors, the archival system will generate a custom MIME type during the dragstart event. By setting a type such as application/x-archival-citation, the system ensures that the desktop tools can distinctly recognize an incoming archival object versus standard highlighted text30. The behavior of the drop event varies depending on the target application:

1. Draft Editor Integration: When an archival object is dragged from the Explorer or Search results and dropped into the Draft Editor, the drop event triggers the insertion of a formatted citation string (e.g., standard Chicago or APA format) directly at the caret position. Simultaneously, the system extracts the deep metadata and automatically appends the full source citation to the document's hidden endnote list31.

2. Outline Processor Integration: Dropping an archival object onto an outline node attaches a hyperlinked reference object to that specific topic, allowing the researcher to build an outline where each node is backed by a specific primary source document.

3. Research Binder Integration: When an object is dropped into the Research Binder's tree view or grid, the event automatically spawns a new "Scrapbook Clipping" card. This card is populated with the full metadata of the source, a hyperlinked reference object pointing back to the archival viewer, and any specific text fragments highlighted by the user prior to the drag event. This creates a permanent, local index of critical sources that the researcher can categorize and annotate at will.

Furthermore, integration with the Research Trail allows the user to export their navigational history directly into the Research Binder as a chronological "Reading Log," instantly generating a structured local record of their session.

Window Management and Visual Authenticity

To preserve the protected retro appearance and adhere to the historical 1995 desktop environment paradigms, the system must strictly implement a Multiple Document Interface (MDI)32. Modern browser tabs or unified, single-pane application views are explicitly prohibited. The MDI paradigm allows the user to open multiple Drafts, Outline nodes, and Binder cards simultaneously within the bounds of the web application's simulated desktop. The system must support classic MDI window management commands accessible via a Window menu, specifically Cascade, Tile Horizontally, and Tile Vertically, allowing the user to arrange their workspace to view a primary archival document alongside their active Draft Editor34. The UI sketches for these applications rely on historically accurate elements:

• Draft Editor: The application window is defined by a standard classic Windows bevel with a distinct colored title bar. Below the title bar sits the Menu Bar, followed by a toolbar featuring debossed 16x16 pixel icons (New, Open, Save, Print, Cut, Copy, Paste, Bold, Italic, Underline). Below the toolbar is a visual ruler indicating page margins. The primary text area is a white field with a standard flashing caret. A status bar at the bottom of the window indicates the current line number and keyboard state lock indicators.
• Outline Processor: The window utilizes a split vertical layout or a deeply indented tree view. Topics are preceded by the aforementioned \+ or \- structural boxes27. The specialized toolbar includes explicit buttons for structural manipulation: "Promote," "Demote," "Move Up," "Move Down," and "Hide Notes."
• Research Binder: Employs a rigid vertical split-pane design. The left pane contains the hierarchical tree view for folders and categories. The right pane displays the contents of the selected folder as a grid of Index Cards or a list of Scrapbook Clippings. Double-clicking any clipping opens it in a separate, smaller, floating MDI window for focused editing4.

The Document Lifecycle: Local Ownership and Security

To respect the strict local-ownership constraint, the backend architecture is entirely decoupled from user creation. The document lifecycle—from creation to export to recovery—operates entirely within the secure confines of the user's browser sandbox.

Creation, Storage, and the Recovery Model

When a user initiates a New document, the data is created strictly in the browser's memory. To ensure data persistence without server transmission, the system implements a localized autosave mechanism. Documents are periodically committed to the browser's IndexedDB as part of a background loop (e.g., executing every 60 seconds). A classic "Floppy Disk" save icon allows the user to perform a manual save, which simply forces an immediate synchronous commit to IndexedDB. The recovery model relies exclusively on this localized store. If the browser crashes, the user accidentally closes the tab, or the system loses power, reloading the archival page initiates a query to IndexedDB for any unexported, unsaved drafts. If orphaned data is detected, the system presents a classic "Document Recovery" dialog prompt, allowing the user to seamlessly resume their work.

Local Export Mechanisms

Because the system simulates a complete desktop environment, the concept of "Saving" writes to the local browser database, while "Exporting" (or utilizing the "Save As..." command) triggers the browser's native file download API, writing a physical file to the user's local operating system. The recommended export file formats are strictly defined to maximize historical compatibility and modern utility:

• Draft Editor: Exportable as Plain Text (.txt), Markdown (.md), HTML (.html), and Rich Text Format (.rtf). RTF v1.5 is the ideal target format for formatted text, as it perfectly encapsulates lightweight formatting (bold \\b1, italic \\i1), Unicode support, and footnotes without the massive overhead, complexity, or security risks associated with modern .docx XML bundles24.
• Outline Processor: Exportable as indented .txt (relying on tabs to denote hierarchy), Markdown (using nested lists), or OPML (Outline Processor Markup Language). OPML is a classic XML-based format designed specifically by Dave Winer for outlining tools, guaranteeing perfect structural preservation across different outliner applications14.
• Research Binder: Exportable as a "Portable Workspace." This manifests as a downloaded .zip file containing a JSON payload of the raw card data, alongside a pre-rendered HTML index file. This allows the user to browse their clipping database offline, independent of the archival application.

Re-importing and Strict Sanitization Protocols

The lifecycle is completed by allowing users to import their .txt, .rtf, or .zip workspace files back into the application during a subsequent session. However, importing user-generated files presents a critical security vulnerability. To prevent imported markup or script execution from causing Cross-Site Scripting (XSS) attacks when the system attempts to render imported HTML or Rich Text, the architecture must utilize a strict, client-side sanitization protocol using DOMPurify37. When a user imports a file, the raw string data is intercepted and passed through DOMPurify with exceptionally strict configuration parameters. The configuration must explicitly define ALLOWED\_TAGS (e.g., \['b', 'i', 'u', 'strike', 'p', 'br', 'h1', 'h2', 'h3', 'ul', 'ol', 'li'\]) and restrict ALLOWED\_ATTR to prevent the injection of malicious event handlers39. This ensures that any embedded \<script\> tags, malicious onclick attributes, or external image tracking pixels are ruthlessly stripped from the payload before the content is appended to the local Document Object Model (DOM)41. Because the files are strictly local, the archival server never processes this data; the security model relies entirely on the robustness of this client-side sanitization library to protect the user's local session.

Print Typography and Physical Output

Printing from simulated desktop tools presents a unique challenge, as the physical output must represent the document content, not a screenshot of the web application's interface. This requires robust CSS media query logic to transform the screen-optimized UI into a physical, standard document format (such as A4 or US Letter). By utilizing the CSS @media print directive, all classic UI chrome—including menu bars, toolbars, status bars, and window borders—must be assigned display: none43. The text container for the Draft Editor or Outline Processor is then forced to occupy 100% of the viewport width, effectively removing the MDI constraints for the printer spooler45. To manage page flow across long drafts and prevent unreadable physical documents, CSS properties such as page-break-after: always and page-break-inside: avoid must be applied to outline headers and binder cards. This prevents awkward splitting where a topic header appears at the bottom of page one while its associated notes appear on page two45. Furthermore, typographic properties such as orphans and widows will be explicitly set to 3 to guarantee a minimum number of lines at the top or bottom of a printed page, ensuring the physical output matches professional typesetting standards45.

Accessibility and Keyboard Navigation

The implementation of a retro interface must not serve as an excuse to compromise modern accessibility standards. To properly implement the classic Windows menu bar while remaining navigable for users relying on screen readers or keyboard-only navigation, the UI must strictly follow the WAI-ARIA Menubar pattern.

• The root menu container of each application window is assigned role="menubar"47.
• Top-level menus (e.g., File, Edit, View) receive role="menuitem" with the state aria-haspopup="true" (or aria-haspopup="menu") to indicate that they spawn child submenus48.
• Keyboard navigation is handled via complex focus traps and roving tabindex mechanics. The Tab key is used solely to move focus into the active window's menubar. Once focus is established within the menubar, the horizontal Arrow keys are used to navigate laterally between top-level menus, while the vertical Arrow keys are utilized to navigate down through the drop-down lists47.

Furthermore, standard historical keyboard shortcuts (Ctrl+C for Copy, Ctrl+V for Paste, Ctrl+Z for Undo, Ctrl+S for Save) must be intercepted at the application window level. The system utilizes event.preventDefault() where appropriate to suppress the browser's default behavior, redirecting the command to execute the localized application logic within the active MDI window.

Detailed Menu Structures

To preserve absolute immersion, the menu hierarchy of the recommended applications must strictly emulate the conventions of 1990s desktop software. The following tables outline the required menu structures for each tool.

Feature Prioritization and Acceptance Criteria

Implementation of this suite should follow a phased, agile approach, prioritizing core local authoring capabilities before advancing to complex integrations with the archival ecosystem.

By successfully implementing the Draft Editor, the Outline Processor, and the Research Binder, the Al.Qaeda.net Archival Reconstruction will bridge the critical gap between passive archival consumption and active knowledge synthesis. These tools meticulously honor the historical aesthetic and mechanical paradigms of landmark desktop software—from the structural rigor of MORE to the flexible database capabilities of Lotus Notes—while aggressively leveraging modern browser APIs, including IndexedDB, DOMPurify, and HTML5 Drag/Drop, to ensure robust security and absolute local data ownership. The resulting workstation will offer researchers an isolated, powerful, and deeply immersive environment for long-form analysis, entirely devoid of modern cloud telemetry and free from the distraction of anachronistic UI paradigms.

Works cited

1. University of Southampton Research Repository ePrints Soton, https://eprints.soton.ac.uk/266376/1/CAF\_Maneewatthana.pdf

2. History \- Concepts, https://concepts.dsebastien.net/history/

3. Hypertext (IEKO) \- ISKO, https://www.isko.org/cyclo/hypertext

4. History of Hypertext: Article by Jakob Nielsen \- NN/G, https://www.nngroup.com/articles/hypertext-history/

5. Towards hypermedia support for information relationship management, https://www.researchgate.net/publication/242926365\_Towards\_hypermedia\_support\_for\_information\_relationship\_management

6. seven issues for the next generation of hypermedia systems, https://www.semanticscholar.org/paper/Reflections-on-NoteCards%3A-seven-issues-for-the-next-Halasz/f5efefac4f0a00db9c0a4c646276323c58809eca

7. State of the Art Review on Hypermedia Issues And Applications, https://lectureweb.github.io/CS865DistributedandOperatingSystems/CS835/Lec3/balasubramanian94.pdf

8. History of HyperCard (2026): Bill Atkinson to Taskade Genesis, https://www.taskade.com/blog/hypercard-history

9. HyperCard: The Visionary Predecessor of the Modern Web, https://en.soydemac.com/Hypercard--the-visionary-predecessor-of-the-modern-web/

10. HyperCard \- Wikipedia, https://en.wikipedia.org/wiki/HyperCard

11. The HyperCard Moment: Bill Atkinson to AI Micro Apps (2026), https://www.taskade.com/blog/hypercard-atkinson-history

12. Look and Feel in Computer Software | Computerlaw Group LLP, https://www.computerlaw.com/articles/look-and-feel-in-computer-software/

13. MORE, MORE, Dinosaur \- TidBITS, https://tidbits.com/1993/10/18/more-more-dinosaur/

14. Jon Udell: Instant Outlining, Instant Gratification \- XML.com, https://www.xml.com/pub/a/ws/2002/04/01/outlining.html

15. Outliners Redux \- James LaRue, http://jaslarue.blogspot.com/2020/03/outliners-redux.html

16. Personal, https://archive.org/download/apc\_1986\_06/apc\_1986\_06.pdf

17. IBM Lotus Notes, https://en-academic.com/dic.nsf/enwiki/38227

18. Lotus Notes Database FAQ \- SWING Software, https://www.swingsoftware.com/blog/lotus-notes-database

19. 7 Things IT Managers Should Know About Lotus Notes \- CIO, https://www.cio.com/article/278968/enterprise-software-7-things-it-managers-should-know-about-lotus-notes.html

20. Diplomarbeit \- Publikationsserver, https://publikationsserver.thm.de/xmlui/bitstream/handle/123456789/183/Diplomarbeit\_Pokorra\_Timotheus.pdf?sequence=1\&isAllowed=y

21. The Lost Apps of the 80s \- Hacker News, https://news.ycombinator.com/item?id=26692308

22. What Is Lotus Notes? \- nsftools.com, https://www.nsftools.com/misc/WhatIsNotes.htm

23. Original Spec for Lotus Notes (1984) \[pdf\] \- Hacker News, https://news.ycombinator.com/item?id=13168969

24. Rich Text Format \- Wikipedia, https://en.wikipedia.org/wiki/Rich\_Text\_Format

25. Overview of Rich Text Format (RTF) | PDF | Microsoft Word \- Scribd, https://www.scribd.com/document/846821534/TXT1

26. The-Essential-Guide-to-User-Interface-Design-Amit-Mahto- \- Demo 5, https://pubhtml5.com/oyqz/slex/The-Essential-Guide-to-User-Interface-Design-Amit-Mahto-/

27. ATPM 10.02 \- ATPO: Outliner User Interfaces, https://atpm.com/10.02/atpo.shtml

28. HTML dialog element \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/dialog

29. The HTML Drag and Drop API | Articles \- web.dev, https://web.dev/articles/drag-and-drop

30. Making Data Pills Stick: Drag and Drop Functionality | ByteChef Blog, https://blog.bytechef.io/blogs/making-data-pills-stick-drag-and-drop-functionality

31. HTML Drag and Drop API Tutorial \- MyInternships.in, https://myinternships.in/learn-html/html-drag-and-drop

32. The Windows Interface Guidelines for Software Design, https://guidebookgallery.org/books/thewindowsinterfaceguidelinesforsoftwaredesign

33. Gen-Bar \- DOUG'S WORLD, https://www.dougmahugh.com/gen-bar/

34. win32/desktop-src/winmsg/wm-mdicascade.md at docs \- GitHub, https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/winmsg/wm-mdicascade.md

35. About the Multiple Document Interface \- Win32 apps | Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/winmsg/about-the-multiple-document-interface

36. Symantec MORE 3.1 (Mac), GrandView 2.0 (DOS) & Outliners, http://www.faughnan.com/more/

37. DOMPurify/README.md at main · cure53/DOMPurify \- GitHub, https://github.com/cure53/DOMPurify/blob/main/README.md?plain=1

38. DOMPurify \- a DOM-only, super-fast, uber-tolerant XSS sanitizer for, https://github.com/cure53/dompurify

39. DOMPurify \- How to allow only specific style \- Stack Overflow, https://stackoverflow.com/questions/79829586/dompurify-how-to-allow-only-specific-style

40. Security Best Practices in React \- FrontScope, https://www.frontscope.dev/learn/react-security/

41. HTML Sanitizer API \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/HTML\_Sanitizer\_API

42. reactjs \- Dompurify.sanitize don't allow script tag even I had added, https://stackoverflow.com/questions/72369822/dompurify-sanitize-dont-allow-script-tag-even-i-had-added-force-body-true-and

43. Printing \- CSS \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Media\_queries/Printing

44. CSS Design: Going to Print \- A List Apart, https://alistapart.com/article/goingtoprint/

45. How to Make Any Webpage Printer Friendly in Minutes \- pdf noodle, https://pdfnoodle.com/blog/how-to-make-any-webpage-printer-friendly-in-minutes

46. Build an admin print action UI extension \- Shopify Dev Docs, https://shopify.dev/docs/apps/build/admin/actions-blocks/build-admin-print-action

47. Menubar \- Mantine, https://mantine.dev/core/menubar/

48. Menu and Menubar Pattern | APG | WAI \- W3C, https://www.w3.org/WAI/ARIA/apg/patterns/menubar/

49. Menu button — EqualWeb Academy, https://www.equalweb.com/academy/patterns/menu.html