จะให้ผู้ใช้อ่านข้อความแสดงข้อผิดพลาดได้อย่างไร?

หากคุณตั้งโปรแกรมสำหรับผู้ชมที่ไม่มีความรู้ด้านเทคนิคคุณจะพบว่าตัวเองมีความเสี่ยงสูงที่ผู้ใช้จะไม่อ่านข้อความแสดงข้อผิดพลาดที่ได้รับการพูดอย่างถี่ถ้วน แต่เพียงคลิกที่ปุ่มแรกที่มีความหงุดหงิด

ดังนั้นฉันสงสัยว่าวิธีปฏิบัติที่ดีที่คุณสามารถแนะนำเพื่อช่วยให้ผู้ใช้อ่านข้อความแสดงข้อผิดพลาดของคุณจริง ๆ คือแทนที่จะสละมันไว้ข้าง ๆ แนวคิดที่ฉันคิดได้จะตกไปตามสายของ:

• การจัดรูปแบบของหลักสูตรช่วย; อาจเป็นข้อความสั้น ๆ ง่ายๆพร้อมปุ่ม "เรียนรู้เพิ่มเติม" ที่นำไปสู่ข้อความแสดงข้อผิดพลาดที่ยาวและละเอียดมากขึ้น
• มีข้อความแสดงข้อผิดพลาดทั้งหมดเชื่อมโยงไปยังบางส่วนของคู่มือผู้ใช้ (ค่อนข้างยากที่จะบรรลุ)
• ไม่ต้องออกข้อความแสดงข้อผิดพลาดเพียงปฏิเสธที่จะทำงาน (วิธี "Apple" ที่ค่อนข้างจัดการกับการป้อนข้อมูลผู้ใช้)

แก้ไข:ผู้ชมที่ฉันมีอยู่ในใจเป็นฐานผู้ใช้ที่ค่อนข้างกว้างซึ่งไม่ได้ใช้ซอฟต์แวร์บ่อยเกินไปและไม่ได้เป็นเชลย (เช่นไม่มีซอฟต์แวร์ภายใน บริษัท หรือชุมชนแคบ) รูปแบบทั่วไปของคำถามนี้ถูกถามในslashdotดังนั้นคุณอาจต้องการตรวจสอบคำตอบบางส่วน

นั่นเป็นคำถามที่ยอดเยี่ยมที่ควรค่าแก่ +1 จากฉัน คำถามนี้เรียบง่าย แต่ครอบคลุมหลายแง่มุมของธรรมชาติของผู้ใช้ปลายทาง มันช่วยลดปัจจัยหลายประการที่นี่ซึ่งจะเป็นประโยชน์ต่อคุณและตัวซอฟต์แวร์เองและแน่นอนสำหรับผู้ใช้ปลายทาง

• อย่าวางข้อความแสดงข้อผิดพลาดในแถบสถานะ - พวกเขาจะไม่อ่านแม้จะมีสีแจ๊สและอื่น ๆ ... พวกเขาจะคิดถึงพวกเขาเสมอ! ไม่ว่าคุณจะพยายามอย่างหนักเพียงใด ... ในขั้นตอนเดียวระหว่างการทดสอบ Win 95 UI ก่อนที่จะเปิดตัว MS ดำเนินการทดสอบเพื่ออ่าน UI ( ed - ควรสังเกตว่าข้อความดังกล่าวระบุไว้อย่างชัดเจนในบริบทของ 'Look under the chair' ) โดยมีบิล $ 100 ดอลล่าร์ติดไว้ที่ด้านล่างของเก้าอี้ที่ผู้เข้าร่วมนั่ง ... ไม่มีใครเห็นข้อความในแถบสถานะ!
• ทำให้ข้อความสั้นอย่าใช้คำที่ข่มขู่เช่น 'การแจ้งเตือน: ระบบพบปัญหา' ผู้ใช้จะต้องกดปุ่มตกใจและจะตอบโต้ ...
• ไม่ว่าคุณจะพยายามอย่างหนักเพียงใดอย่าใช้สีเพื่อระบุข้อความ ... ทางจิตวิทยามันเหมือนกับการโบกธงแดงไปยังวัว!
• ใช้คำที่ทำให้เกิดเสียงที่เป็นกลางเพื่อถ่ายทอดปฏิกิริยาที่น้อยที่สุดและวิธีดำเนินการต่อ!
• มันอาจจะดีกว่าที่จะแสดงกล่องโต้ตอบที่แสดงข้อความข้อผิดพลาดที่เป็นกลางและรวมถึงช่องทำเครื่องหมายที่ระบุว่า 'คุณต้องการดูข้อความแสดงข้อผิดพลาดเหล่านี้เพิ่มเติมในอนาคตหรือไม่' สิ่งสุดท้ายที่ผู้ใช้ต้องการคือการทำงาน ในช่วงกลางของซอฟต์แวร์ที่ถูกโจมตีด้วยข้อความป๊อปอัพพวกเขาจะผิดหวังและจะถูกปิดโดยแอพพลิเคชั่น! หากช่องทำเครื่องหมายถูกทำเครื่องหมายให้บันทึกลงในไฟล์แทน ...
• แจ้งให้ผู้ใช้ทราบถึงข้อผิดพลาดที่จะเกิดขึ้นซึ่งหมายถึง ... การฝึกอบรมและเอกสารประกอบ ... ตอนนี้นี่เป็นวิธีที่ยุ่งยากในการข้าม ... คุณไม่ต้องการให้พวกเขาคิดว่าจะมี เป็น 'ปัญหา' หรือ 'บกพร่อง' และสิ่งที่ต้องทำในกรณีที่ ... พวกเขาต้องไม่ทราบว่าจะมีข้อผิดพลาดที่เป็นไปได้หากินอย่างแน่นอน
• อย่ากลัวที่จะขอคำติชมเมื่อเกิดเหตุการณ์ไม่ปกติเช่น 'เมื่อหมายเลขข้อผิดพลาด 1304 ปรากฏขึ้นคุณจะตอบสนองอย่างไร? การตีความของคุณคืออะไร - โบนัสซึ่งผู้ใช้ปลายทางอาจให้คำอธิบายที่สอดคล้องกันมากขึ้นแทน 'ข้อผิดพลาด 1304 วัตถุฐานข้อมูลหายไป!' แทนพวกเขาอาจพูดว่า 'ฉันคลิกที่สิ่งนี้' ดังนั้นใครบางคนดึงสายเคเบิลเครือข่ายของเครื่องโดยไม่ตั้งใจ 'นี้จะเบาะแสคุณในการที่จะจัดการกับมันและอาจแก้ไขข้อผิดพลาดที่จะพูดว่า' Ooops เชื่อมต่อเครือข่ายตัดการเชื่อมต่อ '... คุณได้รับการเลื่อน
• สุดท้าย แต่ไม่ท้ายสุดหากคุณต้องการกำหนดเป้าหมายไปยังผู้ชมต่างประเทศคำนึงถึงความเป็นสากลของข้อความแสดงข้อผิดพลาด - นั่นเป็นสาเหตุที่ทำให้เป็นกลางเพราะมันจะง่ายกว่าในการแปลหลีกเลี่ยงคำพ้องคำสแลง ฯลฯ ซึ่งจะทำให้ การแปลที่ไร้ความหมาย - ยกตัวอย่างเช่นFiat Ford บริษัท ผลิตรถยนต์กำลังขายยี่ห้อFiat Ford Pinto แต่สังเกตว่าไม่มีการขายเกิดขึ้นในอเมริกาใต้ปรากฏออกมา Pinto เป็นคำสแลงที่ 'อวัยวะเพศชายเล็ก' และไม่มียอดขาย ...
• ( ed ) จัดทำรายการรายการข้อความแสดงข้อผิดพลาดที่คาดหวังในส่วนที่แยกต่างหากของเอกสารที่มีชื่อว่า 'ข้อความผิดพลาด' หรือ 'การแก้ไขที่ถูกต้อง' หรือที่คล้ายกันโดยระบุหมายเลขข้อผิดพลาดตามลำดับที่ถูกต้อง ..
• ( ed ) ขอบคุณVictor Hurdugaciสำหรับการป้อนข้อมูลของเขาเก็บข้อความที่สุภาพอย่าทำให้ผู้ใช้ปลายทางรู้สึกงี่เง่า สิ่งนี้ขัดกับคำตอบของJack Marchettiหากฐานผู้ใช้เป็นสากล ...

แก้ไข:ขอขอบคุณคำขอบคุณเป็นพิเศษกับgnibblerที่กล่าวถึงจุดสำคัญอย่างยิ่งเช่นกัน!

• อนุญาตให้ผู้ใช้ปลายทางสามารถเลือก / คัดลอกข้อความแสดงข้อผิดพลาดเพื่อให้สามารถทำได้หากต้องการให้ส่งอีเมลไปยังทีมสนับสนุนช่วยเหลือหรือทีมพัฒนา

แก้ไข # 2:ฉันไม่ดี! อ๊ะขอบคุณDanMที่พูดถึงเรื่องรถฉันได้ชื่อมาผสมกันมันคือ Ford Pinto ... ฉันไม่ดี ...

แก้ไข # 3:มีการเน้นโดยedเพื่อระบุการเพิ่มหรือภาคผนวกและให้เครดิตแก่ผู้อื่นสำหรับอินพุตของพวกเขา ...

แก้ไข # 4:เพื่อตอบสนองต่อความคิดเห็นของ Ken - นี่คือสิ่งที่ฉันใช้ ... ไม่มันไม่ใช้สีมาตรฐานของ Windows ที่เป็นกลาง ... อย่าไปหาสีฉูดฉาด! ติดกับสีเทาด้านหลังปกติด้วยข้อความสีดำซึ่งเป็นแนวทาง GUI มาตรฐานปกติในข้อกำหนดของ Microsoft .. ดูUX Guidelines ( ed )

หากคุณยืนยันสีฉูดฉาดอย่างน้อยให้คำนึงถึงผู้ใช้ที่ตาบอดสีเช่นการเข้าถึงซึ่งเป็นอีกหนึ่งปัจจัยสำคัญสำหรับผู้ที่มีความพิการการขยายข้อความบนหน้าจอข้อความแสดงข้อผิดพลาดที่เป็นมิตรกับผู้ตาบอดสีพวกเขา อาจมีความไวต่อสีฉูดฉาดและโรคลมชักเช่นกัน ... ผู้ที่อาจประสบกับสีใดสีหนึ่งที่อาจทำให้เกิดการจับกุม ...

แสดงข้อความเหล่านั้น ความขยันหมั่นเพียรและทั้งหมด แต่บันทึกข้อผิดพลาดทุกไฟล์ ผู้ใช้ไม่สามารถจำสิ่งที่พวกเขากำลังทำหรือสิ่งที่เกิดข้อผิดพลาดเป็นวินาทีหลังจากเหตุการณ์มันก็เหมือนบัญชีพยานผู้กระทำผิด

ให้วิธีที่ดีในการอนุญาตให้ส่งอีเมลหรืออัปโหลดบันทึกให้คุณเพื่อให้คุณสามารถช่วยเหลือพวกเขาในการตรวจสอบปัญหา หากเป็นเว็บแอปพลิเคชัน: ดียิ่งขึ้นคุณสามารถรับข้อมูลเกี่ยวกับสถานการณ์ข้างหน้าของใครก็ตามที่รายงานปัญหา

คำตอบสั้น ๆ : คุณทำไม่ได้

คำตอบสั้น ๆ น้อยลง: ทำให้พวกเขามองเห็นมีความเกี่ยวข้องและตามบริบท (เน้นสิ่งที่พวกเขาทำผิดพลาด) แต่ถึงกระนั้นคุณกำลังต่อสู้กับการต่อสู้ที่แพ้ ผู้คนไม่ได้อ่านบนหน้าจอคอมพิวเตอร์สแกนและพวกเขาได้รับการฝึกฝนให้คลิกปุ่มจนกว่ากล่องโต้ตอบจะหายไป

เราใส่กราฟิกที่น่าจดจำอย่างง่ายในกล่องข้อผิดพลาด: ไม่ใช่ไอคอนบิตแมปขนาดใหญ่พอสมควรและไม่มีอะไรเหมือนไอคอนข้อความมาตรฐานของ Windows ไม่มีใครสามารถจดจำถ้อยคำของกล่องข้อความ (ส่วนใหญ่จะไม่ได้อ่านถ้ากล่องมีปุ่ม "ตกลง" ที่พวกเขาสามารถกด) แต่คนส่วนใหญ่จำภาพที่เห็นได้ ดังนั้นฝ่ายสนับสนุนของเราสามารถถามลูกค้าว่า "คุณเห็นคนที่ดื่มกาแฟหรือไม่" หรือ "คุณเห็นโต๊ะว่างหรือไม่" อย่างน้อยเราก็รู้อย่างคร่าว ๆ ว่าเกิดอะไรขึ้น

การเขียนข้อความแสดงข้อผิดพลาดตลก / หยาบคาย / บุคคลขึ้นอยู่กับฐานผู้ใช้ของคุณ

ตัวอย่างเช่นฉันเขียนแอปพลิเคชันที่อนุญาตให้พนักงานฝ่ายทรัพยากรบุคคลของเราติดตามวันที่เช่า / พนักงานดับเพลิงได้ดีขึ้น [เราเป็น บริษัท เล็ก ๆ สบาย ๆ มาก]

เมื่อพวกเขาป้อนวันที่ผิดฉันจะเขียน:

เฮ้ลาโง่เรียนรู้วิธีป้อนวันที่!

แก้ไข: แน่นอนข้อความที่เป็นประโยชน์มากขึ้นคือการพูดว่า: "โปรดป้อนวันที่เป็น mm / dd / yyyy" หรืออาจจะเป็นรหัสเพื่อลองและคิดออกสิ่งที่พวกเขาป้อนและถ้าพวกเขาป้อน "blahblah" เพื่อแสดงข้อผิดพลาด อย่างไรก็ตามนี่เป็นแอปพลิเคชั่นขนาดเล็กมากสำหรับบุคคล HR ที่ฉันรู้จักเป็นการส่วนตัว ดังนั้นผู้คนอีกครั้งอ่านบรรทัดแรกของโพสต์นี้: ขึ้นอยู่กับฐานผู้ใช้ของคุณ ...

ฉันเพิ่งทำงานเกี่ยวกับโครงการสถาบันศิลปะดังนั้นข้อความแสดงข้อผิดพลาดจึงถูกส่งไปยังผู้ชมเช่น:

ศิลปะส่วนใหญ่ก่อนยุคบาโรกไม่ได้ลงนาม อย่างไรก็ตามเราอยู่นอกเหนือจากยุคบาร็อคในขณะนี้ดังนั้นฟิลด์ทั้งหมดจะต้องเสร็จสมบูรณ์

โดยทั่วไปแล้วจะส่งให้กับผู้ชมของคุณหากเป็นไปได้และหลีกเลี่ยงการเบื่อเนื่องจากข้อผิดพลาดทั่วไปที่พบโดยทั่วไปเช่น: "โปรดป้อนอีเมล" หรือ "โปรดป้อนอีเมลที่ถูกต้อง"

การแจ้งเตือน / ป๊อปอัปนั้นน่ารำคาญนั่นเป็นสาเหตุที่ทุกคนกดปุ่มแรกที่เห็น

ทำให้มันน้อยที่น่ารำคาญ ตัวอย่าง: หากผู้ใช้ป้อนวันที่ไม่ถูกต้องหรือป้อนข้อความที่คาดว่าจะมีตัวเลขดังนั้นไม่ต้องป๊อปอัพข้อความเพียงแค่ไฮไลต์ฟิลด์และเขียนข้อความที่อยู่รอบ ๆ

ทำให้กล่องข้อความที่กำหนดเอง อย่าใช้กล่องข้อความเริ่มต้นของระบบตัวอย่างเช่นกล่องข้อความ Windows XP น่ารำคาญตัวเอง สร้างกล่องข้อความสีใหม่พร้อมสีพื้นหลังที่แตกต่างจากค่าเริ่มต้นของระบบ

สำคัญมาก: ไม่ยืนยัน กล่องข้อความบางกล่องใช้กล่องโต้ตอบ Modal และยืนยันให้คุณอ่านมันเป็นเรื่องที่น่ารำคาญมาก หากคุณสามารถทำให้กล่องข้อความปรากฏเป็นข้อความเตือนมันจะเป็นการดีกว่าตัวอย่างเช่นข้อความ Stack Overflow ที่ปรากฏอยู่ด้านบนของหน้าแจ้งให้ทราบ แต่ไม่น่ารำคาญ

UPDATEทำให้ข้อความที่มีความหมายและเป็นประโยชน์
ตัวอย่างเช่นอย่าเขียนบางอย่างเช่น "ไม่พบคีย์บอร์ดกด F1 เพื่อดำเนินการต่อ"

การออกแบบ UI ที่ดีที่สุดจะเป็นที่ที่คุณแทบไม่เคยแสดงข้อความแสดงข้อผิดพลาด ซอฟต์แวร์ควรปรับให้เข้ากับผู้ใช้ ด้วยการออกแบบประเภทนั้นข้อความแสดงข้อผิดพลาดจะแปลกใหม่และจะดึงดูดความสนใจของผู้ใช้ หากคุณส่งข้อความโต้ตอบแบบไม่มีเหตุผลให้กับผู้ใช้คุณจะต้องฝึกให้ผู้ใช้ไม่สนใจข้อความของคุณอย่างชัดเจน

ในความเห็นและประสบการณ์ของฉันมันคือผู้ใช้ระดับสูงที่ไม่อ่านข้อความแสดงข้อผิดพลาด ผู้ชมที่ไม่มีเทคนิคที่ฉันรู้จักอ่านข้อความบนหน้าจออย่างระมัดระวังที่สุดและปัญหา ณ จุดนี้ส่วนใหญ่คือพวกเขาไม่เข้าใจ

ประเด็นนี้อาจเป็นสาเหตุของประสบการณ์ของคุณเพราะเมื่อถึงจุดหนึ่งพวกเขาจะหยุดอ่านเพราะ "พวกเขาไม่เข้าใจเลย" ดังนั้นงานของคุณจึงง่าย:

ทำให้ข้อความแสดงข้อผิดพลาดนั้นเข้าใจง่ายที่สุดและเก็บชิ้นส่วนทางเทคนิคไว้ใต้ฝากระโปรง

ตัวอย่างเช่นฉันถ่ายโอนข้อความเช่นนี้:

ORA-00237: การดำเนินการสแน็ปช็อตไม่อนุญาต: ไฟล์ควบคุมที่สร้างขึ้นใหม่สาเหตุ: มีความพยายามเรียกใช้ cfileMakeAndUseSnapshot ด้วยไฟล์ควบคุมที่เมาท์อยู่ซึ่งสร้างขึ้นใหม่ด้วย CREATE CONTROLFILE การดำเนินการ: เมาท์ไฟล์ควบคุมปัจจุบันและลองดำเนินการอีกครั้ง

เพื่อสิ่งที่ชอบ:

ไม่สามารถดำเนินการขั้นตอนนี้เนื่องจากปัญหาชั่วคราวกับฐานข้อมูล กรุณาติดต่อ (ผู้ดูแลระบบของคุณ | ฝ่ายช่วยเหลือ | ใครก็ตามที่สามารถติดต่อผู้พัฒนาหรือผู้ดูแลระบบเพื่อแก้ปัญหา) ขออภัยในความไม่สะดวก.

แสดงผู้ใช้ว่าข้อความแสดงข้อผิดพลาดมีความหมายและเป็นวิธีการช่วยเหลือผู้ใช้และพวกเขาจะอ่าน หากเป็นเพียงข้อความไร้สาระศัพท์แสงหรือไร้สาระทั่วไปพวกเขาจะได้เรียนรู้ที่จะยกเลิกพวกเขาอย่างเงียบ ๆ

ฉันได้เรียนรู้ว่าเป็นวิธีปฏิบัติที่ดีมากในการรวมกล่องโต้ตอบข้อผิดพลาดพร้อมการกระทำเริ่มต้นเพื่อส่ง (เช่นผ่านทางอีเมล) ข้อมูลการวินิจฉัยโดยละเอียดหากคุณตอบอีเมลเหล่านั้นอย่างรวดเร็วด้วยข้อมูลที่มีค่าหรือวิธีแก้ปัญหา

นี่ยังเป็นเครื่องมือการเรียนรู้ที่ยอดเยี่ยม ในรุ่นอนาคตคุณสามารถแก้ปัญหาที่ทราบหรืออย่างน้อยให้ข้อมูลการแก้ปัญหาในสถานที่ จนกว่าผู้ใช้จะได้เรียนรู้ว่าข้อความนี้เกิดจาก X และปัญหาสามารถแก้ไขได้โดย Y - ทั้งหมดเพราะมีคนอธิบายให้พวกเขา

แน่นอนว่าสิ่งนี้จะไม่ทำงานกับแอปพลิเคชั่นขนาดใหญ่ แต่ทำงานได้ดีมากในแอปพลิเคชันระดับองค์กรที่มีผู้ใช้ไม่กี่ร้อยคนและในแบบที่ไม่ติดมัน

แก้ไข:

เนื่องจากคุณมีฐานผู้ใช้ที่กว้างขวางฉันแนะนำให้จัดทำซอฟต์แวร์ที่ทำในสิ่งที่ผู้ใช้ / สามารถคาดหวังได้เช่น อย่าแสดงข้อความข้อผิดพลาดหากหมายเลขโทรศัพท์มีรูปแบบไม่ดีให้ทำการฟอร์แมตใหม่

ฉันชอบซอฟต์แวร์ที่ไม่ทำให้ฉันคิดว่าและเมื่อใดก็ตามที่ไม่มีสิ่งใดที่คุณ (นักพัฒนา) สามารถทำเพื่อตีความเจตนาของฉันได้ให้ข้อความ (และตรวจสอบโดยผู้ใช้จริง) เป็นอย่างดี

เป็นความรู้ทั่วไปที่ผู้คนไม่อ่านเอกสาร (คุณอ่านคำแนะนำแบบย้อนกลับไปทำเมื่อคุณเสียบปลั๊กเครื่องใช้ในบ้านหรือไม่) พวกเขาลองวิธีรับผลลัพธ์อย่างรวดเร็วเมื่อล้มเหลวคุณต้องดึงดูดความสนใจของตน (เช่น ปุ่มเริ่มต้นปิดการใช้งานในขณะที่) ที่มีความหมายและเป็นประโยชน์ข้อมูล พวกเขาไม่สนใจความล้มเหลวของซอฟต์แวร์ของคุณพวกเขาต้องการได้ผลลัพธ์

ทำให้พวกเขาสนุก (ดูเหมือนว่าจะเกี่ยวข้องเนื่องจากไซต์ที่เราใช้อยู่นั้น :))

ในการเริ่มต้นเขียนข้อความแสดงข้อผิดพลาดที่ผู้ใช้สามารถเข้าใจได้จริง "ข้อผิดพลาด: 1023" ไม่ใช่ตัวอย่างที่ดี ฉันคิดว่าวิธีที่ดีกว่าคือการบันทึกข้อผิดพลาดแทนที่จะแสดงให้ผู้ใช้เห็นด้วยรหัส "แฟนซี" หรือหากการบันทึกไม่สามารถทำได้ให้วิธีที่เหมาะสมแก่ผู้ใช้ในการส่งรายละเอียดข้อผิดพลาดไปยังฝ่ายสนับสนุน

ยังสั้นและชัดเจนพอ อย่ารวมรายละเอียดทางเทคนิคบางอย่าง อย่าแสดงข้อมูลที่ไม่สามารถใช้ได้ หากเป็นไปได้ให้วิธีแก้ไขปัญหาสำหรับข้อผิดพลาด หากไม่ได้ระบุเส้นทางเริ่มต้นควรดำเนินการ

หากแอปพลิเคชันของคุณเป็นเว็บแอปการออกแบบหน้าข้อผิดพลาดที่กำหนดเองเป็นความคิดที่ดี พวกเขาทำให้ผู้ใช้เครียดน้อยลงยกตัวอย่างเช่น คุณสามารถรับแนวคิดบางอย่างเกี่ยวกับวิธีออกแบบหน้าข้อผิดพลาดที่ดีได้ที่นี่: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

สิ่งหนึ่งที่ฉันต้องการเพิ่ม

ใช้คำกริยาสำหรับปุ่มการกระทำของคุณเพื่อปิดข้อความแสดงข้อผิดพลาดแทนที่จะใช้อัศเจรีย์ตัวอย่างเช่นอย่าใช้ "Ok!" "ปิด" ฯลฯ

เคล็ดลับที่ดีอย่างหนึ่งที่ฉันได้เรียนรู้คือคุณควรเขียนกล่องโต้ตอบเหมือนบทความในหนังสือพิมพ์ ไม่ได้อยู่ในขนาดความรู้สึก แต่อยู่ในระดับความสำคัญ ให้ฉันอธิบาย

คุณควรเขียนสิ่งที่สำคัญที่สุดในการอ่านก่อนและให้ข้อมูลรายละเอียดเพิ่มเติมที่สอง

ในคำอื่น ๆ นี้ไม่ดี:

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Do you want to retry opening the file?

ให้เปลี่ยนลำดับ:

Problem loading file, do you want to retry?

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

ด้วยวิธีนี้ผู้ใช้สามารถอ่านได้มากเท่าที่เขาต้องการหรือรบกวนและยังมีความคิดเกี่ยวกับสิ่งที่ถูกถาม

ดูการตอบสนองของผู้ใช้ Slashdot ได้ที่นี่ที่นี่

ยกเว้นว่าคุณสามารถให้ผู้ใช้งานได้ง่ายไม่ต้องกังวลกับการแสดงข้อความข้อผิดพลาดให้ผู้ใช้ ไม่มีประเด็นเพราะผู้ใช้ 90% ไม่สนใจสิ่งที่พูด

ในทางกลับกันถ้าคุณทำได้แสดงวิธีแก้ปัญหาที่มีประโยชน์ให้กับผู้ใช้จริง ๆ แล้ววิธีหนึ่งที่จะบังคับให้ผู้ใช้อ่านมันคือการทำให้ปุ่ม OK เปิดใช้งานหลังจาก 10 วินาทีหรือมากกว่านั้น เรียงลำดับว่า Firefox ทำอย่างไรเมื่อใดก็ตามที่คุณพยายามติดตั้งปลั๊กอินใหม่

หากเป็นความผิดพลาดทั้งหมดที่คุณไม่สามารถกู้คืนได้อย่างสง่างามให้แจ้งผู้ใช้ด้วยคำศัพท์ธรรมดา ๆ ที่พูดว่า:

" ฉันขอโทษที่เราเมาแล้วเราอยากส่งข้อมูลบางอย่างเกี่ยวกับความผิดพลาดนี้คุณจะอนุญาตให้เราทำเช่นนั้นใช่หรือไม่ใช่ / ไม่ "

นอกจากนี้พยายามอย่าทำให้ข้อความแสดงข้อผิดพลาดของคุณยาวเกินหนึ่งประโยค เมื่อผู้คน (ฉันรวมอยู่) เห็นทั้งย่อหน้าพูดคุยเกี่ยวกับข้อผิดพลาดใจของฉันเพิ่งจะปิด

ด้วยโซเชียลมีเดียและข้อมูลมากเกินไปจิตใจของผู้คนก็หยุดเมื่อพวกเขาเห็นกำแพงข้อความ

แก้ไข:

บางคนเคยแนะนำให้ใช้แถบการ์ตูนพร้อมกับข้อความที่คุณต้องการแสดง เช่นบางอย่างจากDilbertที่อาจใกล้เคียงกับชนิดของข้อผิดพลาดที่คุณอาจมี

จากประสบการณ์ของฉัน: คุณไม่ได้รับผู้ใช้ (โดยเฉพาะที่ไม่ใช่ด้านเทคนิค) เพื่ออ่านข้อความแสดงข้อผิดพลาด ไม่ว่าคุณจะแสดงข้อความที่ชัดเจนและเข้าใจเป็นตัวหนาสีแดงและกะพริบผู้ใช้ส่วนใหญ่จะคลิกอะไรที่ไม่คุ้นเคยแม้ว่ามันจะเป็น "คุณต้องการลบทุกอย่างจริงๆหรือไม่" ฉันเห็นผู้ใช้คลิก "ปิดหน้าต่าง" - ไอคอนแทน "ตกลง" หรือ "ยกเลิก" แม้ว่าพวกเขาจะไม่รู้ตัวเลือกที่เลือกโดยทำเช่นนั้น ...

หากคุณต้องการบังคับให้ผู้ใช้อ่านสิ่งที่คุณกำลังแสดงจริงๆฉันขอแนะนำ JavaScript-Countdown จนกว่าปุ่มจะสามารถคลิกได้ ด้วยวิธีนี้ผู้ใช้หวังว่าจะใช้เวลารอเพื่ออ่านสิ่งที่เขาควรจะเป็นจริง ระวังให้ดี: ผู้ใช้ส่วนใหญ่จะรู้สึกรำคาญมากกว่า :)

ฉันชอบความคิดของคุณเกี่ยวกับลิงก์ "read more" ถึงแม้ว่าฉันสงสัยว่าจะทำให้ผู้ใช้สนใจมากกว่าที่ต้องการกำจัดข้อความโดยทั้งหมดหมายความว่า ...

สำหรับบันทึก: มีผู้ใช้ที่อ่านข้อความแสดงข้อผิดพลาด แต่กลัวว่าจะไม่ทำอะไรกับมัน ฉันเคยมีฝ่ายสนับสนุนซึ่งลูกค้าจะอ่านข้อความแสดงข้อผิดพลาดให้ฉันถามฉันว่าเขาควรทำอย่างไร "เอาละทางเลือกของคุณคืออะไร" ฉันถาม "หน้าต่างมีปุ่ม 'ตกลง' เท่านั้นเขาตอบ ... mmh, ยากมาก :)

ฉันมักจะแสดงข้อผิดพลาดเป็นสีแดง (เมื่อการออกแบบอนุญาต)

Red ย่อมาจาก "alert" และอื่น ๆ ดังนั้นจึงอ่านได้บ่อยขึ้น

เพื่อตอบคำถามของคุณโดยตรง: อย่าให้โปรแกรมเมอร์เขียนข้อความแสดงข้อผิดพลาด หากคุณทำตามคำแนะนำเพียงส่วนเดียวคุณจะสามารถประหยัดค่าใช้จ่ายในการช่วยเหลือทางเทคนิคได้หลายพันล้านชั่วโมง

อย่างไรก็ตามเป้าหมายที่แท้จริงควรออกแบบแอปพลิเคชันของคุณเพื่อให้ผู้ใช้ไม่สามารถทำผิดพลาดได้ อย่าปล่อยให้พวกเขาดำเนินการที่นำไปสู่การนวดผิดพลาดและต้องการให้พวกเขาสำรอง ตัวอย่างง่ายๆในเว็บฟอร์มที่ต้องการให้กรอกข้อมูลในฟิลด์ทั้งหมดแทนที่จะแสดงข้อความแสดงข้อผิดพลาดเมื่อผู้ใช้คลิกที่ปุ่มส่งอย่าเปิดใช้งานปุ่มส่งจนกว่าฟิลด์ทั้งหมดจะมีเนื้อหาที่ถูกต้อง มันหมายถึงการทำงานมากขึ้นที่ด้านหลัง แต่มันส่งผลให้ประสบการณ์การใช้งานที่ดีขึ้น

แน่นอนว่าเป็นโลกในอุดมคติ บางครั้งข้อผิดพลาดของโปรแกรมจะหลีกเลี่ยงไม่ได้ เมื่อเกิดขึ้นคุณต้องให้ข้อมูลที่ชัดเจนสมบูรณ์และมีประโยชน์และที่สำคัญที่สุดคืออย่าเปิดเผยระบบให้กับผู้ใช้และไม่โทษผู้ใช้สำหรับการกระทำของพวกเขา

ข้อความแสดงข้อผิดพลาดที่ดีควรมี:

1. ปัญหาคืออะไรและสาเหตุที่เกิดขึ้น
2. วิธีแก้ไขปัญหา

หนึ่งในสิ่งที่แย่ที่สุดที่คุณสามารถทำได้คือเพียงส่งข้อความแสดงข้อผิดพลาดของระบบไปยังผู้ใช้ ตัวอย่างเช่นเมื่อโปรแกรม Java ของคุณเกิดข้อยกเว้นอย่าส่งโปรแกรมเมอร์ไปยัง UI และเปิดเผยให้ผู้ใช้ทราบ จับมันและมีข้อความที่ชัดเจนที่สร้างขึ้นโดยนักพัฒนาช่วยเหลือผู้ใช้ของคุณที่คุณสามารถนำเสนอให้กับผู้ใช้ของคุณ

ฉันโชคดีที่ได้ทำงานครั้งสุดท้ายกับทีมโปรแกรมเมอร์ที่ไม่คิดว่าจะเขียนข้อความแสดงข้อผิดพลาดของตัวเอง เมื่อใดก็ตามที่พวกเขาพบว่าตัวเองอยู่ในสถานการณ์ที่จำเป็นต้องใช้และโปรแกรมไม่สามารถออกแบบมาเพื่อหลีกเลี่ยงมัน (มักจะเป็นเพราะทรัพยากรที่ จำกัด ) พวกเขามาหาฉันเสมออธิบายสิ่งที่พวกเขาต้องการและให้ฉันสร้างข้อความแสดงข้อผิดพลาด ชัดเจนและตามสไตล์ บริษัท ถ้านั่นเป็นความคิดเริ่มต้นของโปรแกรมเมอร์ทุกคนโลกแห่งการคำนวณจะเป็นสถานที่ที่ดีกว่ามาก

ข้อผิดพลาดน้อยลง

หากแอปพลิเคชั่นพ่นอาเจียนมาที่คุณเป็นประจำคุณจะมีภูมิคุ้มกันต่อข้อผิดพลาดและทำให้เกิดการระคายเคืองพื้นหลัง หากข้อผิดพลาดเป็นเหตุการณ์ที่หายากก็จะดึงดูดความสนใจมากขึ้น

อะไรก็ตามที่ไม่ได้เป็นข้อตกลงที่สำคัญทิ้งคำเตือนเหล่านั้นค้นหาวิธีการทำความเข้าใจเจตนาของผู้ใช้ทำการตัดสินใจในทุกที่ที่ทำได้ ฉันมีแอพพลิเคชั่นบางตัวที่ยังคงความคล่องตัวในวิธีนี้ นักพัฒนาเห็นว่าทุกข้อผิดพลาดมีความสำคัญ แต่สิ่งนี้ไม่เป็นความจริงจากมุมมองของผู้ใช้ ค้นหาการตอบสนองทั่วไปของผู้ใช้ต่อปัญหาและจับภาพนั้นนำไปใช้เป็นการตอบสนองของคุณ

หากคุณต้องการแจ้งข้อผิดพลาด: สั้นกระชับและหวาดกลัวต่ำไม่มีเครื่องหมายอัศเจรีย์ ย่อหน้าที่จะล้มเหลว

ไม่มีกระสุนเงิน แต่คุณต้องวิศวกรสังคมเพื่อทำข้อผิดพลาดที่สำคัญ

เราบอกผู้ใช้ว่าผู้จัดการของพวกเขาได้รับการติดต่อแล้ว (ซึ่งเป็นเรื่องโกหก) มันใช้งานได้ดีเกินไปและต้องถูกลบออก

การเพิ่มปุ่ม "ขั้นสูง" ที่เปิดใช้งานรายละเอียดทางเทคนิคเพิ่มเติมจะช่วยสร้างแรงจูงใจให้อ่านสำหรับกลุ่มเป้าหมายที่คิดว่าเป็นเทคนิค

ฉันขอแนะนำให้คุณให้ข้อเสนอแนะ (ระบุว่าผู้ใช้ทำผิด) ทันทีหลังจากทำผิดพลาด (ตัวอย่างเช่นเมื่อป้อนค่าของเขตข้อมูลวันที่ให้ตรวจสอบค่าและหากข้อมูลผิดให้ฟิลด์ป้อนข้อมูลแตกต่างกันโดยมองเห็น)

หากมีข้อผิดพลาดในหน้า (ฉันเพิ่มเติมในการพัฒนาเว็บดังนั้นฉันหมายถึงมันเป็น "หน้า" แต่มันอาจจะเรียกว่า "แบบฟอร์ม") แสดง "สรุปข้อผิดพลาด" อธิบายว่ามี เป็นข้อผิดพลาดและรายการหัวข้อย่อยของสิ่งที่เกิดข้อผิดพลาด อย่างไรก็ตามหากมีมากกว่า 5-6 คำต่อข้อความข้อความนั้นจะไม่สามารถอ่าน / เข้าใจได้

วิธีทำสถานะปุ่ม "คลิกที่นี่เพื่อพูดคุยกับช่างเทคนิคช่วยเหลือที่จะช่วยคุณแก้ไขปัญหานี้"

มีหลายเว็บไซต์ที่ให้ตัวเลือกในการพูดกับคนจริง

ฉันอ่านผู้สมัครเพื่อหาทางออกที่น่ากลัวที่สุดใน slashdot:

เราพบว่าวิธีเดียวที่จะทำให้ผู้ใช้รับผิดชอบต่อข้อผิดพลาดคือให้พวกเขาได้รับโทษจากการบังคับให้ข้อผิดพลาดหายไป สำหรับผู้เริ่มต้นที่เป็นไปได้ข้อผิดพลาดจะไม่ปิดลงหากเราป้อนรหัสผ่านของผู้ดูแลระบบเพื่อให้หายไปและหากพวกเขารีบูตเพื่อกำจัดมัน (ตัวจัดการงานถูกปิดใช้งานในพีซีไคลเอนต์ทุกเครื่อง) เครื่องจะไม่เปิด แอปพลิเคชันที่ล้มเหลวเป็นเวลา 15 นาที แน่นอนว่าทั้งหมดนี้ขึ้นอยู่กับประเภทของผู้ใช้ที่คุณติดต่อด้วยเนื่องจากผู้ใช้ที่มีความเชี่ยวชาญด้านเทคนิคจะไม่ยอมรับระบบประเภทนี้ แต่หลังจากพยายามอย่างแท้จริงเป็นเวลาหลายปีเพื่อให้ผู้ใช้รับผิดชอบต่อการขัดข้องและทำให้แน่ใจว่าฝ่ายไอที เพื่อแก้ไขปัญหาก่อนที่จะจัดการยากเกินไปนี่เป็นขั้นตอนเดียวที่ใช้งานได้ ตอนนี้

"ATTENTION! ATTENTION! ถ้าคุณไม่อ่านข้อความแสดงข้อผิดพลาดคุณจะตาย!"

แม้จะมีคำแนะนำทั้งหมดในคำตอบที่ได้รับการยอมรับผู้ใช้ของฉันยังคงคลิกปุ่มแรกที่พวกเขาสามารถหาได้ ดังนั้นตอนนี้ฉันแสดงสิ่งนี้:

ผู้ใช้มีให้เลือกก่อนที่จะปรากฏปุ่มตกลง

หากเขาเลือกตัวเลือกที่ 3 เขาสามารถทำต่อได้