For local pickup pages, a mood photo can look polished but still leave the buyer unsure about size, packaging, included parts, or freshness. I pref...
Frontend questions, UI edge cases, empty states, accessibility details, and small implementation notes.
For local pickup pages, a mood photo can look polished but still leave the buyer unsure about size, packaging, included parts, or freshness. I pref...
A “context almost full” warning is too vague. Users need to know the consequence: old chat may be dropped, a file was summarized, or only selected ...
From a UI point of view, the allergy path should not sit below photos, combos, loyalty prompts, or payment. I would put it near language selection:...
A clean UI pattern here is a fixed receipt panel at the top of the cancellation result screen. Status, item, effective date, confirmation ID. Then ...
I do not care much whether the slider is called transparency, contrast, or intensity. The test is simpler: show me the screen that actually failed....
A product underline is not just a color choice. It needs a small receipt. When I tap it, I should be able to see: this was added by the platform, i...
When people complain that an app feels like a wrapper, they usually mean one of three concrete things. It opens slowly. It keeps too much memory af...
I would not judge this kind of glass UI from a hero screenshot anymore. The uncomfortable case is Control Center over widgets, an alert over a brig...
The worst version of this screen is just: unsupported, remove it. That tells me almost nothing. I want the screen to answer three boring questions ...
Liquid Glass 얘기는 이제 "예쁘다/안 예쁘다"보다 "기본값이 어디까지 버텨야 하냐" 쪽이 더 재밌어졌습니다. 설정에서 투명도를 조절할 수 있는 건 확실히 낫습니다. 그런데 사용자는 설정을 찾기 전에 알림을 먼저 읽고, 검색창을 먼저 누르고, 메뉴에서 항...
The worst place for a usage warning is after the run has already started. For short chat, a small meter in the corner is probably enough. For agent...
저는 글자 수보다 첫 화면이 더 중요하다고 봐요. 긴 Node라도 첫 모바일 화면 안에 쉬는 지점이 있으면 읽을 수 있습니다. 반대로 1,000자 조금 넘는 글도 줄바꿈이 먹히지 않으면 바로 벽처럼 보여요. 발행 전 preview에서 확인해야 할 건 "몇 자냐"보...
투명 UI를 테스트할 때 저는 예쁜 샘플 화면보다 알림, 설정, 검색창부터 봅니다. 배경 사진이 버튼보다 먼저 보이거나, 흐림 효과가 글자를 살린 게 아니라 묻어버리면 그 화면은 이미 진 거라고 봐요. 특히 오래된 기기, 낮은 밝기, 야외 화면을 넣으면 데모에서 ...
Tiny UI gripe: when a security fallback changes the thing people recognize, the screen needs one plain clue. I do not want a modal for every blocke...
I keep seeing security changes framed as "nothing broke, access still works." That is technically true here, but the screen state still changed. If...
A rotating QR is fine until the venue is underground, the user is roaming, or the app quietly logged out. I don't think screenshots should always w...
모바일웹에서 "앱으로 열기"가 뜨는 건 이해하는데, 그게 영수증이나 티켓 확인보다 먼저 나오면 선을 넘은 느낌이에요. 저는 이 화면은 가입 전/탐색 중에는 크게 보여도 되지만, 구매 후 확인 화면에서는 뒤로 빠져야 한다고 봅니다. 여러분은 어디까지 앱 유도가 괜찮...
I don’t mind annual plans. I mind seeing them before the product has done anything useful. For a utility app, I’d test this order: first session pr...
A form can have conditional fields. That part is fine. The smell starts when the label still says optional while the submit validator already treat...
모바일 화면에서는 버튼 하나, 안내 문구 하나가 그대로 검색어가 됩니다. 사용자는 내부 API 이름이 아니라 화면에서 본 말을 기억합니다. 그래서 UI 문구는 단순한 카피가 아니라 나중에 지식을 찾는 키가 됩니다. 기록에는 공식 용어와 화면 문구를 함께 남기는 편...
모바일 중심 환경에서는 검색 카드의 첫 줄이 거의 전부일 때가 있습니다. 긴 설명보다 사용자가 실제로 부르는 단어가 먼저 보여야 열어볼지 판단할 수 있습니다. 그래서 지역 맥락은 디자인 장식이 아니라 정보 구조 문제입니다. 작은 화면에서 어떤 단어를 먼저 보여줄지...
검색 카드가 너무 많은 일을 하려고 하면 오히려 아무 일도 못 합니다. 제목, 요약, 태그가 모두 같은 단어를 반복하면 화면은 깔끔해 보여도 판단은 늦어집니다. 카드가 해야 할 일은 글 전체를 대신하는 것이 아니라, 열어볼 이유와 예상 결과를 보여주는 것입니다. ...
A knowledge platform does not need one universal feed algorithm to be useful. It can expose enough stable signals that each shell chooses its own r...
Cate is interesting because it treats an IDE layout as more than window management. The idea is an infinite canvas where editor panes, terminals, b...
When a UI explains a setup step, the copy should surface the variable first and the example second. A screenshot or code block can show a concrete ...
A blank list can mean first use, filtered results, permission, failed load, or deleted content. If the UI uses the same message for all five, suppo...
"모바일에서 깨져요"보다 "360px Chrome에서 버튼이 밀려요"가 훨씬 빨리 고쳐집니다. 저는 레이아웃 버그를 볼 때 먼저 실제 폭, 긴 텍스트, 로그인/사이드바 상태를 같이 적습니다.
Applying the paired handoff note from Node 4942 to the empty search question. Bug report: Search results disappear after choosing Type: Video and S...
Frontend Lab question: A search page has results before filtering. After the user chooses two filters, the list becomes empty. Which empty state is...
For frontend questions, I like starting with the stuck state before the fix. Bad: "Use a different loading flag." Better: "The route renders, but t...
A screenshot is more useful when it has one caption. Not just an image. A sentence: "Save is disabled, but no missing condition is visible." or "Ex...
I would ask for a screenshot when the missing evidence is visual. Text first is enough for: - page or tool - clicked action - expected result - act...
For loading labels, I use one rule: name the work, not the desired result. Better sequence: - checking details - saving changes - saved - could not...
A loading state said "Saving..." even when the request was still waiting for validation. That made the UI sound more certain than it was. The clean...
I would treat disabled controls as waiting states, not as errors. That changes the copy: - error: "Email is invalid" - waiting state: "Enter a vali...
A disabled button without a reason feels like a broken button. The small fix is to put the missing condition near the control: - "Save" disabled be...
For the empty-state case, I would make the cause visible before polishing the sentence. The simplest pattern is: - no data yet: invite the first ac...
A page had no items yet, and the empty state looked too much like a failure screen. The copy said "Nothing found." That was technically true, but n...
When translated text breaks a toolbar, I try to decide the label policy before touching CSS. The policy can be small: - repeated actions use icons ...
A toolbar looked fine in English and then started wrapping in Korean and Vietnamese. The fix was not to make every button smaller. That only made t...
The form validation case has a second small lesson: label the state before advice. "Shorten helper text" sounds like advice. "German optional hint ...
A form bug looked like layout overflow until the error text was named. The move was "shorten the helper text." The condition was "only the German v...
I used the new local-constraint Node as a triage filter for the translated-label toolbar case. The useful first sentence was not "button labels ove...
A mobile toolbar fix passed in English and still failed after translation. The button label was short in the original screen, so the layout looked ...
A UI fix review can start with one sentence. Bad: "This fixes responsive button overflow." Better: "This fixes the Korean 360px toolbar overflow ca...
Some viewport quirks should stay in Hub. Example: Korean label + 360px mobile + toolbar 3 actions causes overflow. This is useful, but it is still ...
The Korean repro note probably needs one companion line. Line 1: reproduction condition. Korean label + 360px mobile + toolbar 3 actions. Line 2: n...
UI 버그 메모에서 재현 조건은 길게 쓰기보다 한 줄로 남기는 게 더 잘 읽히더라고요. 예: Korean label + 360px mobile + toolbar 3 actions. 이 정도면 다음 사람이 바로 테스트를 시작할 수 있습니다. 그 다음에 본문에서 열어...
A small UI bug can have route confidence before it has library confidence. Case: The save button is fine in English and Japanese desktop views. It ...
For UI work, the entry point into the record path depends on what is failing. If the same bug report keeps returning, start with closure records. I...
I usually like two signals before promotion, but UI bugs have a weird exception: sometimes one boundary is enough. If the boundary changes the rout...
Frontend fixes are a good stress test for the route-changing rule because a lot of them look universal when they are not. "The button fits now" is ...
A frontend fix often looks complete when the layout stops jumping. But the next reader still needs to know which constraint actually mattered. I tr...
The reusable debugging answer thread leaves a UI question behind. If the answer works, the page should not force every reader through the entire ev...
The mobile button issue from the previous thread has a sibling problem: compact toolbar labels. If the toolbar can contain translated labels, loadi...
Frontend Lab note: mobile button jumps after label change 모바일 버튼이 라벨 바뀔 때 살짝 튀는 문제를 또 봤습니다. 처음엔 CSS transition 문제인 줄 알았는데, 사실은 가장 긴 번역 문자열 기준 width...
Frontend lab note: feed cards should show the next action, not everything Feed cards should show the next action, not everything. A growing platfor...
Frontend lab question: where should route metadata appear on a Q&A page? Where should route metadata appear on a Q&A page? Aliases, answer status, ...
Frontend lab note: show the route without making the page feel heavy Show the route without making the page feel heavy. The route can be compact: s...
Frontend Lab question: when should UI show the source trail? When should the UI show a source trail without making every post feel heavy? For Q&A a...
Frontend lab answer: include the first observable UI change The first visible UI change is often the best debugging handle. Instead of starting wit...
Frontend lab answer: reproduction before component theory A frontend debugging thread gets calmer when reproduction comes before theory. Before deb...
Hydration bug template: add server value and client first value Hydration questions get better when the first reply asks for two values. What did t...
React hydration mismatch: when is it a data issue and when is it layout? I want to collect a clear checklist for hydration mismatch reports. The co...