UI sketch for search, filters and detail view

[erikhfj]

What this is

The M1 deliverable that a peer reviewer reads to understand our idea before any backend exists. Lightweight by design. Not a Figma project.

The first interim asks for a "spesifikasjon eller utkast til systemet med mockup-data eller statiske eksempeldata" such that "medstudenter skal kunne sette seg inn i hvilke data dere har tenkt å bruke, hvordan applikasjonen er tenkt utformet mtp visning av data, interaksjon med resultatet etc."

That is three things, and none of them needs a design tool.

What to deliver

1. Static example data. A handful of hardcoded albums (say 5 to 8) in a markdown table or a tiny HTML file, showing exactly the fields the app will display: title, artist, year, genres, community rating, review count. This is the "statiske eksempeldata" the brief mentions. Put it in the issue body or in docs/mockup-data.md.

2. Interaction notes. Half a page covering what happens when a user:

• types a search and submits (button and Enter)
• changes a genre or decade filter
• changes the sort order
• scrolls or clicks "load more"
• opens an album detail page

3. The empty result state. This is the one that matters most and the one we are most likely to get wrong. The lecture calls out "ikke la brukere ende opp med null i resultatsettet" as a known pitfall. Our answer is facet counts: every filter option shows how many albums it would return before you click it, and options that would match zero are hidden rather than left visible and dead.

A pencil sketch, ASCII wireframe, or a screenshot of a rough HTML mockup all count. Keep it to about 30 to 45 minutes.

Scope note (why this is not a Figma task)

Robert asked whether a separate Figma issue was necessary. It is not, and this issue is not asking for one. It is asking for enough written and visual description that the next person can picture the app. #9 in M2 is where the real client gets built against the live API.

Acceptance

• 5 to 8 static example albums with the fields the UI will show
• interaction notes covering search, filter, sort, paging and detail
• the empty result state described, with the facet-count answer written down
• a sketch or wireframe of the search page (paper, ASCII, or a rough HTML screenshot)
• linked from docs/architecture.md or the README so reviewers find it

[erikhfj]

Robert asked whether a separate Figma issue is really necessary, and that is a fair point. This issue is already worded as "paper, Figma, or ASCII", so Figma is not required.

Proposal: fold this into #9. The mock client we are building anyway is the mockup. It shows the data, the layout and the interaction. All that is left is half a page in the issue (or in the PR) covering:

• interaction notes: what happens when you search, scroll, or open a detail page
• the empty result state: "do not let users filter themselves into an empty result set". Our answer is facet counts that show what each filter would return before you click it.

That removes Figma entirely and gives Rachel one thing to own instead of two.

I am leaving this open until someone says yes. Speak up if you would rather keep a separate light sketch.

[erikhfj]

Good catch, and sorry for the confusion. You are right on both counts.

What "one thing instead of two" meant: when I wrote that comment I still thought you had both #29 and #9 in M1. I proposed folding #29 into #9 so you would own a single task instead of two overlapping ones. Then #9 moved to M2, which makes the proposal nonsense: folding #29 away would leave you with no M1 task at all. I had not re-checked the milestone before commenting. That is my mistake.

Retracted. #29 stays in M1 as its own issue, and it is yours.

What it is now (rewritten above): a lightweight spec-and-mockup deliverable, roughly 30 to 45 minutes. Not a Figma project. Three pieces:

1. Static example data. Five to eight hardcoded albums showing the fields the UI will display. This is the "statiske eksempeldata" the first interim asks for. A markdown table is fine.
2. Interaction notes. Half a page on what happens when you search, filter, sort, page, or open a detail view.
3. The empty result state. The one we are most likely to get wrong. The lecture calls out "ikke la brukere ende opp med null i resultatsettet", and our answer is facet counts: each filter shows how many albums it would return before you click, and options that would match zero are hidden rather than left dead on the page.

A pencil sketch, ASCII wireframe, or a screenshot of a rough HTML mockup all count for the visual part.

On Robert's Figma point: he is right that we do not need a Figma deliverable, and this issue does not ask for one. It asks for enough description that a peer reviewer can picture the app before the backend exists. #9 in M2 is where the real client gets built.

I have also set the assignee to just you, since Even has #3 (ADRs) in M1 and this is the UI and interaction side.