On Twitter UI

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

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

ใน blog ก่อน ผมเคยบอกว่า ผมมอง twitter ในฐานะ micro-planet คือใน planet นั้น นอกจากจะเป็นการรวม blog ของสมาชิกมาร้อยเรียงต่อกันแล้ว ยังมีการโต้ตอบระหว่างกันด้วย แต่บังเอิญการโต้ตอบระหว่าง blog ไม่เกิดขึ้นใน planet บ้านเราเท่าไร (เคยเขียนถึงเหมือนกัน) แต่พอเป็น micro-blog อย่าง twitter แล้ว ปรากฏว่ามีการโต้ตอบกันสูงมากจนกลายเป็น chat room กลาย ๆ

แต่ UI ของ twitter ก็มีปัญหาของมัน คือ

• tweet ที่เป็นข้อความต่อเนื่องกันหลาย tweet ไม่มี reference ถึงกัน เนื่องจาก twitter จำกัดความยาวอยู่ที่ 140 อักขระ เวลาจะ tweet อะไรยาว ๆ จึงต้องแบ่งข้อความเป็นหลาย tweet โดยแต่ละ tweet จะมี URL อ้างอิงได้ แต่ปรากฏว่าในแต่ละ tweet เอง ไม่มีลิงก์ต่อไปยัง tweet ก่อนหน้าหรือถัดไป เช่น เมื่อครั้งที่ผม tweet เป็นกลอน ผมอ้างอิงได้แค่ทีละ tweet เดียว จากนั้น ถ้าจะอ่านตอนต่อไป ก็ต้องไปไล่ควานหาใน timeline ของผม ว่าอยู่ตรงไหน ไม่มีลิงก์ next/previous หรือ archive ของ blog ในเวลาไล่เลี่ยกันให้เหมือนใน blog ทั่วไป สรุปว่า ถ้าจะให้อ้างอิงได้ ก็ต้องเขียนเป็น blog แล้ว tweet แต่ URL ของ blog (แบบนี้)

  ทางแก้: ขอลิงก์ next/previous ในแต่ละ tweet

• tweet ที่ Reply ถึงกันไม่ค่อยจะมี reference ถึงต้นตอ เรื่องนี้ความจริง web interface ของ twitter ทำได้ โดยใส่ข้อมูล In-Reply-To ไว้ใน tweet แต่ปัญหาคือ client ส่วนใหญ่ไม่รองรับความสามารถนี้ ผู้ใช้ส่วนใหญ่เลยใช้แค่การ reply แบบลุ่น ๆ เหมือน IRC ทำให้เวลามีการอ้างอิงถึง tweet ในเว็บหรือ blog ต่าง ๆ จะเห็นแต่คำตอบ แต่ไม่มี reference ถึงคำถาม

  ระยะหลังเริ่มมีการใช้ธรรมเนียม retweet โดย RT แล้วเติมความเห็นต่อท้าย ทำให้เห็นทั้งคำถามและคำตอบใน tweet เดียว แต่ปัญหาของวิธีนี้ก็คือ เวลาที่ RT ซ้อน ๆ กันหลายทอด จะแยกไม่ออกว่าข้อความไหนเป็นของใคร ตัวอย่างเช่น เวลาที่มี tweet "RT @userB RT @userA คำถาม / คำตอบ" จาก @userC จะแยกไม่ออกว่าคำตอบมาจาก @userB แล้ว @userC แค่ RT ต่อ หรือว่าเป็น @userB ที่แค่ RT @userA แล้ว @userC เป็นคนเพิ่มคำตอบ บางที อาจจะต้องแก้ความกำกวมด้วยการใส่วงเล็บกระมัง?

  ทางแก้: อาจเป็นไปได้หลายแบบ:

  • รองรับ In-Reply-To ในทุก client และผู้ใช้หันมาใช้ feature นี้ในการตอบมากขึ้น โดย client อาจจะทำ thread view จากข้อมูล In-Reply-To นี้ด้วยก็ได้ ก็จะออกมาคล้ายกับ interface ของ facebook ซึ่งผมคิดว่าอ่าน-ตอบสะดวกกว่ากันมาก
  • ผู้ใช้ใช้ RT กันต่อไป แต่กำหนดรูปแบบนิพจน์ใหม่ให้แยกความกำกวมได้ดีกว่านี้ เช่น เมื่อ retweet "ข้อความ" จาก @userA :
    • retweet เป็น "RT @userA (ข้อความ) ความเห็นเพิ่มเติม_opt" ซึ่งตามตัวอย่างข้างบน ถ้าเป็นกรณีที่ @userB เป็นคนเพิ่มความเห็น ก็จะกลายเป็น "RT @userB (RT @userA (คำถาม) คำตอบ)" แต่ถ้าเป็น @userC ที่เพิ่มความเห็น ก็จะกลายเป็น "RT @userB (RT @userA (คำถาม)) คำตอบ" เป็นต้น
    • อาจสังเกตว่า วงเล็บเปิดในแบบแรกนั้นไม่จำเป็น แค่ใส่เครื่องหมายปิดท้ายต้นฉบับทุก retweet ก็พอแล้ว ก็อาจจะ retweet เป็น "RT @userA ข้อความ / ความเห็นเพิ่มเติม_opt" โดยตามตัวอย่างข้างบน ถ้าเป็นกรณีที่ @userB เป็นคนเพิ่มความเห็น ก็จะกลายเป็น "RT @userB RT @userA คำถาม / คำตอบ /" แต่ถ้าเป็น @userC ที่เพิ่มความเห็น ก็จะกลายเป็น "RT @userB RT @userA คำถาม / / คำตอบ" เป็นต้น (แต่มันอ่านยากกว่าแบบใช้วงเล็บมะ?)
  โดยส่วนตัวแล้ว ผมชอบวิธีการใช้ In-Reply-To มากกว่า (โดยถ้าทำเป็น thread view ได้ด้วยจะดีมาก) ทั้งนี้ ก็ต้องขึ้นอยู่กับผู้ใช้ด้วย ว่าจะหันมาใช้ Reply กันมากขึ้นหรือเปล่า แล้วใช้ Retweet แบบของ twitter web สำหรับการ retweet แบบไม่มีความเห็นต่อเติมเท่านั้น

คงมีเท่านี้ก่อน ซึ่งในที่นี้ขอพูดเฉพาะ UI factor เท่านั้น ยังไม่พูดถึง user factor ในส่วนของผมเอง :-)