사용자가 저지르는 실수는 무엇이며 어떻게 처리하도록 응용 프로그램을 업데이트 할 수 있습니까? [닫은]

실제로이 질문은 양질의 사용자 경험을 향상시키고 피할 수있는 지원 요청을 줄이기 위해주의를 기울여야합니다.

적절한 입력 유효성 검사가 없다는 것은 프로그래머가 실제로 처리해야 할 때 사용자가 응용 프로그램에서 "나쁜"일을하는 데 매우 빨리 걸리는 경향 중 하나입니다.

사용자에게 다음과 같은 교육을받은 레거시 앱을 보았습니다.

• 이름에 아포스트로피를 입력하지 마십시오
• 이외의 기호를 입력하지 마십시오 a-z0-9,
• 입력 한 텍스트 전후에 공백이 없는지 확인하십시오
• 올바른 형식의 이메일 주소가 email필드 에 입력되어 있는지 확인하십시오 . 그렇지 않으면 해당 사용자에게 보내는 후속 메일은 필드에있는 모든 것을 사용하고 실패합니다
• http://웹 주소 앞에 " "이 (가) 있는지 확인하십시오

등

위의 모든 문제는 응용 프로그램 개발자가 처리 해야하는 문제 입니다. 입력 유효성 검사가 본질적으로 "사용자가이 필드의 형식을 알고 입력 한 내용이 올바른지 확인하십시오"인 경우, 예상치 못한 일이 앱으로 유입됩니다. 명백한 보안 영향 외에도 사용자는 실수를합니다. 프로그래머로서 우리는 종종 아무리 노력해도 사용자 가 잘못 이해 하지 못하도록 뒤로 구부려 최고의 제품을 생산 합니다!

앱이 사라져서 한 번 고객 지원 전화를 받았습니다. 그들은 그 위에 다른 앱을 열었습니다.

... 나는 앱이 아닌 문제를 일으킨 것은 사용자 컴퓨터 문맹이기 때문에 다시는 일어나지 않기로 결정했습니다. 이 문제를 해결하기 위해 내가 할 수 있었던 일은 다른 사람에게는 사용자 경험이 좋지 않을 수 있습니다.

내가 작성한 거의 모든 프로그램은 명령 행에서 엄격하게 호출됩니다. 또한 CLI 인터페이스로 시작하여 다른 것보다 더 많은 쉘로 빠르게 성장한 더 멋진 것들을 작성했습니다.

그래서 나는 내가 아는 것에 대해서만 말할 수 있습니다. 다음은 명령 줄 프로그램과 관련된 몇 가지 일반적인 문제입니다.

너무 많은 옵션

컴파일러 나 라인 편집기를 작성하지 않는 한, --help또는 /?전달 될 때 옵션을 80x25 프레임 버퍼에서 한 화면으로 만 제한하십시오 . 그보다 더 많은 옵션을 갖는 것이 완벽하지만 하위 범주로 나눕니다. 예를 들어

foo --help

foo --help option_name

더 이상 옵션이 없습니다

기억하는 foo --attach_to [argument] --volatile --verbose것보다 기억하는 것이 훨씬 쉽습니다 foo -a [arg] -v +V. 이것이 항상 가능한 것은 아니지만 대부분의 경우 가능합니다.

입력 검증이 없음

거의 모든 플랫폼에는 인수를 구문 분석하고 유효성을 검사 할 때 시도, 테스트 및 적용되는 여러 라이브러리가 있습니다. 거의 모든 플랫폼에는 CLI의 입력을 검증하는 검증 된 진정한 어휘 분석기가 있습니다. 하나만 사용하십시오. 사용자가 제공 한 것으로 인해 프로그램이 segfault하거나 0으로 나누면 당황 스럽습니다.

어휘 분석기만큼 복잡한 것이 필요하지 않을 수도 있습니다. 어쩌면 특정 장소에서 특정 것들로 특정 순서로 물건을 기대하는 경우 문자열을 토큰 화 할 수 있습니다.

실제로 정수가 예상되고 누군가 f*** my life가 따옴표로 입력 한 버그 보고서를 받았습니다 . 나는 그 프로그램을 쓰지 않았고, 상속받지 못한 불행이 있었다.

'verbocity'노브 없음

숙련 된 사용자가 대부분의 사람들이 허용하는 것보다 프로그램에서 더 많은 소음을 얻는 방법을 쉽게 발견 할 수 있지만, 심각하고 중요한 자료 만 인쇄하는 것이 기본입니다. straceNULL 파일 스트림에서 작동했기 때문에 segfaulted 된 것을 인식 하기 위해 몇 번이나 실행 해야하는지 말할 수 없습니다 .

또한 어설 션을 래핑하여 NDEBUG 또는 기타 수단을 통해 끄면 여전히 사용자가 찾을 수 있도록 인쇄되거나 기록 된 결과가 나타납니다.

로그 파일에 대해 말하면, 파일에 넣은 모든 것이 다른 사람에게 (적어도 조금) 의미가 있는지 확인하십시오. 모든 출품작의 시작이 유닉스 시대라면 버그를 재현하는 데 정말로 도움이되고 싶은 누군가에게 좌절감을 느끼게됩니다.

디버그 모드에서 '버그 버디'없음

많은 프로그램이 프로그램과 관련하여 추가 채팅을 제공하는 일종의 '디버그'스위치를 제공하지만 다음 중 일부는 제공하지 않습니다.

• HTTP / HTTPS를 통해 보고서를 자동으로 전송하고 일종의 서비스 참조 번호를 얻는 방법
• 지원 요청에 대한 첨부 파일로 전송 될 수 있는 유용한 정보를 파일에 덤프하는 방법

또는 사람들이 전화로 다음을 읽는 것을 듣는 것이 좋습니다.

그것은 제로에서 예상치 못한 상태를 말합니다 eff oh four zero oh .... OK lemme 당신에게 다시 읽습니다 ...

지나치게 복잡한 구성 파일

많은 구문 설탕에 대한 윙윙 거리는 구실로 구성을 구문 분석해야 할 필요성을 정당화하지 마십시오. 구문 분석시 추가 작업을 의미하더라도 사람들이 실제로 알고있는 형식을 사용하십시오. 가능할 때마다 INI 스타일 형식을 사용하려고합니다. 간단한 키-> 값 사전으로 무엇을 얻을 수 있는지 놀랄 것입니다.

구성 파일이 없습니다

프로그램을 사용하기 위해 쉘 스크립트 나 배치 파일을 작성하지 마십시오. 일반적인 옵션이 포함 된 파일을 가리키고 몇 가지 추가 인수 만 제공 할 수있는 수단을 제공하십시오.

'습식 바닥'표시 없음

일부 기능으로 인해 사용자가 어려움을 겪을 수있는 경우 (아마도 고급 사용자를위한 기능 일 수 있음) 명확하게 표시하십시오. 또한 누군가 뚱뚱한 손가락이 무언가를 입력하거나 잊어 버린 경우 온라인 문서에 매우 친숙한 링크를 인쇄하도록 프로그램하십시오. KVM을 통해 프로그램을 사용하고 잘라내어 붙여 넣을 수없는 사람을 상대하고있을 수 있습니다.

가능하면 (입력 유효성 검사와 일치) Google apporach를 사용하십시오.

foo --bar FILENME을 의미 했습니까? foo --bar 만 입력 했습니까?

파괴적인 지시에서 벗어날 수있는 방법을 제공하십시오

목표는 사용자에게 작동하지 않는 이유를 알려주고 몇 번 더 시도하도록하는 한편, 사용자가 실제로 원하지 않는 경우가 아니면 잠재적으로 파괴적인 일을하지 않도록하는 것입니다. 예를 들어 'nagging'을 끄는 스위치를 허용 -Y하거나 /Y단순히 '뚱뚱한 손가락'을 가진 사람에게는 탈출구를 허용하십시오.

아마 몇 가지 포인터를 잊어 버릴 것입니다. 대부분의 사람들이 실수를 피할 수있을 정도로 직관적 인 무언가를위한 '낮은 수준의'인터페이스를 만들기가 매우 어렵 기 때문에 자주이 문제를 처리합니다.

"이 파일 / 레코드를 삭제 하시겠습니까? 예 / 아니요". 예를 클릭 한 다음 빨간색 삭제 버튼을 "실제로"클릭했다는 전화를 받았으며 해당 데이터가 다시 필요합니다.)

특정 깨기 / 수정 예제를 얻는 것이 이것을 실현하는 것만 큼 중요하지 않다고 생각합니다.

• 사용자는 설명서를 읽거나 자습서를 보지 않습니다. 그들은 탐험을 통해 소프트웨어를 배웁니다.

그 탐사를 통해 그들이 무언가를 깨 뜨리면 프로그래머로서 위험을 경고하거나 처음부터 발생하지 않도록하는 것이 당신의 임무입니다. 나는 지금 어디에서 그것을 보았는지 기억이 나지 않지만, 나는 항상 내 소프트웨어 사용자에게 " 올바른 일을 쉽게 하기" 위해 노력한다 .

당신이 예제를 고집한다면 :

• 사용자가 소문자 이름을 입력하여 통합 코드를 위반하고 입력 유효성 검사를 수행하여 수정했습니다.
• 사용자는 올바른 버튼 만 표시하여 조치를 수행하고 수정 한 후 잘못된 버튼을 클릭 할 수있었습니다.
• 사용자는 X를하려고한다고 경고함으로써 실수로 X를 고칠 수있었습니다.

어디로 가는지 봅니까? :)

이번 주에 들어 본 것이 있습니다. 사용자는 "이벤트가 발생하면 알림을 보냅니다"기능을 요청합니다. 충분히 간단하고 개발자가 계속해서 구현합니다. 물론 첫 번째 질문은 "이 알림으로 무엇을 해결하려고합니까?"였습니다. 나는 그것에 들어 가지 않을 것입니다. 며칠 후 사용자가 개발자에 의해 중지되고 "이 알림을 받았습니다. 어떻게해야합니까?"라고 묻습니다.

나는이 Dilbert 만화를 기억하고 개발자에게 "사용자가 그 알림으로 무엇을해야하는지 알아 내기 위해 앱을 작성하라고"제안했다.

mpeterson이 말했듯이 사용자는 전문 분야에서 매우 경쟁력이 있습니다. 그들은 단지 소프트웨어 개발자 나 디자이너처럼 생각하지 않습니다.

나는 사용자가 바보라고 생각하지 않습니다. 그들은 당신이나 다른 프로그램을 전혀 사용하고 싶지 않습니다. 그들이 원하는 것은 그들의 일을 끝내는 것입니다. 길을 따라 그들을 도와주고 해를 끼치 지 않도록하십시오.

좋은 사용자 인터페이스를 갖고 적절한 학습 경험을 제공하는 것은 사용자가 나쁜 일을하는 것을 막기 위해 먼 길을갑니다.

• 좋은 사용자 인터페이스는 마찰이 없어야합니다.

  삭제를 확인하고 삭제를 수행하고 실행 취소 방법을 제공하기 위해 대화 상자 (고가의 작업 및 사용자가 잠시 후에 무시하는 작업)를 포기하는 대신.

• 좋은 사용자 인터페이스를 찾을 수 있어야합니다.

  Microsoft Office의 리본은 Word의 오래된 사용자가 자신의 방식을 변경하도록 강요하기 때문에 많은 결함이 있지만 리본은 인터페이스를 검색 가능하게 (즉, 쉽게 검색 할 수있게) 만드는 방법의 빛나는 예입니다.

• 좋은 코드와 같은 좋은 사용자 인터페이스는 설명이 필요합니다.

  아무도 매뉴얼을 읽지 않습니다. 사용자가 읽을 수있는 유일한 매뉴얼은 소프트웨어의 단계별 연습을 포함하는 PowerPoint 프레젠테이션이었습니다. Camtasia와 같은 비디오 도구를 사용하여 이러한 작업을 수행하는 것을 보았지만 단계를 쉽게 앞뒤로 넘길 수 있기 때문에 PowerPoint가 더 좋습니다.

사용자는 실수하지 않습니다. 사용 가능한 인터페이스를 만들지 못한 프로그래머에게 실수가 있습니다.

각 릴리스마다 사용성 테스트를 수행하십시오!