---
title: 'TextOnly: Unified Mobile Text Portal'
url: https://www.emergentmind.com/topics/textonly
type: topic
---

# TextOnly: Unified Mobile Text Portal

Searching arXiv for the target paper and closely related text-only systems to ground the article.
TextOnly is a unified function portal for text-related functions on smartphones that enables access to functions from various applications by simply inputting text into a sole text box [2508.16926]. The system is designed around the observation that text boxes serve as portals to diverse functionalities in contemporary mobile interfaces, yet particular functions typically require navigation through multiple steps before a relevant input field becomes available. TextOnly addresses this by combining large language models and a BERT model: the LLM provides general knowledge, while the BERT model continuously learns user-specific preferences and enables quicker predictions [2508.16926]. In the reported real-world study, TextOnly achieved a top-1 accuracy of 71.35%, improved both its accuracy and inference speed over time, and was preferred over manual executions by participants [2508.16926].

## 1. Definition and interaction model

TextOnly is defined as a unified function portal in which a single text box mediates access to text-related functions across applications [2508.16926]. Its operating premise is that short raw text inputs can contain sufficiently rich information to infer user intent, even when the intended destination function belongs to a different application than the current interface [2508.16926]. The examples given are direct and function-level: entering a restaurant name could trigger a Google Maps search, while a greeting could initiate a conversation in WhatsApp [2508.16926].

The interaction model is centered on a floating trigger, implemented as a ball or gesture, that brings up the unified text box [2508.16926]. Users type exactly the text they would have typed into their target app, and the system interprets that text as a query over a finite set of supported text-related functions [2508.16926]. In formal terms, intent classification is posed as learning
$$
f: X \to Y
$$
where $X \subset \Sigma^*$ is the set of raw text inputs and $Y=\{f_1,\dots,f_N\}$ is the finite set of supported text-related functions [2508.16926]. The target prediction is
$$
y^* = \arg\max_{y\in Y} P(y\mid q).
$$

This formulation places TextOnly at function granularity rather than app granularity [2508.16926]. A plausible implication is that the system is not merely selecting an application, but attempting to identify a specific in-app action reachable from typed text alone.

## 2. System architecture and processing pipeline

The high-level architecture consists of six main components arranged as a left-to-right flow: Input Interface, Preprocessing, Inference Fusion, LLM Module, BERT Personalization Module, and Action Dispatcher [2508.16926]. The preprocessing stage tokenizes raw text $q$, encodes it via BERT into $\phi(q)$, retrieves contextual features, and concatenates them into a joint representation:
$$
\mathbf{v} = \phi(q)\;\oplus\;\mathbf{v}_{app\_usage}\;\oplus\;\mathbf{v}_{time}.
$$
The contextual features explicitly include a recent app-usage embedding $\mathbf{v}_{app\_usage}$ and a time-of-day embedding $\mathbf{v}_{time}$ [2508.16926].

The LLM module queries GPT-3.5 Turbo via API and returns a probability distribution $P_{\mathrm{LLM}}(y\mid q)$ over candidate functions [2508.16926]. In parallel, the BERT personalization module maintains per-user history $H$ and computes a fast local prediction from similar past queries [2508.16926]. The action dispatcher then presents the top-5 candidates in a scrollable list; upon user tap, it executes the chosen function via RPA and fills the text box in the target app [2508.16926].

This architecture combines remote semantic inference with local adaptation. The paper states that the LLM consistently provides general knowledge, while the BERT model continuously learns user-specific preferences and enables quicker predictions [2508.16926]. This suggests a division of labor in which cold-start generalization and long-term personalization are handled by different components under a unified inference interface.

## 3. Intent recognition, fusion, and personalization

Intent recognition in TextOnly is implemented through a fusion of two estimators [2508.16926]. On the local side, the BERT module searches the user history for the top $K$ most similar past queries using cosine similarity:
$$
\mathrm{sim}(\mathbf{v},\mathbf{v}_i)\;=\;\max\{\cos(\mathbf{v},\mathbf{v}_i)\times\alpha_{user},\,1\}.
$$
It then aggregates their labels into a prediction:
$$
\mathrm{Prediction}_{\mathrm{BERT}}(q)
=\frac{\sum_{i=1}^K \mathrm{Label}_{k_i}\,\mathrm{sim}(q,q_{k_i})}
{\sum_{i=1}^K \mathrm{sim}(q,q_{k_i})}.
$$
A confidence score is computed as
$$
v_{\mathrm{conf}}
= \frac{\sum_{i=1}^K \mathrm{sim}(q,q_{k_i})\,(K-i+1)}{\sum_{i=1}^K i}.
$$
If $v_{\mathrm{conf}}>T$, the system uses the fast BERT-based prediction; otherwise it falls back to the LLM distribution [2508.16926].

The paper also presents a combined-probability formulation:
$$
P_{\mathrm{combined}}(y\mid q)
= \alpha\,P_{\mathrm{LLM}}(y\mid q)
+(1-\alpha)\,P_{\mathrm{BERT}}(y\mid q),
$$
where $\alpha\in[0,1]$ is adapted automatically by the confidence test [2508.16926]. In effect, the fusion mechanism arbitrates between a general-purpose inference source and a personalized retrieval/classification source.

Personalization is maintained through a lightweight classification head $W\in\mathbb{R}^{N\times d}$ on top of BERT’s $\phi(q)$ [2508.16926]. The output and loss are
$$
\hat{\mathbf{y}} = W\,\phi(q)\;+\;b,
$$
and
$$
\mathcal{L}_{\mathrm{CE}}
=-\sum_{i=1}^N y_i\,\log\bigl[\mathrm{softmax}(\hat{\mathbf{y}})\bigr]_i.
$$
After each interaction, the system records the chosen function and the LLM’s top-5, assigning labels $[0.8,\,0.07,\,0.06,\,0.04,\,0.03]$, then performs daily mini-batches retraining of $(W,b)$ with a small learning rate and L2 regularization on $W$ to mitigate catastrophic forgetting [2508.16926]. For cold-start, each new user’s BERT head is initialized with global data weighted by function frequency and by the user’s initial set size $(\alpha=10)$; for rare functions, examples are synthesized via LLM [2508.16926].

## 4. LLM prompting and action execution

The LLM subsystem uses GPT-3.5 Turbo, described as a 175 B-parameter model accessed via the OpenAI HTTP API, with no fine-tuning; all capability is injected via prompt [2508.16926]. Each prompt contains four parts: a task description, a candidate list of all apps and actions, few-shot examples, and the current input query [2508.16926]. The few-shot context comprises the $M=20$ most similar history entries from $H$, each represented as $(q_i,\text{context},y_i)$ [2508.16926]. The paper reports that omitting verbose function descriptions in the candidate list improves LLM accuracy [2508.16926].

Execution is delegated to the action dispatcher, which displays top-5 ranked candidate functions and triggers the selected function via RPA, for example future-scanner, filling the text box in the target app [2508.16926]. This makes the system operationally broader than a conventional search interface: the output is not just a ranked label, but an executable function invocation in another application.

The comparison drawn in the paper is specifically against manual executions and voice assistants [2508.16926]. Compared with voice assistants, TextOnly is reported to support a greater range of text-related functions and to allow more concise inputs [2508.16926]. A plausible implication is that the system leverages textual underspecification more efficiently than voice-based command interfaces, though the article’s concrete evidence remains the function-coverage and input-length measurements reported in the evaluation.

## 5. Evaluation methodology and empirical performance

The evaluation uses four primary metrics: Hit@1 (Top-1 Accuracy), Hit@5 (Top-5 Accuracy), MRR, and inference latency [2508.16926]. Hit@1 is defined as
$$
\mathrm{Acc}_{1}
= \frac{1}{N}\sum_{i=1}^N
\mathbf{1}\{\arg\max_y P(y|q_i)=y_i\}.
$$
Hit@5 is defined analogously using inclusion of the correct function in the top 5 [2508.16926].

The experimental setup comprises 22 users, 5,136 entries, and 275 distinct functions for data collection, and a real-world study with 16 users over 1 week, yielding 3,847 trials and 243 functions [2508.16926]. Hardware execution is split between Android phones locally and the remote GPT API; the reported average latency is 4.32 s for GPT API and 0.18 s for local BERT [2508.16926].

The principal comparative results are as follows [2508.16926]:

| Method | Hit@1 | Hit@5 | MRR |
|---|---:|---:|---:|
| MFU (baseline) | 0.308 | 0.701 | 0.473 |
| MRU (baseline) | 0.391 | 0.658 | 0.505 |
| Bayesian (ctx only) | 0.352 | 0.725 | 0.520 |
| LLM-only | 0.550 | 0.829 | 0.660 |
| BERT-only | 0.540 | 0.773 | 0.632 |
| TextOnly-general | 0.536 | 0.770 | 0.626 |
| TextOnly-no-ctx | 0.601 | 0.838 | 0.695 |
| **TextOnly (full)** | **0.696** | **0.866** | **0.765** |

The corresponding latencies are reported as 4.62 s for LLM-only, 0.04 s for BERT-only, 2.47 s for TextOnly-general, 1.64 s for TextOnly-no-ctx, and 1.90 s for TextOnly (full) [2508.16926]. The paper additionally states that on Day 1 Hit@1 is approximately 46.5%, reaching approximately 81.7% by Day 7, while latency falls from 2.73 s to 1.36 s as the BERT branch takes over more queries [2508.16926].

These measurements support two empirical claims made in the paper: first, that the hybrid architecture outperforms either LLM-only or BERT-only alternatives on accuracy; second, that continuous personalization shifts the operating point toward lower latency without sacrificing performance [2508.16926].

## 6. User studies, comparison with voice assistants, and limitations

The real-world study involved 16 users over 1 week, and users rated each trial’s satisfaction on a 1–5 scale with mean 4.26 and standard deviation 0.41 [2508.16926]. Reported qualitative comments include: “Its recommendations are quite accurate, and I can feel it adapting to my habits,” “I often use multiple apps to search for the same content, and this seems to confuse the system,” and “I prefer TextOnly when the phone is locked or on the home screen” [2508.16926]. The paper states that even incorrect predictions did not erode users’ confidence, and that some users altered their input style over time, for example by using fewer stop-words, to improve disambiguation [2508.16926].

A controlled lab study with 12 users examined chat intent and compared TextOnly to a built-in text portal and a built-in voice assistant [2508.16926]. The reported results are:

| Tool | % Functions Covered | Input Length (words) |
|---|---:|---:|
| TextOnly | 100 % | 5.20 |
| Built-in Text Portal | 52.6 % | 5.20 |
| Built-in Voice Assistant | 66.2 % | 11.69 |

Satisfaction is reported as 4.20 for TextOnly and 2.86 for the built-in text portal [2508.16926]. The paper concludes from these results that TextOnly covers all target functions via RPA and requires on average half the words of voice input [2508.16926].

The stated limitations concern latency, coverage, onboarding, and dependence on LLM quality [2508.16926]. Reliance on a remote LLM introduces network delay; functions requiring extra parameters, such as pickers and multi-field forms, are not yet supported; users must record RPA scripts to add new functions; and cold-start behavior depends on the quality of GPT-3.5 [2508.16926]. Proposed future directions are to integrate a lightweight offline LLM or distill GPT to on-device models, dynamically scrape on-screen text boxes and extend the candidate set, share a community repository of scripts, and develop automated demo recording [2508.16926].

Within the scope reported, TextOnly is presented as a text-only NLI for function-level access on smartphones that combines LLM generality with fast, personalized BERT predictions to deliver both accuracy and low latency [2508.16926]. This suggests a broader design pattern for mobile interaction in which typed text is treated not merely as content entry but as an interface primitive for cross-application action selection.

Source: https://www.emergentmind.com/topics/textonly