TextOnly: Unified Mobile Text Portal

• The paper demonstrates that TextOnly achieves a top-1 accuracy of 69.6% by fusing LLM generalization with BERT personalization for efficient cross-app function invocation.
• The system architecture integrates remote semantic inference with local adaptation, enabling quick predictions and continuous improvement through user-specific training.
• Empirical results indicate that TextOnly outperforms manual and voice-based approaches by reducing input length and latency while increasing function coverage and user satisfaction.

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 (Tu et al., 23 Aug 2025). 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 LLMs and a BERT model: the LLM provides general knowledge, while the BERT model continuously learns user-specific preferences and enables quicker predictions (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025).

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 (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025).

The interaction model is centered on a floating trigger, implemented as a ball or gesture, that brings up the unified text box (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025). 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}$ (Tu et al., 23 Aug 2025).

The LLM module queries GPT-3.5 Turbo via API and returns a probability distribution $P_{\mathrm{LLM}}(y\mid q)$ over candidate functions (Tu et al., 23 Aug 2025). In parallel, the BERT personalization module maintains per-user history $X \subset \Sigma^*$0 and computes a fast local prediction from similar past queries (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025).

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 (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025). On the local side, the BERT module searches the user history for the top $X \subset \Sigma^*$1 most similar past queries using cosine similarity:

$X \subset \Sigma^*$2

It then aggregates their labels into a prediction:

$X \subset \Sigma^*$3

A confidence score is computed as

$X \subset \Sigma^*$4

If $X \subset \Sigma^*$5, the system uses the fast BERT-based prediction; otherwise it falls back to the LLM distribution (Tu et al., 23 Aug 2025).

The paper also presents a combined-probability formulation:

$X \subset \Sigma^*$6

where $X \subset \Sigma^*$7 is adapted automatically by the confidence test (Tu et al., 23 Aug 2025). 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 $X \subset \Sigma^*$8 on top of BERT’s $X \subset \Sigma^*$9 (Tu et al., 23 Aug 2025). The output and loss are

$Y=\{f_1,\dots,f_N\}$0

and

$Y=\{f_1,\dots,f_N\}$1

After each interaction, the system records the chosen function and the LLM’s top-5, assigning labels $Y=\{f_1,\dots,f_N\}$2, then performs daily mini-batches retraining of $Y=\{f_1,\dots,f_N\}$3 with a small learning rate and L2 regularization on $Y=\{f_1,\dots,f_N\}$4 to mitigate catastrophic forgetting (Tu et al., 23 Aug 2025). 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 $Y=\{f_1,\dots,f_N\}$5; for rare functions, examples are synthesized via LLM (Tu et al., 23 Aug 2025).

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 (Tu et al., 23 Aug 2025). Each prompt contains four parts: a task description, a candidate list of all apps and actions, few-shot examples, and the current input query (Tu et al., 23 Aug 2025). The few-shot context comprises the $Y=\{f_1,\dots,f_N\}$6 most similar history entries from $Y=\{f_1,\dots,f_N\}$7, each represented as $Y=\{f_1,\dots,f_N\}$8 (Tu et al., 23 Aug 2025). The paper reports that omitting verbose function descriptions in the candidate list improves LLM accuracy (Tu et al., 23 Aug 2025).

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 (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025). Compared with voice assistants, TextOnly is reported to support a greater range of text-related functions and to allow more concise inputs (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025). Hit@1 is defined as

$Y=\{f_1,\dots,f_N\}$9

Hit@5 is defined analogously using inclusion of the correct function in the top 5 (Tu et al., 23 Aug 2025).

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 (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025).

The principal comparative results are as follows (Tu et al., 23 Aug 2025):

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) (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025).

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 (Tu et al., 23 Aug 2025).

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 (Tu et al., 23 Aug 2025). 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” (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025).

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 (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025). The paper concludes from these results that TextOnly covers all target functions via RPA and requires on average half the words of voice input (Tu et al., 23 Aug 2025).

The stated limitations concern latency, coverage, onboarding, and dependence on LLM quality (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025). 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 (Tu et al., 23 Aug 2025).

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 (Tu et al., 23 Aug 2025). 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.