Command Palette

Search for a command to run...

Hectal
Phase 10Intermediate11 of 16 in AI Frontend

AI Product UX

The details that make an AI feature feel good: waiting well, honest labels, feedback, a first screen, a real input box, screen readers, phones and other languages.

Phases 5 to 9 made Mitra work: it streams, renders safely, uses tools and resists hostile input. This phase makes it pleasant and fair to use. Most of what separates a demo from a product is not the model. It is what the screen does in the first second, what it says when it is unsure, what happens when someone presses Enter in the middle of a Japanese word, and whether a person using a screen reader hears a clear sentence or a hundred fragments.

Every topic here is about a behaviour you can check. So the live examples do not ask you to "feel" anything. They log decisions and counts: how many times a live region changed, where keyboard focus is, whether Enter sent the message, whether a draft came back. Things that depend on screen size (pixels, keyboard height) are turned into yes-or-no decisions so they are the same on every machine.

Accessibility claims in this phase were checked against the W3C WAI and MDN pages. Where behaviour differs between screen readers and browsers, the text says so instead of promising one result. You finish with Mitra v10: starters on an empty chat, a real input box, feedback buttons, and an announcement pattern that does not flood a screen reader.

0/8 · 0%
8 topics ~4 h 25 code blocks & diagrams
Start with the first topic
1
10.1

Perceived Speed

How fast an AI feature feels depends on what the screen does while it waits: nothing for the first fraction of a second, a quiet sign of life next, real words about real progress after that, and a way to stop when it is slow.

29 min 3 code practice

2
10.2

Showing Uncertainty Honestly

A model gives no reliable measure of how sure it is, so the screen must tell the truth in other ways: say the text is AI-written, show the sources it rests on, say when there are none, note how an answer ended, and ask for a check only where a mistake costs something.

26 min 3 code practice

3
10.3

Feedback and Recovery

Give users ways to react to an answer: thumbs with a reason, regenerate, edit their question, report a problem. Each action has a precise effect on the message list and on the server, and feedback only helps if you store it carefully and read it honestly.

28 min 3 code practice

4
10.4

Empty States and Suggested Prompts

An empty chat with only a text box leaves people unsure what to ask. A good first screen says what the assistant can and cannot do, offers a few real starter questions that send exactly once, and handles the first visit without breaking when browser storage is blocked.

26 min 2 code practice

5
10.5

The Prompt Input

The prompt box looks like a text field and behaves like a small editor: it grows, sends on Enter but not on Shift+Enter, must not send while an input method is composing a word, must cope with a huge paste, shows limits honestly, keeps its draft, and stays usable while an answer streams.

35 min 4 code practice

6
10.6

Accessibility for Streaming UI

A streaming answer changes the page many times a second. Used carelessly it floods a screen reader with fragments. This topic shows how to announce a stream once or twice, keep keyboard focus where the person expects it, make every control reachable, respect reduced motion and keep code readable.

34 min 4 code practice

7
10.7

Mobile, RTL and Languages

Most people meet your assistant on a phone, in many languages. This topic covers long words that break narrow layouts, text that runs right to left, an on-screen keyboard that hides the input box, and system messages that need translation and correct plural forms.

33 min 4 code practice

8
10.8

Build: Mitra Feels Good to Use

Mitra gets starters on an empty chat, a proper prompt box (Enter, Shift+Enter, IME, growth, limit, give-back on failure), thumbs feedback on finished answers, and an announcement pattern that a screen reader can follow. All of it is checked with scripted events.

35 min 2 code practice

Practise this phase

Hands-on exercises: write the code, see your page live, and press Check to have it tested automatically.

1

A Starter That Sends Once

The page shows two starter buttons inside #starters. Each button carries its question in data-prompt. When a starter is clicked, send that question to /api/ask with POST and a JSON body { "question": … }, read the streamed reply and add each piece to #answer.

Beginner
2

Enter Sends, Shift+Enter Does Not

#prompt is a textarea and #sent is a list. Pressing Enter must add the trimmed text as a new <li> in #sent, empty the box and stop the browser from inserting a line break (preventDefault).

Beginner
3

Announce a Stream Once

#ask starts a streamed answer into #log. Make the page screen-reader friendly. #log must have role="log" and an aria-label. While the answer streams it must have aria-busy="true", and when the stream ends aria-busy="false".

Intermediate
4

Keep the Draft

Save what the person types in #prompt under the localStorage key mitra-draft on every change. When the page starts (and when #reload is clicked, which pretends the tab was reopened), put the saved text back in the box.

Intermediate
5

Good Answer, Bad Answer

Under a finished answer there are two toggle buttons, #up ("Good answer") and #down ("Bad answer"). Clicking one sends POST /api/feedback with { "rating": "up" } or { "rating": "down" }.

Intermediate