วันอาทิตย์, มกราคม 31, 2553

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

วันศุกร์, มกราคม 29, 2553

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 ด้านล่าง จะช่วยให้ท่ายากๆ ทำได้ง่ายขึ้น

วันพฤหัสบดี, มกราคม 28, 2553

นโยบายก็ต้องการ 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

วันพฤหัสบดี, มกราคม 21, 2553

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

วันอังคาร, มกราคม 19, 2553

ไม่มีทางลัด

เมื่อวานนี้ได้ยินคนคุยกันว่า "ปล่อยให้เค้าจบๆ ไปเถอะอย่างไปตัดอนาคตเค้าเลย" ทำให้เกิดความคิดค้างอยู่ในหัว นานจนถึงเช้า

ผมคิดว่าตอนนี้มีคนมากมายที่มีความคิดฝังหัวแบบง่ายๆ ว่า

"มีเงิน" = "เรียนจบ"

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

"มีเงิน: มีงาน" = "เรียนจบ: มีความรู้"

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

การหาทางลัดไม่ได้มีเฉพาะเรื่องเรียน แต่มันซึมไปทุกเรื่อง เช่น

"เท่" = "มีรถขับ"

คนจึงพยายามแก้สมการนี้ด้วยวิธีลัด

"เท่: หาเงินได้" = "มีรถขับ: ขอตังพ่อแม่"
"เท่: หาเงินได้" = "มีรถขับ: ขโมยมา"

แต่ถ้าอยากเท่จริง สมการนี้ควรสมบูรณ์ด้วย

"เท่: หาเงินได้" = "มีรถขับ: หาเงินได้"

ปัญหานี้วนอยู่ในหัวผมนานมาก สุดท่้ายก็ได้แนวทางแก้ปัญหาออกมาแบบนี้

ทางออกของสังคมคือ การทำลายความจริงสองข้อ

"มีเงิน: มีงาน" = "เรียนจบ: อาจารย์ให้จบ"

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

"เรียนจบ: มีความรู้" = "เรียนจบ: อาจารย์ให้จบ"

คืออาจารย์เห็นใจ จำใจ ท้อแท้ใจ ให้จบๆ ไป

ทางออกของนักศึกษาคือ

"อย่าเสียเวลาหาทางลัด เพราะทางลัดไม่มีจริง" อย่าเสียเวลาหาทางเรียนให้จบ เอาเวลาไปหาความรู้ดีกว่า

** แล้วจะรู้ว่าการเรียนเป็นทางที่เร็วที่สุดในการหาความรู้ เค้าจึงเรียกย่อๆ ว่า "เรียนรู้" ไงครับ

วิวัฒนาการของที่ขั้นหนังสือ

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


มันคือที่ขั้นหนังสือแบบมีนิ้วคอยชี้ตำแหน่งที่เราอ่านถึง ไม่ต้องคอยอ่านให้จบหน้าทุกครั้ง คราวนี้อ่านแค่จบย่อหน้าก็พอ จากนั้นก็เอานิ้วคอยชี้เอาไว้

ของเค้าเท่จริง แต่ผมว่ามันยังใช้ยากอยู่ โดยเฉพาะกับคนที่อ่านๆ หยุดๆ แบบผม คงต้องพัฒนาอีกหน่อยให้ดึงเข้าดึงออกง่ายๆ

จุดประกายโดย swiss-miss

วันจันทร์, มกราคม 18, 2553

Google App สำหรับ Google Nexus

หลังจากดู Video หน้าตาของ Gmail บน Google Nexus เป็นครั้งแรก ที่ผานมาได้ดูแต่รูป ไม่รู้สึกเท่าไหร พอได้เห็นภาพเคลื่อนไหว ทำให้ผมรัก Web OS ของ Palm มากขึ้น



ประทับใจที่ Google แปลง Gmail มาลงมือถือได้ครบถ้วน แต่ถ้าพยายามมองหาข้อเสีย คงมีหลักๆ สองข้อครับ

1. Google ไม่ได้นำ widget พื้นฐานของตัวเองมาใช้ เช่น ปุ่ม reply, Start หรือ การสร้าง layer ของ E-mail ควรจะใช้ตัวเดียวกับ google reader จะทำให้นักพัฒนาสามารถเลียนแบบ Google ได้ง่ายขึ้น ไม่ต้องสร้างรูปแบบการแสดงผลของตัวเองขึ้นมาใหม่ ซึ่งเป็นเหตุให้โปรแกรมบน Android ขาดความสม่ำเสมอ(consistency)

ทางแก้ 1:เปิด API ส่วนของการสร้าง widget แบบ e-mail ออกมา แล้วส่งเสริม หรือนำไปใช้ในหลายๆ App ของ Android
ทางแก้ 2: พยายามสร้าง widget ของส่วนที่เป็น web กับส่วนที่เป็น app ให้เหมือนกัน

2. การเก็บรายละเอียด ไม่รู้ต้องโทษทีม browser หรือทีมออกแบบ Application แต่ส่วนพื้นฐานของ Android ไม่ได้เก็บรายละเอียด (โดยเฉพาะถ้าเทียบกับ iPhone) เช่น


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

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


จุดประกายโดย Digitizor