Update Omnigraffle Stencil for web designer

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

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

วันนี้ต้องออกแบบ web ใหม่ จึงเอา Stencil เก่ามาปัดฝุ่น และจัดกลุ่มให้ใช้งานง่ายขึ้น ใครต้องทำงานออกแบบ web เหมือนกัน สามารถ Download ได้จาก http://graffletopia.com/stencils/459

ตัวอย่างการใช้งานลองดูใน video นะครับ



สำหรับคนที่ออกแบบ Application ให้ลองดู Stencil นี้ครับ http://graffletopia.com/stencils/446 Read More!

Usability vs User Experience

วันก่อนได้มีโอกาสคุยกับทีมงาน open dream ได้ความรู้เรื่อง User Experience  จึงมาทำการบ้านเพิ่มเติมจนได้ข้อสรุปขั้นแรกว่า โจทย์ของ Usability และ User Experience นั้นต่างกัน

Usability

ผู้ใช้สามารถทำสิ่งที่ตนเองต้องการได้หรือยัง

User Experience

ผู้ใช้มีความสุขกับการทำงานหรือยัง

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

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

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


  Read More!

Cash Study โปรแกรม ERP: HDD มาก่อน TDD

HDD ไม่ใช่ Hard disk นะครับ แต่เป็น Help Driven Development (ผมตั้งขึ้นมาส่วนตัว) ก่อนหน้านี้เราฮิตเรื่อง Test Driven Development กันมาก ซึ่งผมเห็นด้วยเป็นอย่างยิ่ง แม้ว่าตอนทำงานจริงๆ จะเอามาใช้ได้แค่นิดหน่อย แต่ตอนที่ใช้อยู่จะมีความสุขมาก โดยเฉพาะตอนที่เจอ bug ที่คาดไม่ถึง

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

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

หากเอา Help มาเขียนหลังสุด เราต้องใช้ความพยายามอย่างมากในการนึก ในการอ่านเอกสาร หรือการอ่าน code เพื่อสรุปว่าโปรแกรมของเราทำงานอย่างไร และมีข้อยกเว้นอยู่ตรงไหนบ้าง อย่าลืมว่าโปรแกรม ERP มันจะโตขึ้นเรื่อยๆ ถ้าไม่รีบเขียนแต่ต้นๆ ก็จะเหมือนการทำ Test สุดท้ายจะทำไม่ได้ดี

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

เมื่อผู้ใช้คุ้นเคยกับ Help จะทำให้ SA, Developer, Tester, User ทำงานบนเอกสารเดียวกัน พูดเป็นภาษาเดียวกัน และเข้าใจกันและกัน มากขึ้น

   Read More!

Case Study โปรแกรม ERP: Paranoid System

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

ปัญหา

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

ข้อมูลในรายงานกับข้อมูลในคอมพิวเตอร์ ไม่เท่ากัน

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

ทางแก้

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

 

หน้าจอ version ของ google docs

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

คำแนะนำด้านเทคนิค

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

 

table สำหรับเก็บข้อมูล

ที่สำคัญเป็นการลดภาระให้โปรแกรม โดยเฉพาะส่วนออกรายงาน เพราะไม่ต้องแยกเอกสารเก่าออกจากเอกสารใหม่ทุกครั้ง

สำหรับคนที่ใช้ rails ผมแนะนำให้ใช้ plugin ชื่อ acts as versioned เพราะเป็น plugin ที่ทีมงานใช้อยู่ โดยมีเพื่อนร่วมงานคนหนึ่ง (Sid) ทำการดัดแปลงให้ใช้กับเอกสารที่มีหลายตารางได้ เช่น ใบ Quotation มีตาราง quotations เก็บข้อมูลของเอกสาร และ ตาราง quotation_details ใช้เก็บรายการในเอกสารเป็นต้น พอใช้ plugin ตัวนี้ก็แทบจะลืมไปเลยว่ามีการทำ version อยู่ ทุกอย่างทำอัตโนมัติ ทุกครั้งที่สั่ง save

จริงๆ มี plugin อีกตัวที่ชื่อ acts as versioned association ที่สามารถทำ version ของ เอกสารที่มีหลายตารางได้ แต่เนื่องจากไม่เคยใช้เลยไม่ได้แนะนำครับ นอกจากนี้จะมี plugin อีกตัวชื่อ acts as versioable ตัวนี้น่าจะทำงานคล้ายกับ act as verioned แต่ไม่เคยเล่นเหมือนกัน ใครสนใจลองหามาเล่นดูนะครับ

สำหรับ acts_as_paranoid เป็น plugin ที่เก่ามากแล้ว (2005) และไม่น่าเกี่ยวกับ versions แต่ชื่อมันเท่ดีเลยเอามาเป็นหัวข้อครับ :p Read More!

Case Study โปรแกรม ERP : ความกังวลเรื่องชื่อกับเวลา

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

กรณีศึกษาแรกคือเรื่องของการเปลี่ยนชื่อ, ที่อยู่ หรือข้อมูลในเอกสาร

ปัญหา

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

 

ภาพตัวอย่างเมื่อลูกค้า Orange เปลี่ยนชื่อเป็น True

ในภาพเมื่อลูกค้าย้อนกลับมาพิมพ์เอกสาร หรือกลับมาตรวจค้นเอกสาร โดยนำกระดาษมาเป็นตัวสืบค้น ลูกค้าจะเกิดความสับสนทันทีว่าอะไรคือค่าที่ถูกต้อง เอกสารในมือลูกค้าเขียนว่า "Orange" แต่ในโปรแกรมกลับแสดงคำว่า "True" ความไม่เท่ากันเกิดจากความผิดพลาดของโปรแกรม หรือเกิดจากการกรอกข้อมูลที่ไม่ถูกต้องกันแน่ แล้วแบบนี้ตอนรายงานจะถูกหรือเปล่า แล้วเอกสารอื่นๆ ล่ะ etc.

ทางแก้

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

ปัญหาที่ตามมามีสองข้อ

1. เอกสารที่ยังไม่ได้พิมพ์ หรือลูกค้ายังไม่ได้นำไปออกรายงาน ลูกค้าจะมีความเชื่อว่าเมื่อเปลี่ยนชื่อลูกค้า ใน Address book แล้ว เอกสารทุกใบที่กำลังจะพิมพ์ควรเปลี่ยนตามให้ด้วย (ลูกค้าลืมปัญหาแรกของเราไปแล้ว) จุดนี้ต้องตกลงกันให้ดีว่า ลูกค้าจะตามไปแก้เอกสารทุกใบเปลี่ยนเอง หรือจะให้โปรแกรมเปลี่ยนให้ตามเงื่อนไข เช่น ถ้า Project ของเอกสารนั้นยังไม่ปิด ให้นำข้อมูลใหม่มาพิมพ์เสมอ หรือมีปุ่มให้ลูกค้ากดในหน้า Project หรือในหน้าเอกสาร เพื่อเปลี่ยนเอกสารทั้งหมดให้เป็นชื่อใหม่
   
   ผมมีประสบการณ์ว่าถ้าเงื่อนไขซับซ้อน เราควรจะเปลี่ยนข้อมูลโดยให้ลูกค้าเป็นคนตัดสินใจ แต่อาจจะอำนวยความสะดวกด้วย ปุ่ม [update data] ในหน้าเอกสาร หรือในหน้า Project
   
2. เอกสารที่ตามมา เช่น Invoice ออกมาตาม Quotation จำเป็นต้องมีชื่อที่อยู่เหมือนใบ Quotation หรือไม่ อันนี้ต้องคุยกับลูกค้าให้ดีครับ เพราะเมื่อลูกค้าเปลี่ยนชื่อ อย่างกรณี Orange -> True ใบ Quotation ของเราเขียนว่า Orange แต่ถ้าออก Invoice ใบใหม่ เราจะเขียน True หรือ Orange ดี ตรงนี้ต้องแล้วแต่ลูกค้า บางรายก็อยากให้เราแก้ Quotation  ให้เป็น True เพราะ Job นี้ยังไม่ปิด บางรายก็ให้ copy ข้อมูลจาก Quotation มาให้หมดแล้วเค้าจะแก้เอง
   
   ผมมีประสบการณ์ว่าลูกค้าเปลี่ยนแปลงบ่อย ตรงนี้เราควรกำหนดไว้ใน config file หรือกำหนดไว้ในจุดที่เปลี่ยนวิธีได้ง่ายๆ สำหรับเรา

ทางแก้ในด้าน GUI

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

แนะนำทางเทคนิค

เมื่อโปรแกรมของเรามีเอกสารมากกว่า 1 เอกสาร ให้จำไว้ว่า "Don't repeat your self" อย่าให้มี code ซ้ำซ้อนกัน อย่าเอาง่ายโดยการ copy logic นี้ไว้ในเอกสารทุกตัว ถ้าไม่สามารถทำได้ หรือทำได้ยากให้ลองอ่านพวก Enterprise Software หรือถ้าใช้ Rails ให้ลองอ่าน Enterprise Rails ด้านล่าง จะช่วยให้ท่ายากๆ ทำได้ง่ายขึ้น

Read More!

นโยบายก็ต้องการ Usability

หลังจากอ่านบทความ "ประสบการณ์สร้างความสมานฉันท์ ของประเทศแอฟริกาใต้ในโครงการ Mont Fleur Scenario" ที่แสดงอยู่ในเว็บ SIU ทำให้ความรู้สึกเก่าๆ ย้อนกลับมา

ในบทความคณะรัฐบาลใช้ พฤติกรรมของสัตว์ 4 ประเภท แทนภาพอนาคตทั้ง 4 แบบ เพื่อให้ความรู้กับประชาชน

ในเว็บไซต์กล่าวว่า

1. นกกระจอกเทศมุดหัวลงในพื้นทราย (Ostrich) – เป็นอนาคตแบบที่ทุกฝ่ายไม่ต้องการการเจรจา ต่างคนต่างปกป้องผลประโยชน์ของกลุ่มตนเองเหมือนกับพฤติกรรมของนกกระจอกเทศ ที่เอาหัวมุดลงไปในดินไม่สนใจภาวะแวดล้อมที่เกิดขึ้นข้างนอก
2. เป็ดง่อย (Lame Duck) – อนาคตแบบนี้ ทุกกลุ่มต่างเริ่มหันหน้าเข้ามาคุยกัน เกิดรัฐบาลผสมหลายพรรคเกิดขึ้นแต่ด้วยเป็นรัฐบาลผสมทำให้ไม่มีเสถียรภาพ ตลอดจนไม่สามารถควบคุมกลุ่มต่างๆ ทำให้วิกฤตทางการเมือง
3. อิคารัส (Icarus) – อนาคตแบบนี้คือรัฐบาลผิวดำได้รับชัยชนะในช่วงแรก แต่ก็ต้องออกนโยบายประชานิยมขึ้นเพื่อให้ได้รับเสียงสนับสนุนจากกลุ่มต่างๆ ให้รัฐบาลอยู่ต่อไปได้ นโยบายประชานิยมเหล่านี้จะก่อให้เกิดปัญหาขาดดุลงบประมาณจำนวนมาก จนวิกฤตทางเศรษฐกิจ และปัญหาสังคมตามมา เปรียบเสมือนวีรบุรุษอิคารัสในเทพนิยายกรีก ที่มีปีกเป็นขี้ผึ้ง แต่บินสูงเกินไปจนถูกดวงอาทิตย์แผ่ความร้อนลงมาทำให้ขี้ผึ้งละลายจนร่วงตกลง สู่พื้นดิน
4. นกฟลามิงโกโบยบิน (Flight of the Flamingos) – เป็นอนาคตที่ทุกฝ่ายหันหน้าเข้าหากัน สามารถจัดตั้งรัฐบาลที่มีเสถียรภาพสูงได้ มีธรรมาภิบาล ไม่มีการคอร์รัปชั่น มีการพัฒนาการทางเศรษฐกิจที่ยั่งยืน สามารถสร้างความเชื่อมั่นต่อประชาชนทุกกลุ่มไม่ว่าจะผิวสีใดหรือชนเผ่าใดก็ ตามในประเทศ

(ผมย่อไปไปเยอะ สามารถอ่านตัวเต็มในเว็บ SIU นะครับ)

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

คนออกแบบ Usability ของนโยบาย ต้องรู้ว่าใครเป็นผู้ฟัง การออกแบบข้อความก็ต้องไม่เหมือนกัน เปรียบเหมือนการออกแบบโปรแกรม Lightroom กับ iPhoto

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

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

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

เทียบกับการนำเสนอรัฐธรรมนูญไทย ในช่วงที่ผ่านมาที่เอาหนังสือมาแจกหนึ่งเล่ม แถมในเล่มไม่ได้แสดงภาพรวม แต่กลับบอกเป็นข้อๆ ทั้งหมด 183 มาตราเป็นภาษากฏหมายล้วนๆ เปรียบเหมือนเอา Photoshop มาให้ประชาชนทั่วไปใช้

ส่วนตัวผมเชื่อว่าคนส่วนใหญ่ไม่ได้อ่าน และมีเพียงบางคนที่พยายามอ่านแล้วเข้าใจ

จุดประกายโดย SIU Read More!

Firebug ออก version 1.5 แล้ว

วินาทีนี้ที่ยังใช้ Firefox อยู่ก็เพราะเจ้า Firebug นี่ล่ะครับ วันนี้version 1.5 สามารถ Download ได้แล้วครับ เลยเอามาประกาศให้ทราบโดยทั่วกัน

สำหรับผม สิ่งที่ชอบที่สุดใน version นี้ ไม่ใช่ Feature ที่เพิ่มขึ้น อย่าง Break on Next หรือการรองรับ SVG, Math ML แต่ผมถูกใจความเร็วที่เพิ่มขึ้นแบบสุดๆ เมื่อก่อนตอนเลื่อน mouse เพื่อทำ inspect แทบจะต้องรอเป็นวินาที จนต้องหันมาใช้การ คลิกขวา>inspect แทน

แต่ตอนนี้เมื่อกดปุ่ม inspect แล้วเลื่อน mouse ไปบนหน้าจอ การ inspect จะเกิดขึ้นแบบ real time ประทับใจสุดๆ ครับ

ใครยังไม่ได้ใช้ก็หามาแทนตัวเก่าได้แล้วนะครับ

จุดประกายโดย Firebug Release note Read More!