it-swarm-korea.com

왜 "프로젝트 이름을 입력하여 확인"을 사용합니까?

오랜 GitHub 사용자라면 다음과 같은 것을 보았을 것입니다.

이는 공개/개인 상태 전환 또는 보관/삭제와 같이 잠재적으로 파괴적인 일을 저장소에 수행 할 때마다 발생합니다.

동작 단추를 클릭하면 프롬프트가 모달에 표시되므로 우발적 인 동작을 방지하기위한 추가 조치입니다.

그러나 내가 아는 한, 이것은 "다른 장벽을 설정"하는 데 효과적이지 않거나 "추가 확인"으로 너무 성가시다. URL에서 또는 입력 상자 바로 위의 저장소 이름 (위의 굵은 체 텍스트)을 간단히 복사 할 수 있지만 이는 추가 단추를 클릭하는 것보다 여전히 복잡합니다.

제 생각에는 밝은 빨간색의 여분의 모달 button Enter 키와 같은 키보드 동작에 응답하지 않는 것으로 충분합니다. 주의를 기울이려면 마우스를 밝은 빨간색 버튼으로 이동하여 클릭해야합니다. 번거롭지 않고 Enter 키를 누르는 것만으로도 간단하고 효과적입니다.

누구든지이 "프로젝트 이름 입력"이 어떻게 훌륭한 UI 디자인인지 설명 할 수 있습니까?

48
iBug

반드시 "좋은 UI 디자인"에 관한 것이 아니라 실수로 삭제하는 것을 방지하고 사용자가 자신이 삭제하는 내용을 완전히 인식하도록하기위한 모든 조치를 취하는 것에 관한 것입니다 .

이 블로그 항목은 다음을 잘 보여줍니다.

실수로 누를 수있는 확인 단추를 사용자에게 제공하는 대신 텍스트 필드를 제공하고 "삭제"라는 단어를 입력하여 확인하도록 요청하십시오. 사용자가 텍스트 필드에 "삭제"를 입력하면 의심의 여지가 없습니다. 실수로 삭제 버튼을 누르지 않았습니다. 확인 텍스트 필드를 통해 사용자가 삭제하기 전에해야 할 일을 확실하게 알 수 있으므로 사용자가 삭제해도 후회하지 않습니다.
사용자가 실수로 삭제하지 않도록하는 방법-UX 이동

물론, 버튼을 누르는 것이 더 쉽지만 항상 이름을 잘못 읽거나 잘못된 항목을 삭제할 가능성이 있습니다.
이름을 입력하거나 복사하여 붙여 넣어야 할 경우 사용자가 실수로 그렇게하지 않을 것이라고 99 % 확신 할 수 있습니다. 그들은 복사-붙여 넣기의 이름을 강조 할 때 가장 최근에 그것을 깨달을 것입니다.

게다가 이것은 일반적으로 매우 중요한 삭제 작업에만 사용됩니다. 이러한 경우는 매우 드물기 때문에 성가 시게하거나 성가 시게하는 것에 대한 주장이 실제로는 그런 것이 아닙니다.


다음은 몇 가지 관련 질문입니다.

168
Big_Chair

명확한 "좋은"UI 디자인을 원한다고해서 원하는 것을 사용자에게 제공한다는 의미는 아닙니다. 종종 사용자가 자신을 더 나은 버전으로 만드는 것을 돕는 것을 의미합니다.

이미 언급 한 것 외에도이 패턴 (및 이와 유사한 패턴)을 통해 UI 속도를 줄일 수 있습니다. 일반적으로 muscle memory-> speed-> mistakes-> sad path.

건강 관리 업무를하고 있다고 상상해보십시오. 사용자가 일반적인 작업에서 너무 많은 "흐름"을 만들면 잠재적으로 누군가를 죽이는 간단한 실수를 할 수 있습니다. 직관적 인 반면, 상호 작용 (항상 동일한 위치에 나타나고 근육 기억에 추가 될 수있는 단순한 확인 대화 상자 이상)을 요구하여 사용자를 흐름에서 벗어나게하는 것이 좋습니다.

텍스트 입력은 이에 대한 한 가지 예일뿐입니다. 나는 또한 보았다 :

  1. 버튼을 사용할 수있게되기 전에 시간 초과를 추가합니다.
  2. 공정 연속 버튼의 무작위 배치.
  3. 잠금 추가 (예 : 비밀번호를 사용하여 관리자로 프로세스 실행)

이러한 모든 패턴은 진행하기 전에 프로세스를 정신적으로 평가하지 않을 정도로 사용자를 성가 시게하기위한 것입니다.

51
Bryce Howitson

이것은 다음을 보장하기위한 것입니다.

  1. 당신은 당신이하고있는 일의 위험을 이해합니다.
  2. 가장 중요한 것은 실제로 올바른 저장소를 삭제한다는 것입니다.

사용자가 이름이 긴 repos가 많으면 혼동하기 쉽습니다. 이름을 입력하는 것은 잘못된 이름을 쓰지 않도록하는 좋은 방법입니다.

15
frodo2975

마우스 왼쪽 클릭으로 간헐적으로 사용하기 위해 사용하지 않는 키보드 키 (AutoHotKey를 통해)를 다시 매핑하여 마우스 손목의 과도한 사용으로 인한 부담을 줄이고 때로는 멀티 태스킹 할 때 잘못된 위치에서 해당 키를 누르지 않습니다. 또한 때때로 마우스 자체가 충돌하여 실수로 대화 상자의 단추를 클릭했습니다.

"나를 생각하지 마라"는 아주 좋은 규칙이지만, 사용자가 드물고 파괴적인 명령을 실행하는 것이 실제로 무엇을하는지에 집중하도록 돕는 것이 합리적입니다. 사용자 유형에 "wiki, 이슈 및 의견을 포함한 iBug/example-repository 리포지토리를 삭제하십시오"라는 문장의 전체 문장을 고려하는 것도 고려하고 싶습니다. 자신 = 그 상황에서는 사용자가 해당 저장소에서 한 번만 수행하므로.

실제로 코드를 작성하는 사람은 완전하고 명확하며 철자가 정확한 텍스트 줄을 매우 자주 입력해야하므로 프로젝트에서 수행 할 수있는 가장 파괴적인 작업을 확인하기 위해 한 줄을 더 추가하는 것은 무리가 없습니다.

9
user117529

이미 실수로 실수 한 것을 만들었습니다.

  • 내 손이 버튼을 두 번째로 옮겼습니다 ( "취소"를 원하고 "확인"이 표시됨). 또는 광고가 팝업되어 페이지가 이동했습니다.
  • 지시가 너무 혼란스러워서 잘못된 버튼을 눌렀습니다 (물론 덜 파괴적인 것은 아닙니다)
  • 나는 "oh no no"였고 공황 상태에서 잘못된 버튼을 눌렀다
  • Juan Pablo Davila 일 수도 있고 아닐 수도 있습니다

그렇기 때문에 나는 근육 기억이 제안하는 것과 다르게 행동하게 만드는 과정을 선호합니다.

5
WoJ

Github이 여기서하려고하는 것은 사용자 오류를 피하는 것이지만 Don Norman이 일상적인 것들의 디자인에서 언급 한 것처럼 "슬립"입니다.

슬립은 사용자가 한 작업을 수행하려고하지만 다른 작업 (종종 비슷한 작업)을 수행 할 때 발생합니다. 예를 들어, "o"대신 "i"를 입력하면 미끄러짐으로 간주됩니다. 실수로 치약 대신 칫솔에 액체 손 비누를 바르는 것도 미끄러운 일입니다. 슬립은 일반적으로 사용자가 자동 ​​조종 장치를 사용하고있을 때주의 자원을 완전히 배정하지 않은 경우 이루어집니다.

나는 인용문의 마지막 부분을 특히 관련있는 것으로 강조합니다.

Nngroup의 다음 기사에서는 전표를 방지하는 방법에 대해 설명합니다.

슬립 유형의 실수는 종종 해당 프로세스에 매우 익숙한 전문가 사용자에 의해 이루어집니다. 여전히 시스템 사용법을 배우고있는 새로운 사용자와 달리

https://www.nngroup.com/articles/slips/

Github을 사용하는 사람들의 유형을 고려할 때 GDS Digital Inclusion Scale 과 같이 매우 높은 것으로 간주하면 전문가 사용자가 미끄러질 가능성이 더 큽니다.

그런 다음 두 가지를 함께 모아서 프로젝트에 수백 시간을 투자했지만 피곤한 전문가 Github 사용자와 공감하십시오. 어느 프로젝트에 있었는지 잊어 버리고 의도하지 않았을 때 삭제를 누르십시오. 그들은 어떻게 느끼는가?

많은 Github 사용자는 많은 리포지토리를 가지고 있으며 삭제 페이지에는주의를 기울이지 않으면 구분할 것이 많지 않습니다. 아마도 "백만 파운드 프로젝트-초안"저장소를 삭제하려고했을 것입니다. "백만 파운드 프로젝트".

이것이 그들이하는 일이며 효과적인 UI 디자인이라고 생각합니다. 복구 할 수없는 작업 방식에 유용한 제한을 두는 것이 좋습니다.

3
dougajmcdonald