3.1 System functionality
In practical use, the BeamNet workflow behaved largely as intended. A user could move from an unfamiliar website to a functioning, notification-enabled feed entry in a handful of steps: navigating to the site, selecting representative elements, and confirming the source (Figure 1). Multiple such sources, once created, could be grouped into a single feed spanning different websites but a shared topic of interest (Figure 2), and the resulting aggregated view presented all tracked content from those sources side by side (Figure 3). This end-to-end flow — unremarkable as it may sound described plainly — is, we would argue, the core contribution of the system: it removes the need for a user, or a developer acting on their behalf, to write source-specific extraction rules for each website they wish to follow.
3.2 Extraction accuracy
The exploratory accuracy assessment described in Section 2.6 produced an error rate of roughly 2% to 5%, varying by website, with most misclassifications traceable to a single recurring cause: unrelated text elements sharing the LCA node identified as the extraction anchor (Table 1). This is, we think, an instructive failure mode rather than merely an unfortunate one — it points fairly directly at the structural assumption underlying the whole approach, namely that content the user cares about and content the user does not care about will, on the pages that matter, tend to sit in structurally distinct parts of the tree. That assumption holds reasonably well on the more rigidly templated sites (news listings, in particular) and rather less well on pages with denser, more irregular markup. We would resist over-claiming here: a 2–5% range across an informally sampled set of sites is a rough signal, not a validated benchmark, and a more rigorous
Table 1: Summary of the exploratory extraction-accuracy assessment, reporting the observed error-rate range and its primary source across a heterogeneous, non-randomized sample of websites. The table reports a single metric, content extraction error rate, observed to fall between 2% and 5% depending on the site tested, alongside the primary cause of misclassification identified during review. No confidence interval or formal statistical test accompanies these figures, consistent with the exploratory, non-randomized nature of the assessment described in Section 2.6. The note beneath the table flags this limitation explicitly so the values are not mistaken for a validated benchmark. This table underlies the accuracy discussion in Section 3.2.
|
Metric
|
Observed Range
|
Primary Error Source
|
|
Content extraction error rate
|
2%–5%
|
Shared LCA node with unrelated text elements
|
Figure 1. Basic tree structure of the Document Object Model (DOM), illustrating how HTML elements nest into parent-child relationships that BeamNet's Lowest Common Ancestor (LCA) inference relies on. The diagram shows a simplified DOM tree with a root node branching into nested child elements, mirroring how a real webpage's markup is structured beneath the hood. It is used to explain, at a conceptual level, why two selected content elements sharing a common ancestor node can be generalized into a reusable extraction pattern. This figure is purely illustrative of the underlying web-standard concept and does not depict BeamNet's own interface or output. It grounds the technical explanation of the LCA-based extraction method introduced in Section 2.
Figure 2. Flowchart of the BeamNet content-curation algorithm, tracing the sequence of steps from a user's initial element selection to the generation of a reusable extraction rule. The flowchart lays out the algorithm's decision points in order, showing how raw user input (clicking representative elements on a page) is converted into a generalized LCA-based pattern that can later be reapplied to detect new, similar content on the same site. Branches in the flowchart indicate where the algorithm checks for structural consistency before finalizing a pattern. This figure is referenced in the system-design discussion and complements the narrative description of the extraction process given in the text.
Figure 3. Main components of the BeamNet system and the communication pathways connecting them, showing how the client interface, extraction engine, and content-aggregation backend interact. The diagram depicts the system at an architectural level, showing discrete components (such as the source-selection client, the LCA-based extraction module, and the feed-aggregation service) connected by directional arrows indicating data flow between them. It is intended to give readers a top-down view of how user actions on the client eventually produce the aggregated content shown to the user. This figure supports the system-overview discussion and precedes the more granular data-flow diagram in Figure 4.
follow-up study — with a documented sampling frame, inter-rater reliability checks on what counts as an extraction error, and comparison against an established baseline such as the pattern-matching approach benchmarked by Nusret et al. (2017) — would be needed before the figure could be treated as a reliable estimate of real-world performance.
3.3 Comparison with existing approaches
Set against prior extraction strategies, BeamNet's LCA-based method occupies something of a middle ground. It is more general than fully hand-authored, site-specific scraping rules, yet it does not attempt the linguistic sophistication of text-detection-framework approaches such as Wu's (2016), which forgo DOM analysis altogether in favor of language-level heuristics — an approach that may generalize better across languages but, arguably, less well across arbitrary page structures. Nor does BeamNet attempt the speed optimization that has driven much of the pattern-matching literature (Nusret et al., 2017); given that a personal feed involves comparatively few sources refreshed at modest intervals, raw throughput was, frankly, judged less important during design than structural robustness and ease of use for a non-technical end user.
3.4 User-facing workflow
The content-selection interface (Figure 5a–b) and multi-source feed assembly (Figure 5c) were designed around the premise that curation should not require any technical background from the user — no CSS selectors, no XPath, nothing of that sort has to be written or understood. Whether this design goal was actually achieved for a representative range of users is, admittedly, a question this paper cannot answer with confidence, since no formal usability study or user survey was conducted alongside system development; this remains an important gap for subsequent work. Once a source has been selected and confirmed, the user is not limited to tracking it in isolation. The "Add Feed" screen (Figure 5c) lets a user name a topic-based feed and attach multiple sources to it in sequence, so that, for example, several international-news sites can be folded into a single "World News" feed rather than monitored as separate, unrelated entries. This grouping step is what turns BeamNet from a single-source scraper into something closer to a personal aggregator: once two or more sources are attached to a feed, their extracted content is merged and re-sorted into one continuous stream, shown to the user in the aggregated feed view (Figure 5d). That view interleaves headline, source attribution, and a short excerpt for each item, ordered chronologically across sources rather than grouped by site, which was a deliberate choice intended to spare the user the extra step of checking each source individually. Whether that ordering choice holds up well as the number of attached sources grows substantially beyond the two or three shown in Figure 5c is, admittedly, untested; our informal use during development involved feeds of similar size, and larger, more heterogeneous feeds may surface ordering or de-duplication issues that this preliminary design has not yet had to confront.
3.5 Limitations and directions for future work
Several limitations deserve to be stated openly rather than glossed over. First, scalability: extending the current headless-browser-per-source architecture to a large user base would place substantial, and possibly prohibitive, demand on server resources, and lighter-weight headless browsing approaches — stripped of the graphical rendering overhead that conventional browsers carry — would likely need to be explored. Second, the image-curation logic that pairs images with their associated text in card-style views remains imprecise and was not a focus of the present evaluation. Third, and perhaps most consequential for the system's long-term usefulness, is the absence of any content-quality or trustworthiness layer: BeamNet currently curates whatever the user selects, without regard to the reliability of that content. Given the growing literature on automated misinformation detection (Ebadi et al., 2022) and on personalized news recommendation more broadly (Ito et al., 2015), a natural next step would be to layer a fact-checking or stance-detection component — of the kind demonstrated by Bahuleyan and Vechtomova (2017) for topic-independent rumor-stance classification — on top of the existing curation pipeline, so that personalization is not achieved at the expense of accuracy.
Figure 4. Flow of data through the BeamNet system, tracing a single piece of content from initial source scraping through to notification delivery on the user's device. The diagram follows one item of tracked content step by step: extraction from the source website, pattern matching against the stored LCA rule, storage in the aggregation backend, and final delivery as a notification or feed entry. Arrows indicate the direction of data movement between each processing stage. This figure is more granular than the component-level view in Figure 3 and is intended to clarify the system's runtime behavior rather than its static architecture.
Figure 5. BeamNet source-creation and feed-assembly workflow, shown across four sequential app screens. (a) Content-selection interface (view 1): the embedded in-app web view a user navigates to locate and load a target website before selecting content to track. (b) Content-selection interface (view 2): once the page has loaded, candidate content elements are visually highlighted so the user can tap to select at least two items to track, without needing to understand the underlying HTML structure. (c) “Add Feed” interface: the user names a topic-based feed (here, “World News”) and attaches multiple previously confirmed sources to it, with the option to add further sites or remove existing ones before finalizing. (d) Aggregated feed view: the resulting feed interleaves headlines, source attribution, and short excerpts from all attached sources in a single chronologically ordered stream, rather than grouping content by site. Panels (a)-(b) support the per-source content-selection procedure described in Section 2.2, while panels (c)-(d) illustrate the multi-source feed-assembly and aggregation workflow discussed in Section 3.4.
