진보적 검증 및 공개
점진적 유효성 검사의 예를 찾으려고합니다. 사용자가 치수를 픽셀 또는 퍼센트로 표시하는 것과 같은 작업을 수행하는 비주얼 편집 기용 UI가 있습니다.
편집기 특성은 탭 세트에 있으므로 모든 필드를 동시에 볼 수있는 것은 아닙니다. 우리는이 UI에서 검증 방법과 방법에 대해 논의했습니다.
A) 검증은 사용자가 소프트웨어의 기대치를 배우고 필요한 것을 "더 잘"얻을 수있는 통신 채널을 생성하기 때문에 유용합니다. b) 사용자가 변경해야 할 사항에 대한 시각적 신호를 갖도록 입력 필드에 유효성 검사 오류를 직접 표시하는 것이 좋습니다 (요약이 다른 곳에서 사용되는지 여부).
내가 존중하는 것 외에는 아무것도없는 나의 동료. 그의 논리는 다음과 같다 : a) 특정 유형의 진입을 막는 것이 더 바람직하거나, 일부 진입의 경우, 유효하지 않은 경우보다 적절한 값으로 변경하는 것이 더 편리 할 것이다. 예를 들어, 누군가가 100보다 큰 백분율 값을 사용하는 경우 UI는 초점 상실 이벤트에서 값을 100으로 재설정합니다. b) 우리는 탭 환경에 있기 때문에 일부 오류는 사용자에게 보이지 않습니다. 잠재적으로 "많은"유효성 검사 오류가있을 수 있으므로 요약을 사용하는 것은 쓸모가 없습니다.
나는 이것에 대한 해결책이 유효하지 않은 값의 점진적 공개라고 생각했다. 사용자가 올바르지 않은 값을 입력하면 일종의 요약으로 플래그가 지정됩니다. 요약을 통해 사용자는 해당 필드를 보지 않고도 탐색 할 수 있습니다.
나는 원래 사람 이었으면 좋겠지 만 여기에 선례가 있다고 확신합니다. 내 질문은 다음과 같습니다.
나와 동료의 관점에 추가 할 것이 있습니까?
점진적인 유효성 검사를 수행하는 복잡한 항목이있는 이와 같은 UI의 예는 무엇입니까?
우리는 현재 탭 기반이 아닌 데스크탑 앱에 대해 동일한 문제를 겪고 있습니다. 다음과 같은 접근법을 시도 할 수 있습니다.
사용자의주의가 필요한 경우 작은 아이콘이 나타납니다. 어쩌면 경고의 경우 노란색과 사용자가 더 나아 가기 전에 필수로 고정 된 것들의 경우 두 가지 색상을 사용할 수도 있습니다.
이 복잡한 상황에서 할 수있는 최선의 방법은 할 수있는만큼 UI의 프로토 타입 을 만들고 사용자 기반 에서 테스트하여 어떤 일이 발생하는지 확인하십시오. HTML을 jQuery UI와 함께 사용하면 많은 대화 형 컨트롤을 빠르게 사용할 수 있고 빠르게 테스트 할 수 있습니다.
탭 시스템이 복잡하게 들리므로 단순화 할 몇 가지 사항을 제안해야합니다.
- 각 탭 내에 "적용"버튼을 만들어 사용자가 지금 볼 수있는 속성에 대해서만 상태를 저장할 수 있습니다. 응용 프로그램 상태가 잘못되면 탭을 다시 디자인하여 사용자가 속성을 그룹화하여 can 서로 독립적으로 저장되도록하십시오.
- 그렇게 할 수없는 경우 "유효하지 않은"아이콘이있는 탭을 강조 표시하고 해당 탭의 속성에주의가 필요함을 나타내는 색을 지정할 수 있습니다. 탭이 유효하지 않으면 "적용"버튼이 비활성화됩니다. 여전히 오류가 있음을 나타내는 메시지를 표시하기 위해 단추를 클릭하면 단추에 알림을 추가하는 것을 고려할 수 있습니다. 전체 요약이 아닌 각 탭 내에 잘못된 내용에 대한 요약이 표시됩니다.
- 전체 요약이 효과가있을 수 있지만, 즉시 명확한 위치가 없을 것 같으므로 제안하는 것이 주저하고 있으며, 그렇지 않은 경우 사용자가 주목할 것입니까?
- 속성은 어떻게 그룹화됩니까? 아마 기능적으로? 예를 들어 사용 가능성에 따라 다른 각도에서 살펴보십시오. 이것은 Microsoft가 Office 2007 제품의 리본 디자인에 접근 한 방식의 일부입니다. 아마도 대부분의 사용자가 첫 번째 탭에서 속성을 엉망으로 만들 필요가 있거나 탭이 즉시 표시되고 다른 탭은 "고급"또는 상황에 맞는 방식으로 탭을 설계 할 수 있습니다.
궁극적으로 이미 말했듯이 디자인을 테스트하십시오! :-)
처리 오류가 발생하는 한, 내 경험에 따르면 특정 입력을 막 으면 사용자가 혼란스러워집니다. 예를 들어, 입력 필드에서 숫자 만 허용된다는 것이 확실하지 않지만 어쨌든 다른 문자를 허용하지 않으면 사용자에게 실망 할 것입니다-그들은 그것을 도와주는 지능적 형태로 경험하지 않을 것입니다 . 따라서 이벤트 및 입력 감지의 경로를 따라 자동으로 문제를 해결하기로 결정한 경우 전체적으로 명확한 현미경을 사용하는 것이 좋습니다.
그러나이 모든 것은 일화입니다. 저는이 분야에 대한 연구를하지 않았습니다. 내 말로 받아들이는 대신 Luke Wroblewski의 저서 Web Form Design : Filling in the Blanks 및 이와 같은 상황을 처리하는 방법에 대한 유용한 통찰력을 제공하는 오류 처리 연구를 참조하십시오. 예를 들어,이 Apple의 체크 아웃 양식 redesign에 게시 오류 처리 방법에 대해 자세히 설명합니다.
최근에 비슷한 문제가 발생한 프로젝트에서 일했습니다. 작년의 " Minimizing Complexity "기사에서이 문제를 해결 한 방법의 스크린 샷을 볼 수 있습니다.
많은 오류에 대한 요약이 사용되는 경우를 생각해 보았습니다.
IDE Visual Studio와 같이 코드를 작성하는 동안 정적 분석 도구를 작성하거나 사용할 때 끝없는 오류가 발생할 수 있습니다. 일반적으로 수십 또는 수백 개의 파일이 있으며 그 중 많은 파일이 열려 있습니다 한 번에 하나 또는 두 개가 보이는 탭
그런 다음 오류는 기본 UI 아래 (기본적으로) 밖으로 스크롤 가능한 크기 조정 가능한 목록에 나열됩니다. 오류가 발생하자마자이를 수행 할 수 있습니다. 오류를 클릭하거나 두 번 클릭하면 올바른 위치로 이동하여 오류를 수정하고 더 이상 유효하지 않으면 목록에서 오류가 사라집니다.
실제로 이러한 많은 오류는 사용자가 평가 한 재평가가 필요하지만 백그라운드에서이를 수행하고 실제로 코드를 편집하는 동안 오류 목록을 동적으로 업데이트하는 정적 분석 추가 기능이 많이 있습니다) .
a) 예를 들어 누군가가 100보다 큰 백분율 값을 사용하는 경우 UI는 포커스가없는 이벤트에서 값을 100으로 재설정합니다.
좋은 지적이지만 다음을 확인해야합니다.
- 사용자는 자신의 입력이 고정되었음을 인식합니다.
예를 들어, 값을 수정하면 필드가 1 초 동안 깜박입니다. - 사용자가 실제로 무엇을 의미했는지 추측 할 수 있습니다.
예를 들어, 어제 레슬링 한 색상 피커를 선택하십시오. 다른 사이트의 요소와 일치하는 몇 가지 요소가 필요했기 때문에 16 진수 값을 가져 와서 작은 임시 텍스트 상자에 붙여 넣었습니다. 첫 번째 값은#202040였지만 어떤 이유로 든#20204만 붙여 넣었으며#020204에 즉시 "고정"되었습니다. 붙여 넣은 두 번째 값은#BCD(#BBCCDD의 약자)이며#000BCD로 '고정'되었습니다. 한숨.