Three ways to present tables on phones
A mobile table must preserve the comparisons and actions that matter. Compare horizontal scrolling, cards and summary-to-detail layouts before choosing a pattern.
Identify the comparison people need
Shrinking a desktop table can make both labels and values unreadable. Identify whether the task compares the same field across records, reads one record in depth or acts directly from a list.
Comparing stock quantities across products may need a different presentation from checking one order’s delivery details. List the essential comparison fields, fields suitable for details and the identifier that must remain visible.
Reducing visible columns should not remove access to required information. Define where omitted fields can be found and how filters and sorting survive that navigation.
Option one: horizontal scrolling for comparison
When cross-row comparison matters, retain the table and allow horizontal movement. Make the existence of additional columns discoverable and contain the scrolling region so the entire page does not shift unexpectedly.
Consider a persistent row identifier or header using realistic content. An overly wide pinned column can leave little space for the values being compared. Try long names, large numbers and missing values.
The W3C tables tutorial explains relationships between header and data cells. Preserve those relationships when adding a scrolling presentation.
Option two: cards for reading individual records
For reading one record at a time, cards can group its context. Put the title and status first, then show labeled values. Meaning previously supplied by table headers must remain available in the card.
Cards can make cross-record comparison more laborious, especially in a long collection. Do not assume they are universally better on mobile. Review whether sorting and filtering can reduce the work.
Resolve interaction between a clickable card and its inner actions. If details, selection and deletion are all available, make targets and keyboard order unambiguous so one action does not unexpectedly trigger another.
Option three: summaries with a reliable return path
If the list needs only a few decision fields, show a summary and provide details in another view or an expandable region. Keep an identifier, current status and the values needed for the initial decision.
Preserve sorting, filters, selection and position when returning from details. Otherwise people must find the same item again. Also define a return path for a detail view opened directly.
- Compare the three patterns with realistic record counts and long text.
- Exercise selection and editing as well as reading.
- Check narrow widths, enlarged text and keyboard use.
Choose by the task the screen supports instead of enforcing one mobile pattern everywhere.
ほかの記事
記事一覧へ-
운영 기능을 권한으로 나눌 때 먼저 정할 것
운영 화면을 함께 쓰더라도 데이터 접근은 분명하게 나눠야 합니다. 역할, 작업, 데이터 범위, 승인과 기록을 기준으로 권한을 설계하고 서버에서 검증하는 방법입니다.
-
Define permissions before combining admin workflows
A shared interface still needs explicit authorization. Define roles, actions, data scope and audit requirements, then enforce them on the server.
-
AI가 만든 기능을 검증하는 코코드의 방법
코드가 완성된 뒤에는 약속한 동작이 실제로 이어지는지 확인해야 합니다. 코코드는 단위 테스트로 개별 규칙을, BDD 통합테스트로 사용자 흐름을 검증하고, 변경 후에도 다시 확인할 수 있는 기준을 남깁니다.
働き方と福利厚生は採用ページでご覧いただけます。
採用情報を見る