Content-Driven Local Response: Supporting Sentence-Level and Message-Level Mobile Email Replies With and Without AI

TL;DR

The paper introduces Content-Driven Local Response (CDLR), a mobile email UI that embeds sentence-level local replies within the incoming email and allows optional AI-based refinements at both sentence- and message-level scopes. Through iterative prototyping and a rigorous within-subject study (N=126), the authors show CDLR supports flexible workflows between manual, sentence-level suggestions, and full-message AI generation, while maintaining user control. CDLR yields faster task completion than manual drafting and reduces typing and error rates, yet preserves content diversity and perceived quality; its key strength lies in giving users nuanced control over AI involvement and enabling decision moments within the reading and drafting process. The work demonstrates that rethinking AI integration UI—rather than adding AI

Abstract

Mobile emailing demands efficiency in diverse situations, which motivates the use of AI. However, generated text does not always reflect how people want to respond. This challenges users with AI involvement tradeoffs not yet considered in email UIs. We address this with a new UI concept called Content-Driven Local Response (CDLR), inspired by microtasking. This allows users to insert responses into the email by selecting sentences, which additionally serves to guide AI suggestions. The concept supports combining AI for local suggestions and message-level improvements. Our user study (N=126) compared CDLR with manual typing and full reply generation. We found that CDLR supports flexible workflows with varying degrees of AI involvement, while retaining the benefits of reduced typing and errors. This work contributes a new approach to integrating AI capabilities: By redesigning the UI for workflows with and without AI, we can empower users to dynamically adjust AI involvement.

Figures (13)

• Figure 1: A commonly used UI and interaction design for reply generation in mobile email apps: (A) Users work with AI in a pop-up, (B) on top of the empty draft view. (C) They can enter a prompt, (D) view the generated reply, and (E) accept it with a button. At the time of writing this paper, this pattern appears across Gmail (left), Superhuman (centre), and Outlook (right). It also appears in other email apps, such as Shortwave. Screenshots from: Google's website google2024geminiwebsite, Superhuman's YouTube channel superhuman2024video, The Copilot Connection's YouTube channel copilotconnection2023video.
• Figure 2: Replying to an email with our first prototype: (1) In the first screen, users insert responses directly while reading the email. Tapping on a sentence opens a response widget, with a text box where users enter a response or a prompt that affects the sentence suggestions below. (2) After adding local responses, users can edit their reply on a second screen, by reordering paragraphs via drag-and-drop, by deleting paragraphs via swiping left-to-right, and by manual editing via the integrated keyboard. (3) On the third screen, users can finalise the reply before sending it.
• Figure 3: The text suggestions in the local response widget are flexible: (A) Users get suggestions without any input. (B)Suggestions can be adapted and refined by entering text, for example keywords or a draft snippet. In all cases, suggestions are generated with an LLM based on the text of the incoming email and all local responses that the user has entered so far, even if responses have been added to later parts of the email first. In (C), for example, the suggested title of the idea pitch is generated based on the information about the project that the user has already entered in local responses below. Note that suggestions are paginated, with three pages of two suggestions each.
• Figure 4: Three measures of interaction behaviour: Task completion time (left), manual typing (centre), and writing speed (right). All AI features increased typing speed and reduced the time taken (both sig. for MSG). They also reduced the number of keystrokes (sig. for CDLR and MSG). If people made use of the optional improvement pass feature (impr.) in CDLR, this contributed to narrowing the gap between the otherwise sentence-level design of CDLR and the message-level design of MSG (sig. for manual typing and writing speed). See \ref{['sec:results_interaction_logs']} for details.
• Figure 5: Analysis of workflows with content-driven local response: Each point is one email and its position is the state of the drafting process at the moment when the user switched from the first screen (\ref{['fig:teaser']}.1) to the second (\ref{['fig:teaser']}.2). Concretely, the x-axis shows normalised time (0-100% ), i.e. temporal progression. The y-axis shows normalised length, i.e. draft progression. Note that y-values >100% are possible if an intermediate draft is longer than the final version. Colour and marker shape indicate if the improvement pass feature was used or not. The figure reveals three clusters: (1) Bottom left -- here, people skipped to the second screen and used the improvement pass feature to generate a draft. (2) Top right -- mostly drafting on the first screen, with light manual editing on the second. (3) In between -- partly drafting on the first screen and finalising it with AI on the second one.