AJAX ที่ซ่อนไว้นั้นปลอดภัยแค่ไหนที่ขอประสิทธิภาพปลอมมา?


48

คำขอ AJAX ที่ซ่อนอยู่คืออะไร

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

นี่คือตัวอย่างของคำขอ AJAX ที่ไม่ปิดกั้น

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

เพื่อชี้แจงนี่คือตัวอย่างของการปิดกั้นการร้องขอ AJAX;

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

ความแตกต่างระหว่างสองสถานการณ์ข้างต้นคือการตั้งค่า AJAX ที่ไม่บล็อกไม่มีผลตอบรับการทำงานและการตั้งค่า AJAX บล็อก

ความเสี่ยงของคำขอ AJAX ที่ซ่อนอยู่

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

ตัวอย่างเช่นตัวอย่างที่ไม่บล็อก

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

อีกตัวอย่างหนึ่งคือการบล็อก

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

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

แล้วทำไมมันถึงได้รับความนิยม?

Facebook, Google, Microsoft, ฯลฯ .. โดเมนขนาดใหญ่เหล่านี้กำลังใช้คำขอ AJAX แบบไม่มีการปิดกั้นเพิ่มมากขึ้นเพื่อให้การทำงานปรากฏว่ามีการดำเนินการทันที ผมเคยเห็นการเพิ่มขึ้นในการแก้ไขแบบฟอร์มที่ได้ไม่มีการบันทึกหรือปุ่มส่ง ทันทีที่คุณออกจากสนามหรือกด Enter บันทึกค่าแล้ว ไม่มีโปรไฟล์ของคุณได้รับการปรับปรุงข้อความหรือขั้นตอนการบันทึก

คำขอ AJAX นั้นไม่แน่นอนและไม่ควรถือว่าสำเร็จจนกว่าจะเสร็จ แต่มีเว็บแอปพลิเคชันหลัก ๆ จำนวนมากที่ใช้งานเช่นนั้น

เว็บไซต์เหล่านี้ที่ใช้การโทร AJAX ที่ไม่มีการบล็อกเพื่อจำลองแอปพลิเคชันที่ตอบสนองต่อความเสี่ยงที่ไม่จำเป็นในราคาที่ปรากฏอย่างรวดเร็วหรือไม่?

นี่เป็นรูปแบบการออกแบบที่เราทุกคนควรปฏิบัติตามเพื่อให้สามารถแข่งขันได้หรือไม่?


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

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

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

2
@Kilian ทั้งฉันอยากให้คนที่คิดว่าทุกอย่างผิดพลาดถ้าคนที่ "แดด" กำลังชกคุณและขโมยกระเป๋าเงินของคุณเมื่อสัญญาณแรกของปัญหา ดังนั้นขึ้นอยู่กับขนาดของปฏิกิริยาของหน้าต่อความล้มเหลว
Izkata

1
@ButtleButkus ฉันคิดว่าข้อความที่บันทึกเป็นข้อความใหม่ พวกเขาไม่ได้อยู่ที่นั่นเมื่อฉันถามคำถาม ฉันสังเกตเห็นว่า google ได้เพิ่มข้อเสนอแนะเพิ่มเติมเมื่อเร็ว ๆ นี้นั่นคือสิ่งที่กำลังทำอยู่ในพื้นหลัง
Reactgular

คำตอบ:


62

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

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

คำเตือนที่รอการ AJAX


8
จุดสุดท้ายนั้นเบราว์เซอร์ทั้งหมดทำตามค่าเริ่มต้นหรือไม่
Svish

ฉันไม่รู้ ฉันเพิ่งทดสอบบน IE9 และโครเมียมล่าสุด
Karl Bielefeldt

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

2
@hippietrail ดีคุณไม่สามารถทำให้ทุกคนมีความสุขตลอดเวลา
KOVIKO

1
เมื่อผู้ใช้ส่งคำขอเขาไม่ได้ขอหน้าใหม่เสมอไป ฉันคิดว่าแอปพลิเคชัน AJAX ที่ได้รับการออกแบบมาอย่างดีสามารถทำให้พวกเขาสนุกยิ่งขึ้นทำให้ผู้ใช้รู้ว่าเกิดอะไรขึ้นอย่างมีประสิทธิภาพมากกว่าการโหลดซ้ำ
Frederik.L

32

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

ที่จริงแล้วไคลเอนต์อีเมลเป็นตัวอย่างที่ดีสำหรับเรื่องนี้: เมื่อฉันมีรายการที่มี 5 อีเมลและถูกเลือกอันดับหนึ่งฉันคาดว่าเมื่อกดปุ่มDELสามครั้งสามครั้งแรกอีเมลสามรายการจะถูกลบ ด้วย "nonblocking AJAX" นี่ใช้งานได้ดี - ทุกครั้งที่ฉันกดปุ่มอีเมลที่เลือกจะถูกลบทันที หากมีสิ่งผิดพลาดเกิดขึ้นจะมีข้อผิดพลาดปรากฏขึ้นและจะแสดงอีเมลที่ไม่ถูกต้องลบอีกครั้งหรือหน้านั้นถูกโหลดซ้ำเพื่อกำจัดสถานะโลคัลที่ไม่สอดคล้องกัน

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


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

@JimmyHoffa คุณจะใช้รหัสอีเมลที่ไม่ซ้ำกันในคำขอลบ มันจะไม่ดีจริงๆที่จะส่งคำขอลบตามลำดับการแสดงผลโดยพลการของอีเมลในกล่องจดหมายของคุณ
Buttle Butkus

14

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

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

หากเกิดข้อผิดพลาดจากสิ่งที่รุนแรงมากขึ้น (สมมติว่าฐานข้อมูลขัดข้อง) คุณควรมีวิธีบันทึกการดำเนินการและลองอีกครั้งเมื่อระบบกลับมาทำงานอีกครั้ง

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


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

1
@Niphra "ทำไมการลบจึงล้มเหลว" เครือข่ายสามารถล้มเหลวได้หลายสาเหตุไม่เกี่ยวข้องกับแอปพลิเคชันของคุณ มีอะไรที่คุณสามารถทำได้เพื่อหยุดว่า
Pacerier

5

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

Amazon AWS ใช้วิธีการนี้: เมื่อคุณหยุด / เริ่มต้นอินสแตนซ์ช่องทำเครื่องหมายที่อนุญาตให้คุณเลือกมันจะกลายเป็นสปินเนอร์ (ดังนั้นคุณจะไม่สามารถทำอะไรกับมันได้ในเวลาไม่กี่วินาที) การโต้ตอบกับอินสแตนซ์อื่น


คำแนะนำของคุณคล้ายกับวิธีที่ gmail แสดงข้อความ "ประหยัด ... " ในขณะที่ XHR ดำเนินไปและ "บันทึก" หลังจากดำเนินการเสร็จสิ้น ถ้าพูดเสมอว่า "บันทึกแล้ว" ใครจะเชื่อล่ะ
Buttle Butkus

3

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

คุณพูดว่า "ขณะนี้รหัส JavaScript ค้นพบคำขอ AJAX ล้มเหลวสคริปต์อาจแสดงข้อความแสดงข้อผิดพลาด แต่ตอนนี้ไม่มีประโยชน์จริงๆ"

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


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

คนส่วนใหญ่ค่อนข้างจะใช้แอปพลิเคชันที่สิ่งต่าง ๆ เกิดขึ้นทันทีระบบตอบสนองและมีโอกาส 1 ใน 10,000 ที่ UI อาจอัปเดตข้อผิดพลาดผิดพลาดกว่าแอปพลิเคชันที่ค้างเป็นเวลาหนึ่งวินาทีทุกครั้งที่เปลี่ยนค่า
Gort the Robot

1

2c ของฉันคือ: มีสถานการณ์ที่ดีกว่าที่จะมีในขณะที่คุณใส่มันการดำเนินงาน Ajax "ไม่ปิดกั้น" และอื่น ๆ ที่เป็นตัวเลือกการออกแบบที่ไม่ดี ตัวอย่าง: โหวตวิดีโอ YouTube คุณไม่ต้องการให้ส่วนใดส่วนหนึ่งของหน้าถูกบล็อกในขณะที่คุณคลิกที่จุดเริ่มต้นเล็ก ๆ มันจะดีกว่าที่จะล้มเหลวอย่างเงียบ ๆ แม้แต่ข้อความยืนยันจะถูกฆ่ามากกว่า อย่างไรก็ตามตัวอย่างของคุณที่มีการลบอีเมลฉันจะถือว่าเป็นสิ่งจำเป็นสำหรับการปิดกั้นคำขอประเภท Ajax

Mongo DB ทำสิ่งนี้ (และนี่อาจเป็นตัวอย่างแอปพลิเคชันเดสก์ท็อป) พวกเขามี "ข้อกังวลเกี่ยวกับการเขียน" ที่หลากหลายสำหรับการดำเนินการของพวกเขาและคุณสามารถกำหนดค่าให้เป็นค่าที่แตกต่างกันสำหรับการดำเนินการแต่ละอย่างตั้งแต่ "ย้อนกลับไปทันทีและไม่รออะไรเลย" ถึง "บล็อก" จนกว่าคุณจะยืนยันว่า จากนั้นส่งคืน "เป็น" รอจนกว่าเนื้อหาจะได้รับการกำหนดเวลาอย่างเหมาะสมสำหรับการเขียนดิสก์บนเครื่องระยะไกลก่อนส่งคืน " เห็นได้ชัดว่าถ้าคุณทำให้ไคลเอนต์แบบเดสก์ท็อปหนา (เช่น C ++) โดยใช้ไดรเวอร์ Mongo คุณจะตั้งค่าข้อกังวลการเขียนที่เบาที่สุดสำหรับการดำเนินการ db ของ "วิกฤติ" น้อยที่สุด (เช่นการตรวจสอบอีเมลใหม่) และอื่น ๆ .

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


+1 เมื่อเห็นสิ่งต่าง ๆ ในแบบของฉัน :) การอัปโหลดภาพถ่ายเป็นตัวอย่างที่ดีของความล้มเหลว
Reactgular

1
ทำไมการอัปโหลดการบล็อกจึงดีกว่า ใน Picasa (เว็บอินเตอร์เฟส) คุณสามารถลากรูปภาพเข้ามาและในขณะที่อัพโหลดในพื้นหลังคุณสามารถลากเพิ่มเติมหรือแท็กรูปภาพที่เสร็จสิ้น ฯลฯ การดำเนินการบล็อกการอัปโหลดจะทำให้ UX น่ากลัว
BLSully
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.