• CLI의 우선 순위
• UX 스타일 가이드 및 원칙
  • 생성기 사용 시기
  • 사용자로부터 기대되는 점
  • 개발 환경으로부터 기대되는 점
  • 사용자와 기대치 설정
  • 사용자에게 정보 전달
  • 사용자로부터 정보 수집
• 디자인 팁
• 개발 관행
• FAQ

내부 이벤트 CLI 기여

CLI의 우선 순위

1. CLI가 모든 계기화 작업의 주진입점이기 때문에 계기화 능력과 동등한 기능
2. 성능 및 수동 테스팅은 사용자에게 깨끗하고 명확한 UX를 제공하는 것이 주요 우선 순위입니다.
3. 사용자가 CLI를 사용하지 않을 경우에도 danger/specs/pipelines는 여전히 정의 유효성/데이터 무결성/기능 등을 보장합니다.

UX 스타일 가이드 및 원칙

생성기 사용 시기

내부 이벤트 생성기는 다음과 같이 사용해야 합니다:

• 모든 공학 작업과 관련된 계기화 작업에 대한 일괄 쇼핑처(complete shop)가 되어야 합니다.

내부 이벤트 생성기는 다음과 같이 사용하면 안 됩니다:

• 필수적이지 않습니다. 사용자는 동일한 작업을 수동으로 수행할 수 있어야 합니다.

사용자로부터 기대되는 점

내부 이벤트 생성기는 다음과 같이 사용자를 보호해야 합니다:

• 실수를 저지르지 않도록 사용자를 보호해야 합니다.
• 언제든지 목표를 달성하기 위해 완료되어야 할 작업을 사용자에게 알려주어야 합니다.
• 화면에서 보이는 정보만으로 사용자가 특정 옵션을 선택하거나 텍스트를 입력한 경우의 결과를 전달해야 합니다.

내부 이벤트 생성기는 다음과 같이 사용자로부터 기대되는 부분은 아닙니다:

• 사용자에게 계기화에 대해 어떤 것도 알 필요가 없습니다.
• 특정 컨텍스트가 필요한 경우 사용자가 화면을 전환하도록 요구해서는 안 됩니다.
• 대체 경로를 제시하지 않고 사용자가 진행하지 못하도록 막아서는 안 됩니다.

개발 환경으로부터 기대되는 점

내부 이벤트 생성기는 다음과 같이 해야 합니다:

• 동일한 작업을 수동으로 수행하는 것보다 빠르게 작동되어야 합니다.
• 강제 종료 시 사용자의 환경을 깨끗하고 유효한 상태로 유지해야 합니다.

내부 이벤트 생성기는 다음과 같이 해서는 안 됩니다:

• 유효하지 않은 사용자 생성 콘텐츠가 존재할 때 작동되지 않아야 합니다.
• Rails가 실행되어야 하는 검증을 요구해서는 안 됩니다.
• 사용을 위해 기능하는 GDK가 요구되서는 안 됩니다.

사용자와 기대치 설정

내부 이벤트 생성기는 다음과 같이 해야 합니다:

• 각 화면 상단에 진행률 표시줄을 표시하고 필요한 단계를 설명해야 합니다.
• 각 흐름을 정의하기 위한 결과 기반 진입점을 가져야 합니다.
• 캐주얼하고 열정적인 톤을 사용해야 합니다.

사용자에게 정보 전달

내부 이벤트 생성기는 다음과 같이 해야 합니다:

• 모든 것에 대한 텍스트 레이블과 설명을 제공해야 합니다.
• 사용자가 CLI를 종료할 때 항상 InternalEventsCli::Text::FEEDBACK_NOTICE를 출력해야 합니다.
• 결과를 설명하기 위해 예제를 사용해야 합니다.

내부 이벤트 생성기는 다음과 같이 해서는 안 됩니다:

• 정보나 컨텍스트를 전달하기위한 유일한 메커니즘으로 색상 및 서식을 사용해서는 안됩니다.

사용자로부터 정보 수집

내부 이벤트 생성기는 다음과 같이 해야 합니다:

• 일반 텍스트 입력 대신 선택 메뉴를 사용하는 것을 선호해야 합니다.
• 가능한 경우 기본값으로 자동 채우거나 이전 선택 사항을 통해 정보를 추론해야 합니다.
• 첫 번째/가장 쉬운 기본 옵션으로 가장 일반적인 사용 사례를 선택해야 합니다.
• 모든 유효한 옵션을 항상 허용해야 합니다. CLI는 가장 흔한 사용 사례가 항상 사용된다고 추정해서는 안 됩니다.

내부 이벤트 생성기는 다음과 같이 해서는 안 됩니다:

• 사용자로부터 동일한 정보를 여러 번 입력하도록 요구해서는 안 됩니다.
• CLI를 전체 화면으로 사용할 때(가능한 경우) 화면의 “fold” 이상으로 상호 작용 되게 하는 것을 방지해야 합니다.

디자인 팁

• 서로 다른 유형의 정보 및 입력의 서식을 포맷하는 데는 scripts/internal_events/cli/helpers/formatting.rb을(를) 참조하십시오.
• 콘텐츠를 추가하거나 제거하는 것은 흐름이 얼마나 잘 작동하는지를 변경시킬 수 있습니다. 항상 보다 넓은 콘텍스트를 고려하고 UX를 향상시키기 위해 다른 수정도 두려워하지 마십시오.
• 다중 선택 메뉴와 종속성 및 유효성 검사가 있는 대신, 허용 가능한 각 조합을 나열하는 단일 선택 메뉴를 고려하십시오. 이것은 항상 잘 작동하지는 않을 수 있지만, 더 빠른 상호 작용이 가능하며 사용자에게 선택의 결과를 명확하게 보여줍니다.
• 기존 흐름에 추가할 때, 기존 화면의 서식과 구조를 최대한 일치시키십시오. 텍스트의 각 부분이 제공하는 기능을 고려하고, a) 기능에 따라 관련 텍스트를 그룹화하거나, b) 주제별로 관련된 텍스트를 그룹화하고 각 주제에 대해 동일한 기능적 순서를 사용하십시오.

개발 관행

• 피처 문서화: CLI 업데이트와 함께 공동 릴리즈 문서 업데이트
  • 모든 계기화가 권장하는 주진입점이라면 항상 피처가 완전해야 합니다. 문서 또는 다른 팀에 공지한 기능보다 뒤떨어지지 않아야 합니다.
• CLI 문서화: 가능한 한 CLI 코드의 내부 또는 동일 위치에 문서화에 의존해야 합니다.
  • CLI를 작업하는 동안 컨텍스트/설명과 우연히 마주치고 활용도 및 다시 익숙해지는 속도를 높일 가능성이 더 높습니다.
• 테스트: 프론트엔드 애플리케이션에 대한 접근 방식과 동일하게 테스트해야 합니다.
  • 자동화된 테스트는 주로 UX 중심 E2E 테스트여야 하며 필요에 따라 에지 케이스 테스트와 유닛 테스트를 보조해야 합니다.
  • 퇴보를 막기 위해 절대적으로 필요한 곳에 유닛 테스트를 적용해야 합니다.
• 검증: 기능 지원을 추가할 때 항상 CLI를 직접 실행해야 합니다.
  • 자동화된 테스트만 의존해서는 안 됩니다. 사용자 경험을 높이고자 하는 목표라면 우리가 사용자로서 모든 합병점에 맞도록 하는 것은 중요한 도구입니다. 수동으로 테스트를 하는 것이 번거롭고 짜증난다면, 사용하기도 번거롭고 짜증날 확률이 큽니다.

FAQ

Q: 왜 InternalEventsCli::Event 및 InternalEventsCli::Metric은 각각 Gitlab::Tracking::EventDefinition 및 Gitlab::Usage::MetricDefinition을 사용하지 않는가요?

A: EventDefinition 및 MetricDefinition 클래스를 사용하려면 GDK가 실행되어야 하고 레일 앱이 로드되어야 합니다. CLI의 성능은 그 사용자 경험에 매우 중요하기 때문에 별도의 클래스가 시작 시간의 빠른 속성을 가치로 하는 것입니다. 이상적으로는 이것이 시간이 경과함에 따라 CLI 및 레일 앱 모두에 사용될 수 있는 같은 클래스로 리팩토링 될 것입니다. 현재, 레일 앱과 CLI는 여전히 정의를위한 단일 진리의 소스로서 json-schemas를 공유합니다.