Author Archives: Konggoy

Mobile first ตอนที่ 6 Input

Mobile first ตอนที่ 6 Input

Input ในมือถือนั้นมีแนวทางในการใช้ดังนี้

การยอมรับ Input
มือถือรุ่นใหม่พยายามทำให้การใช้ Input ไม่ว่าจะเป็นการสัมผัส, การพิมพ์, การพูด และการแชร์ขึ้นออนไลน์นั้นง่ายขึ้น และด้วยความสามารถใหม่ที่เพิ่มเข้ามาเช่น location, detection, video ฯลฯ ทำให้เรามีทางเลือกใหม่ที่จะใส่ input เพิ่มมากขึ้น

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

  • label ไม่ควรเป็นส่วนหนึ่งของคำตอบ จะเกิดขึ้นเมื่อมีบางอย่างยังโหลดไม่ครบซึ่งอาจทำให้ label ไปอยู่ในคำตอบได้
  • label และ Input ไม่ควรดูเหมือนกัน
  • เมื่อใส่ Input แล้วคำถามหายไปอาจทำให้ใช้งานได้ยากขึ้น

ส่วนของคำตอบ
          แบ่งออกเป็น 3 แบบดังนี้

  • แบบมาตรฐาน เป็น Input พื้นฐานที่ใช้ใน website ได้แก่ checkbox, radio, password, select, file pick, submit buttons และ plain text
  • แบบนอกเหนือจากมาตรฐาน เป็นข้อยกเว้นสำหรับมือถือสำหรับแบบมาตรฐานเนื่องจากมีการแสดงผลที่ต่างไปในแต่ละรุ่นมือถือ จึงควรจะใช้ให้เข้ากับข้อมูล, เหมาะสมกับหน้าจอและการแสดงผล
  • แบบมาตรฐานใหม่ เป็น Input ที่มีเพิ่มใน html5 ที่เข้ามาช่วยให้การใส่ Input นั้นถูกต้องตามรูปแบบที่กำหนดไว้ (สามารถดู Input type ใหม่ได้ที่ : http://www.w3schools.com/html/html5_form_input_types.asp) type ของ input นั้นจะบังคับ keyboard ให้สามารถใส่ค่าที่ต้องการได้เท่านั้น (จะเห็นได้ชัดจาก keyboard IOS ดูตัวอย่างได้ที่ : http://mobileinputtypes.com/ ) นอกจากนี้ใน IOS จะปิด auto capitalize และ auto correct เมื่อ Input type email, password, URL และกรณีจำเป็นอื่นๆ แต่ในส่วนของ Input type ใหม่นี้จะมีบาง browser ที่ไมได้ support อยู่ด้วย

ป้อนข้อมูลที่ถูกต้อง
ในที่นี้จะใช้ Input Mask ช่วยให้ user เข้าใจและกรอกข้อมูลที่เราต้องการโดยดูจากตัวอย่างคำตอบที่เรากำหนดไว้ใน Input ซึ่งหากเรากรอกข้อมูลจริงตัวอย่างนั้นจะหายไป หรือ หากมีข้อมูลที่ใช้ซ้ำอยู่แล้วเช่น @ ตามหลังด้วย url อีเมล์ ก็ควรจะกำหนดไว้โดยที่ผู้ใช้ไม่จำเป็นต้องพิมพ์อีก หลักในการใช้ mask โดยทั่วไป คือ mask text แบบตรงตัวโดยไม่ต้องสลับการแสดงผลเป็นรูปแบบอื่น

การจัดวางคำถาม
มีหลัก 3 ส่วนที่ควรพิจารณา ได้แก่

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

เมื่อออกการจัดวางคำถามจะต้องคำนึงถึง keyboard ในมือถือด้วย ควรจะให้ผู้ใช้เห็นคำถามและคำตอบเมื่อ keyboard ในมือถือแสดงขึ้นมา

ส่วนที่นอกเหนือกจาก input
          Input ไม่ใช่เป็นเพียงการพิมพ์ข้อมูล และส่วนมากสามารถให้ผู้ใช้มีส่วนโดยไม่รู้ตัวและนอกจากนี้ยังมีเทคโนโลยี Google Goggles ค้นหาจากรูปภาพ (เหมาะกับสิ่งที่อธิบายด้วยคำพูดได้ยาก), เทคโนโลยีไร้สายระยะสั้น NFC ระบบสื่อสารระยะสั้นที่สามารถทำให้มือถือใช้ digital barcodes ได้ และเทคโนโลยีอื่นๆ ที่เราควรจะศึกษาเพื่อให้ได้ Input แบบใหม่ๆ เพิ่มขึ้น

Mobile first ตอนที่ 4 Organization

Mobile first ตอนที่ 4 Organization

ในการจัดการ  mobile web experience นั้นทำได้โดยศึกษาจากพฤติกรรมและความต้องการของผู้ใช้

1. ศึกษาพฤติกรรมการใช้มือถือของผุ้ใช้ว่าเป็นไปตามลักษณะไหนใน 4 ข้อนี้
– Lookup / Find
– Explorer / Play
– Check In / Status
– Edit / Create
และนำมาปรับใช้ให้สอดคล้องกับเว็บไซต์ของคุณ

2. เน้นที่เนื้อหามากกว่า navigation ให้ผู้ใช้เข้าถึงข้อมูลได้เร็วที่สุด

3. วางทางเข้าในตำแหน่งที่เหมาะสมและมีสิ้งค์ที่เชื่อมโยงเพื่อให้ผู้ใช้ได้เข้าถึงข้อมูลหน้าอื่นๆได้

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

Mobile first ตอนที่ 1 Introduction

Mobile first ตอนที่ 1 Introduction

บทความนี้จะ นำ ไปสู่การอธิบาย การเริ่มต้น หรือสิ่งที่ควรทำจาก web site ไปสู่ Mobile

การออกแบบมือถือ เป็นการเตรียมพร้อมสำหรับการเติบโตของเทคโนโลยีอย่าง มือถือ และรองรับการใช้งาน ของ website บน mobile Growth การใช้ Smart Phone นั้นมีการใช้งานที่เพิ่มขึ้นมาก เกือบทุกคน ในทุกๆที่ ที่เราไป

จากระยะเวลาที่ผ่านมาจึงได้มีการวิเคราะห์ว่าการเติบโตของมือถือเกิดขึ้นได้อย่างไร

  • Smart Phone ถูกคาดการณ์ ว่าจะเติบโตพร้อมกับ labtop notebook แต่ Smart Phone นั้นเติบโตอย่างรวดเร็วและแซงหน้า notebook labtop ไป
  • การเข้าใช้ website ใน mobile เพิ่มขึ้น
  • ผู้เข้าใช้ email จาก desktop ลดลง แต่ mobile เพิ่มขึ้น
  • Traffic การใช้งาน ของ internet on mobile เพิ่มขึ้น
  • 500 ล้านคนจากทั่วโลก เข้าใช้งาน internet on mobile ในปี 2009

จึงได้คาดการณ์ว่า Smart Phone จะเข้ามาแทนที่ PC จากการเข้า website ทั่วโลก

นอกจากการเข้า Website ใน Mobile เพิ่มขึ้นแล้ว การใช้งานธุรกรรมทางการเงิน เช่น PayPal ก็มีการชำระเงินจาก Mobile 10 ล้านดอลล่า ต่อวัน

So What changed?

Motorola Z3 เป็นการเริ่มของการเจริญเติบโต ของการใช้งาน Internet ในมือถือ หลังจากนั้น Apple ก็ออก  iPhone ออกมา นั้น ทำให้เกิดการเปลี่ยนแปรงครั้งใหญ่ของ การใช้  Smart Phone

All device are not created equal.

การใช้งาน หรือ ความสามารถของ Mobile แต่ละรุ่นนั้นต่างกันทั้ง ขนาดจอ การใช้งาน หรือ traffic ของ internet แต่ละเครือข่ายที่เราใช้งาน  เราจึงต้องออกแบบ เพื่อให้รองรับการใช้งานที่ดีที่สุด ใน Mobile

What about native?

การใช้งานของ Mobile มีทั้งเป็นแบบ Application และเว็บไซต์ และ มีการเรียก เว็บไซต์มากจากตัว App. ด้วย  เราจึงต้อง ออกแบบการ ใช้งาน ให้ดีและใช้งานง่ายจากทุกทาง

Joe Hewitt, former lead developer of Facebook’s iPhone application: “My goal was initially just to make a mobile companion, but I became convinced it was possible to create a version of Facebook that was actually better than the website,”

“เป้าหมายแรกของเรา คือการทำ Facebook ในมือถือ เพื่อให้แค่เพิ่มเติมจากการทำงาน บน desktop แต่กลายเป็นว่าเราต้อง สร้าง Facebook on Mobile ให้ดีกว่า desktop”

Mobile first ตอนที่ 7 Layout

Mobile first ตอนที่ 7 Layout

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

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

Flexible Images

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

ข้อเสีย

– บราวเซอร์ Internet Explorer ยังไม่รองรับ properties ที่ชื่อว่า max-width แต่สามารถแก้ไขโดยการใช้ properties ที่ชื่อว่า width แทน
– ในบราวเซอร์เวอร์ชั่นเก่าๆ ยังไม่รองรับเทคนิคการทำงานดังกล่าวเช่นกัน ซึ่งสามารถแก้ไขโดยการใช้ JavaScript ช่วยในการทำงานแทนได้

แม้วิธีข้างต้นจะเป็นการแก้ปัญหาการยืดหยุ่นของภาพได้ดีและรวดเร็ว แต่สิ่งที่ไม่ควรมองข้ามคือ ความละเอียดของภาพและเวลาในการโหลดรูปภาพ เนื่องจากในปัจจุบัน นิยมใช้งานเว็บไซต์ผ่านทาง Smartphone หรือ Tablet มากขึ้น การโหลดภาพที่มีขนาดใหญ่และความละเอียดสูงจะทำให้เสียเวลาและใช้พื้นที่โดยไม่จำเป็น Filament Group’s Responsive Images เป็นเทคนิค ที่ไม่เน้นการปรับขนาดของรูปภาพ แต่ใช้วิธีเลือกรูปภาพที่มีขนาดเหมาะสมกับอุปกรณ์มาแสดงแทน ซึ่งช่วยแก้ปัญหาการโหลดรูปภาพที่มีขนาดใหญ่มาแสดงผลในอุปกรณ์ที่มีขนาดเล็ก และลดการใช้พื้นที่โดยไม่จำเป็นได้

ปัจจุบันอุปกรณ์ของค่าย Apple ไม่ว่าจะเป็น IPhone(เวอร์ชั่น 4 ขึ้นไป) หรือ IPad(เวอร์ชั่น 2 ขึ้นไป) ได้นำเทคโนโลยีที่ช่วยในการแสดงผลของหน้าจอได้ดีขึ้นซึ่งมีชื่อเรียกว่า Retina Display ทำให้การแสดงผลของ Responsive Web บนอุปกรณ์ดังกล่าวไม่ได้ขนาดที่เหมาะสมกับที่ได้ทำการออกแบบไว้ ซึ่งมีเทคนิคในการแก้ไขปัญหาดังกล่าวโดยการนำค่า pixels มาเป็นตัวช่วยในการแก้ปัญหา

Pixels

หน่วยที่ใช้วัดค่าความละเอียดของรูปภาพหรือหน้าจออุปกรณ์ pixels แบ่งได้ 3 แบบด้วยกัน คือ Physical Pixels, CSS Pixels และ Device Pixels
- Physical Pixels คือ จำนวน pixels จริงๆ ตาม spec ของ Device นั้นๆ เช่น iPhone3 เท่ากับ 320×480 ส่วน iPhone4 เท่ากับ 640×960 เป็นต้น

- CSS Pixels นั้นเป็นส่วนที่ใช้ใน CSS declarations ตัวอย่าง เรากำหนด width:320px หรือ font-size:16px ค่า pixels ในส่วนนี้จะหมายถึง CSS Pixels ซึ่งโดยปกติแล้ว CSS Pixels จะมีค่าเท่ากับ Physical
Pixels ถ้าเราไม่ได้ Zoom หน้าจอ แต่ถ้าเรา Zoom เข้า ภาพจะขยายใหญ่ขึ้น นั่นเป็นเพราะว่าเว็บบราวเซอร์จะไปขยาย CSS Pixels ให้มีขนาดใหญ่ขึ้น ในทางกลับกัน ถ้าเรา Zoom ออก CSS Pixels ก็จะมีขนาดเล็กลง
ส่งผลให้ภาพที่ได้มีขนาดเล็กลง ซึ่งนี่ก็เป็นหลักการเดียวกับการเปลี่ยน Resolution ของหน้าจอ PC ครับ สมมติหน้าจอเรามี Physical Pixels เป็น 1280×1024 หากเราเปลี่ยน Resolution เป็น 1024×768
สิ่งที่เปลี่ยนไปก็คือ CSS Pixels นั่นเอง

- Device Pixels ในสมัยก่อน Device Pixels จะมีค่าเท่ากับ Physical Pixels เช่น iPhone3 จะมี Physical Pixels และ Device Pixels เท่ากันคือ 320×480 แต่ต่อมา iPhone4
ได้ปรับปรุงหน้าจอให้มีความละเอียดมากขึ้น หรือที่เรียกว่า Retina Display ซึ่งจะทำให้ iPhone4 มี Physical Pixels เพิ่มขึ้นเป็น 2 เท่า คือ 640×960 ซึ่งหมายความว่า เว็บที่แสดงผลได้ดีใน iPhone3
กลับมีขนาดเล็กลงใน iPhone4 ทั้งๆ ที่จริงๆ แล้ว ขนาดหน้าจอของ iPhone3 และ iPhone4 นั้นเท่ากัน ปัญหานี้สามารถแก้ง่ายๆ ด้วย Device Pixels ครับ เนื่องจาก Device Pixels นั้นเป็นเหมือน Pixels จำลอง
ที่จะช่วยให้ application สามารถกำหนดขนาดขององค์ประกอบต่างๆ ได้ตรงกับความเหมาะสมในมุมมองของผู้ใช้งาน ซึ่งค่านี้ไม่ได้เพิ่มตาม Physical Pixels แต่จะเพิ่มตามขนาดของหน้าจอ(Screen size) ครับ

โดยวิธีแก้ไขปัญหาคือการอ้างอิง Meta Tag ดังต่อไปนี้ในหน้าเว็บไซต์ของเรา
<meta name="viewport" content="width=device-width; initial-scale=1.0">
โค็ด html ด้านบน เป็นการกำหนดให้ viewport ของเราใช้ค่า Device Pixels แทน CSS Pixels และยังกำหนดให้ระดับการซูมเบื้องต้นเป็น 100% อีกด้วย

Custom Layout Structure

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

สิ่งที่ควรคำนึงก่อนออกแบบเว็บให้เป็น Responsive

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

2. ลำดับความสำคัญของ element ต่างๆ ให้ถูกต้อง
หลายๆ ครั้งที่เราเขียนโค็ด โดยไม่คำนึงถึงลำดับความสำคัญของ element ต่างๆ ตัวอย่างที่มักจะเจอกันบ่อยๆ คือ sidebar ที่บางคนเอาโค็ดของ sidebar มาไว้ก่อน content และจัดการ float:right
เพื่อให้มันไปอยู่ขวามือแทน ปัญหามักจะเกิดขึ้นเมื่อเราทำเว็บให้เปิดได้บนมือถือ ที่ทุกอย่างมักจะกลับไปเหลือเพียงคอลัมน์เดียว ถึงตอนนั้นเจ้า sidebar ที่เคยอยู่ขวามือ มันก็จะมาอยู่ข้างบนก่อนเข้าถึงเนื้อหา
ทำให้ผู้ใช้ต้องลากยาวๆ ผ่าน sidebar ไปก่อน ถึงจะเห็นเนื้อหา อย่างนี้ไม่ดีกับผู้ใช้แน่นอน ดังนั้น การวางลำดับ element ต่างๆ ให้ถูกต้อง ก็เป็นเรื่องที่สำคัญอีกเรื่องหนึ่ง

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

4. ลดการใช้งานไฟล์ขนาดใหญ่
การใช้งานเว็บบนอุปกรณ์พกพา (โดยเฉพาะโทรศัพท์มือถือ) นั้นล้วนเชื่อมต่อจาก EDGE หรือ 3G กันเป็นส่วนใหญ่ ซึ่งนอกจากความเร็วที่ค่อนข้างต่ำเมื่อเทียบกับ ADSL ตามบ้านแล้ว ยังติดปัญหา Fair Usage Policy (หรือที่เรียกว่า FUP) กันอีกด้วย ทำให้ผู้ใช้หลายคนค่อนข้างเหงื่อตก เมื่อต้องเปิดเว็บที่มีขนาดเป็นสิบเม็กกะไบต์

Mobile first ตอนที่ 5 Actions

Mobile first ตอนที่ 5 Actions

หลักพื้นฐานในการออกแบบ User Interface ให้ง่ายต่อการทัช มีดังนี้

- ตรงที่จะให้ User ทัชนั้น (เรียกว่า Touch Target) ควรมีตาแหน่งและขนาดที่เหมาะสม
- เรียนรู้และเข้าใจท่าทางการทัชอย่างเป็นธรรมชาติของมนุษย์เป็น และวิธีการที่มนุษย์จะพาตัวเองไปหาจุดมุ่งหมาย
- ครอบคลุมเรื่องการ hover
- อย่าลืมเรื่องการใช้งานบนโทรศัพท์รุ่นที่ยัง touch ไม่ได้ด้วย

GO SMALL BY GOING BIG
หลักการออกแบบบนหน้าจอเล็กๆ สาหรับ Touch Target คือ ต้องออกแบบ Touch Target ให้มีขนาดอย่างน้อย 44×44 พิกเซล และระหว่าง Touch Target แต่ละอันให้มีระยะห่างประมาณ 2 มิลลิเมตร หรืออย่างน้อย ก็ควรจะให้ Touch Target มีขนาดอย่างน้อยประมาณ 50%-100% ของขนาด 44×44 พิกเซล

WHERE DO WE TOUCH?
จากการสารวจ 70%-90% ของมนุษย์ถนัดมือขวา ถ้ามนุษย์ใช้มือขวาเป็นมือหลักในการ Touch ตาแหน่งบนหน้าจอที่ง่ายต่อการ Touch มากสุดจนถึงยากสุดคือ ซ้ายล่าง (ง่ายสุด)  ซ้ายบน (ยากสุด)

LEARN THE LANGUAGE OF TOUCH

ท่าทางในการ Touch หลักๆ ก็จะมี tap (แตะเบาๆ), double tap (แตะ), drag (ลาก), swipe (ปัด), pinch (หยิก), spread (กระจาย), press (กด), press และ tap (กดและแตะเบา), press และ drag (กดและลาก) และการหมุนในหลากหลายรูปแบบ นักออกแบบ จะนาท่าทางเหล่านี้ มาประกอบการใช้งานบน App หรือ Website ของเขา เช่น tap ปุ่มเปิดปิดเมนูเพื่อเปิดปิดเมนู หรือ ดึงหน้าจอลงมาเพื่อ refresh เป็นต้น

DON’T FEAR THE NUI
อย่ากลัว Natural User Interfaces (NUIs) เนื่องจากมนุษย์มีท่วงท่าการ Touch หน้าจออย่างเป็นธรรมชาติ การเข้าถึงข้อมูลก็จะเป็นไปอย่างเป็นธรรมชาติด้วยเช่นกัน การออกแบบด้วยหลักการของ NUIs คือลดภาพกราฟิกที่ไม่จาเป็น เพื่อให้ User เข้าถึงข้อมูลได้โดยง่ายและเป็นธรรมชาติที่สุด COVER THE HOVER การทดแทน hover เมื่ออยู่ในมือถือ มีดังนี้
1. นาสิ่งที่แสดงตอน hover มาแสดงไว้บนหน้าจอ ไม่ต้องมี action ใดๆ ก็เห็น
2. ใช้วิธีการ tap หรือ swipe แทนการ hover
3. ใช้วิธีการแยกออกมาอีกหน้าจอเมื่อจะ action ใดๆ เช่น tap แล้วเปิดหน้าใหม่
4. ตัดทิ้ง ใช้กรณีที่ hover นั้น ไม่สาคัญ

CANT’T TOUCH THIS
สาหรับมือถือที่ touch ไม่ได้ การใช้ :hover หรือ :focus ก็ยังมีความจาเป็น เพราะว่า มือถือเหล่านี้ใช้ trackball, trackpads, keypads, scrollwheels และ keyboards ซึ่งการ focus ณ จุดใดๆ บนหน้าเว็บควรจะทาให้ User เห็นและเข้าใจให้ง่ายๆ

UX User test VDOs

UX User test VDOs

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

Sanook!, Wechat

ตัวอย่างที่ 1

ตัวอย่างที่ 2

ตัวอย่างที่ 3




สิ่งที่ไม่ควรมองข้าม สําหรับคนทําเว็บ

สิ่งที่ไม่ควรมองข้าม สําหรับคนทําเว็บ

Sanook

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

อธิบายทั้งหมดคงไม่ไหว ลองหาดูได้จากเว็บเหล่านี้ และศึกษาและ ทดลองใช้

  1. http://www.xhtml.com/en/xhtml/reference/
  2. http://www.w3schools.com/html/default.asp
  3. http://thaicss.com

คําถามที่ถามบ่อย

  1. HTML, XML, XHTML และ CSS คืออะไร ต่างกันอย่างไร และใช้อย่างไร
  2. เปลี่ยนใจมาใช้ div แทน table
  3. เขียน CSS ในลักษณะต่างๆ มีกี่แบบ

รู้จักกับ HTML5 – ภาคหนึ่ง HTML5 คืออะไร?

รู้จักกับ HTML5 – ภาคหนึ่ง HTML5 คืออะไร?

บทความดีๆจาก http://www.blognone.com/ ที่ jojobaoil แนะนํามาครับ อยากให้ลองอ่านกัน


บทความชุดนี้จะแนะนำข้อมูลเบื้องต้น (ย้ำว่า “เบื้องต้น”) ของเทคโนโลยีใหม่ที่ทุกคนจับตาอย่าง HTML5 เพื่อเตรียมความพร้อมและปูพื้นฐานของ HTML5 ให้กับนักพัฒนาเว็บในประเทศไทย

ภาคแรกของบทความนี้จะกล่าวถึงข้อมูลของ HTML5 ในภาพรวม ว่ามันคืออะไร มันทำอะไรได้บ้าง ก่อนจะเข้าสู่รายละเอียดของเทคโนโลยีบางตัวที่สำคัญในภาคต่อๆ ไป

อะไรคือ HTML5

คงได้ยินชื่อ HTML5 กันมาเยอะ แต่ว่าแท้จริงแล้วมันคืออะไรกันแน่?

ความหมายทั่วไปของคำว่า HTML5 มีสองนัยยะที่เหลื่อมซ้อนกันอยู่ครับ

ความหมายในมุมแคบ มันคือ สเปกของภาษา HTML รุ่นที่ 5 ซึ่งต่อจาก HTML4 ที่เราใช้กันทุกวันนี้ โดยปัจจุบันสเปกยังร่างไม่เสร็จ (ดูได้จากเอกสารของ W3C) เนื้อหาจะครอบคลุมลักษณะ ฟีเจอร์ และ syntax ของ HTML เท่านั้น

ความหมายในมุมที่กว้างขึ้น มันคือ ชุดของเทคโนโลยีเว็บสมัยใหม่ อันประกอบไปด้วย

  • ภาษา HTML5 ตามข้อแรก
  • CSS3
  • API อีกชุดหนึ่งที่อยู่นอกสเปก HTML5 แต่ออกแบบมาให้ใช้งานร่วมกัน เช่น Geolocation, IndexedDB, File API ที่กำลังเป็นร่างมาตรฐานของ W3C แยกมาอีกชุดหนึ่ง
  • เทคโนโลยีประกอบอื่นๆ ที่เป็นมาตรฐานของ W3C อยู่แล้ว และนำมาใช้ร่วมกับ HTML (ซึ่งจะเป็น HTML4 หรือ HTML5 ก็ได้) เช่น SVG หรือ MathML

HTML5 ในที่นี้เราจะหมายถึงความหมายอย่างที่สอง ก็คือเทคโนโลยีเว็บรุ่นใหม่แบบรวมๆ นะครับ

ทำไมต้องมี HTML5

จะว่าไปแล้ว เทคโนโลยีใน HTML5 แทบไม่มีอะไรใหม่ในโลกไอทีเลย เพราะเกือบทุกอย่างที่ HTML5 ทำได้ อยู่ในกระบวนการพัฒนาโปรแกรมแบบ native มาช้านานแล้ว เช่น การทำงานแบบออฟไลน์ หรือ การวาดกราฟิก

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

เดิมที ภาษาตระกูล HTML/SGML เป็นภาษาที่ออกแบบมาเพื่อ “อธิบาย” หรือ “นิยาม” การแสดงผลข้อมูล เช่น ตัวหนา ตัวเอียง หัวเรื่อง ลิงก์ ซึ่งการใช้งานก็คือเอาไว้ทำเอกสารที่เชื่อมโยงกัน (ตัวอย่างคือ Help ของวินโดวส์)

พอมีอินเทอร์เน็ต HTML ก็ทำหน้าที่สร้าง “โบรชัวร์อิเล็กทรอนิกส์” ที่สามารถดูได้จากระยะไกล ถึงแม้ตอนแรกจะมีแต่ข้อความ แต่ระยะต่อๆ มาเทคโนโลยีเว็บก็พัฒนามากขึ้น สามารถใส่ภาพ เสียง วิดีโอ (ผ่านปลั๊กอิน) มีแนวคิดเชิงโปรแกรมอย่างจาวาสคริปต์เข้ามา (จริงๆ มี VBScript ด้วยแต่ดังสู้ไม่ได้) ในยุคของ HTML3

พอเป็นยุคของ HTML4 เราเริ่มเห็นเว็บแบบที่ตอบโต้ได้ มีความเป็นอินเตอร์แอคทีฟมากขึ้น ซึ่งเกิดจากเทคโนโลยีอย่าง AJAX, XMLHttpRequest ทำให้เว็บมีความใกล้เคียงกับ “แอพ” แบบดั้งเดิมมากขึ้น อย่างไรก็ตาม มันยังสู้แอพแบบ native ไม่ได้ เพราะยังขาดฟีเจอร์สำคัญๆ อีกหลายอย่าง เช่น การทำงานออฟไลน์ กราฟิกสามมิติ ฯลฯ นั่นเอง

สุดท้ายแล้ว HTML5 จะช่วยให้เรานำเทคโนโลยีจากโลกของเว็บ มาสร้างแอพที่มีลักษณะใกล้เคียงกับแอพแบบ native (ไม่ว่าจะบนพีซีหรือมือถือได้) ตัวอย่างที่ชัดเจนที่สุดในตอนนี้คือ PhoneGap ซึ่งเป็นเครื่องมือพัฒนาแอพมือถือด้วย HTML5

HTML5 มีความสามารถอะไรบ้าง

เกริ่นกันมานานก็เริ่มเข้าเรื่องกันสักทีนะครับ ส่วนประกอบของ HTML5 มีหลายอย่างมาก เราอาจไม่จำเป็นต้องใช้ทุกฟีเจอร์

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

W3C แบ่งเทคโนโลยีในชุด HTML5 ออกเป็น 8 หมวด พร้อมไอคอนประกอบทุกหมวด ขอใช้ชื่อตามนั้น และเรียงลำดับกันไปเช่นเดียวกับเว็บ W3C HTML5 Logo

1. Semantics

HTML5 Semantic

เทคโนโลยีกลุ่ม Semantics คือตัว syntax ของภาษา HTML5 ที่แน่นอนว่าเปลี่ยนไปจาก HTML4 ซึ่งมีแท็กใหม่ๆ และคุณสมบัติ (atrribute) ใหม่ๆ เพิ่มขึ้นอีกพอสมควร

โดยโครงสร้างของภาษาแล้ว HTML5 ยังเหมือนกับ HTML ที่เราคุ้นเคย แต่เพิ่มแท็กใหม่ ตัดแท็กเก่า และเปลี่ยนวิธีใช้แท็กเก่าบางตัวออกไป รายละเอียดอ่านได้จาก HTML5 differences from HTML4 ของ W3C

ยกมาเป็นตัวอย่างพอให้เห็นภาพ

แท็กใหม่

แท็กกลุ่มนี้จะช่วยบ่งบอกความหมายของวัตถุในเว็บเพจได้ดีขึ้น เช่น จากเดิมเราใช้ <div id=”header”> ก็เปลี่ยนมาเป็น <header> ทำให้เบราว์เซอร์สามารถรับทราบความหมายของวัตถุแต่ละชิ้นได้ดีขึ้น

ตัวอย่าง

  • section – บ่งบอกเซคชันของเนื้อหา
  • article – กำหนดขอบเขตของตัวเนื้อบทความ
  • aside – กำหนดขอบเขตของเนื้อหาเสริม (ล้อมกรอบ)
  • header – กำหนดขอบเขตของส่วนเริ่มต้นหรือส่วนหัวของเว็บไซต์ (อย่าสับสนกับ <head>)
  • footer – กำหนดขอบเขตของส่วนท้ายของเว็บไซต์ พวกข้อความกำหนดสิทธิ์ต่างๆ
  • nav – บอกว่ามันเป็นส่วนนำทางของเว็บไซต์
  • figure – บอกว่าเป็นภาพหรือวิดีโอประกอบเนื้อหา (ข้างในสามารถซ้อนแท็ก img หรือ video พร้อมคำอธิบายได้อีกชั้น)

นอกจากนี้ส่วนของฟิลด์ยังมี attribute ใหม่อีกกลุ่มสำหรับ input type ที่เจาะจงกว่าเดิม เช่น จากเดิมเราใช้ <input type=”text” id=”email”> ก็เปลี่ยนเป็น <input type=”email”> แทน

  • tel – เบอร์โทร
  • search – ช่องค้นหา
  • url
  • email
  • datetime
  • date
  • time
  • color

แท็กที่ถูกตัดออก

ส่วนใหญ่เป็นแท็กเก่าที่ทำหน้าที่กำหนดฟอร์แมตการแสดงผล ซึ่งย้ายไปใช้ CSS แทนหมดแล้ว นอกจากนี้ยังเอาแท็กที่เกี่ยวกับเฟรมทั้งหมดออกไป เพราะล้าสมัยแล้ว และแท็กที่ไม่ค่อยมีคนใช้อย่าง acronym (ใช้ abbr แทน) หรือ applet (ใช้ object แทน)

  • big
  • center
  • font
  • strike
  • frame
  • frameset
  • noframes
  • acronym
  • object

แท็กที่ถูกเปลี่ยนวิธีใช้

แท็กเก่าแต่เปลี่ยนความหมาย-วิธีใช้งาน

  • i – ไม่ได้หมายถึงการทำตัวเอียง (เพราะอยู่ใน CSS) แต่หมายถึงโทนเสียงของตัวข้อความที่เปลี่ยนแปลง
  • small – หมายถึงข้อความหรือคอมเมนต์ประกอบเนื้อหาหลัก ที่ควรจะแสดงด้วยตัวเล็กกว่าปกติ
  • strong – หมายถึงข้อความสำคัญ ไม่ใช่การเน้นด้วยตัวเข้ม
  • u – เป็นการบ่งชี้ว่าข้อความจุดนี้มีการแสดงผลแบบพิเศษ เช่น จงใจเขียนให้ผิดเพื่อเป็นตัวอย่าง หรือ ชื่อในภาษาจีน เป็นต้น

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

จะเห็นว่าในภาพรวมแล้ว HTML5 หมวด semantics จะช่วยให้ตัวโครงสร้างของเว็บเพจมีความหมาย (ในเชิงของ semantic web) มากขึ้น

รายละเอียดเพิ่มเติมอ่านได้จาก HTML5 Semantics – Smashing Magazine

2. Offline & Storage

HTML5 Offline & Storage

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

ผมเคยเขียนเนื้อหาในหมวดนี้ไปแล้วครั้งหนึ่งในบทความ รู้จักกับวิธีการเก็บข้อมูล Local Storage ของ HTML5 ก็ขอเอามารียูสเพราะเนื้อหาเหมือนกันทุกประการ

Web Storage

เทคโนโลยีแรกคือ Web Storage ซึ่งเป็นการเก็บข้อมูลแบบง่ายๆ ในรูป key-value (ภาษาโปรแกรมบางภาษาเรียก dictionary) ซึ่งแยกย่อยได้อีก 2 อย่าง คือ

  • Session storage เก็บข้อมูลเฉพาะเซสชันการท่องเว็บนั้นๆ ปิดแท็บเมื่อไรข้อมูลก็หายไป ใช้ออบเจคต์ชนิด sessionStorage อันนี้ไม่ซับซ้อน
  • Local storage เก็บข้อมูลระยะยาว (persistence) โดยใช้ออบเจคต์ชื่อ localStorage ซึ่งจะซับซ้อนขึ้น เพราะเราสามารถเปิดเว็บเพจเดียวกันใน 2 แท็บหรือมากกว่า ซึ่งมันจะแชร์ข้อมูลก้อนเดียวกัน

ฟีเจอร์ Web Storage จะคล้ายกับ Google Gears เมื่อ 3-4 ปีก่อนหน้านี้ เพียงแต่ Web Storage รวมมากับ HTML5 เลย ไม่ต้องลงปลั๊กอินเพิ่มเองแบบ Gears

ฐานข้อมูล

การเก็บข้อมูลง่ายๆ แบบ key-value อาจไม่เพียงพอต่อความต้องการของนักพัฒนา HTML5 จึงเพิ่มวิธีการเก็บข้อมูลที่ซับซ้อนขึ้นมา ซึ่งก็คือฐานข้อมูลแบบที่เราคุ้นเคยนั่นเอง

ปัญหาของฐานข้อมูลใน HTML5 ก็คือมาตรฐานที่แยกเป็นสองทาง

  • Web SQL Database มันคือการนำ SQL มายัดใส่เบราว์เซอร์ (ส่วนมากนิยม SQLite) ตอนนี้ใช้ได้แค่เบราว์เซอร์ตระกูล WebKit และ Opera แนวทางนี้มีข้อเสียตรงความซับซ้อนของ SQL และเริ่มหมดความนิยมแล้ว (ทั้งที่มาตรฐานยังไม่เสร็จ)
  • IndexedDB แนวทางใหม่ที่สร้างขึ้นในภายหลัง ไม่ใช้ SQL แต่เก็บข้อมูลแบบ key-value เหมือนกับ Web Storage เพียงแต่เพิ่มการทำดัชนี (index) ช่วยให้หาข้อมูลได้รวดเร็วขึ้น และเพิ่มเรื่อง transactions เพื่อความปลอดภัยของข้อมูลมาด้วย

Blognone เคยลงเรื่อง Web SQL vs IndexedDB ไปครั้งหนึ่งแล้ว ย้อนอ่านรายละเอียดได้ในตอนเก่าครับ

File API

เราพูดถึงการเก็บข้อมูลแบบง่ายๆ และการเก็บลงฐานข้อมูลไปแล้ว ลำดับถัดไปคือการจัดการกับ “ไฟล์” นั่นเอง HTML5 มี API มาให้เราสองตัวคือ FileReader กับ FileWriter หน้าที่ก็ตามชื่อครับ

ปัญหาของ FileReader ที่จะต้องสนใจคือความแตกต่างระหว่างไฟล์ที่อยู่ในเครื่อง กับไฟล์ที่อยู่บนเว็บ ซึ่งกำลังพัฒนากันอยู่

ส่วน FileWriter มีข้อกังวลเรื่องความปลอดภัย เพราะต่อจากนี้ไปเว็บเพจจะสามารถเขียนไฟล์ในเครื่องเราได้ มาตรการแก้ไขจุดอ่อนนี้ก็ต้องพัฒนากันต่อไป

(ข่าวเก่า W3C เปิดตัว File API, มาตรฐานกลางในการเข้าอ่านไฟล์ในเครื่องลูกข่าย)

แคชสำหรับเวลาออฟไลน์ (App Cache)

เมื่อเว็บแอพพลิเคชันไม่ได้ต่อเน็ต ก็ต้องมีวิธีจัดการกับข้อมูลที่เกิดขึ้นระหว่างนั้น ซึ่งเป็นหน้าที่ของ AppCaching API ที่บอกว่าเว็บแอพพลิเคชันจะถูกเก็บไว้บนเครื่องนานแค่ไหน ทำให้เว็บแอพมีลักษณะคล้ายๆ กับแอพที่ติดตั้งแบบปกติมากขึ้น

3. Device Access

HTML5 Device Access

เทคโนโลยีหมวดที่สามจะเน้นความเชื่อมโยงกับฟีเจอร์ของฮาร์ดแวร์ (โดยเฉพาะฮาร์ดแวร์แบบพกพา) เช่น

  • Geolocation API เพื่อขอข้อมูลเชิงพิกัดของอุปกรณ์
  • เข้าถึงไมโครโฟนและกล้องถ่ายภาพของอุปกรณ์
  • เข้าถึงข้อมูลภายในตัวอุปกรณ์ เช่น สมุดที่อยู่ หรือข้อมูลการเอียงเครื่อง (tilt orientation)

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

ในการใช้งานจริงๆ เราคงใช้ผ่านเฟรมเวิร์คจาวาสคริปต์ที่เตรียมเรื่องพวกนี้ไว้ให้แล้วมากกว่า เช่น jQuery Mobile, Sencha Touch หรือ SproutCore เป็นต้น

4. Connectivity

HTML5 Connectivity

เทคโนโลยีกลุ่มที่สี่เน้นการเชื่อมต่อกับเครือข่ายที่ดีขึ้น มี 2 อย่างที่สำคัญ

WebSockets

WebSockets เป็น API ที่ออกมาเพื่อต่อยอดแนวทางของ AJAX ในอดีต อธิบายง่ายๆ มันคือการ push ข้อมูลจากเซิร์ฟเวอร์มายังไคลเอนต์ (แบบเดียวกับ push mail ที่เรารู้จักกัน)

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

WebSockets เกิดมาเพื่อแก้ปัญหานี้ โดยสร้างการเชื่อมต่อแบบ (เกือบ) ถาวรระหว่างเซิร์ฟเวอร์กับไคลเอนต์ เพื่อให้สองฝั่งส่งข้อมูลกันได้ตลอด ทั้งหมดรันอยู่บนโพรโตคอล TCP อีกชั้นหนึ่ง และไม่ได้วิ่งบนโพรโตคอล HTTP เพื่อประหยัดโหลดของ HTTP ครับ

ในการใช้งานเราจะเรียก WebSockets ด้วย

ws://

หรือถ้าต้องการการเชื่อมต่อแบบปลอดภัย

wss://

ข้อดีคือเบากว่า HTTP แต่ข้อเสียคือทั้งสองฝั่ง (โดยเฉพาะเซิร์ฟเวอร์) ต้องรองรับ WebSockets ด้วย จึงอาจจะใช้ไม่ได้ในทุกกรณี

ปัจจุบัน WebSockets เป็นมาตรฐานที่รับรองโดย IETF และกำลังผ่านกระบวนการเข้าเป็นมาตรฐานของ W3C

ข้อมูลเพิ่มเติม: Wikipedia, W3C, สอนการใช้งานที่ HTML5 Rocks

Server-sent Events (SSE)

WebSockets เป็นการส่งข้อมูลแบบสองทาง แต่ถ้าเราต้องการส่งข้อมูลทางเดียวจากเซิร์ฟเวอร์มายังไคลเอนต์ (เช่น notification ของ Facebook/Twitter) เราสามารถใช้เทคโนโลยีอีกตัวชื่อ Server-sent Events (SSE) แทนได้

SSE ถูกออกแบบมาเพื่อแก้ปัญหา polling ของ AJAX เช่นเดียวกับ WebSockets หลักการทำงานของ SSE คือเซิร์ฟเวอร์สามารถส่งข้อมูลไปยังไคลเอนต์ได้โดยตรง โดยที่ไคลเอนต์ไม่ต้องร้องขอ (GET Request) ก่อน

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

ในการใช้งานจริง เราอาจเลือกได้ระหว่าง

  • การส่งข้อมูลด้วย WebSockets ทั้งสองทาง (บน WebSockets)
  • การรับข้อมูลจากเซิร์ฟเวอร์ด้วย SSE แล้วส่งกลับด้วย XMLHttpRequest (บน HTTP)

ข้อมูลเพิ่มเติม: Wikipedia, W3C, สอนการใช้งานที่ HTML5 Rocks

5. Multimedia

HTML5 Multimedia

เรื่องนี้เราพูดกันมาเยอะมาก และเริ่มใช้งานจริงกันแล้ว คงไม่ต้องลงลึกในบทความตอนนี้

อธิบายแบบสั้นๆ คือเดิมที่ HTML4 ขึ้นไปไม่สามารถแสดงผลเสียง-วิดีโอได้โดยตรง ต้องใช้วิธีฝัง <object> แล้วติดตั้งปลั๊กอินเพื่อช่วยเล่นมัลติมีเดีย ซึ่งทำงานได้ตามนั้นแต่ก็มีปัญหายิบย่อยมากมายตามมาเช่นกัน

แต่พอเป็น HTML5 ได้กำหนดให้ HTML ต้องเล่นไฟล์เสียงและวิดีโอได้ในตัว จึงเป็นที่มาของแท็กใหม่ <audio> และ <video> ที่หลายคนคงลองใช้กันแล้ว ดังนั้นต่อไปเสียงและวิดีโอจะกลืนเป็นเนื้อเดียวกับเว็บเพจโดยตรง เราสามารถปรับเปลี่ยนการแสดงผลของมันได้เฉกเช่นเดียวกับส่วนอื่นๆ ของเว็บเพจ เช่น ย้ายตำแหน่ง ซ้อนฉากหลัง หาอย่างอื่นมาบัง ฯลฯ

อย่างไรก็ตาม เรื่องมัลติมีเดียของ HTML5 กลับมีปัญหาประการใหม่เพิ่มเข้ามา นั่นคือ “สงคราม codec” ระหว่างเบราว์เซอร์สองค่ายใหญ่ ดังที่เราเห็นจากข่าว WebM+Ogg (สนับสนุนโดย Chrome/Firefox/Opera) vs H.264 (สนับสนุนโดย IE/Safari) นั่นเอง

(ดูข่าวหมวด codec ประกอบ)

6. 3D, Graphics & Effects

HTML5 - 3D, Graphics & Effects

หมวดที่หกเกี่ยวกับเรื่องกราฟิก แบ่งเป็น 4 ประการย่อยๆ

SVG (Scalable Vector Graphics)

เป็นภาษาตระกูล XML ที่ออกแบบมาสำหรับการวาดกราฟิกแบบเวกเตอร์ (พอเทียบเคียงได้กับ SWF ของ Adobe หรือ XAML ของไมโครซอฟท์) เทคโนโลยีนี้มีมานานพอสมควรแล้ว คงไม่ต้องลงรายละเอียดนะครับ

Canvas

แท็ก <canvas> ถือเป็นของใหม่ที่สำคัญใน HTML5 เพราะมันช่วยเปลี่ยนลูกเล่นการแสดงผลของเว็บเพจไปอีกมาก

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

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

สิ่งที่เราสามารถใส่ลงไปในกรอบ canvas ได้แก่

  • รูปทรงพื้นฐาน สี่เหลี่ยม วงกลม เส้นตรง เส้นโค้ง พาธ (รูปทรงมีไม่เยอะเท่ากับ SVG)
  • ไฟล์รูปภาพ จะซ้อนกันกี่ชั้นก็ได้ตามสะดวก
  • แอนิเมชัน กำหนดให้วัตถุต่างๆ เคลื่อนไหว
  • แปลงสภาพวัตถุ (transformation) จะกำหนดให้หมุน เอียง บิดเบี้ยว ได้เหมือนกัน
  • ประกอบ-ซ้อนภาพวัตถุ (composition) เช่น นำสี่เหลี่ยมกับสามเหลี่ยมมา intersect เพื่อสร้างวัตถุแบบใหม่

ความต่างที่สำคัญของ SVG กับ canvas คือ

  • SVG ได้ผลลัพธ์เป็นเวกเตอร์ ส่วน canvas ได้ผลลัพธ์เป็นราสเตอร์ (ภายในกรอบวัตถุ canvas)
  • SVG สั่งวาดด้วยแท็กแบบ markup (ซับเซ็ตของ XML) ส่วน canvas สั่งวาดด้วยจาวาสคริปต์

รายละเอียดดูได้จาก Wikipedia, Canvas tutorial – Mozilla Developer Network, W3Schools HTML5 Canvas

WebGL

โดยทั่วไปแล้ว การวาดภาพ-แสดงผลใน canvas เรามักใช้กับภาพ 2 มิติเป็นหลัก แต่ถ้าต้องการวาดภาพ 3 มิติ เราจะใช้ส่วนขยายของ canvas ที่เรียกว่า WebGL (Web-based Graphics Library)

WebGL เป็นไลบรารีกราฟิกที่พัฒนาอยู่บน OpenGL ES 2.0 ซึ่งเป็นไลบรารีกราฟิก 3 มิติมาตรฐานของวงการไอที แต่ดัดแปลงให้เรนเดอร์ภาพออกมาบนออบเจคต์ canvas ภายในเบราว์เซอร์ และสั่งงานได้ผ่านจาวาสคริปต์ ตอนเรนเดอร์ก็ทำผ่าน GPU ตามปกติ (ดูข่าวเก่าหมวด WebGL ประกอบ)

ขั้นตอนการวาดภาพ 3 มิติบน WebGL แทบไม่ต่างอะไรกับ canvas ปกติ เพราะเราต้องกำหนดบริเวณที่เป็น canvas ในเว็บเพจขึ้นมาก่อน เพียงแต่ตอนวาดในจาวาสคริปต์ เราจะสร้างออบเจคต์ชนิด WebGL ขึ้นมาแทน canvas ปกติ

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

สถานะตอนนี้ของ WebGL คือเบราว์เซอร์ทุกค่ายสนับสนุนแล้ว ยังเหลือฝั่งไมโครซอฟท์ที่ยังไม่ยอมสนับสนุน (เหตุผลหนึ่งเพราะอยู่บน OpenGL ไม่ใช่ DirectX)

ข้อมูลเพิ่มเติม Getting started with WebGL – Mozilla Developer Network

CSS3 3D

CSS3 นั้นต่างไปจาก CSS2 มาก เพราะมันไม่ใช่มาตรฐานเดี่ยวๆ แต่ประกอบด้วยมาตรฐานย่อยๆ จำนวน “หลายสิบ” ชนิด ซึ่งหนึ่งในนั้นคือ CSS3 3D Transforms ที่สามารถแปลงสภาพวัตถุบนเว็บเพจในแบบต่างๆ เช่น ขยายขนาด หมุนเอียงตามแกน xyz

ดูตัวอย่างได้ที่ WebKit (ต้องใช้ WebKit เข้าด้วยนะครับ) หรือ The Web Rocks (Gecko/WebKit)

7. Performance & Integration

HTML5 - Performance & Integration

หมวดที่เจ็ดเป็นการปรับปรุงประสิทธิภาพการทำงานของเว็บแอพ แบ่งออกเป็น 2 ส่วนใหญ่ๆ

Web Worker

อธิบายง่ายๆ Web Worker คือจาวาสคริปต์ที่ทำงานแบบมัลติเธร็ด เพื่อให้สคริปต์สามารถทำงานเบื้องหลังได้หลายๆ งานพร้อมกัน

การใช้งานเราสามารถสั่งได้ที่ตัวโค้ดจาวาสคริปต์โดยตรง โดยสร้างตัวแปรชนิด worker ขึ้นมาบอกเบราว์เซอร์ว่า โค้ดจาวาสคริปต์ส่วนนี้ ขอให้ทำงานแบบ Web Worker เพื่อประสิทธิภาพที่ดีขึ้น

รายละเอียดอ่านเพิ่มที่ Wikipedia, W3C, Mozilla, HTML5 Rocks

XMLHttpRequest Level 2

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

XMLHttpRequest Level 2 เป็นความพยายามของ W3C ที่จะพัฒนา XMLHttpRequest รุ่นแรกให้มีประสิทธิภาพ-ความสามารถมากขึ้น แบ่งได้ง่ายๆ 3 อย่าง ได้แก่

  • การแยกแยะเหตุการณ์ (event) แต่ละชนิดออกจากกัน ช่วยให้โปรแกรมเมอร์ติดตามและควบคุมการส่งข้อมูลได้ง่ายขึ้น
  • รองรับการอัพโหลดไฟล์จากฝั่งไคลเอนต์ (เดิมที่ไม่รองรับการส่งไฟล์) ซึ่งจะใช้ควบคู่กับ File API ในหัวข้อก่อน
  • ส่งข้อมูลแบบข้ามหลายโดเมน ซึ่งรุ่นก่อนเรียกได้เฉพาะโดเมนเดียวกัน

รายละเอียดอ่านได้จาก AJAX 2: What is coming with XMLHttpRequest Level 2? – JS Classes blog

8. CSS3

HTML5 - CSS3

CSS3 มีความสามารถเพิ่มขึ้นจาก CSS2 ในปัจจุบันมาก เพิ่มฟีเจอร์ของแวดวงสิ่งพิมพ์ที่เกี่ยวข้องกับการจัดหน้า การควบคุมการไหลของข้อความ และฟอนต์เข้ามาอีกมาก แต่ก็ยังมีเรื่องอื่นๆ เช่น 3D, เสียงพูด, แอนิเมชัน ฯลฯ (ดูข่าวเก่าเรื่อง CSS3 Regions ประกอบ)

เทคโนโลยีอีกตัวที่เกี่ยวข้องกันคือ Web Open Font Format (WOFF) ที่ช่วยให้เราฝังฟอนต์เข้ามาในเว็บเพจได้ด้วย

รายการของชุดเทคโนโลยีใน CSS3 ทั้งหมดดูได้จาก CSS3.info

สถานะการรองรับ HTML5 ของเบราว์เซอร์ต่างๆ

เทคโนโลยีทั้ง 8 หมวดเป็นตัวแทนของเทคโนโลยีเว็บรุ่นใหม่ อย่างไรก็ตาม เทคโนโลยีเยอะขนาดนี้ซับซ้อนมาก และต้องใช้เวลาอีกนานกว่าจะทำเสร็จ อย่างไรก็ตาม เบราว์เซอร์ในปัจจุบันก็เริ่มรองรับมาตรฐาน “ฉบับร่าง” ในบางประเด็นแล้ว และเว็บดังๆ บางแห่งก็เริ่มใช้ฟีเจอร์ HTML5 กับงานจริงแล้วเช่นกัน

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

  • Wikipedia ข้อมูลละเอียดพร้อมลิงก์อ้างอิง
  • Can I Use ทำตารางเปรียบเทียบว่าคุณสมบัติใดใช้ได้บนเบราว์เซอร์ยี่ห้อไหน รุ่นไหนได้บ้าง
  • FindmebyIP.com ทำตารางเปรียบเทียบแบบดูง่ายๆ ภายในเว็บเพจหน้าเดียว
  • HTML5Test.com ทดสอบกับเบราว์เซอร์ที่เราใช้อยู่ในขณะนั้น และได้ผลลัพธ์ออกมาเป็นคะแนนรวม
  • HTML5 Readiness ทำเป็นแผนภาพ infographic แบบครึ่งวงกลม แยกตามมาตรฐานแต่ละส่วน (ใช้ข้อมูลจาก Can I Use อีกทีหนึ่ง)

ข้อมูลเพิ่มเติม

คัดมาเฉพาะอันที่เจ๋งๆ นะครับ ตามไปอ่านกันต่อได้

เว็บไซต์ของผู้ผลิตเบราว์เซอร์

  • HTML5 Rocks ของกูเกิล มีทั้งเอกสาร tutorial และโค้ดสำหรับทดสอบ-สาธิตการทำงาน
  • หน้าแนะนำ HTML5 ของ Mozilla Developer Network รวมข้อมูลเชิงเทคนิคไว้ครบถ้วน
  • HTML5 Labs เว็บไซต์สำหรับนักพัฒนา HTML5 ของไมโครซอฟท์
  • HTML5 Please แนะนำโดยคุณ @pittaya

เดโม

เอกสารอื่นๆ

  • HTML5 for Web Developers สเปก HTML5 แบบอ่านง่าย เหมาะสำหรับนักพัฒนาเว็บ ตัดส่วนที่ไม่สำคัญในสเปกของ W3C ออกไป
  • W3Schools HTML5 Tutorial เป็น online reference/tutorial แบบสั้นๆ ตามสไตล์ของ W3Schools
  • เอกสารของ InfoWorld เป็น PDF ที่เขียนโดยนิตยสาร InfoWorld ต้องสมัครสมาชิกก่อนจึงจะโหลดได้ (โหลดฟรี) ข้อมูลละเอียดและเนื้อหาอัพเดต
  • Dive Into HTML5 หนังสือแจกฟรีของ Mark Pilgrim

บทความดีๆจาก http://www.blognone.com/

การเขียนคําว่า “สนุกดอทคอม” แบบที่ถูกต้อง

การเขียนคําว่า “สนุกดอทคอม” แบบที่ถูกต้อง

Sanook

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

สอบถามข้อมูลได้จากทีม Corporate Communication ของบริษัท

การเขียนถึงสนุกดอทคอม แบบที่ถูกต้อง

  • สนุกดอทคอม
    (หากเขียนสนุกดอทคอมคำเต็ม ไม่ต้องมีเครื่องหมาย ! หลังคำว่าสนุก)

  • Sanook.com
    (ต้องขึ้นต้นด้วย S ตัวใหญ่เสมอ)

  • สนุก! (คำว่าสนุก! ต้องมีเครื่องหมาย ! ต่อท้ายทุกครั้ง)

  • Sanook!
    (คำเขียนภาษาอังกฤษต้องขึ้นต้นด้วย S ใหญ่และมีเครื่องหมาย ! ต่อท้ายทุกครั้ง)

  • Sanook! News
    (สำหรับคำภาษาอังกฤษ Sanook! วรรค ตามด้วยชื่อบริการ , Sanook!
    ให้ใช้ S ตัวใหญ่นำหน้า และ ขึ้นต้นชื่อบริการด้วยตัวอักษรภาษาอังกฤษตัวแรกตัวใหญ่เสมอ)

  • สนุก! ข่าว
    (ถ้าใช้ภาษาไทยก็ต้องเป็นคำไทยทั้งหมด เช่น สนุก! วรรค ตามด้วยชื่อบริการ )

  • S! News
    (โดยปกติคำเขียนห้ามใช้ S! ย่อ เนื่องจากคนจะอ่านว่า “เอส !” ไม่ได้อ่านว่า “สนุก!”
    จึงให้ใช้ได้เฉพาะบางกรณีเท่านั้น เช่น ชื่อของ Mobile application ที่ถูกจำกัดความยาว)

การเขียนถึงสนุกดอทคอม แบบที่ผิด ห้ามใช้

  • (X) สนุก! ดอทคอม
  • (X) Sanook!.com
  • (X) สนุก (เขียนผิดเพราะไม่มีเครื่องหมาย ! ต่อท้าย)
  • (X) Sanook (เขียนผิดเพราะไม่มีเครื่องหมาย ! ต่อท้าย)
  • (X) S! (เขียนผิดเพราะ S! ย่อจะใช้ได้เฉพาะที่เป็นโลโก้เท่านั้น)
  • (X) Sanook!News (เขียนผิดเพราะหลัง Sanook! ต้องเว้นวรรคแล้วตามด้วยชื่อบริการ)
  • (X) สนุก! News (เขียนผิดเพราะปนภาษาไทยและอังกฤษ)
  • (X) Sanook! ข่าว (เขียนผิดเพราะปนภาษาไทยและอังกฤษ)

การเขียนถึงชื่อบริษัท

  • บริษัท สนุก ออนไลน์ จำกัด / Sanook Online Limited
  • บริษัท สนุก ช้อปปิ้ง จำกัด / Sanook Shopping Limited
  • บริษัท ท้อปสเปซ (ประเทศไทย) จำกัด / Topspace (Thailand) Co., Ltd
  • บริษัท เลเวลอัพ ออนไลน์ จำกัด / Levelup Online Co., Ltd.