# DevLog: Display Book Details Before Add Confirmation (CLI UX Slice)

When you build a CLI, it’s dangerously easy to forget the most important UI rule:

**Users can’t confirm what they can’t see.**

In Bibby, my book import flow (`book new --scan`) was doing the right work under the hood—fetching metadata from the ISBN—but the user experience was basically: “trust me bro.”

## The problem: confirmation without context

Here’s what the scan flow looked like:

```python
? ISBN Number: 9781492078005
? Would you like to add this book to the library?
```

That prompt is polite… but also kind of absurd.

As a user, I don’t want to confirm adding an *ISBN string*. I want to confirm I’m adding **the correct book**—title, author(s), publisher, and anything else that helps me catch mistakes *before* the system creates records.

The metadata was already being fetched successfully (I could see it in logs), but in the “logs off” experience, the user never saw it. That gap was pure UX friction.

## The user story that drove the slice

> As a user scanning a book, I want to see the book's details (title, authors, publisher, ISBN) before confirming addition, so that I can verify I'm adding the correct book.

Simple. Human. Unarguable.

## The fix: a preview card between input and confirmation

The solution was a presentation-only change: **render a formatted “book preview card” after ISBN entry and before the confirmation prompt.**

Now the flow becomes:

```yaml
? ISBN Number: 9781098110338

┌──────────────────────────────────────────────────────────────┐
│ 📖 Learning TypeScript                                       │
│                                                              │
│ ISBN: 9781098110338                                          │
│ Author: [Josh Goldberg]                                      │
│ Publisher: O'Reilly Media                                    │
│                                                              │
│ Bookcase: PENDING / NOT SET                                  │
│ Shelf: PENDING / NOT SET                                     │
└──────────────────────────────────────────────────────────────┘

? Would you like to add this book to the library?
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1766074598524/7253c69f-3602-4cc2-8d7f-fe5ea8d6fa35.png align="center")

That one change turns the prompt from “take a leap of faith” into “verify and proceed.”

## What I *didn’t* change (on purpose)

This slice stayed intentionally narrow:

* **In scope:** formatting + displaying the existing `BookMetaDataResponse` in the CLI layer
    
* **Out of scope:** changing fetch logic, adding error handling, expanding fields like edition/description (kept existing behavior)
    

This was a “move pixels, not plumbing” kind of commit.

## Data flow: same pipeline, better moment of truth

Nothing about the underlying workflow changed—just the point where the user is given the information:

```yaml
ISBN input
  ↓
BookFacade.findBookMetaDataByIsbn(isbn)
  ↓
BookMetaDataResponse
  ↓
Format card for display  ← NEW
  ↓
Confirmation prompt
  ↓
BookFacade.createBookFromMetaData(...)
```

The system already had the knowledge. The user didn’t. Now they do.

## Terminal UI: the weird little dragons

CLI UI looks simple until it isn’t.

After implementing the card, I noticed occasional alignment artifacts—like a stray vertical line fragment on the right edge in certain rows. The most likely culprits:

* **Emoji width lies** (📖 often renders as 2 columns visually, even though it’s “1 character” in a string)
    
* **ANSI color codes** (if you count them in padding math, your box gets haunted)
    
* **Variable content length** (long titles/publishers can overflow a fixed-width layout)
    

Mitigations I’m considering:

* compute **display width** (not string length)
    
* strip ANSI codes before padding
    
* enforce max width + truncate with ellipsis
    

Classic “terminals are not a UI toolkit, they’re a negotiated settlement.”

## Testing: manual, but targeted

I validated the experience with a few real-world scenarios:

* short titles
    
* multiple authors
    
* long publisher names like `NO STARCH PRESS, INC`
    
* preview card appears before confirmation
    
* still need to test very long titles for truncation behavior
    

Nothing fancy—just checking the moments where the UI could betray the user.

## Takeaways

This slice was small, but it’s the kind of small that matters:

* It improved trust in the workflow without touching domain logic.
    
* It exposed a reusable UI pattern (a “terminal card” component).
    
* It reminded me that terminal UX has its own physics: emoji width, ANSI codes, and padding math all want to fight you.
    

Most importantly: **confirmation prompts should never ask users to guess.**