Trong thực tế, câu hỏi này là về những cảnh báo cần được thực hiện để nâng cao trải nghiệm người dùng chất lượng và giảm các cuộc gọi hỗ trợ có thể tránh được.
Câu trả lời:
Thiếu xác thực đầu vào thích hợp là một trong những điều có xu hướng dẫn đến khá nhanh chóng cho người dùng làm những việc "xấu" với ứng dụng của bạn, khi nó thực sự cần được lập trình viên xử lý.
Tôi đã thấy các ứng dụng cũ mà người dùng đã được đào tạo:
a-z0-9,emailtrường, nếu không các thư tiếp theo tới người dùng đó sẽ sử dụng bất cứ thứ gì trong trường và sẽ thất bạihttp://" được đặt trước địa chỉ webVân vân
Tất cả các vấn đề trên là những vấn đề cần được xử lý bởi nhà phát triển ứng dụng. Khi xác thực đầu vào của bạn về cơ bản là "đảm bảo người dùng biết định dạng của trường này và tin tưởng những gì họ đã nhập là đúng", thì những điều không mong muốn sẽ bị ràng buộc để tìm đường vào ứng dụng. Bên cạnh những tác động bảo mật rõ ràng, người dùng cũng mắc lỗi. Là những lập trình viên, chúng tôi thường sản xuất những sản phẩm tốt nhất của mình bằng cách cúi xuống để đảm bảo rằng người dùng không thể hiểu sai, bất kể họ có cố gắng đến mức nào!
http://điểm xác nhận. Ví dụ, ASDFthực hiện điều này theo cách ngây thơ và kết quả là bạn không thể lưu trữ các gói trên các tên miền sử dụng https://.
Tôi đã từng có một cuộc gọi hỗ trợ khách hàng vì ứng dụng của tôi vừa biến mất. Hóa ra họ đã mở một ứng dụng khác trên đầu trang.
... Tôi quyết định không đảm bảo điều đó không xảy ra lần nữa, vì chính tình trạng máy tính của người dùng đã gây ra sự cố chứ không phải ứng dụng. Bất cứ điều gì tôi có thể làm để khắc phục nó sẽ dẫn đến trải nghiệm người dùng kém cho người khác.
Hầu như mọi chương trình mà tôi viết đều được gọi hoàn toàn từ dòng lệnh. Tôi cũng đã viết một số thứ lạ hơn bắt đầu từ giao diện CLI và nhanh chóng phát triển thành một thứ gì đó giống như mọi thứ.
Vì vậy, tôi chỉ có thể nói cho những gì tôi biết. Đây là một số vấn đề phổ biến với các chương trình dòng lệnh:
Cách quá nhiều lựa chọn
Trừ khi bạn đang viết trình biên dịch hoặc trình chỉnh sửa dòng, hãy cố gắng giữ các tùy chọn giới hạn ở một màn hình đầy trên bộ đệm khung 80x25 khi --helphoặc /?được thông qua. Hoàn toàn ổn khi có nhiều lựa chọn hơn thế, nhưng chia chúng thành các danh mục phụ. Ví dụ
foo --help
foo --help option_name
Không có lựa chọn dài
Nó dễ nhớ foo --attach_to [argument] --volatile --verbosehơn nhiều so với việc nhớ foo -a [arg] -v +V. Điều này không phải lúc nào cũng có thể, nhưng trong hầu hết các trường hợp, nó là.
Không có xác nhận đầu vào
Hầu như mọi nền tảng đều có nhiều thư viện được thử, kiểm tra và đúng khi phân tích cú pháp và xác thực các đối số. Hầu hết mọi nền tảng đều có một lexer đã được thử nghiệm, thử nghiệm và xác thực để xác nhận đầu vào từ CLI. Sử dụng một, cái khác hoặc cả hai. Nếu chương trình của bạn tách biệt hoặc chia cho 0 do một thứ mà người dùng cung cấp, điều đó thật đáng xấu hổ.
Bạn có thể không cần một cái gì đó phức tạp như một từ vựng, có lẽ bạn chỉ có thể mã hóa chuỗi nếu bạn đang mong đợi công cụ theo một thứ tự nhất định với những thứ nhất định ở một số nơi nhất định.
Tôi thực sự đã nhận được một báo cáo lỗi một lần khi một số nguyên được mong đợi và ai đó đã gõ f*** my lifevào dấu ngoặc kép. Tôi đã không viết chương trình đó, tôi đã không may kế thừa nó.
Không có núm 'động từ'
Cho phép người dùng có kinh nghiệm dễ dàng khám phá cách loại bỏ tiếng ồn ra khỏi chương trình của bạn hơn hầu hết mọi người sẽ chịu đựng, nhưng mặc định chỉ in những thứ nghiêm trọng và quan trọng. Tôi không thể nói cho bạn biết tôi đã phải kích hoạt bao nhiêu lần stracechỉ để nhận ra rằng có gì đó bị lỗi do nó hoạt động trên luồng tệp NULL.
Bạn cũng có thể gói các xác nhận để tắt chúng thông qua NDEBUG hoặc các phương tiện khác vẫn dẫn đến kết quả được in hoặc ghi lại để người dùng tìm thấy.
Nói về các tệp nhật ký, hãy cố gắng đảm bảo bất cứ điều gì bạn đặt trong chúng đều có ý nghĩa (ít nhất là một chút) đối với người khác ngoài bạn. Nếu bắt đầu của mỗi mục là một ngày kỷ nguyên UNIX, bạn sẽ gặp phải sự thất vọng ở một người thực sự muốn giúp bạn tái tạo lỗi.
Không có 'bạn thân lỗi' trong chế độ gỡ lỗi
Rất nhiều chương trình cung cấp một số loại chuyển đổi 'gỡ lỗi' cung cấp thêm các cuộc trò chuyện liên quan đến những gì đang xảy ra với chương trình, nhưng rất ít chương trình cung cấp như sau:
Hoặc, có lẽ bạn thích nghe người ta đọc những điều sau qua điện thoại:
Nó nói điều kiện bất ngờ ở mức 0 oh oh bốn zero oh .... OK tôi sẽ đọc lại cho bạn ...
Các tập tin cấu hình quá phức tạp
Đừng biện minh cho việc cần phải phân tích cấu hình như một cái cớ để có được tiếng vang trên nhiều đường cú pháp. Cố gắng sử dụng một định dạng mà mọi người thực sự biết, ngay cả khi nó có nghĩa là làm thêm khi phân tích cú pháp. Tôi cố gắng sử dụng định dạng kiểu INI bất cứ khi nào có thể. Bạn sẽ ngạc nhiên về những gì bạn có thể rút ra với một từ điển khóa đơn giản-> giá trị.
Không có tập tin cấu hình
Đừng bắt mọi người viết tập lệnh shell hoặc tập tin bó chỉ để sử dụng chương trình của bạn, trừ khi nó được dự định là một công cụ cho cả hai tác vụ. Cung cấp cho tôi một phương tiện để chỉ vào một tệp chứa các tùy chọn thông thường của tôi và chỉ cung cấp một vài đối số bổ sung.
Không có dấu hiệu 'sàn ướt'
Nếu một số tính năng có thể khiến người dùng gặp rắc rối (có lẽ đó là dành cho người dùng nâng cao), hãy đánh dấu rõ ràng như vậy. Ngoài ra, nếu ai đó mập ngón tay nhập hoặc quên thứ gì đó, hãy để chương trình in một liên kết rất thân thiện với tài liệu trực tuyến. Bạn có thể giao dịch với ai đó đang sử dụng chương trình của bạn thông qua KVM và không thể cắt và dán.
Khi có thể, (điều này trùng với xác thực đầu vào) sử dụng apporach của Google:
Ý bạn là foo --bar FILENME, bạn chỉ gõ foo --bar
Cung cấp một cách thoát khỏi hướng dẫn phá hoại
Mục tiêu là cho người dùng biết lý do tại sao nó không hoạt động và để họ thử thêm vài lần nữa, trong khi đảm bảo rằng bạn không làm gì có khả năng phá hoại trừ khi có vẻ như người dùng thực sự muốn bạn làm điều đó. Chẳng hạn, cho phép một công tắc tắt 'cằn nhằn' -Yhoặc /Ynếu không thì cho phép một lối thoát cho một người chỉ đơn giản là có 'ngón tay mập'.
Có lẽ tôi đã quên một vài gợi ý. Tôi thường xuyên phải đối phó với vấn đề này vì rất khó để tạo giao diện 'cấp thấp' cho một cái gì đó đủ trực quan để hầu hết mọi người tránh mắc lỗi.
"Bạn có chắc chắn muốn xóa tệp / bản ghi này? Có / Không". Nhấp vào có và sau đó nhận được một cuộc gọi rằng nó "bấm nhầm" vào nút xóa màu đỏ và nó cần dữ liệu đó trở lại :)
Tôi không cảm thấy việc lấy các ví dụ phá vỡ / sửa lỗi cụ thể cũng quan trọng như nhận ra điều này:
Nếu thông qua cuộc thám hiểm đó, họ phá vỡ một cái gì đó, với tư cách là một lập trình viên, công việc của bạn là cảnh báo họ về sự nguy hiểm hoặc ngăn chặn nó xảy ra ngay từ đầu. Tôi không thể nhớ mình đã nhìn thấy nó ở đâu bây giờ, nhưng trong tâm trí tôi luôn cố gắng " làm cho mọi việc trở nên dễ dàng " cho người dùng phần mềm của tôi.
Nếu bạn nhấn mạnh vào các ví dụ:
Thấy nơi đang tới không? :)
Đây là một trong những tôi đã nghe trong tuần này. Một người dùng yêu cầu một tính năng "gửi cho tôi thông báo khi có sự kiện xảy ra". Đủ đơn giản và nhà phát triển đi trước và thực hiện nó. Chắc chắn, câu hỏi đầu tiên phải là "những gì đang cố gắng giải quyết bằng thông báo này?". Tôi sẽ không đi vào đó. Vài ngày sau, người dùng dừng lại bởi nhà phát triển và hỏi "Tôi đã nhận được thông báo này. Tôi phải làm gì với nó?".
Tôi nhớ truyện tranh Dilbert này và đề nghị với nhà phát triển "viết một ứng dụng để tìm hiểu xem người dùng nên làm gì với thông báo đó".
Giống như mpeterson đã nói, người dùng rất cạnh tranh trong lĩnh vực chuyên môn của họ. Họ chỉ không nghĩ như một nhà phát triển phần mềm hoặc nhà thiết kế.
Tôi không nghĩ người dùng là ngu ngốc. Họ không muốn sử dụng bất kỳ chương trình nào của bạn. Tất cả những gì họ muốn là hoàn thành công việc của họ. Giúp họ và ngăn chặn tác hại xảy ra với họ trên đường đi.
Có một giao diện người dùng tốt và cung cấp trải nghiệm học tập đầy đủ sẽ giúp ích rất nhiều cho việc ngăn chặn người dùng làm điều xấu.
Giao diện người dùng tốt nên không ma sát.
Thay vì đưa ra một hộp thoại (một thao tác đắt tiền và một thao tác mà người dùng bỏ qua sau một lúc) để xác nhận xóa, thực hiện xóa và đưa ra cách hoàn tác.
Giao diện người dùng tốt nên được khám phá.
Mặc dù dải băng trong Microsoft Office có nhiều lỗi vì nó buộc người dùng cũ của Word phải thay đổi cách thức, nhưng dải băng là một ví dụ sáng chói về cách bạn có thể tạo giao diện có thể khám phá (nghĩa là dễ khám phá).
Giao diện người dùng tốt, giống như mã tốt, nên tự giải thích.
Không ai đọc hướng dẫn. Hướng dẫn duy nhất tôi từng có cho người dùng của mình đọc là một bản trình bày PowerPoint có chứa các hướng dẫn từng bước của phần mềm. Tôi đã thấy những điều này được thực hiện với các công cụ video như Camtasia, nhưng PowerPoint tốt hơn vì bạn có thể dễ dàng lật ngược và chuyển qua các bước.
Người dùng không phạm sai lầm. Những sai lầm nằm ở lập trình viên đã thất bại trong việc tạo ra một giao diện có thể sử dụng được.
Vì vậy, làm các bài kiểm tra khả năng sử dụng với mỗi bản phát hành!