UI 구조 표준

UI 구조 표준은(는) 무엇을 하나요?

인터페이스는 크기가 아니라 구조 때문에 사용하기 어려워집니다. 300개의 설정이 있는 앱도 쉽게 탐색할 수 있고, 30개만 있는 앱도 미로가 될 수 있습니다. 원인은 항상 동일한 몇 가지입니다: 동일한 컨트롤이 여러 곳에 존재함, 코드나 팀 구조를 반영한 메뉴, 환경설정과 동작이 혼재됨, 레이블이 없는 아이콘, 보이지 않는 범위, 그리고 아무것도 제거되지 않는 것입니다.

해결책은 이미 주요 플랫폼에서 사용하는 방식을 모든 앱에서 동일하게 적용하여 사람들이 이미 알고 있는 것을 사용할 수 있도록 하는 것입니다:

• 하나의 익숙한 레이아웃. 왼쪽에는 검색 가능한 카테고리 목록, 오른쪽에는 열린 페이지, 행은 왼쪽에 레이블, 오른쪽에 컨트롤이 배치됩니다.
• 하나의 카테고리 이름 세트. 계정, 알림, 개인정보 보호 및 보안, 접근성, 모양, 언어 및 지역, 데이터 및 저장소, 그리고 제품 고유의 주제입니다. 일곱 가지 질문으로 모든 설정을 정확히 하나의 카테고리에 배치할 수 있습니다.
• 더 적은 컨트롤. 가장 좋은 설정은 더 나은 기본값이 불필요하게 만든 설정입니다.
• 남은 각 컨트롤에 대한 하나의 홈. 모든 설정, 목적지 및 명령은 레지스트리의 레코드이며, 각 레코드는 정확히 하나의 홈을 가지며, 인터페이스는 레코드에서 그려집니다. 아무도 수동으로 컨트롤을 배치하지 않으면 구조가 표류할 수 없습니다.

작업 선택

이 표에서 요청을 찾고 해당 섹션과 명시된 파일만 읽으십시오.

요청	섹션	추가로 읽을 파일
"설정 / 메뉴 항목 / 버튼 추가"	컨트롤 하나 추가	대개 더 이상 없음
"이 UI는 엉망입니다", "이것을 검토하세요", "사용자가 항목을 찾을 수 없습니다"	기존 인터페이스 감사	references/audit.md, references/rules.md
"설정 화면, 사이드바 또는 툴바 구축 / 설계 / 재설계", 또는 하나로 만들어야 할 기능 목록	새로운 표면 구축	references/categories.md, references/visual-design.md, references/record-schema.md
"설정 구성", "어떤 카테고리를 가져야 하나요?"	표준 카테고리	references/categories.md
"우리 프로젝트에 설정"	레지스트리 도입	references/record-schema.md

어떤 작업이든, 현재 프로젝트를 존중하십시오. 코드베이스에 이미 설정 레지스트리, 컴포넌트 라이브러리 또는 마크업에 대한 자체 규칙이 있다면, 이를 확장하십시오. 병렬 시스템을 도입하지 마십시오. 이 표준은 기술이 아닌 구조를 설명합니다.

evals/ 폴더에는 이 스킬의 테스트 케이스가 있습니다. 참조 자료가 아니므로 작업을 수행하는 동안 읽지 마십시오.

컨트롤 하나 추가

다음 다섯 가지 질문을 순서대로 하고 첫 번째 '예'에서 멈추십시오. 사용자에게 결정과 이유를 알리십시오. 더 이상 적용되지 않는 질문을 안내하지 마십시오.

1. 더 나은 기본값이 불필요하게 만들 수 있습니까? 기본값을 변경하거나, 상황을 감지하거나, 사람들이 싫어하는 동작(아무도 필요로 하지 않는 확인, 자동 저장되는 항목에 대한 프롬프트)을 단순히 제거하여 모든 사람의 요구를 충족할 수 있다면, 그렇게 하십시오. 설정은 없습니다.
2. 시스템 또는 관리자가 이미 결정합니까? 테마, 텍스트 크기, 알림 권한 등은 하위 레이어에 속합니다. 이를 따르십시오. 제품이 자체 선택을 제공할 타당한 이유가 있다면, 그 선택에는 "시스템 설정 사용"이 포함되고 이것이 기본값입니다. 절대 단순한 켜기/끄기 스위치가 아닙니다.
3. 한 번만 수행되고 지속적인 선택이 아닙니까? 그렇다면 동작입니다: 토글과 분리된 버튼으로, 컨텍스트 내 또는 해당 페이지 하단의 레이블이 지정된 그룹에 배치됩니다.
4. 매주 이상 자주 변경됩니까? 그렇다면 컨트롤은 컨텍스트 내, 즉 변경하는 기능 옆에 있으며, 홈 페이지에 대한 링크가 함께 제공됩니다. 홈 페이지에는 여전히 나열됩니다.
5. 약 20명 중 1명 미만이 변경할 것입니까? 그렇다면 등급은 고급입니다. 세 개 이상의 고급 항목이 있는 페이지는 고급 접기 안에 표시합니다. 더 적다면 마지막에 배치된 일반 행입니다.

그렇지 않으면 해당 주제 페이지의 표준 행입니다.

질문 1 또는 2에 대한 답변이 '예'였다면, 명확하게 말하고 설정 대신 그 변경을 제안하십시오. 모든 설정은 테스트, 지원 및 다른 사람들이 항목을 찾는 능력에 비용이 들기 때문에 사용자는 먼저 더 저렴한 옵션을 들어야 합니다. 사용자가 여전히 설정을 원할 수 있습니다. 그것은 사용자의 선택입니다. 몇 줄로 대체 방안으로 제공하십시오.

홈 선택. 표준 카테고리의 일곱 가지 질문을 사용하여 존재하는 페이지에 매핑하십시오. 컨트롤이 어느 것에도 맞지 않으면, 주제가 누락되었다는 증거입니다. 말하고 하나를 제안하십시오. 일반, 기타, 기타 또는 고급이라는 페이지를 만들지 마십시오. 기존 인터페이스에 이미 그러한 페이지가 있다면, 대신 가장 구체적인 이름의 특정 페이지에 새 컨트롤을 배치하고 나중에 수정할 가치가 있는 것으로 종합 페이지를 한 줄로 언급하십시오. 하나의 컨트롤을 추가하라는 요청은 감사 요청이 아닙니다.

질문을 하는 컨트롤. "다시 묻지 않음"이 있는 확인은 설정에 대한 컨텍스트 내 컨트롤입니다(질문 4): 체크박스와 설정 행은 동일한 레코드이므로 선택을 찾고 나중에 되돌릴 수 있습니다. "다시 묻지 않음"을 제공하는 경우, 이를 취소하는 행이 어딘가에 없으면 안 됩니다.

사용자에게 얼마나 보여줄 것인가. 프로젝트에 레지스트리가 있다면, 전체 레코드(아래 필드)를 작성하고 해당 페이지가 여전히 한도 내에 있는지 확인하십시오. 레지스트리가 없거나 사용자가 조언만 요청했다면, 일반 언어로 답변하십시오: 무엇을 추가할지, 어디에, 무엇이라고 부를지, 기본값은 무엇이며 그 이유, 그리고 이 장치에 적용되는지 전체 계정에 적용되는지. id, tier, owner, reviewed와 같은 필드는 부기 항목이므로 대화형 답변에서 제외하십시오. 레코드에 필요한 것을 모르는 경우(설정이 장치 간 동기화되는지, 어떤 페이지가 존재하는지), 가정을 절로 명시하고 계속 진행하십시오.

기존 인터페이스 감사

목표는 규칙 번호에 연결된 구체적이고 수정 가능한 결과 목록과 제안된 구조입니다. 먼저 references/rules.md를 읽어 결과가 규칙을 인용할 수 있도록 하고, references/audit.md의 보고서 템플릿을 사용하십시오.

감사는 설정, 내비게이션, 툴바 또는 세 가지를 모두 다룰 수 있습니다. 사용자가 요청한 것과 볼 수 있는 것을 감사하십시오. 화면에 설정이 없으면 템플릿의 설정 부분을 건너뛰십시오. 억지로 맞추지 마십시오.

1. 인벤토리. 사람이 변경하거나 트리거할 수 있는 모든 장소를 나열하십시오: 설정 화면, 계정 메뉴, 컨텍스트 메뉴, 항목별 대화상자, 내비게이션 목록, 툴바, 아이콘 스트립, 명령줄 플래그, 구성 파일. 대규모 코드베이스에서는 스윕을 위임하거나 패턴(레이블, 토글, 메뉴 빌더)을 검색하십시오. 거대한 파일을 전체 읽지 마십시오. 각 컨트롤에 대해 표시된 레이블, 종류, 위치 및 접근 방식을 기록하십시오. 컨트롤에 레이블이 전혀 없으면 그렇게 말하고 위치로 설명하며, 기능에 대한 추측이 있으면 추측으로 표시하십시오.
2. 측정. 규칙이 제한하는 것을 계산하십시오: 변경할 수 있는 장소 수, 최상위 내비게이션 항목 수, 페이지당 설정 수, 깊이, 툴바당 버튼 수, 아이콘 전용 컨트롤 수, 접근 가능한 이름이 없는 컨트롤 수, 검색 상자 수, 그리고 동일한 유형의 객체가 표시하는 고유한 명령 세트 수.
3. 증상 찾기.
   • 동일한 설정이나 명령이 두 곳 이상에서 접근 가능하거나, 두 컨트롤이 중첩되거나 충돌하는 경우
   • 하나의 주제가 여러 페이지에 흩어져 있는 경우
   • 하나의 항목에 여러 이름; 링크 레이블이 대상 제목과 다른 경우; 거의 중복된 이름이 나란히 있는 경우
   • 일반, 기타, 기타, 고급이라는 페이지
   • 동작(내보내기, 삭제, 로그아웃)이 환경설정이나 목적지 사이에 있는 경우
   • 범위가 힌트 텍스트로만 설명되거나 전혀 설명되지 않는 경우
   • 레이블에 개발자 용어가 사용된 경우
   • 항목이 하나인 그룹과 한도를 초과하는 목록
   • 보이는 단어가 없는 아이콘; 하나의 아이콘이 두 가지 의미로 사용되는 경우
   • 버튼이 5개를 초과하는 툴바; 동일한 유형의 객체 간에 다른 명령 세트
   • 현재 위치 표시가 없는 경우
   • 화면에 두 개 이상의 검색 상자
   • 혼잡을 해결하기 위해 컨트롤 표시, 숨기기 또는 재정렬을 제공하는 경우
4. 제안. 설정의 경우: 적용되는 표준 카테고리와 최대 두 개의 제품 주제, 총 9개 이하로, 모든 컨트롤을 정확히 하나에 매핑하십시오. 내비게이션의 경우: 최대 9개의 최상위 항목, 나머지는 레이블이 지정된 그룹 아래에 둡니다. 툴바의 경우: 객체 유형당 하나의 명령 세트, 5개는 막대에, 나머지는 더보기 아래에 둡니다. 표면에서 완전히 사라지는 항목과 이동 위치를 나열하십시오. 그룹화는 카드 정렬과 트리 테스트(5명이 큰 문제를 찾음, 80% 작업 성공률 목표)로 확인할 제안이라고 말하십시오. 그룹화는 사용자가 생각하는 방식과 일치해야 하며 코드에서 읽을 수 없기 때문입니다.
5. 변경 사항을 순서화하여 아무도 다시 배울 필요가 없는 것부터 먼저 하십시오: 아이콘의 단어 및 현재 위치 표시, 중복 축소 및 이름 통일, 일관된 툴바, 그 다음 재그룹화. 이동은 기존 사용자에게 비용이 들기 때문에 늦게 옵니다. 레지스트리 도입이 정당화되면 마지막에 제공되며 강요되지 않습니다. 사용자는 화면에서 무엇을 변경할지 물었습니다.

새 사용자에게 얼마나 해로운지에 따라 결과를 순서화하십시오. 이미 작동하는 것을 인정하십시오: 기존 레지스트리, 검색, 재설정 또는 주소 메커니즘은 수정이 구축되는 기초이며, 이를 말하면 아무도 필요로 하지 않는 재작성을 방지할 수 있습니다.

새로운 표면 구축

1. 먼저 모든 항목에 대해 다섯 가지 질문을 실행하십시오. 제품 위시리스트에는 항상 더 나은 기본값이 되어야 하거나, 시스템에 속하거나, 환경설정보다는 동작인 항목이 포함됩니다. 잘라낸 항목은 레지스트리에서 제외하고 요약에 이유와 함께 나열하여 사용자가 당신을 무시할 수 있도록 하십시오.
2. 마크업보다 먼저 references/record-schema.md에 따라 레코드를 작성하십시오. 레지스트리가 있으면 추가하십시오.
3. 모든 레코드를 일곱 가지 질문(다음 섹션)으로 분류하십시오. 비어 있을 카테고리는 제외하십시오. 사람들이 이름으로 찾는 경우(알림) 하나 또는 두 개의 설정이 있는 카테고리는 괜찮습니다. 그렇지 않으면 이웃 카테고리로 접으십시오. 주제에 대한 상태는 해당 주제의 페이지에 남습니다. 앱 전체 정보만 정보에 들어갑니다.
4. 한도 확인(아래)을 수동으로 또는 검사기로 수행하십시오.
5. 레코드에서 표준 레이아웃을 그리고 배열, 크기, 컨트롤 및 상태에 대해 references/visual-design.md를, 동작에 대해 references/patterns.md를 따르십시오. 요약: 넓은 화면에서는 카테고리 목록이 페이지 옆에, 좁은 화면에서는 앞에 배치됩니다. 하나의 열은 약 1,100px로 제한됩니다. 레이블은 왼쪽, 컨트롤 또는 현재 값은 오른쪽. 관련 행은 포함된 그룹에 있습니다. 켜기/끄기에는 스위치, 25개 옵션에는 라디오 버튼, 저장 버튼 없음. 대상은 최소 24px, 터치용 4448px. 텍스트 대비 4.5:1. 색상만으로 표시하지 않음. 각 행은 범위를 표시하고, 기본값과 다를 때 변경 표시와 함께 재설정을 표시합니다. 검색은 상단에 있습니다. 모든 레코드에는 안정적인 주소가 있습니다. 동작은 환경설정과 분리되고, 파괴적인 동작은 다시 분리됩니다.
6. 가정한 것을 말하십시오: 추측해야 했던 기본값, 범위 및 소유자는 사용자가 확인할 사항입니다. 알 수 없는 소유자에는 unassigned을 사용하십시오. 팀 이름을 만들지 마십시오.

표준 카테고리

순서대로 질문하고 첫 번째 '예'에서 멈추십시오. 순서가 동점자 해결 기준입니다.

#	질문	카테고리
1	당신이 누구인지, 어떻게 접근하는지, 또는 무엇을 지불하는지에 관한 것입니까?	계정
2	제품이 당신을 언제 또는 어떻게 방해할지 결정합니까?	알림
3	다른 사람, 다른 앱 또는 서비스가 볼 수 있거나, 보관하거나, 수행할 수 있는 것을 제어합니까?	개인정보 보호 및 보안
4	특정 요구가 있는 사람이 제품을 보고, 듣거나, 작동할 수 있도록 존재합니까?	접근성
5	모양만 변경합니까?	모양
6	언어, 시간 또는 형식에 관한 것입니까?	언어 및 지역
7	데이터가 보관되는 위치, 양 또는 네트워크에 관한 것입니까?	데이터 및 저장소
	그렇지 않으면: 어떤 기능을 변경합니까?	최대 두 개의 제품 주제 중 하나 (메시지, 편집기, 재생)

정보(버전, 도움말, 법적 고지)는 하단의 링크이며 계산되지 않습니다. 관리자가 모든 사람을 위해 만드는 설정은 별도의 표면입니다. 약 15개 미만의 설정이 있는 작은 앱은 이러한 이름을 그룹 제목으로 사용하는 하나의 페이지를 사용합니다.

따라서 통화 벨소리는 통화가 아닌 알림입니다. "동작 줄이기"는 모양이 아닌 접근성입니다. 설정이 두 곳에 있을 수 있는 경우, 첫 번째 '예'로 분류하고 다른 카테고리의 단어를 검색어에 넣으십시오. references/categories.md는 대규모 제품, 제품군, 명명 및 추론을 다룹니다.

이 이름은 운영 체제에서 이미 사용하는 이름입니다. 이것으로 시작하고, 제품 자체 사용자가 카드 정렬에서 다르게 그룹화하는 경우에만 변경하십시오.

레코드

필드	대답하는 질문	허용 값
id	영구적인 이름은 무엇입니까?	chat.notifications.sound와 같은 점으로 구분된 경로. 재사용되거나 이름이 변경되지 않음.
kind	어떤 종류의 것입니까?	preference, action, status, list, destination, command
subject	어떤 하나의 명사에 관한 것입니까?	정확히 하나의 주제. 이것이 홈입니다.
scope	누구 또는 무엇을 변경합니까?	item, device, account, organization
tier	얼마나 많은 사람이 필요로 합니까?	everyday, standard, advanced
label, summary	무엇이라고 부르며, 무엇을 합니까?	일반 레이블; 결과에 대한 한 문장
search	사람이 찾기 위해 입력할 것은 무엇입니까?	동의어, 이전 이름, 전문 용어
value	어떤 종류의 값을 보유합니까?	옵션 또는 범위가 있는 유형
default, default_reason	아무도 건드리지 않으면 어떻게 됩니까?	대부분의 사람이 선택할 값과 그 이유
risk	변경되면 무엇이 깨집니까?	safe, care (복구 가능), destructive (영구 손실)
owner, reviewed	언제 사라질지 누가 결정합니까?	소유자와 마지막으로 정당화된 날짜

목적지와 명령은 더 짧은 필드 세트를 사용합니다. 전체 스키마는 references/record-schema.md에 있으며, assets/registry.example.json은 작동하는 예제입니다.

한도

한도	값	출처

…

[번역을 위해 잘림]