01204482 – Human Computer Interface


เนื้อหาทั้งหมดต่อจากนี้ถูกเขียนโดยนิสิตภาควิชาวิศวกรรมคอมพิวเตอร์

คณะวิศวกรรมศาสตร์ มหาวิทยาลัยเกษตรศาสตร์ รุ่นที่ 23

โดยเป็นเนื้อหาจากบทเรียนทีเกิดจากการจดบันทึกในห้องเรียนและศึกษาเพิ่มเติมจากนอกห้องเรียน

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

อย่างไรก็ตาม

ในกรณีที่ถูก นำไปใช้หรือนำไปอ้างอิงด้วยวิธีใดวิธีหนึ่งก็ตาม ในกรณีที่เนื้อหาไม่ถูกต้อง ไม่เหมาะสม ผู้เขียนจะไม่ขอรับผิดชอบใดๆทั้งสิ้น ขอให้อ่านด้วยวิจารณญาณของผู้อ่านเอง

ท่านสามารถอ่านเลคเชอร์ฉบับ Document ได้ที่นี่

==============================================

 

Human-Computer Interface

designing

the

User Interface

 


 

ผู้แต่ง

Ben Shneiderman
Catherine Plaisant


แปลไทยโดย

Sargon

 


สารบัญ


Usability of Interactive Systems

Intro

Usability Goals and Measures

Usability Motivations

Universal Usability

Goals for Our Profession

Guidelines, Principles, and Theories

Guidelines

Principles

Theories

Direct Manipulation and Virtual Environments

Introduction

Examples of Direct Manipulation

Discussion of Direct Manipulation

3D Interfaces

Teleoperation

Virtual and Augmented Reality

Menu Selection, Form Fill-In, and Dialog Boxes

Introduction

Task-Related Menu Organization

Single Menu

Combinations of Multiple Menus

Content Organization

Command and Natural Language

Interaction Devices

Collaboration and Social Media Participation← ครึ่งเทอมหลังเริ่มที่นี่

Introduction

Goals of Collaboration and Participation

Asynchronous Distributed Interfaces : Different Place, Different Time

Synchronous Distributed Interfaces: Different Place, Same Time

Face-to-Face Interfaces: Same Place, Same Time

Quality of Service

Introduction

Model of Response-Time Impacts

Expectations and Attitudes

User Productivity

Variability in Response Time

Frustrating Experience

Balancing Function and Fashion

Introduction

Error Message

Nonanthropomorphic Design

Display Design

Web Page Design

Window Design

User Documentation and Online Help

Introduction

Online Versus Paper Documentation

Reading from Paper Versus from Displays

Shaping the Content of the Documentation

Accessing the Documentation

Online Tutorials and Animated Demonstrations

Online Communities for User Assistance

The Development Process

Information Search

Introduction

Searching in Textual Documents and Database Querying

Multimedia Document Searches

Advanced Filtering and Search Interfaces

Information Visualization

Introduction

Data Type by Task Taxonomy

The Seven Data Type

The Seven Basic Tasks

Challenges for Information Visualization

Managing Design Processes

Introduction

Organizational Design to Support Usability

The Four Pillars of Design

Development Methodologies

Ethnographic Observation

Participatory Design

Scenario Development

Social Impact Statement for Early Design Review

Legal Issue

Evaluating Interface Design

Introduction

Expert Reviews

Usability Testing and Laboratories

Survey Instruments

Acceptance Test

Evaluation During Active Use

Controlled Psychologically Oriented Experiments

[ ข้อสอบ ] ข้อสอบ final จากเว็บ อาจารย์

[ ข้อสอบ ] Final Exam: Computer Human Interfaces 1/2010 (CPE)

[ บทความเสริม ] เวลาตอบสนอง (response time)



Usability[a] of Interactive Systems

“ออกแบบอะไรให้ simple นั้นไม่ simple”

Intro

ตอนนี้เราอยู่ในยุคอันน่าตื่นเต้นของการออกแบบ User interface ดูตัวอย่าง WWW ก็เป็นช่องทางเชื่อมโลกเข้ากับเรา ตอนนี้มี Interface ต่อ WWW บนมือถือกลายเป็นว่าโลกรวมกันเป็นหนึ่งเดียวได้ในทันทีทุกเวลา วิชา HCI นี้ดึงเอา Experimental Psychology (จิตวิทยาเกี่ยวกับการทดลอง) เข้ามารวมกับ Com Sci

ผลกระทบของ User interface ที่น่าสนใจ

  1. Search engine ดีๆอย่าง Google ที่ใช้ง่าย ทุกคนมีข้อมูลที่ต้องการ
  2. โลกอินเตอร์เน็ต เกิดอิสระในการแบ่งปัน ทางตรงข้าม เกิดการละเมิดลิขสิทธิ์ สงครามทรัพย์สินทางปัญญา…
  3. Interface ที่ดีป้องกันโจร ป้องกัน terrorist ทำลายชาติ
  4. หมอตรวจโรคได้ดีขึ่น เราขึ้นเครื่องบินกลับบ้านได้อุ่นใจ เราเรียนรู้ได้ดีขึ้น
  5. เหล่าอาทติสสามารถปลดปล่อยความคิดสร้างสรรค์ได้เต็มที่เช่นโปรแกรมวาดภาพ
  6. คนพิการมีชีวิตที่ดีขึ้น
  7. เกิดความกลัวและไม่ไว้วางใจหรือท้อแท้ได้เพียงแค่เห็นเมนูเป็นพรืด
  8. Interface ช่วยให้นักธุรกิจตัดสินใจ ซื้อหุ้น กำหนดนโยบาย
  9. เกิดมือถือ คอมหายไป การสื่อสารก็เกิด เมื่อมีการสื่อสารก็เกิดการพาณิชย์ เงินไหลๆ
  10. ทำงานที่บ้านก็ได้ ไม่ต้องเจอหน้ากันก็ได้ แล้ว Personal trust จะบั่นทอนลงหรือไม่ ควางจงรักภักดีต่อเจ้านายจะหายไปหรือไม่

จะเห็นว่าวิชานี้มันช่างยิ่งใหญ่นัก


ความท้าทายมีมากมาย เช่นความ Plasticity ที่ไม่ว่าจอจะเล็กจะใหญ่ก็ต้องใช้ได้

ใครมาด้วยภาษาอะไรก็อ่านออก คนพิการต้องใช้ได้ ต้อง ubiquitous

ต้องอ่านใจคนใช้ได้ผู้ใช้ไม่ต้องคิดอะไรมาก แม้กระทั่งต้องทำให้ไม่ต้องพกพาเลย

ฝังมือถือเข้าไปในผิวหนังซะเลยเป็นไง หรือจะให้เปลี่ยนแปลงหน้าที่ตามอารมณ์ผู้ใช้…

Usability Goals and Measures

สิ่งที่ทุกคนอยากได้ : Interface เทพที่ใครๆก็ใช้ มีคนมาลอกเลียนแบบเต็มเลย

สิ่งที่ต้องทำ : กำหนดเวลากับ budget ->ผู้ใช้ต้องการอะไร -> สร้างดีไซน์มาหลายๆแบบไว้เลือก -> ดูว่าอันไหนดี (evaluation) -> คิดให้เหนือกว่า subjective guideline โดยการไปดู evidence-based[b] guideline ประกอบ ว่างๆไปค้นงานวิจัยเพิ่ม -> ทันเวลา ไม่เกินงบ -> อีกมากมายไม่อยากพิมพ์แล้ว

ถ้าทำได้ขนาดนั้นแล้วก็จะได้ Interface ที่ผู้ใช้ใช้แล้วรู้สึก success มั่นใจว่าอะไรจะเกิดขึ้นจากทุกการกระทำไม่ต้องกังวล Error สามารถซึมซับอยู่กับงานเสมือนว่าไม่มี Interface อยู่เลยทีเดียว

เพื่อให้ง่ายเลยมี benchmark มาให้ดูว่าทำไงเพื่อความ usability ที่มากขึ้น:

  1. Time to learn ← ถ้าจะเอาน้อยๆ บางที performance ไม่ดีนะ
  2. Speed of performance ← performance ที่ดีอาจเกิดจากการใช้คีย์ลัด หรืออื่นๆที่ต้องใช้เวลาเรียนรู้นะ
  3. Rate of error by user ← เวลาที่คนใช้กว่าจะแก้ error ได้ก็จะไปเพิ่มในข้อ b อีก
  4. Retention over time ← ใช้แล้วจำได้มั้ย อย่างตอนนี้ก็ลืม vi ไปแล้ว
  5. Subjective satisfaction ← ชอบมั้ย ( subjective แปลว่าเป็นความคิดเห็นส่วนตัว )

ดังนั้นถ้าเราจะเน้น performance จัดๆ พอจะขายก็ต้องอวดถึงจุดนั้น อย่าไปอวดเรื่องความใช้ง่ายที่เราไม่เด่น (เพราะมันดึงกัน ไอ้สองค่านี้)

Usability Motivations

มาดูตัวอย่างกันเถิด

Life-critical system → อยากจะบังคับเครื่องบินหรือยิงนิวเคลียร์งี้ Time to learn นานๆก็รับได้ เอาชัวร์ว่าไม่ error แล้วก็ผู้ใช้เป็นมือ pro ไฟแรงไม่มีแม่บ้านขี้บ่นแน่นอนดังนั้นไม่ต้องแคร์เรื่องความพึงพอใจส่วนบุคคล ด้าน retention ก็ต้องใช้บ่อยๆอยู่แล้วจำได้แน่

Industrial and commercial uses → อย่างการทำบัญชีหรือจองโรงแรม อันนี้เวลาเป็นเงินเป็นทอง ค่าใช้จ่ายคือเลือดเนื้อ Time to learn จะแพงขึ้นมาทันที ถ้าต้องฝึกนานจะทันกินมั้ย อีกอย่างต้องมีหลายภาษาเพราะโลกธุรกิจนั้นกว้างใหญ่ และความเร็วเป็นเรื่องสำคัญที่จะรองรับ transaction เป็นล้านๆอัน

Home & Entertain → ทั้ง Wii , FB , YouTube เทือกนี้ นอกจากต้องเรียนรู้ง่าย Error ต่ำ ยังต้องแคร์ Subjective satisfaction เพราะคู่แข่งมีมาก ถ้าใช้อะไรแล้วไม่พอใจนิดหน่อยก็จะยอมแล้วไปใช้ของคู่แข่งในทันที กลยุทธ์ที่ดีคือทำให้ผู้ใช้ up level ตัวเองไป layer ที่สูงขึ้นได้ ถ้า noob อยู่ก็ได้ใช้อันง่ายๆ ถ้าโปรแล้วก็มีอันเจ๋งกว่าให้ ( google ใช้ง่าย แต่มี advanced search ไง ) หรือตัด feature ออกเช่น iPhone ก็เข้า terminal ไม่ได้แต่มันก็ทำให้คนใช้ไม่ต้อง geek มาก ก็ชนะใจคนได้

Exploratory, Creative, Collab → เช่นโปรแกรมประชุม online หรือโปรแกรม AutoCAD ผู้ใช้จะเจ๋งในด้านการทำงาน แต่จะอ่อนด้านที่ว่าจริงๆแล้วมันทำให้เราได้ยังไง มันทำให้เราประชุมได้ไง ดังนั้นสิ่งสำคัญสำหรับคนทำ interface คือตั้งใจทำให้ interface หายไปเลย พยายามให้ผู้ใช้อยู่กับงานให้เต็มที่ไม่ต้องกังวลด้านเทคนิค

Sociotechnical system → คือระบบที่เกี่ยวข้องกับคนจำนวนมากๆๆๆๆ เช่นระบบสแกนลายนิ้วมือ ระบบแจ้งความ ระบบเลือกตั้ง online อารมณ์ประมาณพัฒนาโดยรัฐบาล อันนี้ส่วนสำคัญคือ Trust , Privacy เช่นเลือกตั้งไปแล้วได้จริงเปล่า ก็ต้องออกใบเสร็จด้วย (feedback) แล้วต้องมีความปลอดภัยสูงเพราะแน่นอนเป็นเป้าโจมตีแน่ คนมาใช้มีมากหน้าหลายตา สำหรับ noob เช่นแม่บ้านมาเลือกตั้งก็เน้นความใช้ง่ายแล้วสร้าง Trust ด้วย Feedback ส่วนมือ pro เช่นพวก admin ก็ต้องมี interface สำหรับดูแลให้ เอาไว้ดูความผิดปกติได้

Universal Usability

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

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

Variations in physical abilities and physical workplaces → คนเรามีหลายแบบเกินไป ชายหญิงอ้วนผอมสูงต่ำดำขาว เพราะงั้นไม่มีคำว่า Average ของมนุษย์โลก เว้นแต่มันเหมือนกันมากๆเช่นขนาดมือ เพราะงั้น icon บน iPhone มันก็ทำมาเท่านั้นตามส่วนมาก ถ้าใครมือใหญ่ก็ซวยไป แต่บางอย่างมันแล้วแต่คน เช่น ความสว่างจอ ความสูงเก้าอี้ เราต้องทำ Adjustment control ไงล่ะ ปรับได้เองเลย หรือทำ Multiple version มีหลายแบบให้เลือก

มาดูด้าน Workspace บ้าง perception[c] ของคนเราก็แตกต่างกัน คนเราตาไวไม่เท่ากัน ตามองเห็นสีไม่เหมือนกัน มองสิ่งสว่างมืดได้ไม่เท่ากัน การได้ยินไม่เท่ากัน การสัมผัสต่างกัน พวกนี้สำคัญ เช่นออกแบบที่ทำงาน เก้าอี้ต้องปรับได้ ที่ว่างที่ขาต้องมี มีที่รองมือขาแขน แสงสว่างต้อง 200-500 lux หรือต้องไม่มีแสงสะท้อน ห้องทำงานอาจจัดให้หัวหน้างานได้ดูแลได้คุยกับลูกทีมได้ง่ายๆ ขณะที่โปรแกรมเมอร์หรือมือวาดรูปเจ้าอารมณ์ก็จัดมุมเงียบๆให้ เห็นมั้ยว่าแค่จัดห้องก็เพิ่มลด human interaction ได้แล้ว หรือออกแบบมือถือ มักจะหยิบมาเล่นบนรถต่างๆที่สั่นสะเทือน ถ้าออกแบบเมนูก็ทำให้แบบว่าสั่นแล้วก็ยังพอใช้ได้ก็ดีนะ

Diverse cognitive[d] and perceptual[e] abilities → ผู้ที่จะมาใช้เนี่ย สมาธิสั้นมั้ย กล้าตัดสินใจมั้ย เรียนรู้เก่งมั้ย อดนอนมารึเปล่า etc. เอามาคิดด้วย

Personality differences → เรื่องที่น่าปวดหัว บางคนไม่ชอบคอม บางคนชอบคอมแต่ไม่อยากได้ GUI เลยก็มีจะ command อย่างเดียว ผู้ชายผู้หญิงก็เกี่ยว ทำไมผู้ชายถึงเล่นเกมมากกว่าหญิง แต่ทำไม The sims มาแล้วผู้หญิงมาเล่นด้วย? เพราะอะไร ชอบเกมที่ไม่ค่อย action หรือ? หรือชอบสีอ่อนๆ การดูสิ่งเหล่านี้ไม่มีหลักตายตัว แต่ดูดีๆอาจได้อะไรที่ซ่อนอยู่ได้…

มี guide คร่าวๆไว้แบ่งประเภทคน

  1. Extroversion vs Introversion : ชอบสิ่งที่แสดงให้ทำ action ต่างๆ ปะทะ ชอบความคุ้นเคยเดิมๆ
  2. Sensing vs Intuition : ทำตามแผน,วิธี แล้วได้ชัวร์ ปะทะ ค้นหาและลองๆแก้เอง
  3. Perceptive vs Judging : ชอบเรียนรู้แต่ตัดสินใจยาก ปะทะ จอมวางแผน
  4. Feeling vs Thinking : คนขี้เกรงใจคนอื่น ชอบเอาใจคนอื่น ปะทะ หนุ่มเงียบไร้อารมณ์ ตัดสินเด็ดขาด อะไรไม่เรียงตามลำดับมีเคือง

Culteral and international diversity → คนญี่ปุ่นหรือจีนมาใช้อาจอ่านเรียนไม่เหมือนคนอื่น คนที่มาจากประเทศที่ระเบียบจัดอาจจะอยากได้หน้าต่างนิ่งๆแบบคลิกทีเดียว ใครมาจากประเทศที่มีตำนานนิยายหรือ action ก็อาจจะชอบหน้าที่มี animation มีคลิกเมนูหลายครั้ง หน้าเว็บมหาลัยของประเทศนึงอาจโชว์ตึกอันน่าภาคภูมิใจแต่อีกประเทศอาจโชว์บรรยากาศนักศึกษากำลังทำกิจกรรมกันแทน หรือการเขียนชื่อสกุลประเทศไหนเอาอะไรนำหน้า

User with disabilities → น่าจะรู้กันอยู่ว่าต้องทำอะไรบ้างสำหรับคนพิการเพราะงั้นไม่พิมพ์แล้ว เออแล้วก็บางทีเราพิการชั่วขณะเช่นขับรถอยู่ไม่มีมือ หรือเสียงรอบข้างดังมากไม่ได้ยิน เอาไปคิดด้วย

Older adult users → ก็คล้ายๆผู้พิการ ทำ font ให้ปรับได้ หรือให้ใช้ทัชสกรีนดีกว่าเม้าส์ etc. อีกอย่างเมื่อคนแก่เข้าถึงเทคโนโลยีได้ คนอื่นๆก็เท่ากับว่าเข้าถึงคนแก่ได้ หลายๆจะเมลหาคุณปู่ได้ เราสามารถรับความคิดเห็นของคนสูงอายุได้ผ่านเน็ต เป็นต้น

Children → เด็กที่คลุกคลีกับเทคโนโลยีได้ โตมาจะเทพ คอยแนะนำคนอื่นได้ ขณะเดียวกันขณะเป็นเด็กก็เสียงกับภัยต่างๆเช่นใช้ยาก เพื่อนเลว ภาพโป๊ คนแปลกหน้า… สำหรับวัยทีน พวกเขาจะเป็นคนนำเทรนเรื่อง communication ทางใหม่ๆได้ดีซะจนคนออกแบบยังทึ่ง ดูอย่าง Line แปปเดียวก็ฮิตแล้ว งานหนักของนักออกแบบคือ เด็กก็อยากได้ความท้าทายบ้าง และให้ผู้ปกครองมั่นใจว่าปลอดภัยด้วย เด็กชอบสำรวจแต่เขาก็อยากรู้หนทางที่จะ restart เริ่มใหม่ลองใหม่ด้วย (ไม่ใช่ไปซ่อนเมนู exit ไว้ซะลึก… angry birds ปุ่มเริ่มใหม่อยู่ใกล้ๆเอง ปุ่มออกของไอโฟนก็แค่กดปุ่มบนเครื่องทีเดียวเป็นต้น) เด็กมีความสามารถในการทำซ้ำสูง นั่งฟังเพลงเดิมๆจนคนอื่นเบื่อไปหมดแล้วก็ยังได้ อ่านนิทานอ่านแล้วอ่านอีก เกมจบแล้วก็เล่นอีกๆ เพราะงั้นนักออกแบบ ถ้าให้เด็กเป็น partner ในการออกแบบได้คงดีมาก แต่! อย่าลืมว่าเด็กๆยังพัฒนาไม่เต็มที การลากเม้าส์ การดับเบิลคลิก การคลิกปุ่มเล็กๆ ระวังด้วย ยิ่ง Error message นี่อย่าเอามาเด็ดขาด เรื่องความปลอดภัยก็ต้องมีตามที่บอกตะกี้

Accommodating hardware and software diversity → ทำอะไรคิดถึงของรุ่นเก่าๆด้วยนะ

Goals for Our Profession

เป้าหมายชีวิตของพวกเรา

Influencing academic and industrial researchers → มาเรียนวิชานี้แล้วเราได้เข้าใจคน เข้าใจความเครียดความกลัว เข้าใจการพัฒนาของคน ศึกษาความเป็นสัตว์สังคมของคน ได้ถกเถียงเรื่องอุปกรณ์ input และอื่นๆอีกมากมาย

Providing tools, techniques, and knowledge for commercial designers → ตลาดด้านนี้กำลังมาแรง ใครดีไซน์ UI เป็นมีแต่คนจ้างไปทำงานเพื่อเอาชนะคู่แข่ง แบบนี้ยังไม่อยากเรียนวิชานี้อีกหรือ

Raising the computer consciousness of the general public → ทำไมหลายๆคนยังกลัวคอมพิวเตอร์อยู่ ใช้แล้วรู้สึกไม่มั่นใจ กลัวคอมจะฉลาดกว่าเราหรือ โอนเงินผ่านเน็ตจะได้จริงเปล่า ความกลัวเหล่านี้เกิดจากดีไซน์ที่ไม่ดีต่างหาก พวกเรานักดีไซน์หวังว่าคนที่เจอ SYNTAX ERROR ขึ้นมาจะไม่โทษตัวเองและรู้สึกแย่แต่มาด่านักออกแบบแทนว่าทำไมไม่คิดอะไรให้ดีกว่านี้ หน้าที่ของพวกเราคือการเปลี่ยนภาพลักษณ์ของคอมและระบบต่างๆให้กลายเป็นความอบอุ่นที่ทุกคนจะได้รับเมื่อมาใช้งาน


Guidelines, Principles, and Theories

Guidelines

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

Navigating the interface

Guidelines โดย National Cancer[f] Institute เพื่อการสร้างเว็บเพจที่ดี แต่มีคนเอาไปใช้ต่อกันมาก

  1. Standardize task sequence – ลำดับการใช้งานต้องคล้ายๆกัน ถ้าสิ่งที่ทำคล้ายๆกัน
  2. Embeded link บอกถึงจุดหมายชัดเจน
  3. Heading แตกต่างกัน บอกถึงเนื้อหาภายใน
  4. อันไหนเลือกได้อันเดียวใช้ Radio button
  5. หน้าเว็บต้อง print ได้
  6. ถ้าภาพใหญ่ไม่สำคัญจริงๆ ต้องแสดงเป็น thumbnail ก่อน

Accessibility guidelines เพื่อคนพิการ โดยสหรัฐ

  1. Text alternatives – อันไหนไม่ใช่ text ต้องแปลงเป็น text ได้!
  2. Media ที่ขึ้นกับเวลา (Time-based) เช่นวิดิโอ ต้องมี “alternatives” เช่นมี subtitle ให้อ่าน
  3. Distinguishable – แยกได้ เช่นดจะดูวิดิโอก็สามารถปิด bg หมดเหลือแต่วิดิโอได้ ใช้สีมาช่วยเช่นทำรอบๆสีดำ ทำให้ตรงกลางเด่นขึ้น
  4. คาดเดาได้ ตรงใจ

 

Organizing the display

อันนี้ guidelines ว่า แสดงข้อมูลอย่างไรให้ดูดี โดย สองพี่น้อง

  1. คำย่อ ขนาดอักษร สี อื่นๆ ต้องคงที่ (consistency)
  2. ผู้ใช้ต้อง Assimilation[g] ได้ดี เช่นเลขผสมอักษร (alphanumeric) ชิดซ้ายในช่องตารางแต่เลขจะชิดขวา จุดทศนิยมของแต่ละช่องตารางจะเรียงกัน etc.
  3. ผู้ใช้ไม่สมควรที่จะต้องจำ ไม่ใช่ว่ามาหน้านี้แล้วต้องใช้ข้อมูลจากหน้าที่แล้ว ลืมไปแล้ว
  4. ใส่ข้อมูลอย่างไรควรจะออกมาอย่างนั้น ดีที่สุดคือตรงแสดงข้อมูลนั่นแหละที่สามารถใส่ข้อมูลได้ (เช่นแก้วันที่ก็คลิกตรงวันที่)
  5. ผู้ใช้เปลี่ยนรูปแบบการนำเสนอให้เหมาะกับที่ต้องการได้

อันนี้ guidelines ของการสร้างห้องควบคุมวงจรไฟฟ้า ดูๆไปก็เอาไปใช้ได้ดีทีเดียว

  1. label, ภาพสัญลักษณ์ คำย่อ ต้อง consistent
  2. ข้อมูลที่ไม่ได้มีประโยชน์ อย่าเอามาให้ดูเลย
  3. ถ้าจะแสดงข้อมูลเป็นภาพ ทำไงก็ได้ให้ไม่ต้องมาแปลค่าตัวเลขอีกรอบ เช่น แสดงตำแหน่งบนกราฟหรือแสดงด้วยความหนาของเส้นอะไรงี้
  4. ถ้าข้อมูลตัวเลขมีประโยชน์จริง ถึงค่อยแสดงมาให้เห็น
  5. จอใหญ่ๆ
  6. เริ่มออกแบบด้วยสีโทนเดียว (monochromatic) ก่อน ใช้การจัดวางหรือขนาดมาช่วย พอเสร็จแล้วค่อยใสสีเพิ่มถ้าการใส่สีนั้นมันช่วยให้ใช้งานได้ดีขึ้น
  7. ออกแบบอยู่อย่าลืมถามผู้ใช้

Getting the user’s attention

เป็นเทคนิคการเรียกร้องความสนใจ เช่น error งี้ ต้องโวยวายเพื่อเรียกร้องความสนใจ

  1. ความเข้ม ต้องมีแค่ 2 ระดับ โดยเราจะกั๊กระดับที่สูงกว่าไว้ใช้ยามคับขันตอนอยากให้สนใจ
  2. การ Marking เช่นขีดเส้นใต้ เอากล่องมาครอบ ชี้ลูกศร บลาๆ
  3. ใช้ขนาด ซัก 4 ขนาด
  4. ใช้ font ช่วย ซัก 3 font
  5. Inverse สีซะ
  6. กระพริบ!! 2-4Hz
  7. สีในโปรแกรมใช้ซัก 4 สี ทีนี้จะโวยวายอะไรให้ใช้สีที่ 5 มันจะเด่นทันที
  8. เล่นเสียงที่โหดร้าย

แต่ระวังอย่าใช้ผิดๆเช่นกระพริบแบบโฆษณาในเว็บก็ไม่ไหว


Facilitating data entry

การใส่ข้อมูลเป็นต้นกำเนิดแห่งความหงุดหงิด

  1. Consistency (อีกแล้ว)
  2. Minimal input ยิ่งผู้ใช้ต้องทำอะไรมาก โอกาสพลาดยิ่งมากขึ้นๆ ถ้าตรงไหนต้องการข้อมูลเหมือนๆกัน อย่าให้ได้ใส่สองครั้ง ก๊อปไปให้ก็ดี แล้วค่อยแก้ก็ได้ถ้าอยากเปลี่ยนนิดๆ
  3. อย่าให้ผู้ใช้ได้จำ (อีกแล้ว)
  4. ใส่ยังไงออกอย่างงั้น (อีกแล้ว)
  5. เปลี่ยนรูปแบบเองได้ (อีกแล้ว) เช่นยอมให้คน Sort ตามที่สนใจได้โดยคลิกที่หัวตาราง อ้อ! ระวังเพราะข้อนี้จะขัดกับ Consistency

Principles

Guidelines นั้นจะแคบๆและเจาะจงแต่ Principles จะกว้างขวาง ใช้ได้มากมาย คงอยู่นาน แต่ ก็ต้องอาศัยการตีความให้กระจ่างกว่าเอาไปใช้กับสิ่งที่เราจะทำได้ ลองอ่านต่อดูจะรู้ว่าอารมณ์มันดูเป็นทางการกว่า Guidelines มาก

Determine users’ skill levels

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

  1. Novice & First-timer – ทั้งคุณปู่ที่จะส่งอีเมลให้หลานครั้งแรก และนักเล่นหุ้นมือฉมังแต่เพิ่งเคยซื้อหุ้นผ่านเน็ต ก็เป็นมือใหม่ที่อาจกลัวการเรียนรู้ เพราะงั้นเราต้องมีวิธีทำ มี dialog box มีศัพท์ไม่มาก action น้อยๆครั้ง และมี feedback บอกว่าทำสำเร็จหรือล้มเหลว
  2. Knowledgeable intermittent [h]users – บางคนก็มีความรู้ แต่นานๆทีมาใช้ครั้งหนึ่ง เราต้องจัดเรียง UI ดีๆเพื่อผ่อนคลายภาระด้านการจำของเขานะ (เน้น recognition มากกว่า recall ) แบบว่าเห็นแล้วทำได้ไม่ต้องนึกย้อน เช่นลืมเติมอะไร ขึ้นมาบอกด้วย
  3. Expert frequent users – เราต้องเอาคีย์ลัดให้เขา เอาวิธีซ่อน help ไปไกลๆให้เขา

มี 3 class แบบนี้ทำไงดี เราก็อาจทำ multi-layer ให้ผู้ใช้ได้เพิ่มระดับตนเองไปสู่สิ่งที่ซับซ้อนขึ้นได้ตามต้องการ ดูตัวอย่างมือถือ มือใหม่ก็จะโทรและรับได้ เมื่อเก่งขึ้นมาก็เข้าเมนูได้ เก่งขึ้นไปอีก เขาก็จะเม็มเบอร์ได้ หรือจะทำให้จัดเรียงเครื่องมือมากน้อยได้ตามชอบ (Word ทำได้) หรือปิด help ได้

Identify the tasks

ได้ข้อมูลผู้ใช้แล้วต่อไปต้องคิดว่า ผู้ใช้จะต้องทำอะไรบ้าง เวลาอยากใช้… บางคนก็ให้ทำได้ทุกอย่างซะเลยหวังว่าผู้ใช้จะเจอทางที่ดีๆ แต่ผู้ชนะกลับเป็นคนที่ limit functionality ลงเหลือนิดเดียวเพื่อการันตีความ simple (iPhone vs Android??)

งานใหญ่ๆเกิดจากการทำ action เล็กๆหลายๆอย่างรวมกัน action ที่เล็กสุดเราจะเรียก atomic action ทีนี้เรื่องยากคือตัว atomic action นี้จะเอาเล็กแค่ไหนดี เล็กไปกลายเป็นว่ากว่าจะเสร็จงานก็ลากเลือดแต่ถ้าใหญ่ไปกลายเป็นว่า ไม่ได้สิ่งที่ต้องการจริงๆซะที อะไรๆก็ต้องมีคำสั่งพิเศษไปหมดเสียเวลามาจำอีก

Task frequency ก็คืออะไรทำบ่อยๆ ขั้นตอนควรจะน้อย มีคีย์ลัด อันไหนทำไม่บ่อยก็ไว้ในเมนูลึกก็โอเค เช่น speed-dial บนมือถือ กดเลขเดียวโทรออกได้เลย

Choose an interaction style

ได้ขั้นตอนการทำงานแล้วมาเลือกวิธีการใช้กัน (ผสมได้)

Direct Manipulation

เห็นชัดๆ เรียนง่าย ลากลงถังขยะได้เลยงี้ มือใหม่ชอบ ถ้าทำดีๆ มือเก๋าก็ใช้ได้เร็วด้วย

Menu Selection

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

Form fill-in

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

Command language

ปลดปล่อยสิ่งที่อยากทำได้เต็มที่และรวดเร็ว แต่ Error สูง เรียนนาน Retention ต่ำ ข้อดีอีกอย่างคือสร้าง macro ง่าย

Natural language

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

The Eight Golden Rules of interface design

Golden เชียวนะ สั่งสมมากว่า 30 ปี

  1. Strive for consistency เหมือนเดิม
  2. Cater to universal usability เหมือนเดิม
  3. Offer informative feedback ตรงตัว
  4. Design dialog to yield closure อันนี้ก็คือ action ที่ต่อเนื่องกันนั้นมีจุดจบที่ชัดเจน เช่นซื้อของผ่านเน็ตพอเสร็จถึง checkout ก็จะพบหน้ายืนยันว่าซื้อเสร็จแล้ว
  5. Prevent error เช่นอันไหนใช้ไม่ได้ก็ทำเป็นสีเทาๆให้คลิกไม่ได้ หรือใส่รหัสไปรษณีย์ผิดก็ให้แก้ตรงนั้นไม่ใช่ลบออกให้พิมพ์ที่อยู่ใหม่ด้วย
  6. Permit easy reversal of actions ก็คือ undo ได้เยอะๆ
  7. Support internal locus of control [i]ผู้ใช้เก่งๆเชื่อว่าเขาเป็นคนควบคุม interface ได้ดั่งใจ พวกเขาไม่ชอบการเปลี่ยนแปลงสิ่งที่คุ้นเคยแล้ว
  8. Reduce short-term memory load ก็คืออย่าให้จำ เหมือนเดิม

Prevent errors

เอาข้อ 5 เมื่อกี้มาเขียนเพราะมันสำคัญ error message ที่ดีจะบอกว่าให้ทำอะไรไม่ใช่บอกปัญหาอย่างเดียว แต่มันก็เป็นเพียงยา เราจะไม่ให้มี error เลยได้มั้ย เช่นจัดหน้าให้ดี ปุ่ม yes no เรียงเหมือนเดิม หรือมีการช่วยให้การกระทำถูกต้องเช่น auto-complete หรือรถยนต์ไม่ให้เข้าเกียร์ถอยหลังถ้ากำลังซิ่งไปข้างหน้า เป็นต้น ถ้าอันไหนเป็น sequence กลัวผู้ใช้จะลืมอาจเอามารวมซะเช่นเปิดไฟเลี้ยวของรถ แค่ดันแกนเดียวก็เปิดทั้งไฟหน้าและหลัง หรือคลุมแถบใน word เพื่อทำตัวหนาหลายๆที่ในทีเดียว

อย่าลืม universal usability ถ้าปู่มาใช้ปุ่มเล็กๆ ก็ error บาน

Ensuring human control while increasing automation

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

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

เรื่อง automation ที่มาแรงอีกเรื่องคือจะมี agent ที่รู้ว่าเราชอบอะไรไม่ชอบอะไร คอยทำงานให้เราคงจะดีไม่น้อย (เหมือนมีเพื่อนเป็นคอม) แต่ที่ผ่านมาก็ล้มหมดเช่นแต่ก่อน MS เคยมีตัวคลิปหนีบกระดาษมาแนะนำแต่ไม่ช่วยอะไรเลยตายไปแล้ว รถพูดได้ก็ไม่ได้ดีขึ้นเท่าไหร่ บางทีมีหน้าโผล่มาด้วยจะมีไปทำไม หล่ออย่างเดียว ถ้าจะทำจริงให้ดูความล้มเหลวด้วยว่าที่ผ่านๆมาพลาดตรงไหน ใครล่ะจะรับผิดชอบถ้า agent ไปทำสิ่งต่างๆพังหมด ถ้า agent มีระบบ monitoring ให้ผู้ใช้ได้ตรวจสอบสถานะได้ว่าตอนนี้มันทำอะไรให้เราอยู่ ก็อาจจะดีขึ้น?

agent อีกแบบที่ไม่ต้องให้คอมแปลงร่างมาเป็นตัวเป็นตนก็ได้ก็คือ User modeling [j]ซึ่งจะให้ adaptive[k] interface เช่นถ้าเราทำงานไวๆๆ คอมก็จะรู้ว่าเราเก่ง ก็เลยโชว์เมนู advanced ขึ้นมาแบบนี้ หรือว่าลบ spam email ออกให้เลยก็ได้ แต่ก็มีปัญหาอีกเพราะ adaptive system อาจจะสร้างเซอร์ไพรซ์เช่นลบเมลสำคัญของเราแทน เราก็ต้องมานั่งดูอีกว่ามันลบอะไรไป ถ้าเปลี่ยนเป็นให้มันมาเตือนก่อนลบ ก็กวนเราอีก ทางทีดีก็คือต้องให้ user สามารถควบคุมความ adaptive เองได้ดีกว่าไม่ใช่ทำให้ซะหมด

อีกแบบของ user modeling คือ recommender system ไม่มี agent ไม่มี adaptive แต่ระบบจะไปค้นๆของต่างๆมาให้ เช่น กูเกิลเซิจก็มีแนะนำขึ้นมา ซื้อของในเว็บก็มีมาบอกว่าคนที่ซื้ออันนี้ไปเขาซื้ออันนี้ๆๆไปด้วยนะ

ทางตรงกันข้ามโดยสิ้นเชิงจาก agents และ user modeling คือสร้างระบบที่เข้าใจได้ง่าย คาดเดาง่ายไปเลย ไม่ต้องมีอะไรเพิ่ม เช่นพวก direct manipulation ผู้สร้างเชื่อว่าผู้ใช้จะฝึกฝนใช้จนช่ำชองและยอมรับกับการกระทำของตัวเอง เพราะงานวิจัยที่ผ่านมาก็มีว่าผู้ใช้จะชอบระบบที่เข้าใจได้มากกว่าระบบซับซ้อน เช่นคนขับเครื่องบินก็จะไม่อยากเปิด auto-pilot เพราะกลัวมันจะไม่ได้ดั่งใจ

อีกโมเดลที่จะแนะนำคือ Control panel model นึกถึงตอนไปตั้งค่าทีวีด้วยรีโมท เรากำลังไปตั้งค่าอัตโนมัติต่างๆ ให้เป็นอย่างที่เราต้องการ เราจะรู้สึกมีการควบคุมมากกว่า หรือการจัด scheduling ให้สแกนไวรัสในช่วงเวลาที่เราชอบได้ ไม่ใช่อยู่ๆดันมาสแกนเองไม่ถามเราเลย นี่ก็เป็น automation อีกอย่างที่น่าสนใจ

Theories

ในที่สุดก็มาถึงอย่างสุดท้ายแล้ว!!

ตัวอย่างของทฤษฎีแบ่งเป็นหมวดๆคือ

  1. Descriptive theories – ช่วยอธิบายศัพท์ต่างๆ ช่วยให้ออกแบบร่วมกันหลายๆคนได้มากขึ้น
  2. Explanatory theories – อธิบายลำดับเหตุการณ์ อาจบอกด้วยว่าลำดับนี้เกิดไรขึ้น
  3. Prescriptive[l] theories – ช่วยนักออกแบบตัดสินใจเรื่องต่างๆ
  4. Predictive theories – ทำให้เราสามารถเอาหลายๆดีไซน์มาเทียบกันในด้านต่างๆได้เป็นรูปธรรมเช่น execution time, error rate

(Descriptive และ Explanatory นั้นส่วนสำคัญคือสิ่งที่เรียกว่า Taxonomy[m] ซึ่งจะแตกอะไรที่ซับซ้อนออกมาเป็นส่วนๆ เดี๋ยวจะได้เห็นกัน)

หรืออาจแบ่งทฤษฎีตามทักษะที่ใช้ก็ได้ ตามสบาย

  1. Motor theories – เช่นชี้เม้าส์
  2. Perceptual theories – เช่นเวลาหาของบน desktop งี้
  3. Cognitive theories – เช่นพอจะจ่ายเงินผ่านเน็ตแล้วก็คิดได้ว่ามีขั้นยังไงมั่ง

ทฤษฎีใช้อธิบายหรือคาดเดาสิ่งต่างๆได้เช่นการที่ผู้ใช้จะหาของในหน้าจอจะทำไง จะมองไปทางไหนก่อน หรือทำนายเวลาในการเลื่อนเม้าส์หรือพิมพ์ได้

นักวิจารณ์ทฤษฎีก็ได้แขวะไว้สองอย่างว่า

  1. ทฤษฎีควรจะเน้นไปช่วยการวิจัยและการพัฒนา เช่นมีนักวิจัยมาดูเกมเทคนิก้างี้ก็รู้เลยว่าเนี่ยหน้าจอนี้ที่ผลมันออกมาดีขนาดนี้เพราะว่ามันมีคอนเซ็ปต์หรือทฤษฎีตรงกับข้อนี้ๆนี่นา และควรช่วยนักพัฒนาออกแบบอะไรที่ดีขึ้นได้
  2. ต้องนำ ไม่ใช่ตาม เพราะทฤษฎีส่วนมากที่เกิดขึ้นดันเอาของที่ประสบความสำเร็จแล้วอย่างไอโฟนมาอธิบาย จริงๆแล้วควรจะช่วยให้ทำอะไรใหม่ๆได้ต่อไปเรื่อยๆต่างหาก

ทิศทางในอนาคตของ ‘นักทฤษฎี’ คือการทำนายความพอใจส่วนบุคคลและผลต่ออารมณ์ของผู้ใช้! จะดีแค่ไหนที่จะมีทฤษฎีแบบนี้แล้วเราควบคุมอารมณ์ผู้ใช้ได้ตามต้องการ เอาไปทำเกมคงดีไม่น้อย (ที่ผ่านมาผู้พัฒนาจะใช้ความรู้สึกของตัวเองมาตัดสินก่อน จากนั้นก็จะทำ Market testing เอาไปให้กลุ่มเป้าหมายลองเล่นเยอะๆจนมั่นใจ)

มาดูทฤษฎีต่างๆกัน

Design-by-levels

เป็ร Descriptive theory ซึ่งหลักสำคัญของ Descriptive theory คือการแบ่ง concept เป็นเสี่ยงๆ อันนี้ก็เช่นกัน

  1. Conceptual Level – คิดถึง Mental model ของผู้ใช้ที่มาใช้ เช่นเกี่ยวกับการสร้างสรรค์ภาพ ก็จะมี mental model คือ เป็นโปรแกรมแก้ไข pixel หรือเป็นโปรแกรมเคลื่อนย้าย object ต่างๆไปมา
  2. Semantic Level – ความหมายที่สื่อออกมาจาก input ของผู้ใช้หรือ output ของจอ เช่นการที่วาดอะไรในโปรแกรมไปแล้วจะลบออก ก็เป็นความหมายของการ Undo หรือการใช้คำสั่งลบ
  3. Syntactic[n] Level – คือทำอย่างไรจะทำ Action ซึ่งสื่อ Semantic (ขั้นตอนข้างบน) ได้ เช่นจะลบภาพแบบเมื่อกี้ก็ต้องเลือกเครื่องมือยางลบก่อน จากนั้นก็ถูๆ
  4. Lexical Level – จะขึ้นกับอุปกรณ์ต่างๆกันไปเช่นต้องกดไปที่ปุ่ม Fn ก่อนหรือว่าต้องดับเบิลคลิกนี้ต้องทำภายใน 200 ms

(สังเกตว่าทั้ง 4 ข้อนั้นเป็นไปตามลำดับจากหยาบไปละเอียด ไม่ใช่ 4 ข้อมั่วๆ)

มาดูการใช้ทฤษฎี…

  1. การทำ Direct Manipulation นั้นให้ความสนใจที่ Conceptual Level ซึ่งใกล้เคียงกับ Task domain[o] มากๆเช่นโปรแกรมเซ็นเช็ค ผู้ใช้ก็จะมี Mental model เป็นการเซ็นเช็ค เพราะฉะนั้นก็โชว์ภาพเช็คแล้วมีช่องว่างให้เซ็นไปเลย จากนั้นผู้ใช้ก็ต้องเรียนรู้ Semantic ว่าทำอย่างไรจะได้ที่ต้องการ ซึ่งถ้าออบแบบดีๆเช่นทำรูปถังขยะมาโชว์ผู้ใช้ก็จะได้ Mental model ของการลบไฟล์ได้อย่างรวดเร็ว จากนั้นก็เรียนรู้ Syntax ของการคลิกลากไปลงถัง (จริงๆไม่ใช่เรียนหรอกเพราะมันใช้บ่อยจนไม่ต้องเรียนแล้ว)
  2. ถ้าเราแตกการกระทำจนละเอียดที่สุดได้ ถึงระดับ Lexical เช่นการขยายภาพต้องเลื่อนเม้าส์ไปคลิกเครื่องมือ ติ้กถูก แล้วลากสักระยะหนึ่งแล้วปล่อย ขั้นตอนพวกนี้สามารถ Predict เวลาที่จะใช้ได้ เพียงแค่เอาเวลาแต่ละขั้นมาบวกกันก็จะคาดเดาเวลาทั้งหมดที่จะใช้ในการกระทำได้ (วิธีคาดเดาแบบนี้นี้เรียกว่า GOMS[p]) แต่การใช้ GOMS ระวังด้วยเพราะจะแม่นยำเมื่อผู้ใช้เป็น Expert เท่านั้น ถ้าเป็นมือใหม่ ต้องคิดถึงความชำนาญ ความเครียดและอื่นๆของผู้ใช้มาร่วมด้วย

สังเกตดูว่า สองอันที่ผ่านมา ถ้าไม่มีทฤษฎี Design-by-levels ก็จะอธิบายไม่ได้ไงล่ะ

Stage-of-action models

อันนี้เป็น Explanatory theory ซึ่งวิธีเขียนขึ้นมานิยมจะอธิบายขั้นตอนการกระทำของผู้ใช้เป็นขั้นๆ Norman ก็เลยอธิบายไว้ว่าอะไรๆก็ต้องมี 7 ขั้นหมด (เป็น loop)

  1. Forming the goal
  2. Forming the intention
  3. Specifying the action
  4. Executing the action
  5. Perceiving the system state
  6. Interpreting the system state
  7. Evaluating the outcome

ก็มีคนเอาทฤษฎีพวกนี้ไปใช้เช่น Information-seeking ก็แบ่งเป็น 7 ขั้น ในเว็บ Amazon เวลาซื้อของก็แบ่งเป็น 4 ขั้น (ขั้นสุดท้ายก็ได้ดูผล.. eval the outcome) หรือเวลาจะเพิ่มหน้าใหม่ใน Wikipedia นี้ก็จะมี 6 ขั้นตอน (ขั้นแรกก็ต้องหาเรื่องที่สนใจ.. forming the goal) ซึ่งทั้งหลายแหล่นี้มันจะคล้ายๆกับ 7 ขั้นของ Norman

Consistency

บอกตั้งหลายรอบแล้วอันนี้ ประมาณว่าจะใช้คำว่า Insert แล้วก็อย่ามาใช้คำว่า Add เขาว่ากันว่า inconsistency ด้านตำแหน่งและสีจะลดความเร็วผู้ใช้ลง 5-10% แต่ด้านคำศัพท์ต่างๆจะลดตั้ง 20-25%

คันเร่งอยู่ทางขวาของเบรค ปุ้มทางซ้ายของมือถือคือ ok ขวาคือ ยกเลิก ปุ่มเลื่อนขึ้นลงต้องเรียงกันแนวตั้ง etc.

ถ้าเขียนเป็น document ไว้ก็ดีว่าที่เราออกแบบจะใช้ consistency อะไรบ้าง

Contextual theories

อ่านเอง บาย


Direct Manipulation and Virtual Environments

“หากเราบรรยายสิ่งที่มันเป็นอยู่ทั้งๆอย่างที่มันควรจะเป็นเลย… ใช่… ภาระด้านความคิดมันหายไปได้อย่างน่าประหลาด”

Introduction

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

เช่นการลากของลงถังขยะ เกมต่างๆ Virtual reality, Augmented reality, เว็บ Second Life และอื่นๆ

Examples of Direct Manipulation

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

Word Processor

เรียกได้ว่าเป็นจุดกำเนิดของ DM ก็ว่าได้ ตอนแรกๆจะพิมพ์งานเราต้องใช้ Command-line แถมยังเห็นผลลัพธ์แค่บรรทัดเดียว Full-page display editor ที่เราจะเห็นได้ทั้งหน้า เลื่อนเคอร์เซอร์ไปแก้ตรงไหนๆก็ได้ นั้นเป็นเพียงความฝัน มาถึงปัจจุบัน MS Word ทำให้เราได้เห็นเอกสารแบบ WYSIWYG[q] รู้เลยว่าเวลาพิมพ์ออกมาจะเป็นไง แล้วก็สามารถแก้เอกสารที่เห็นๆอยู่ได้โดยตรงเลย ของจริงก็ออกมาอย่างที่แก้เลย DM จริงๆ มีคนกล่าวไว้ว่า Word processor เป็นหนูทดลองแห่งวงการ HCI เช่นพวก Grammar check, WWW ก็ต่อยอดมาจากไอเดียของ word processor

VisiCalc Spreadsheet

ก็คือทวดของ Excel นั่นเอง เมื่อแก้ช่องโน้นแล้วผลก็จะอัพเดทตามทันที ผู้ใช้สามารถลองใส่ค่าตัวเลขเป็น What-If เพื่อดูผลที่ออกมาได้ในทันที

Office Automation

คือเซ็ตโปรแกรมสำหรับสำนักงานแบบ MS Office นั่นเอง เริ่มมาจาก Xerox Star -> Apple Lisa -> Macintosh ซึ่งมีจุดสำคัญที่การลดความซับซ้อนแต่ยังคงพลังไว้อยู่ มี Pull-down menu เพิ่มเข้ามาและสามารถลาก icon ไปมาได้แล้ว

Spatial[r] Data Management

เช่นมีภาพโลกทั้งใบอยู่เบื้องหน้า สามารถจับ joystick เพื่อซูมจนเห็นเรือที่แล่นอยู่ ซูมไปถึงหน้ากัปตันไปเลยก็ยังได้ หรือโปรแกรม ArcGIS[s] ที่แสดงข้อมูลเกี่ยวกับแผนที่ได้หลายชั้นตั้งแต่ว่าตรงไหนฝนตก หรือตรงไหนประชากรเยอะ หรือถนน และ Google Map/Earth ที่รวม database ต่างๆและภาพถ่ายดาวเทียมเข้าด้วยกันจนซูมไปถึงถนนได้

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

Video Games

สำหรับหลายๆคน เราจะเห็น DM ประสบความสำเร็จได้มากสุดก็ในเกมนี่้ล่ะ ทำไมเกม Pong ถึงออกแบบมาดีจนขนาดว่าดูคนอื่นเล่น 30 วิก็เล่นเป็นแล้ว (แต่ต้องฝึกมาก กว่าจะเก่ง) ทำไม Mario ถึงดึงดูดใจในขณะที่โปรแกรม Office automation สร้างความกังวล?

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

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

และอย่างที่บอกว่า ทำไม The Sims ถึงดึงดูดผู้หญิงมาเล่นเกมได้มากขึ้น? ศึกษาเกมมันก็ดีแต่ต้องมี limit บ้างเพราะเกมให้ความท้าทายด้วย random event ต่างๆแต่คนใช้ application ต้องการความแน่นอน (ใช้ word อยู่แล้วเจอศัตรูก็ไม่ไหว)

Computer-aided Design

หรือก็คือ CAD เช่น สร้างแปลนบ้าน หรือออกแบบวงจรไฟฟ้าโดยลากอุปกรณ์มาวางและทดสอบเช็คไฟฟ้าได้เลยรวมทั้งคิดราคาค่าอุปกรณ์ให้ด้วย นักออกแบบนิตยสารสามารถลากจัดวางหน้าหนังสือจนพอใจได้ ความสุขพวกนี้มาจาก DM

หรือแม้แต่ Computer-aided Manufacturing (CAM) ที่ใช้ดูสถานะโรงงาน ดูระดับความร้อนหรือความผิดปกติด้วยเส้นสีแดงว่ากำลังแย่ เพียงไม่กี่คลิกก็สามารถ reset หรือซ่อมแซมส่วนต่างๆได้ จุดสำคัญของการออกแบบคอ ความผิดพลาดเกิดปีละครั้งแบบนี้ ออกแบบยังไงให้พอมันเกิดขึ้นมาจริงๆก็แก้ปัญหาได้เลยไม่ใช่ว่าต้องมาเปิดคู่มือดูคำสั่งว่าต้องทำ อะไรบ้าง โรงงานระเบิดก่อนพอดี

The Continuing Evolution

ยุคนี้เป็นยุคที่อดคิดไม่ได้ว่าทำไมแต่ก่อนต้องสั่งคำสั่ง Command-line โง่ๆด้วย แต่ตอนนี้เรามาดูว่าจะพัฒนาเป็นอย่างไรต่อไปได้บ้าง

ตอนนี้จะจองตั๋วเครื่องบินก็เลือกที่นั่งได้จากภาพเครื่องบินเลย หรือระบบ Home control ที่เป็นรูปผังบ้านแล้วเราก็สามารถเปิดปิดเครื่องไฟฟ้าได้จากผังเลย แม้แต่ route เสียงจากเครื่องเสียงให้มาดังในห้องที่ต้องการได้โดยเพียงลากนิ้วเอารูปลำโพงมาใส่ห้องที่อยากได้ หรือการกรอวิดิโอโดยลากที่วัตถุในภาพได้เลย (relative flow dragging) หรือการนำ Dashboard มาใช้ต่อกรกับข้อมูลจำนวนมาก สามารถลากเรียงเพื่อค้นพบ trend ได้ หรือแม้แต่ Ubiquitous computing ที่คอมจะอยู่ทุกที่เช่นในตัวเราหรือตามทางเดิน การนำ AR มาใช้เช่นเห็นว่าท่อน้ำในบ้านอยู่ไหนบ้างผ่านทาง AR บนกำแพงบ้าน หรือแม้แต่วิธีซ่อมเครื่องปริ้นท์ก็ AR มาบอกระหว่างซ่อมได้ Microsoft Surface ที่วางกล้องลงแล้วภาพที่เก็บไว้ก็ออกมาให้ดูทันที Multi-touch กลายเป็นของประจำวันซึ่งใช้สองมือเหมือนการดำรงชีวิตปกติของคนเรามากกว่าการสลับไปมาระหว่างคีย์บอร์ดและเม้าส์

ไม่ว่าอนาคตจะไปทางไหนหลักของ DM คือ เรียนรู้ไว ควบคุมได้ มี Feedback ที่ rapid และยังให้ความเพลิดเพลินพึงพอใจอีกด้วย

Discussion of Direct Manipulation

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

Problems with Direct Manipulation

ที่ผ่านมามีแต่ข้อดีทีนี้มาดูอีกด้านหนึ่งบ้าง

  1. ไม่ใช่ว่าแสดงเป็นภาพๆแล้วจะเหนือกว่า text เช่นถ้าคนมองไม่ชัดมาใช้ก็แย่แล้ว
  2. มันต้องใช้พื้นที่มาก อาจต้องเลื่อนไปมา กว่าจะดูข้อมูลทั้งหมดได้ คนที่เชี่ยวๆคงอยากได้เป็นตารางมากกว่าภาพใหญ่ๆ
  3. ต้องเรียนรู้ความหมายของภาพที่นำมาเสนอ ทุกชาติจะเข้าใจตรงกันมั้ย วิธีแก้ปัญหาเช่นพอ hover เหนือ icon ก็มีความหมายบอก
  4. ผู้ใช้จะตีความผิดๆจากภาพหรือไม่ ต้องเลือกภาพให้ดีๆ
  5. บางอย่าง ใช้คีย์บอร์ดก็เหมาะสมอยู่แล้ว แปลงเป็น touch จะลำบากขึ้น
  6. ถ้าจอเล็กเช่นมือถือจะทำให้มือไปบังข้อมูล

แล้วเคยมองบ้างมั้ยว่า principle ของ DM นี่ดูไปดูมาก็ทำยากเหมือนกัน ยกมาสองข้อคือ Feedback ต่อเนื่อง (เร็วกว่า 100ms) และการย้อนการกระทำได้โดยง่าย (เช่น Undo) ลองคิดว่าถ้าเราจะทำระบบ Database ให้เป็น DM ซึ่งเวลา Query ก็กินไป 1 วิกว่าแล้ว แล้วแบบนี้ Feedback จะต่อเนื่องยังไงก็ต้องใช้เทคนิคเพิ่มเติม หรือการ Undo ยิ่งยาก อะไรที่จะ Undo ได้หมายความว่าเราต้องบันทึกทุกการกระทำของผู้ใช้ไว้เพื่อจะไว้ย้อนกลับ หรือถ้าจะทำเว็บให้เป็น DM เราก็ต้องมีเทคนิคเพิ่มเช่น Flash,Java,AJAX เป็นต้น

The three principles of direct manipulation

  1. เสนอสิ่งที่เราสนใจอย่างต่อเนื่อง เลือกตัวแทนนำเสนอมาอย่างเหมาะสม
  2. ใช้ Physical action แทน Syntax ที่ซับซ้อน
  3. ตอบสนองต่อเนื่องเห็นได้ทันที และสามารถ Reverse ได้

ผลของ DM ก็คือมือใหม่สามารถดูตัวอย่างแล้วทำตามได้เลย (คิดดูเขียนโปรแกรม ยืนดูตัวอย่างได้มั้ย) ใช้แล้วยังคงจำไว้ได้ Error message แทบไม่ได้ใช้ การที่เห็นผลอย่างต่อเนื่องทำให้สามารถปรับแก้ได้ทันทีหากไม่เป็นไปตามหวัง นั่นก็จะช่วยลดความเครียดด้วย และการที่เราเป็นคนออกคำสั่งทำให้เรารู้สึก In control และคาดเดาผลลัพธ์ได้ง่าย

ถ้าเอาตามศักยภาพมนุษย์คนเราเกิดมาย่อมมี Action กับ Visual skill มาก่อน Language อยู่แล้ว

ถ้าดูตามการพัฒนาของมนุษย์ที่มี 4 ขั้น : Sensorimotor (เกิด-2ปี) → Preoperational (2 – 7) → Concrete Operational (7 – 11) → Formal Operational (11~ ) ด้านการใช้ Action จะได้มาในช่วงอายุ 7 ถึง 11 ปีแต่กว่าจะใช้สัญลักษณ์เป็น ก็ตั้ง 11 ปีแล้ว ดังนั้น DM เหมาะกับเด็กต่ำกว่า 11 ปี มาก

Visual thinking and icons

คอมพิวเตอร์เดี๋ยวนี้มีความเป็น Visual มากขึ้นเรื่อยๆเช่นมีไอคอนมีหน้าต่าง แต่ก็ยังมีพวกสมองซีกซ้ายที่ชอบแบบ Textual มากกว่าอยู่ ปัญหาคือจะเลือกระหว่าง Visual กับ Textual ยังไงดี อย่างป้ายเลี้ยวโค้งเป็น Icon รูปลูกศรก็จะดีกว่า แต่ Textual บางอย่างเช่น “ONE WAY! DO NOT ENTER” จะดูสื่อความหมายได้ดีกว่า Icon ดังนั้นเวลาเลือกใช้ก็คิดดีๆ แต่บทนี้เป็น DM เพราะงั้นมาดูว่ามีหลักการใช้ Icon อย่างไรบ้าง

  1. รูปต้องคุ้นเคยและแตกต่างกัน และไม่กลืนกับฉากหลัง และระวังเรื่องไอคอน 3 มิติ ถึงจะเด่นแต่บางทีก็แยงตา
  2. ถ้า select ไอคอนไหนให้มันดูออกว่าเลือกอยู่
  3. ออกแบบ Animation ตอนลากไอคอน เช่นจะเป็นลากภาพไอคอนออกมาเลยหรือมีแค่ outline ดี และออกแบบ Combination การใช้ไอคอนร่วมกันเช่น ลากไอคอนแฟ้มไปใส่ปริ้นเตอร์แล้วปริ้นได้

Direct-manipulation Programming

ไม่ใช่แค่ทำหน้าที่ให้สำเร็จอย่างเดียว เราสามารถโปรแกรมมิ่งด้วย DM ได้ เช่นกล้องถ่ายหนังที่ดีๆ อาจจะสามารถโปรแกรมการ pan zoom แล้วสั่งให้ทำแบบเดิมซ้ำๆได้ หรือตำแหน่งเบาะรถหรือมุมหน้าต่างอาจจะโปรแกรมไว้เป็นคนๆไป พอใครมาขับแล้วก็ปรับเอง แม้แต่โปรแกรมเช่น Photoshop ก็สร้าง Action ที่จะบันทึกสิ่งที่เราทำแล้วสั่ง Run action กี่ครั้งก็ได้

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

3D Interfaces

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

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

เช่นพวก CAD หรือผ่าตัด 3 มิติ ความสำเร็จมันมาจากการทำให้ Interface เหนือกว่าความจริง ไม่ใช่เลียนแบบความจริง เช่นแปะ label ลอยอยู่ตรงไหนก็ได้ หรือ ลองมองแบบ X-ray ดูได้ทันที

สามมิติที่กากลงก็่เช่น หน้าต่างการบิน แสดงเป็น Perspective จะยิ่งงงกว่าแสดงภาพ Top-view หรือห้องสมุดดิจิตอลที่จะโชว์ภาพชั้นหนังสือเพื่อให้ Search ยากขึ้นทำไมไม่รู้ หรือ File directory เป็น tree สามมิติเพื่อให้ดูยากขึ้นทำไม หรือว่า Bar chart ที่กลายเป็นสามมิติลึกเข้าไปจนเทียบไม่ออกว่า Bar ไหนสูงกว่า

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

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

Teleoperation

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

  1. Time delay ทั้ง Transmission delay เวลาในการส่งคำสั่งผ่าน Network และ Operation delay เวลาที่จะใช้ทำคำสั่งนั้นจนสำเร็จ
  2. Incomplete Feedback อุปกรณ์ DM ปกติไม่ได้ออกแบบมาให้รายงานตำแหน่งเป๊ะๆ เพราะมันไม่ได้อยู่ไกล ดูแค่ตาเปล่าก็รู้ แต่ถ้า Tele คงต้องแก้หน่อย
  3. สิ่งรบกวนที่ไม่คาดคิดเช่นพยาบาลวางตำแหน่งฟิลม์เบี้ยวก็จะทำให้ตำแหน่งที่รายงานมาเบี้ยว หรือมีอะไรพัง แต่ตัวหมอเองยังไม่รู้เลยว่าพังเพราะไม่มีอะไรส่งมาบอก

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

Virtual and Augmented Reality

แน่นอนว่า VR ขับเครื่องบินถูกกว่าสร้างเครื่องบินจริง VR จะเปลี่ยนความรู้สึก Looking at ไปเป็น Being in แทนที่สถาปัตจะโมเดลตึกสามมิติ ทีนี้สามารถเข้าไปเดินได้โดยเดินบนสายพาน แล้วภาพก็จะดำเนินไป สามารถตกบันไดได้ หรือใส่หมวก VR เพื่อ block ภาพภายนอกไปหมดเลยก็ได้ แต่นั่นก็เป็นแค่ความคิดด้านสถาปัตย์ที่ว่าปกติเราชินกับการอยู่ในบ้าน Being in จึงเป็นสิ่งที่เหมาะสม แต่บางอย่าง Looking at มันก็ดีอยู่แล้ว เช่นโรงหนังที่ immersive ก็ไม่ได้สนุกเพราะคนดูส่วนมากอยากสนุกกับการที่จะเป็นผู้มองเหตุการณ์ในที่ๆปลอดภัยมากกว่าไปเผชิญจริง หรือหมอผ่าตัดก็อยากจะ Looking at ดูภาพภาคตัดขวางของหัวใจผู้ป่วยหรืออื่นๆมากกว่าที่อยากจะเข้าไปท่องเที่ยวในตัวผู้ป่วย

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

AR ก็เจ๋งไม่แพ้กันเช่นเราจะได้เห็นกำแพงบ้านของเรา และเห็นท่อน้ำหรือสายไฟฟ้าข้างในได้เลย หรือดูคนป่วยเป็นๆแล้วเห็นภาพ X-Ray ซ้อน หรือแม้แต่เรากระทำอะไรบางอย่างกับวัตถุในโลกจริงแล้วทำให้ภาพ AR เปลี่ยนไปก็ได้ ซึ่งถือเป็น alternative ของ VR เพราะ immersive เกินไปมักจะทำให้เกิดความปวดหัวคลื่นไส้กับการที่ทุกอย่างเป็น Simulation ได้แล้วก็ไม่ต้องใส่ที่ครอบหัวตลอดด้วย ซึ่งทั้งหมดนี้มีสิ่งที่ต้องคิดดังนี้

  1. จอ แน่นอนต้องมุมมองกว้าง ตอบสนองไวๆสไตล์ DM มีเทคนิคคือตอนภาพขยับอยู่นั้น แสดงภาพ Low res ได้ขอแค่รูปร่างคร่าวๆ แต่ถ้าหยุดมองนิ่งๆเมื่อไหร่ต้องเป็นภาพ High res เพื่อความ Being in
  2. จับทิศหัว ก็ที่ใส่หัว ดีๆหน่อยก็ฝังในแว่นได้ไม่หนักหัว
  3. จับทิศมือ เช่น Dataglove เขาบอกว่าบางทีสิ่งที่ต้องการมีแค่ 2 นิ้วก็รู้หมดแล้ว หรือไม่ก็แค่ 2 ข้อนิ้วเท่านั้นเอง เขาว่ากันว่ามีเซ็นเซอร์สำหรับจับที่อื่นๆด้วยเช่นเข่า ขา ใช้ได้ดีในด้าน VR กีฬา แล้วก็มีคนคิดเซ็นเซอร์ไว้จับไอ้นั่นซึ่งสามารถให้ feedback ที่สมจริง[t]
  4. Hand held manipulative เช่นมีบ้านจำลองเล็กๆแต่พอถอดหลังคาแล้วของจริงก็จะเกิดอะไรบางอย่างขึ้น หรือคล้ายๆตุ๊กตาที่ขยับแล้วส่งผลในที่อื่น
  5. Force feedback และ haptics [u]เช่นจำลองขับเครื่องบินเวลาชนอะไรหรืออากาศแปรปรวนก็ควรมีการสั่น หรือผ่าตัดแล้วชนอะไรหมอต้องรู้ แม้แต่ Remote handshaking ก็มีคนทำแต่คงไม่รู้สึกดีเท่าจับมือจริงๆมั้ง
  6. เสียง อันนี้รู้กัน
  7. รสสัมผัสอื่นเช่นกลิ่นหรืออากาศ -.-
  8. รองรับการทำงานร่วมกันหรือแม้แต่แข่งกัน

Menu Selection, Form Fill-In, and Dialog Boxes

Introduction

หาก DM ไม่ได้ เมนูเป็นทางเลือกที่ดีเพราะมีลำดับดี เลือกได้จากตัวเลือกมากกว่าการจำ

Task-Related Menu Organization

จุดหลักของเมนูก็คือต้องจัดเป็นหมวดให้ตรงกับ task ของผู้ใช้ เช่นหนังสือเป็นบท หรือเมนูอาหารเป็นตามประเภทอาหาร แต่ต้องเลือกคำที่เอามาเป็นชื่อหมวดให้ชัดๆจนตัดสินใจได้ ผลวิจัยบอกว่าลด Error ได้ครึ่งนึง และอีกวิจัยบอกว่าเลือกไอ้ที่มีความหมายยิ่งดีกว่าการจัดตามอักษรเฉยๆอีก

และในมือถือที่เน้นความใช้ง่ายและเรียนง่ายเราจะเน้นไปที่ frequency of use เช่นเพิ่มเบอร์ใหม่ก็ให้ทำง่ายกว่าลบเบอร์ เมนูแบ่งเป็นกลุ่มตามหัวข้อต่อไปนี้…

Single Menu

คือให้เลือกในคราวเดียว (แต่อาจหลายตัวเลือกได้)

  1. Binary Menu เช่นพวก Yes/No ชาย/หญิง
  1. เมนูพวกนี้อาจนำมา reuse บ่อย ดังนั้นทำ shortcut กับ default choice ไว้เลย
  1. Multiple binary choice
  1. เลือกใช้ Radio หรือ Check box ข้อดีคือผู้ใช้กวาดสายตาดูข้อมูลทั้งหมดได้ทันที
  2. เลือกใช้ Ticker คือเมนูที่มาเองไปเองไม่ต้อง scroll แต่บางที่ต้องรอมันมา หรือมันหายไปไว ก็น่ารำคาญ
  1. Pull down คือแถบข้างบน ใช้เมาส์คลิกหรือลูกศรขึ้นลงได้ อันไหนกดไม่ได้ต้องทำเทาๆไม่ใช่เอาออกไปเลย เพื่อ Positional constancy (คนจะจำเมนูตามตำแหน่ง ถ้ามันเลื่อนไปมาคงไม่ดี) และควรมี Shortcut บอกไว้ข้างๆ เผื่อว่าอยากใช้เมนูนี้บ่อยๆจะได้ใช้ Shortcut แทน
  2. Toolbars และปุ่มไอคอนต่างๆส่วนมากจะใช้เพื่อ apply อะไรบางอย่างกับของที่แสดงอยู่ ต้องเอาออกหรือปรับปุ่มได้เพราะความรกมาจาก toolbar
  3. Pop-up menu จะเด่นตรงที่ว่าโผล่มาที่ไหนก็ได้ตามสั่ง ซึ่งเหมาะกับจอใหญ่ๆเป็นอย่างยิ่งไม่ต้องกวาดตาไปถึงเมนูที่ขอบจอ หากตัวเลือกน้อยๆแล้วอยากเท่ก็ทำเป็น pie menu ที่จะ pop เป็นวงกลมแบบ The sims ได้ ซึ่งมีข้อดีคือถ้าใช้เก่งๆแล้วไม่ต้องมองด้วยซ้ำ ฟาดมือไปตามตำแหน่งที่จำได้ได้ทันที อีกแบบเรียก Flow menu ซึ่งมีช่องกรอกข้อมูลใน pop-up
  4. Ribbon ก็คือแถบใหญ่ๆบน office รุ่นใหม่ ใหญ่และช่วยมือใหม่ แต่ลดขนาดจอ พวกเทพๆอาจไม่ชอบ

Menu for long lists

ถ้าจำนวน item ซัก 30 แล้วจะทำแบบวิธีที่ผ่านมาไม่เหมาะเท่าไหร่ เราอาจทำ Tree แต่บางทีต้องการให้มันมีรวมๆอยู่ที่เดียวเช่นเลือกรัฐ 50 ตัวเลือกเป็น Tree ไม่ดีมั้ง ดังนั้นมาดูพวกนี้

  1. Scrolling menu แสดงส่วนแรกๆและเลื่อนมาดูต่อได้ กดอักขระเพื่อ search ได้
  2. Combo box เห็นจะๆว่ามีช่องให้พิมพ์ได้ด้วย
  3. Fisheye ซึ่งเห็นหมดเลย! แต่ไอ้ที่อยู่ใกล้เคอร์เซอร์ถึงจะใหญ่ ซึ่งเหมาะกับจำนวนตัวเลือกที่ไม่มากเกินไปพอที่จะดูอันที่ยังไม่ขยายรู้เรื่องบ้าง ดังมาจาก Apple ด้านความเร็วเหนือกว่า Scrolling menu แต่ยังแพ้เมนูแบบตามลำดับชั้น (ยังไม่ถึง)
  4. Slider เป็นตัวเลือกฮิตถ้าต้องเลือกตัวเลข (เป็นช่วง) ส่วน Alpha[v]slider อาจเลือกชื่อต่างๆได้ด้วยโดยจะมีตัวอักษรบอกข้างใต้ว่าตำแหน่งนี้มันประมาณตัวไหน จุดสุดยอดคือ Feedback ต่อเนื่อง รูดๆแล้วเปรียบเทียบผลลัพธ์ได้อย่างเจ๋ง
  5. Two-dimensional menus เช่นมี tab ให้เลือกหมวดก่อนค่อยเลือกของข้างใน

Embedded menus and hotlinks

ที่ผ่านมาเรียกได้ว่าเป็น explicit menu คือเห็นจะๆไม่มีข้อมูลภายนอกเลย แต่ embedded คือเมนูอาจซ่อนอยู่ในภาพหรือ text ได้ ทำให้สามารถซ่อนเมนูไว้ในเนื้อหาได้โดยไม่ต้องมีเมนูจริงๆให้กินที่ เช่นเลือกประเทศโดยจิ้มที่แผนที่

Combinations of Multiple Menus

Linear menu sequence & simultaneous menus

เช่นสั่งพิซซ่าก็เป็น sequence ตั้งแต่เลือกแป้งเลือกหน้า หรือพวก wizard install ต่างๆ ส่วน simul ก็คือมีเมนูมากมายพร้อมกันและจะใส่อันไหนก่อนก็ได้ เหมาะกับ Expert

Tree-structured menus

การจัด Tree นั้นทำให้ของมากมายเหลือนิดเดียวเช่นถ้าแต่ละขั้นมี 30 ชนิดให้เลือก และมี 4 ขั้นก็มี Item ได้ตั้ง 810000 อันทีเดียว ซึ่งเป็นหลักของ WWW ที่สำคัญคือตั้งชื่อ group ให้ดี

  1. Expanding menu คือเลือกไปแล้ว อันเก่ายังเห็นอยู่ในขณะที่ให้เลือกอันต่อไป
  1. เหมาะกับ 2-3 Level เท่านั้นไม่งั้นงง
  2. อย่าทำให้ต้อง scroll มากหรือ indent จนงง เมื่อมันเริ่มกระจายออกมาเยอะๆ
  1. Sequential menu ก็เห็นแค่หมวดที่เลือกอยู่

การปะทะกันของ depth และ breadth ของ tree แน่นอนถ้าแต่ละชั้นกว้าง depth ก็น้อยลง แต่จะเอาอะไรดี เขาวิจัยมาว่าถ้าชั้นไปถึงชั้น 4-5 แล้วผู้ใช้จะเริ่มหลงทาง ดังนั้นเราควรให้ depth น้อยๆดีกว่า (แม้ว่าการจัดตามหมวดมากๆจะสำคัญก็ตาม)

Menu maps

เพื่อกันการหลงทาง มี map บอกเมนูโดยรวมก็ดีเช่น sitemap ตามเว็บ

Acyclic and cyclic menu networks

networkต่างจาก tree ที่ว่า choice หนึ่ง อาจเข้ามาได้จากทางอื่นไม่ใช่ว่าต้องไปเริ่มใหม่แต่ต้น นี่มันแก่นของ WWW เลยนี่หว่า ผู้ใช้อาจหลงทางได้มากขึ้น ทำไงก็ได้ให้ผู้ใช้ยังรู้สึกอยู่ถึงคำว่า Level ว่าตอนนี้เขาอยู่ลึกแค่ไหน (แต่คงทำให้รู้สึกได้ยากกว่า tree)

Content Organization

นอกจากจะใช้เมนูแล้วเราควรจัดหมวดให้ดีเพื่อให้ใช้ง่ายขึ้นไปอีก

Task-related grouping in tree structures

หมวดอาจซ้อนกันจนตัดสินใจยากว่าเอาอะไรไว้ไหน เพราะงั้นเลยมีหลักว่า

  1. กลุ่มตามสิ่งที่คล้ายกันตาม logic เช่น ประเทศ → รัฐ → เมือง
  2. ครอบคลุมทุกช่วง เช่น อายุ 0-9, 10-19, >19
  3. ไม่ซ้อนกัน เช่นชื่อหมวด Entertainment กับ Events แบบนี้ใช้ไม่ได้
  4. ใช้คำที่แตกต่างจริงๆ เช่น Day กับ Night ไม่เอา ต้อง AM PM

ดีสุดคือฟังผู้ใช้ว่าเขาต้องการอะไร

Item presentation sequence

จัดตามอะไรดี? เวลา เลข ลักษณะ ตัวอักษร กลุ่ม ใช่บ่อย สำคัญ ?

ที่พิมพ์เพราะอ่านอย่างเดียวแล้วง่วง ตอนนี้ไม่ง่วงแล้วหยุดพิมพ์ก่อน 55

บทนี้ก็ตัดจบลงแต่เพียงเท่านี้เพราะสอบเสร็จไปแล้ว อิอิออิ

Command and Natural Language

“สอบเสร็จแล้ว บาย”


Interaction Devices

“สอบเสร็จแล้ว บาย”


Collaboration and Social Media Participation

“สามคนช่วยกัน ได้งานเท่าทำเดี่ยวๆตั้งหกคน”

Introduction

มนุษย์ต้องการ Connection สมัยนี้มีตัวเลือกมากมายที่จะ Collab กัน ทั้งสร้างโอกาสธุรกิจกัน หรือเพื่อรอยยิ้มกับเพื่อนๆที่อยู่คนละฟากโลก เป็นกำลังหลักของเราที่จะทำให้คอมพิวเตอร์นั้นรู้สึกด้าน “บวก” มากขึ้นสำหรับคนทั่วๆไป

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

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

สำหรับนักออกแบบ (เรา) ต้องคิดหัวแตกในด้านการสื่อสารระหว่างคนใช้ ด้านการป้องกันการรบกวน ด้าน Privacy ด้านการรองรับคนเยอะๆ แต่อย่าเสียใจไป เพราะอะไรก็ตามที่ Collab กันได้ จะสร้าง “พลังในการอยากใช้คอม” กับผู้ใช้ ซึ่งก็เป็นหนึ่งในเป้าหมายของเราไม่ใช่เหรอ ดังนั้นมาตั้งใจเรียนเรื่องนี้กัน

Goals of Collaboration and Participation

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

  1. Focused Partnership แค่สองสามคนร่วมกันทำอะไรบางอย่างเช่นช่วยกันซ่อมคอมหรือถกเถียงอาการคนไข้ อันนี้ใช้ E-mail / Chat / โทรศัพท์ ก็ดี
  2. Lecture เริ่มและจบพร้อมกันสำหรับทุกคน ดังนั้นระบบที่ขาดไม่ได้คือ Replay และกล่องถามคำถาม
  3. Meeting and decision support ทุกคนก็นั่งอยู่ห้องเดียวกันนั้นแหละแต่ต่อหน้าทุกคนมีคอมอยู่ ทุกคนสามารถคอมเม้นด้วยความเป็น Annonymous ได้ (สร้างความกล้าสำหรับคนไม่ยกมือ) หรือแม้แต่การ Vote ก็ทำได้ง่ายในระบบนี้
  4. E-Commerce อันนี้ต้องมีที่ให้ถามราคา มี Help สด 24 ชม คอยตอบคำถาม
  5. Collaboratories[w]แต่ละคนสนใจเรื่องเดียวกันแต่แย่งกันใช้ Resource (แพงๆ) เช่นกล้องจุลทรรศน์
  6. Telepresence ประชุมทางไกลแต่รู้สึกเหมือนใกล้กัน มี Immersive 3D[x] สมจริงรอบตัวไปเลยดีมั้ย (จากบท DM )

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

ทำไมทำไม อีเมลมีแต่อักษรคนใช้เพียบ แต่ประชุมวิดิโอใช้แต่ในบริษัท? ทำไมโทรศัพท์มือถือใช้เพียบ แต่พวก VR[y] กลายเป็นแค่โปรเจคจบ? บางทีเป็นแค่สังคมนั้นเองที่ไม่ยอมรับการเปลี่ยนแปลงเป็นสิ่งใหม่ๆ นักออกแบบขั้นเทพจะต้องทะลวงเข้าไปในจิตใจของสังคมให้เขายอมรับได้

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

ประเด็น “Death of distance” กลับมาอีกครั้ง คนที่อยู่ด้วยกันสามารถหยิบ ชี้ พลิกแผนที่ สามารถจ้องตากัน สร้างความเชื่อใจด้วยภาษากายและ Eye-contact ยิ่งการที่ต้องเดินทางไกลกว่าจะได้ประชุมกัน จะเป็นการส่งเสริมให้ออกความคิดเห็นที่ดียิ่งขึ้น (กุอุตส่าขับรถมาแล้วตั้งไกล ตั้งใจประชุมหน่อยแล้วกัน) อันนี้ข้อดีของแบบเก่าๆที่เราต้องนำมาคิด

หัวข้อต่อๆไปเราจะแบ่งการ Collab ออกเป็น matrix ของ เวลา และ พื้นที่ดังนี้ (บางนักออกแบบเอาสองอันมารวมกันก็ได้นะ เช่น FB ก็มีทั้ง Chat และ Post)

Same time

Different time

Same place

Face-to-face เจอกันจังๆ

งานต่อเนื่องในห้องเดียวกัน

Different place

พวกประชุมทางไกล

พวกอีเมล บอร์ด อื่นๆ

Asynchronous Distributed Interfaces : Different Place, Different Time

เช่นอีเมล ว้าว มีเก็บเมลเก่าๆไว้ได้ ก๊อปแปะก็ง่าย แต่ว่าขาดผู้นำ อาจจะมั่วได้ง่าย คนมาตามทีหลังเห็นเมลเป็นล้านก็จะไม่อยากตาม

E-mail

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

Listservers and Yahoo!/Google groups (Webboard)

ดูทีละอย่าง เพราะ E-mail นั้นขาดความเป็น “กลุ่ม” จึงเกิด Listserver ขึ้นมา ให้หลายๆคนไปสมัครไว้แล้วเดี๋ยวเมลก็จะเทๆเข้ามาเอง ซึ่งสามารถค้นหาเลือกดูได้ แต่ความยากอยู่ที่ว่าจะมาดูว่าเมลไหนเกี่ยวกับเมลไหนเวลามันเข้ามามากๆ (โดยเฉพาะถ้าปนกับเมลปกติแล้วก็จะ WTF ทันที)

อีกอย่างนึงก็คือพวก Board นั้นเอง มีกระทู้ขึ้นมา เข้าไปข้างในเห็นคำตอบเรียงๆอยู่ และเราสามารถไปตอบได้ อันนี้จะเห็นว่าดีกว่า E-mail ตรงที่เราเห็นได้ทันทีว่ามีคำตอบอะไรบ้างแล้วเรียงให้เราดู ไม่ต้องมาเปิดหาเมลที่เกียวข้อง ทั้งยังสามารถค้นหากระทู้เก่า หรือสามารถแปะลิ้งค์ Homepage เราไว้ที่ลายเซ็น (เพื่อให้รู้สึกว่าเราเป็นคนจริงๆ มากขึ้น) หรือใส่ :) ระหว่างคุยเพื่อลดความเครียด

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

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

Blog and wikis

รู้กันว่าทั้งสองเป็นยังไง บางบริษัทอาจจ่ายเงินให้คน Blog เพื่อโฆษณาให้ ส่วน Wiki ก็ต้องกู้คืนได้กันเกรียนมาแก้ แต่ก่อนใครๆก็ฮิตพูดว่าอย่าไปเชื่อ Wiki มาก แต่ตอนนี้มันเปลี่ยนไปแล้วเพราะส่วนมากก็ถูกต้องจริงๆ ใช้ง่ายสำหรับพ่อแม่ปู่ย่า และยังใช้ดีสำหรับ Expert ที่จะร่วมกันแก้และเขียน Wiki ถ้าคุณจะทำอะไรสไตล์ Wiki ให้ระลึกไว้ 3 อย่างคือ Contribute ง่าย, แก้อะไรเป็นส่วนเล็กๆได้ และค่าใช้จ่ายในการรวมบทความและรักษาคุณภาพต้องต่ำ เพราะเกรียนเยอะมากถ้าจ้างคนดูแลแพงก็คงไม่ดี

สำหรับศัพท์ Microblogging นั้นก็คือ Twitter นั่นเอง

Online and networked communities

ไม่น่าสนใจ ข้าม

Synchronous Distributed Interfaces: Different Place, Same Time

Chat , instant messaging, and texting

Chat room นั้นเปิดกว้าง คนมาคุยสวมบทบาทเป็นชื่อใหม่ได้ แต่ก็มีพวก Flamer คอยพิมพ์ด่าขวางโลกเรื่อยๆ

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

Texting ก็คือ SMS เอาไว้ทักหรือเตือนสั้นๆได้ดี หรือคอนเฟิร์มสิ่งต่างๆ

Audio- and videoconferencing

ปัญหาเดิมๆคือเน็ตไม่แรงพอ และสังเกตเห็นท่าทางหรือการสบตาต่างๆได้ยากกว่า จะทำได้ต้องนัดกันมาก่อน เพราะถ้าเป็นแบบเปิดวิดิโอไว้ตลอดเวลาแล้วคุยกันเมื่อไหร่ก็ได้แบบ IM คนก็จะบ่นว่าละเมิดสิทธิส่วนบุคคลอีก แต่ก็ทำให้พ่อแม่ได้เห็นหน้าลูกที่ไปฝึกงานต่างประเทศนะ[aa]

Face-to-Face Interfaces: Same Place, Same Time

อันนี้อยู่ที่เดียวกันแท้ๆ แต่ก็ต้องมีอะไรไว้เชื่อมต่อกันซักหน่อย

Electronic meeting rooms,control rooms, and public space

E-meeting room ก็เช่นที่เราเอาสไลด์ ppt มาเสนอกัน สะดวกเพราะคนร่วมประชุมส่วนมากมีข้อมูลที่อยากเสนออยู่ในคอมหรือเน็ต แต่อย่าลืมว่าคอมเป็นตัวช่วยส่งสารให้ผู้ฟังเท่านั้น ถ้าใช้ไม่ดีการประชุมที่ควรจะมีชีวิตชีวาอาจกลายเป็นการนั่งฟังสไลด์ที่น่าเบื่อในห้องมืดๆแทน เราต้องรักษาเสน่ห์ของการเจอกันแบบ Face-to-face ไว้ด้วย (ตัวอย่างเช่น อ ที่สอนโดยอ่านตามสไลด์หมดเลย vs อ ชัยพร) หรือจะมีระบบ shared control ที่จะทำให้ผู้ฟังแอคทีฟขึ้น คอยเสนอแนะสิ่งต่างๆระหว่างการประชุม สิ่งที่เสนอเอามาจัดกลุ่มเป็นพวกๆแล้ววาดกราฟออกมา พร้อมปริ้นให้เก็บไปดูที่บ้านก็ทำได้

Control room ก็เช่นห้องบัญชาการในกันดั้มที่จะมีจอใหญ่ๆเท่ากำแพง ถือว่าเป็น Public space เพราะทำให้ทุกๆคนเห็นจอเดียวกันและร่วมกันฟันฝ่าอุปสรรคเพื่อเอาชนะหุ่นข้าศึกไปได้

Electronic classrooms

ก็งั้นๆแหละคิดดูเองแล้วกัน จริงๆแค่เราแบกคอมมาเรียนและมีสไลด์สอนก็ E ไปบ้างแล้ว ครูแก่ๆก็ยังไม่ยอมรับเท่าไหร่ จะเขียนกระดานอย่างเดียว

แล้วอีกหัวข้อนึงใน matrix หายไปไหนก็ไม่รู้ อิ


Quality of Service

“ความสุขสุดยอดของลูกผู้ชายนั้นก็คือ การตั่งมั่นว่าจะไม่เร่งรีบ”

Introduction

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

เหตุผลที่ต้องคิดเรื่อง QoS ก็เพราะว่ามนุษย์ทุกคนเห็นว่าเวลามีคุณค่า ถ้าอะไร delay นานๆก็จะปวดหัวหงุดหงิดและทำให้ทำงาน error มากขึ้น แต่อย่าลืมถ้าจะเน้น QoS แบบเร็วฉับไวแต่งานออกมาพลาดเพียบก็ไม่ดี ต้อง balance ดีๆด้วย

นักออกแบบอย่างเราอาจเพิ่ม QoS ด้วยการออกแบบเว็บให้โหลดน้อยๆลง หรือให้เลือกได้ว่าอยากดูภาพใหญ่หรือเล็ก หรือจะ SQL อะไรก็เอาทีละน้อยๆ จริงๆแล้ว QoS คลุมถึงเรื่องอื่นอย่าง โปรแกรมบึ้ม,คนเจาะระบบ ฯลฯ ด้วย แต่เราจะพูดถึง Response time ก่อนเพราะการที่ต้องรอนี้เจอกันทุกวัน

Model of Response-Time Impacts

ทฤษฎีจ๋ากำลังจะมาแล้ว นิยามกันก่อน

Response Time – เวลาจากที่คนใช้กดปุ่มไปแล้ว ถึงจุดที่เห็นว่าคอมตอบสนองแล้ว

User Think Time – เวลาจากที่คอมตอบมาตะกี้ จนถึงเวลาที่คนใช้กดปุ่มต่อไป

คิดตื้นๆ : สั่งการ → รอให้คอมตอบสนอง → รอผลลัพธ์ออกมา → คิดๆ แล้วสั่งการอีก

แต่จริงๆแล้วระหว่างคนพิมพ์หรือคลิกก็คิดไปด้วย ฯลฯ เพราะงั้นเลยวัดยากกว่าที่คิด ด้านโปรแกรมก็ไม่ใช่ว่าจะวัดง่ายเพราะอย่างลากไฟล์ใส่เครื่องปริ้น (DM) เห็นว่ามันเฉยๆแล้วนึกว่าคอมตอบเสร็จแล้ว ผ่านไป 2 วิถึงขึ้นมาว่าเครืองปิดอยู่ ( delay > 160ms สำหรับการลากไฟล์ ถือว่ารับไม่ได้) เพราะงั้นการที่คนๆนึงจะมาบอกว่า Response Time เท่าไหร่นี้มันยากพอสมควรเลย พวกเล่นเน็ตก็ขึ้นกับความเร็วเน็ตที่ซื้อด้วย โทรศัพท์ต่างประเทศก็ต้องเดินหาคลื่นนานกว่าจะเจอทำให้หงุดหงิด

อ่านอะไรจากจอนั้นยากกว่าหนังสือเพราะ Response Time นี่แหละ พวกเว็บควรให้โหลด Text ก่อนแล้วเว้นที่ให้ภาพโหลดทีหลังเพราะคนจะชอบแสกนดูทั้งหน้าคร่าวๆก่อน

Customer Demand เป็นจุดสำคัญ คอมเปิดช้าๆได้ไม่เป็นไร แต่ทำไมมือถือกับเกมต้องเปิดภายในพริบตา

ทฤษฎี Short-term Memory อันนึงกล่าวว่า คนเราจำอะไรได้ประมาณ 7 อย่างและเก็บไว้ได้ประมาณ 15-30 วิ ถ้าจำได้มากกว่า/นานกว่านั้นแสดงว่าเข้า Long-term Memory แล้ว สิ่งที่อยู่ใน Short-term จะนำไปใช้ร่วมกันกับ Working Memory ซึ่งเป็นส่วนที่นำ Short-term มาคิดแก้ปัญหาอีกที แล้วเรื่องพวกนี้มันเกี่ยวตรงที่เวลาเกิด delay แล้วจะทำให้ความจำระยะสั้นและ Working โดนลบไปได้ไงล่ะ

สมมติว่าคิดคำตอบจาก Working Memory มาได้เสร็จแล้ว ทีนี้ก็เอามาทำจริง ถ้าทำเลยก็โอเคไป แต่ถ้ายังไม่ทำผู้ใช้ก็ต้องพยายามจำเข้า Long-term Memory ไม่ก็จดๆไว้ตามที่ต่างๆ = มีโอกาส error เกิดขึ้นแล้ว และการทำงานจะช้าลง นี่ทำให้การคูณ 3312 x 5602 ในหัวนั้นยากเพราะทดไว้ใน Working ไม่พอ ต้องพยายามจำเข้า Long-term การขับเครื่องบินก็ยากเพราะต้องจำหลายอย่างและระวังสภาพโดยรวมจากหลายที่มาอยู่ใน Short-term และ Working

โยงมาเกี่ยวกับคอม มีคนพูดกันว่ามีเวลา response time ที่เหมาะสมอยู่ค่านึง เช่นถ้าเวลา response time นานจะทำให้แผนที่วางไว้ใน short-term ค่อยๆหายไปแล้วต้องมาคอยย้ำคิดใหม่ แต่ ถ้า response ไวไป แผนที่คิดไว้ในหัวอาจยังไม่สมบูรณ์ก็ได้ เช่นมีจอที่อัพเดทสภาพอากาศสดๆ แต่ถ้าอัพเดทซะรัวเลยก็จะทำให้ตามไม่ทัน ส่วนเกมที่ไม่มีฉาก Now Loading มันไม่ค่อยได้อารมณ์ก็เลย fake ฉาก load ขึ้นมา 55

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

แล้วยังมีเรื่องที่มือใหม่จะชอบอะไรที่ response ช้าๆ แต่โปรแล้วอยากได้ไวๆด้วย

Expectations and Attitudes

คำถามที่ว่าคนจะยอมรอนานแค่ไหน ถ้าเปิดทีวีนี่ 2 วิรับได้แต่บางอย่างเช่นหมุนพวงมาลัยรถหรือกดคีย์บอร์ดต้องระดับ 0.1 วิ ขณะที่รอไฟแดง 30 วิก็โอเค

1. นั่นก็เพราะว่าคนมี Expectation[ab] จากประสบการณ์ที่ผ่านมานั่นเอง ถ้าอยู่ๆช้าลงก็จะหงุดหงิด แต่ถ้าอยู่ๆไวผิดปกติก็จะกังวลว่ามีอะไรแปลกไปแน่ๆเลย

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

NW Admin ก็เจอโรคนี้ตอนที่เพิ่มอุปกรณ์ใหม่ๆเข้าไปในระบบแล้วเวลา response time ของโปรแกรมวิเคราะห์ต่ำลงเรื่อยๆ หรือแม้แต่เวลาเช่นตอนเที่ยงคนไปกินข้าวหมดก็จะไวขึ้น แต่บ่ายๆก็ช้าลง ทำให้ NW Admin เป็นบ้า

การ Start-up ไวกลายเป็นจุดขายของพวกกล้องดิจิตอลไปแล้ว แต่บางทีการ Start ไวทำให้โหลดอะไรไม่หมดเช่นเปิดคอมโดยยังไม่โหลดพวก Java/Flash player ต้องไปโหลดตอนใข้งานแทน ก็เลือกเอาว่าจะเริ่มไวหรือจะเริ่มช้าๆแล้วที่เหลือไวหมด

2. ต่อมาคือ Tolerance[ac]ซึ่งก็เป็นเรื่องมือใหม่มือโปรที่บอกไปแล้ว แตกต่างกันไปแต่ละคน

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

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

User Productivity[ad]

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

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

พบว่าผู้ใช้จะ adapt ตัวเองให้เหมาะกับ response time ด้วย ถ้ามันไวมากๆก็จะใส่ไม่ยั้งโดยไม่เช็คอะไรเลย นำไปสู่ปัญหา anticipation error เพราะคิดว่าคอมรับได้ จริงๆแล้วคอมตามไม่ทัน (เคยพิมพ์คำสั่งใน Terminal ส่วนมากจะไวๆ แล้วอยู่ๆมันนานขึ้นก็เลยพลาด) ถ้ามัน response นานกว่า 2 วิเมื่อไหร่ คนใช้จะดูจออย่างตั้งใจเลยว่ามันพร้อมรับรึยังค่อยทำงานต่อ

Variability in Response Time

ใช้คอมอยู่คงไม่มีตาทิพย์จะมองเข้าไปในวงจรไฟฟ้าว่าโอเครึเปล่า คำใบ้หนึ่งที่คนสัมผัสได้คือ response time ซึ่งถ้าปกติ 3 วิแล้วอยู่ๆเป็น 0.5 หรือ 15 วิก็จะเอะใจ นี้คือ Variability [ae]ซึ่งควรหลีกเลี่ยงหรืออย่างน้อยมีอะไรมาบอกก็ดีว่าทำไมไวหรือนานกว่าปกติ

วิจัยออกมาว่าเวลา response (2-4 วิ) ถ้าเปลี่ยนไปแค่ 8% คนจะรู้สึกได้ ก็เลยแนะนำว่าให้ Fix เวลา response time เป็น 4 วิไปเลยในกลุ่มที่ใช้เวลาไม่นาน ในกลุ่มที่ใช้เวลานานก็อาจ Fix เป็น 12 วิ เพื่อลด Variability

เขาบอกว่าถ้า response time ต่ำมากๆความดันเลือดจะสูง

สรุปแล้วถ้านานไปทำให้หงุดหงิด ถ้าสั้นไปทำให้กลัวผิด

Frustrating Experience

เราอาจวัด QoS ได้จากความหงุดหงิดได้ เขาลองไปวัดเวลาคนใช้คอม 5 ชม. พบว่า 43% ของเวลาทั้งหมดเป็น Frustrating Experience[af] ซึ่งเกิดระหว่างใช้ Word / E-mail / Web Browser

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

อีกงานวิจัยเน้นไปด้านความทรงจำ ผู้ใช้จำ Error หรือ Bug ต่างๆได้เพราะว่ามันไปขัด Cognitive[ag] flow ของผู้ใช้ เพราะงั้นเราพยายามออกแบบให้ไม่ขัด

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

แล้วจะแก้ยังไง ก็ควรลดการใช้ Short-term/Working ลง ให้ข้อมูลผู้ใช้มากขึ้น และเพิ่มความ Automaticity ขึ้น ← คือการที่ผู้ใช้ทำอะไรซับซ้อนโคตรๆได้โดยที่ใช้ความ Cognitive เพียงนิดเดียว (เช่นขับรถไปที่ทำงานที่ไปเป็นประจำมาสิบปี)

(แล้วตกลงจะเพิ่มยังไง)


Balancing Function and Fashion

“บางที คำ ก็เป็นเครื่องมือที่แม่นยำสุดๆkสำหรับทำอะไรที่ละเอียดละออ หรือทำให้สัมผัสความจริงที่น่าพิศวงได้”

Introduction

ขี้เกียจพิมพ์

Error Message

ส่วนมากถ้าแยกกันทำจะเห็นได้เลยว่าสำเนียงของ Error มันเป็นของคนละคนกัน ควรตกลงกันให้ดีก่อน ที่สำคัญต้องเชื่อมโยงไปหา Help ที่ตรงกับ Error ให้ผู้ใช้ได้แก้ปัญหาได้ ถ้าทำหลายภาษาควรแยกไฟล์ไว้ไม่ใช่ Hard-code ใส่เข้าไป และ Error ก็ไม่ควรเป็นแค่ SYNTAXERROR เพราะไม่ได้ช่วยอะไรเลย ควรบอกว่าให้ทำอะไร แล้วห้ามด่าด้วย

Specificity → ก็คือบอกให้เจาะจงว่าอะไรผิดไม่ใช่ว่า BAD FILE NAME หรือว่า INVALID INPUT, YOU MUST RETYPE THE ENTIRE RECORD แล้วก็ Error code ถ้าเป็นไปได้ ไม่ต้องเอามา

Constructive guidance and positive tone → คำที่น่ากลัวอย่าง FATAL ERROR, BAD , INVALID อย่าเอามาใช้

User-centered phrasing → คิดถึงผู้ใช้ก่อนเสมอ ให้ผู้ใช้มีความควบคุม สามารถกดหา Help เพิ่มเติมได้ หรือพวก message ก็อย่าไปโทษผู้ใช้

Appropriate physical format → ตัวพิมพ์ใหญ่ล้วนๆควรใช้ในตอนที่ซีเรียสจริงๆ และถ้าอยากจะใส่ Error code เอาไว้ท้ายๆไม่ใช่เอามาขึ้นก่อน สถานที่ๆแสดงอาจเลือกให้ขึ้นมาตรงที่ Error เลย หรือจะให้เป็นช่อง Error เล็กๆข้างล่าง จะใช้เสียงด้วยรึเปล่าก็ได้ (แต่ระวังคนใช้เขิน)


Nonanthropomorphic[ah] Design

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

คอมเป็นคอมนะ ให้คอมเป็นเครื่องมือทำหน้าที่ๆหนึ่งจะดีกว่าบอกว่ามันเป็นเพื่อนซี้หรือผู้ปกครองเรา เราใช้คอมเก่งขึ้นคือความชำนาญของเรา ไม่ใช่ว่าคอมมันเก่ง

ตัวอย่างที่แย่เช่น พอจองตั๋วเครื่องบินปุ๊ป “โอเคค่ะ ฉันจองให้ได้…” ตู้เอทีเอ็มพูดได้ ตู้ไปรษณีย์พูดได้ โปรแกรมอ่านข่าวให้เราฟัง พวกนี้ ตอนนี้เป็นขยะหมดแล้ว 55 (แล้วสิริล่ะ)

วิจัยบอกว่าพอมีตัวละครมาคอยคุยกับเราแทนที่จะสนุกจะยิ่งเครียดขึ้น (โดยเฉพาะคนพวก External LOC[ai]) เช่นมีไอ้คลิปหนีบกระดาษมาคอยถามอยู่นั่นแหละ คำน่ารักทั้งหลายอย่าง “หวัดดีค่ะฉันโซฟีจะมาสอนการสะกดคำนะคะ” รู้สึกดีแค่ครั้งแรก พอครั้งต่อมาเอาฮาและน่ารำคาญอย่างเดียว (แต่ใช้ในโปรแกรมเด็กได้)

กาก : “ฉันจะเริ่มบทเรียนเมื่อคุณกด Enter”

ดี : “คุณสามารถกด Enter เพื่อเริ่มบทเรียนได้”

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

Display Design

รูปลักษณ์ก็ทำให้คนใช้พอใจได้ เราต้องรวมศาสตร์และศิลป์เข้าด้วยกัน

Field layout

เราต้องใช้การ Tab, เว้นวรรค, จัด Column มาช่วย และอย่าลืมเรื่อง Label ประกอบข้อมูลเช่น First Name : SUSAN TAYLOR สังเกตุว่า Label มีทั้งพิมพ์ใหญ่เล็กเพื่อให้ดูแยกออกจากข้อมูลได้ อาจผสมตัวหนาเข้าไป หรือตีกรอบเพื่อจัดกลุ่มก็ได้ (แต่เสียพื้นที่) โดยเฉพาะ วันที่ ควรจะมี Label อย่างยิ่งเพราะคนละประเทศก็เรียงวันเดือนปีต่างกันแล้ว

Empirical results

มาดูตัวอย่างจากทั่วโลกกัน

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

อีกอันเป็น Guidelines จากคนทำเว็บบอกว่าเราควรจัดกลุ่มอะไรที่เกี่ยวข้องกันเข้าด้วยกัน ด้วยสี พื้นที่ ความสว่าง ที่เหมือนๆกัน (consistent) ทำให้คนใช้สืบ/จำข้อมูลได้ไวมาก

Web Page Design

พบว่าการเรียง ซ้ายไปขวา ขวาไปซ้าย ก็ไม่ได้คุณภาพต่างกัน แต่ถ้าความหนาแน่นไม่คงที่กับลิ้งค์เยอะ จะทำให้เว็บดูยาก และคนส่วนมากชอบสีสันสดใส นอกนั้นพวกเราคงรู้กันว่าเว็บที่ดีเป็นยังไง พวก consistent พวก universal usability บอกแปดล้านครั้งแล้ว -*-

ศัพท์อีกอันคือ Mash-up ก็คือเว็บที่รวมหลายๆอย่างเข้าด้วยกันจากหลายๆที่ เช่นเว็บนึงมี Google Map กับ MS Virtual Earth ในที่เดียวกัน ใช้ AJAX ช่วยเขียน

Window Design

มีหลายคนที่ทำงานหลายๆ ‘หน้าต่าง’ พร้อมๆกันด้วยจอใหญ่ หรือหลายๆจอ นักออกแบบอย่างเราจะทำอย่างไรให้ข้อมูลเพียงพอในขนาดจอที่มีได้โดยไม่ต้องมาวุ่นวายลากหน้าต่างไปมาหลบหลีกกัน (หน้าต่าง เริ่มคิดค้นโดย Xerox -> Apple -> Windows

Coordinating multiple windows

หน้าต่างที่ ‘Coordinating’กันก็เช่นเวลาสกรอลหน้าต่างนึงแล้วที่เหลือไปตามด้วยกันทันที ทำให้เปรียบเทียบง่ายในแอพอย่างแอพหางาน หรือการกดอะไรที่หน้าต่างนึงแล้วที่เหลือรับรู้ได้และตอบสนองไปพร้อมๆกัน หรือการทำ Tab แบบ Firefox หรือแม้แต่การเปิดหน้าต่างใหม่แล้วมีหน้าต่างที่เกี่ยวข้องโผล่มาพร้อมๆกัน (จัดเรียงอย่างสวยงาม และควรปิดไปพร้อมๆกัน) ก็เรียกว่าหน้าต่างกำลังร่วมมือกัน

Image Browsing

ก็อย่างเช่นหน้าต่างนึงเห็นทั้งประเทศส่วนอีกหน้าต่างนึงเห็นเป็นจังหวัด ถ้าอยากได้ที่จอมากๆก็ต้องยอมให้ตอนแรกเป็นประเทศก่อน แล้วซูมเข้าไปเป็นจังหวัด แต่ก็จะทำให้ดูภาพรวมไม่ได้ตอนที่ซูมเข้ามาแล้ว ก็เลยอาจมีแบบ Fisheye ที่ซูมเข้าเฉพาะตรงที่ชี้แต่ที่เหลือยังเป็นภาพรวมคล้าย Dock ของ Mac แต่อาจปวดหัวกับการซูม (และอาจซูมได้ไม่เกิน 5 เท่า) หน้าต่างแบบ Image Browsing มีไว้เพื่อจุดประสงค์ 5 ประการ : สร้างภาพใหม่ ทำความเข้าใจ เข้าไปตรวจ เลื่อนดูเส้นทาง (เช่นแผนที่ทางด่วน) และ เฝ้าระวัง (เช่นแผนที่พายุฝน)

Personal role management

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

Color

กลับไปอ่านบทเก่าดิ


User Documentation and Online Help

“สิ่งที่จำเป็นในการศึกษาน่ะหรือ… คือการที่จิตใจเติบโต และพลังงานถูกเร้าออกมา”

Introduction

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

Online Versus Paper Documentation

จริงๆแล้วแถๆไปก็ได้

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

กระดาษ : ตรงข้ามกัน

Reading from Paper Versus from Displays

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

Shaping the Content of the Documentation

ส่วนมากคนคิดว่าคู่มือไม่สำคัญก็เลยให้ลูกกระจ๊อกในทีมเขียนให้ ผลออกมาเลยกาก

Towards minimal manuals

เราคงไม่เห็นภาพมือใหม่มานั่งอ่านคู่มือจนจบก่อนใช้แน่นอน Minimal ก็คือพยายามนำผู้ใช้เข้าสู่การทำงานอย่างรวดเร็วแล้ว Help ค่อยขึ้น หรือพาทัวร์ในโปรแกรมไปเลย

Organization and writing style

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

Accessing the Documentation[aj]

ย้ำอีกทีว่ายังไงคู่มือก็เป็นตัวเลือกสุดท้าย ถึงคนมาอ่านก็อ่านข้ามๆ อยากได้วิธีทำเลยไม่ใช่อยากได้ความรู้

Online documentation

พอออนไลน์แล้วก็สามารถอัพเดทได้ด้วย และควรมีสารบัญทางซ้ายเสมอเพื่อให้โดดไปไหนมาไหนได้

Online help

บางทีอยากหาแต่ไม่รู้ว่าจะค้นด้วยคำว่าอะไร หรือบางทีเป็นตารางมาแต่จริงผู้ใช้อยากได้วิธีทำ อาจทำให้ค้นแบบ Natural language ได้ พิมพ์เป็นภาษาพูดเข้าไปเลย

Context-sensitive help

มีแบบที่ผู้ใช้เรียกขึ้นมา (User-initiated) เช่นพอเอาเม้าส์วางเหนือไอคอนแล้วจะมีบอลลูนขึ้นมาหรือมี Help ไปขึ้นข้างๆจอกับแบบที่ระบบเรียกขึ้นมา (System-initiated) โดยการอ่านใจเราและคาดเดาสิ่งที่เราอยากได้เช่นคลิปหนีบกระดาษนรกนั่น ส่วนมาก Fail หมด กับแบบที่ผสมสองแบบแรกอย่างตอนกรอกฟอร์มในเว็บ Help จะขึ้นเมื่อผู้ใช้คลิกกล่องกรอก แต่เนื้อหาของ Help จะคาดเดาจากการพิมพ์ของผู้ใช้

Special populations

คนอ่านคนละประเทศก็ใช้ภาษาต่างกัน อ่านต่างกัน คนแก่ก็จะไม่เข้าใจศัพท์คอมๆ และอยากได้ตัวอย่างเปรียบเทียบหรือคนพิการก็น่าจะมีขยายอักษรหรือ Help ที่อ่านให้ฟังได้ ก็ว่าไป universal usability…

Online Tutorials and Animated Demonstrations

Online tutorials

ไม่ใช่ Online แบบอย่างที่คิด แต่มันแปลว่าเป็น Help ที่ขึ้นมาตอนเรากำลังทำงานเลย เช่นเมื่อใช้ Photoshop ครั้งแรกก็ให้กดสเปซบาร์ไปเรื่อยๆแล้วมันก็ค่อยๆทำให้ดู (เป็นหลักการ Minimal manual นั่นเอง) ทำให้ผู้ใช้รู้สึกแอคทีฟ

Animated demonstrations

เป็นวิดิโอสาธิต ซึ่งมีข้อดีคือเราสามารถเตรียมการสาธิตที่สวยงามที่สุด (เกินจริง) ได้เพื่อประโยชน์ในการดึงลูกค้าและการโฆษณาด้วย (เช่น Prezi ก็มีวิดิโอสอนใช้อย่างสวยงาม) หรือถ้าโปรแกรมไม่มีอะไรมากอาจเป็น Slide show ก็ได้ ซึ่งแน่นอนว่าผู้ดูควรกรอไปมาได้เองด้วย เรื่อง universal usability ก็เช่นใส่ซับด้วย นอกจากภาพในโปรแกรมแล้วก็อาจถ่ายวิดิโอภาพคน(จริงๆ)ที่กำลังใช้โปรแกรมแทรกเข้าไป และแนะนำให้แบ่งวิดิโอเป็น Section ด้วยว่าตอนนี้หัวข้อไหน ตัวอย่างที่ดีที่สุดของหัวข้อนี้ก็คือเกมตู้อย่าง Technika ซึ่งต้องทำไงก็ได้ให้คนหยอดตู้

Online Communities for User Assistance

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

The Development Process

^หัวข้อเนี่ยหมายถึง Process ของการทำคู่มือ เราควรเริ่มทำแต่เนิ่นๆไม่ใช่ไปทำตอนท้าย (ขัดใจล่ะสิ) เพราะจะได้มีเวลา Review และจำได้มั้ยในวิชา TSPI ผู้ Implement จะอ่าน Specification เมื่ออ่านแล้วไม่กระจ่าง คู่มือที่เราทำไว้ก็จะช่วยให้กระจ่างขึ้นได้ ทำให้เทสโปรแกรมได้โดยที่หน้า Interface ยังไม่เสร็จด้วยซ้ำ ด้วยการลองอ่านคู่มือดู

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


Information Search

“เทพแห่งพสุธาและวารีเสาะหาไปตามธรรมชาติเพื่อหาต้นไม้ต้นนี้ แต่ความพยายามก็สูญเปล่า… เพราะต้นไม้นี้ดันงอกในสมองคน”

Introduction

การค้นหาข้อมูลมีประมาณ 4 แบบ

→ หาสิ่งที่อยากรู้ (หาอีเมลของทักษิณ)

→ หาแบบต่อยอด (คนแต่งเพลงนี้แต่งเพลงอะไรอีกใน Technika)

→ หาว่ามีหรือไม่ (มีบทความเรื่อง AR ใหม่ๆบ้างมั้ย,ในห้องสมุดนานาชาติมีข้อมูลด้านพันธุกรรมอะไรบ้าง)

→ หาแบบปลายเปิดและวิเคราะห์ปัญหา (ภาพนี้แสดงให้เห็นถึงบทบาทของสตรีเพศในสงครามมั้ย)

Intro

Searching in Textual Documents and Database Querying

แต่ก่อนการเซิจต้องเป็นผู้เชี่ยวชาญที่รู้ภาษาเซิจซับซ้อนแต่เดี๋ยวนี้ไม่ใช่แล้วเช่นใน Google ส่วนการเซิจ Database ก็ค่อยๆเข้าถึงคนทั่วไปมากขึ้นเช่นจะหาหนังสือใน E-ห้องสมุดหรือจะหากฏหมายสำหรับทนายความ ซึ่งลึกๆแล้วก็ใช้ SQL โดยมี Natural language / Form-fill in มาบังหน้า ซึ่งอาจใส่ and or not ได้ หรือไฮเทคกว่าคือ Query จากตัวอย่างที่เราใส่เข้าไปก็ยังได้ ต้องบาลานซ์ระหว่างความง่ายให้มือใหม่มาใช้กับ Advanced search ให้มือโปร ซึ่งหน้า Advance นี้มี ‘Five-stage Framework’ ช่วยออกแบบได้ :

Formulation : หาอะไร – ควรมีโหมดการกำหนด fields ว่าหาจากอะไร (ไม่ใช่หาจากทั่วโลกไปเลย) ทำให้รับ phrases ได้เช่นเซิจชื่อคนก็จะไม่แยกชื่อนามสกุลออกจากกันและรองรับ varient เพื่อรองรับผู้ใช้ที่ไม่รู้ว่าจริงๆต้องพิมพ์ว่าอะไร (teach → teach,teacher,teaches,teaching,teach ภาษาอื่น)

Initiation of action : กดหา – ก็คงต้องมีปุ่มเซิจ แต่บางทีให้พิมพ์ๆไปหรือปรับ Filter แล้วผลออกมาเลยก็ได้นะ (แบบ implicit[ak] ซึ่งตรงข้ามกับ explicit ซึ่งเรากดปุ่มเอง)

Review of results : ดูผล – ผลออกมาก็น่าจะปรับจำนวนผลการค้นหาต่อหน้าได้หรือ Sort ตามอะไรต่างๆได้ (อย่าคิดถึงภาพ Google อย่างเดียวนะ ค้นอย่างอื่นก็มี) หรือจัดกลุ่มด้วยตนเอง

Refinement : คิดขั้นต่อไป – หน้าต่างอาจบอกว่า Did you mean… หรือการเก็บการเซิจเก่าไว้ให้ Reuse ได้ หรืออะไรอื่นๆก็ได้ที่ทำให้ผู้ใช้เซิจครั้งต่อไปได้ดีขึ้น

Use : นำมาใช้ – อาจมีระบบ Export ไปเข้าโปรแกรมอื่น หรือเซฟเก็บไว้ได้

Multimedia Document Searches

แล้วถ้าหาอะไรที่ไม่ใช่ Textual ล่ะจะเกิดอะไรขึ้น

Image Search : ระบบอาจ Image Pro ดูภาพว่ามีชิ้นส่วนอะไรยังไงซึ่งยากเพราะไม่รู้ว่ามันจะถ่ายรูปมามุมไหน ง่ายกว่าคืออาจให้ผู้ใช้ Mark ส่วนสำคัญต่างๆเองได้ เช่นการ Tag รูปถ่ายว่าคนนี้อยู่ตรงไหน ต่อไปมันก็จะรู้ได้เอง

Map Search : เดี๋ยวนี้ก็เซิจได้หมดแล้วเพราะข้อมูลต่างๆฝังอยู่ในแผนที่เช่นจำนวนประชากรหรือระยะห่าง

Design or Diagram search : เช่นหาพาดหัวข่าวที่พาดหัวกว้างเท่าหน้ากระดาษ หรือหามอเตอร์ที่รูน๊อตเล็กกว่า 6 cm

Sound Search : เช่นร้องเพลงหรือใส่ไฟล์เสียงเข้าไปแล้วหาให้ได้ หรือหาคำๆนึงว่าอยู่ในเพลงไหน (เทพ)

Video Search : นอกจากจะไล่หาทุก Frame แล้วยังควรแบ่งเป็นซีนๆให้ด้วย หรือเซิจจากคำพูดที่คนในวิดิโอพูดกัน (ซึ่งแปลงเป็น Text แล้ว)

Animation Search : เช่นหาว่าอะไรหมุนๆมั่งใน Flash (…เพื่ออะไรฟะ)

Advanced Filtering and Search Interfaces

Boolean Query : ก็คือ and or not ได้แต่ระวังคำว่า and or เพราะเช่น “I want apple or orange” แปลว่าอยากได้อันใดอันหนึ่งแต่ใน boolean มันเอาทั่งคู่ก็ได้ และ “Find people live in Newyork and Boston” อันนี้กะจะให้หาสองเมืองแต่ใน boolean ก็จะค้นไม่เจออะไรเลยเพราะมันเข้าใจว่าอยู่สองเมืองพร้อมกัน

Automatic Filtering : กำหนดไว้ก่อนว่าจะกรองอะไรแล้วพอค้นมามันก็กรองให้เอง

Dynamic Query : เรียกอีกอย่างว่า DM[al] Query เช่นมี Slider หรือปุ่มกดให้ปรับเขตผลการค้นหาสดๆได้เลยซึ่งส่งเสริมให้คนเซิจได้ลองปรับเล่นและลด syntax error ด้วยเพราะไม่ได้พิมพ์ Form Fill-in เอง (แนะนำให้ดูภาพ 13.5 ในหนังสือ) แต่จะ DM ได้เร็วขนาดนี้คงต้องโหลดผลการค้นหาไว้ในเครื่องของเราซึ่งถ้าใหญ่คงไม่ดี เลยมีเทคนิคอีกว่าเซิจมาอาจมี ‘ภาพรวม’ ให้เห็นและคัดส่วนที่ไม่ต้องการออกก่อนได้ค่อยเก็บลงเครื่อง

Facet[am]ed metadata[an] search : ค้นมาแล้วสามารถ ‘ตัด’ ผลการค้นหาด้วยหมวดหมูต่างๆได้ ซึ่งสามารถลองเพิ่มลดหมวดหมู่เพื่อกรองแบบต่างๆได้สดๆ

Query by example : บอกไปแล้ว

Implicit search : ไม่ได้ Implicit ในด้านการกดเซิจแบบที่บอกไป แต่เป็นประมาณว่า คนที่ซื้อเกม DJMax นี้ ก็ซื้อ Pop’n Music ด้วยนะสนมั้ย ขึ้นมาแนะนำเลยทั้งๆที่เราไม่ได้เซิจ

Collaborative filtering : เราจะช่วยกัน filter ได้เช่นเราเรทร้านอาหาร A ไป 5 ดาว ทีนี้คนอื่นเพื่อนเรา เรทร้าน A และ B ไป 5 ดาว มันก็จะแนะนำ B ให้เราเพราะคิดว่าน่าจะชอบเหมือนๆกัน

Multilingual search : หลายภาษา

Visual field specification : เช่นมีภาพเครื่องบินให้กดๆ[ao]ค้นหรือกรอง มีประเทศฝรั่งเศสให้จิ้มหาหรือลากคลุม ทำให้รู้สึกได้ว่าข้อมูลทั้งหมดเป็นไงมีขอบเขตแค่ไหน และหมดปัญหากับการค้นแล้วไม่เจออะไรเลย (เพราะเห็นแล้วว่าทั้งหมดมีแค่นี้)


Information Visualization[ap]

“การเดินทางอันยิ่งใหญ่เพื่อการค้นพบน่ะไม่ได้เพื่อหาแผ่นดินใหม่ แต่เป็นการหาตาใหม่”

Introduction

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

Data Type by Task Taxonomy

อ่านหัวข้อแล้วติดสตั้น 5 วิ ประมาณว่า ถ้าเจอ Data-type แบบ Tree เงี่ย มันจะเจอปัญหาเกี่ยวกับเส้นทาง จำนวนชั้น ค่าที่ Leaf หรือถ้าเจอ Data-type แบบ Temporal ก็จะเจอปัญหาเกี่ยวกับเวลาเริ่ม เวลาจบ เรามี Task ทั้งเจ็ด ที่ผู้ใช้มักจะหยิบมาใช้เวลาเจอ Data-type ชนิดหนึ่งๆ ทีนี้เข้าใจหัวข้อขึ้นมามั่งยัง เรามารู้จัก Data-type ทั้งเจ็ด แล้วตามด้วย Task ทั้งเจ็ด กัน

The Seven Data Type

1. 1D linear data

มิติเดียวก็เช่นโค้ดโปรแกรม ไฟล์ Word หรือพวกรายชื่อคน ถ้าเราแปลง 1 ตัวอักษรเป็น 1 pixel เราก็จะได้ภาพรวมของเอกสารมาอย่างง่ายดายในรูปแบบภาพ พวกวันที่ที่แก้ไขล่าสุด ก็ทำเป็น Color coding[aq] เลย ในโปรแกรมพวก (ท้อถอย) SVN ก็จะเห็นได้ประจำว่าบรรทัดไหนที่ไม่เหมือนเวอร์ชั่นที่แล้ว มันจะมีสีระบายไว้ หรือการหาคำที่คล้ายกันในเอกสารก็เปลี่ยนสี pixel ว้าว เอกสารเราถูก Visualize แล้ว

2. 2D map data

เช่นแผนที่ ผังตึก 1 ชั้น หรือ layout ของหนังสือพิมพ์ ก็ล้วน Visualize มาจากของจริงซึ่งก็เป็นแผ่นๆ อะไรที่เป็นแผ่นๆอยู่แล้วผู้ใช้มักจะอยากหาสิ่งใกล้เคียงกับ x หรือบริเวณที่มี y อยู่ หรือเส้นทางระหว่าง a กับ b

3. 3D world data

(ชักจะใหญ่ขึ้นเรื่อยๆ) ของจริงเช่นโมเลกุล ตึกแท่งนึง ก็ถูก Visualize ด้วยโครงสร้างเคมีเป็นเส้นๆกับอักษร หรือแบบแปลนที่สถาปนิกเขียนขึ้น ผู้ใช้มักจะต้องหาค่าที่ ‘Continuous’ เช่นอุณหภูมิ หรือความหนาแน่น การ Visualize เป็นสามมิติมีปัญหาที่เราจะตีความยากขึ้นเพราะต้องหมุนๆดู

4. Multidimensional data

เช่นพวกข้อมูล Database ต่างๆซึ่งมีหลายมิติตามจำนวน attribute ที่มี ก็อาจ Visualize ให้กลายเป็นจุดๆกระจาย อันไหนคล้ายๆกันก็ให้จุดไปอยู่ใกล้ๆกัน (ใช้อัลกอจัดกลุ่มอย่าง K-means เข้ามาช่วย) อาจทำให้ค้นพบอะไรใหม่ๆได้ (อันนี้อ่านแล้วงงจริง)

5. Temporal[ar] data

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

6. Tree data

ก็คือข้อมูลที่ทุกตัวมีความสัมพันธ์กับพ่อของมัน ผู้ใช้มักจะอยากรู้ว่า Tree นี้มันลึกมั้ย (เช็ค downline ของแอมเวย์ว่าชวนมาได้กี่ทอดแล้ว) หรือว่าใน node นี้ครอบคลุม node ลูกอื่นๆกี่อัน (พนักงานคนนี้มีลูกกระจ๊อกกี่คน) วิธี Visualize ก็คือวาดเป็น Tree แบบที่เรียนมาใน ADT นั่นแหละโดยที่ node ก็ทำสวยๆหน่อยเป็นกล่องมีภาพหน้าพนักงาน อันไหนสำคัญอาจกล่องใหญ่ๆ

7. Network data

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

สรุปคือทั้ง 7 อย่างนี้คือการเปลี่ยนความจริงให้เป็นภาพ

The Seven Basic Tasks

1. Overview Task การมองภาพรวมซึ่งแน่นอนต้องซูมออกมาเยอะๆ หรือทำ Fisheye

2. Zoom Task ซูมเข้าไปควรจะค่อยๆเข้าไปแบบนุ่มๆเพื่อให้รู้ว่าเปลี่ยนไปจากที่เดิมยังไง จะซูมโดยจิ้มที่ๆอยากเข้า หรือลาก Slider ก็ดี

3. Filter Task การกรองออกก็เช่นการทำ Dynamic Query ในบทที่แล้ว DM DM DM

4. Details-on-demand Task ถ้าอยากได้ข้อมูลของสิ่งนั้นๆส่วนมากเขาก็ทำให้คลิกแล้ว pop up เป็นหน้าใหม่ขึ้นมา ในกล่อง pop up อาจมี link ต่อไปอีกก็ได้นะ (เช่นคลิกจังหวัด)

5. Relate Task เช่นผู้ใช้คงอยากลองดูๆว่ากราฟนี้มีกลุ่มนี้ใกล้กันนะ หรือทำไมตรงนี้สีแดงเยอะจัง เชื่อมโยงตีความด้วยการกวาดตา เพราะงั้นเวลา Visualize ก็ใช้สีใช้อะไรให้ผู้ใช้สามารถ Relate ได้ง่ายๆด้วย

6. History Task เช่นผู้ใช้อาจอยากย้อนไปย้อนมาเพื่อลองทางใหม่ แน่นอนสิ่งที่นักออกแบบอย่างเราต้องทำคือ ระบบ Undo

7. Extract Task เช่นผู้ใช้คงจะอยากได้ผลลัพธ์แบบเซฟเป็นไฟล์ออกมา ก็จัดให้ซะ

Challenges for Information Visualization

เข้าใจปัญหาแบบต่างๆกันแล้วแต่ก็ยังมีความท้าทาย :

  1. แค่ข้อมูลนำเข้าก็หืดขึ้นคอแล้วเพราะต้องมาจัดเรียงให้เข้ากับโปรแกรมเราก่อน
  2. บางทีวาดภาพมาสวยงามแล้ว ยังคงต้องมีตัวอักษรประกอบอีก ต้องไม่รกด้วย
  3. ผู้ใช้อยากได้ข้อมูลที่เกี่ยวข้องจากหลายๆแหล่ง คุณสามารถหามาประเคนให้เขาได้มั้ย
  4. ข้อมูลเยอะโคตรๆ เป็นภาพแล้วดูไม่รู้เรื่องเลย
  5. เราใส่ Data Mining เข้าไปร่วมแจมด้วยได้มั้ย พลังของ Visualization ทำให้ค้นพบแนวโน้มใหม่ๆ (ด้วยตา) ส่วน Data Mining ก็ทำให้พบคู่น่าสนใจที่เคลื่อนไปทางเดียวกัน มีทั้งสองอย่างคงเข้าขากันดีไม่น้อย
  6. เชื่อมต่อเข้ากับเครื่องมือ Decision Making ด้วย ครบเครื่องเรื่องธุรกิจไปเลย
  7. ช่วยกันดูกับเพื่อนได้ เช่นเซฟ State แล้วส่งให้เพื่อนช่วยวิเคราะห์
  8. UNIVERSAL USABILITY!! แต่ไม่ต้องถึงขั้นคนตาบอดก็ได้ (จะเห็นอะไร)
  9. ต้องกลับมาทบทวนได้ เพราะกว่าจะเห็นอะไรจากภาพมันต้องใช้เวลา… อาจเป็นเดือน!

Managing Design Processes

“แผนคือเครื่องกำเนิดไฟฟ้า ถ้าไม่มีก็จะเหี่ยวเฉา”

Introduction

(บทนี้ใน Text แทบไม่มีภาพเลย T_T ยาวโคตร)

แต่ก่อนโปรแกรมเราสร้างให้ตัวเองหรือเพื่อนๆใช้ เดี๋ยวนี้ไม่ใช่อย่างนั้นแล้ว ผู้ใช้คือตาสีตาสามาจากไหนไม่รู้หรือเป็นสถาปัตย์มือฉมังที่ไม่เคยแตะคอมเลย หัวข้อ Usability กลายเป็นเรื่องใหญ่ถึงขนาดว่ามีองค์กร UPA (Usability Professional Association) ขึ้นมาเลยทีเดียว แถมยังมีวัน World Usability Day ด้วย อืมม แล้วทำยังไงจะเข้าใกล้ผู้ใช้ได้มากขึ้นกันนะ (เหลือกขึ้นไปดูหัวเรื่อง) เรามาจัดกระบวนการ Design กันใหม่ดีกว่า เริ่มจาก…

Organizational Design to Support Usability

รู้ไหมตอนนี้ฝ่ายต่างๆในองค์กรเริ่มเอะใจกันแล้วว่า Usability เป็นสิ่งสำคัญ ยิ่งถ้าเราผลิตของคล้ายๆกัน มันจะเฉือนกันที่เรื่องนี้แหละ ถึงกับคุ้มที่จะสร้าง ‘Usability Lab’ ขึ้นมาเพื่อทดสอบและรีวิว (รายละเอียดติดตามในบทถัดไป) ยิ่งถ้ามี CUO (Chief Usability Officer) ด้วยยิ่งดี (ดูเวอร์จัง) หรือจะจัดกิจกรรมมาสัมมนาเรื่อง Usability หรือติดบทความเรื่องนี้ทั่วบริษัท

……แต่ทั้งหมดนี้เป็นเพียงความฝันหากองค์กรของคุณต่อต้านการเปลี่ยนแปลง ผู้นำการเปลี่ยนแปลงควรมีเทคนิคการเชิญชวนที่ดี เช่นยกข้อดีของบริษัทที่เปลี่ยนแปลงไปใช้ Usability-engineering แล้วดีขึ้นมาบอก (เวลาเรียนรู้ลดลง error rate ลดลง ส่วนแบ่งตลาดสูงขึ้น คนโทรมาบ่นลดลง บลาๆ) หรืออาจเสริมว่า เนี่ย เพราะระบบของเราตอนนี้มันเน่าเฟะ องค์กรเราก็เลย บลาๆ และอย่ายอมแพ้ มันต้องใช้เวลาบ้างกว่าทุกคนจะยอมรับ

ทีนี้คงโดนลูกทีมถามเรื่อง Return on Investment (ROI)[as] ชัวร์ แต่ผลก็ออกมาเยอะแล้วว่าคุ้มจริง (ลงทุน 1$ ได้คืนมา 100$) แนะนำให้ใช้สองเทคนิคร่วมกันคือ มีแลปสำหรับทดสอบ Usability ในมุมมองคนทั่วไปและมีอีกคนที่ออกแบบ UI มาทดสอบด้วยเพื่อให้เป็นมุมมองของนักออกแบบ/คนเก่ง

มาเปลี่ยนทีมของคุณ ให้นึกถึง Usability ตั้งแต่ต้นกันเถอะ!

The Four Pillars of Design

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

สิ่งที่จะได้ →

U

I

ที่

สุดยอด

ต้องทำ →

UI Requirement

Guidelines ต่างๆ

เครื่องมือช่วยสร้าง UI

รีวิว

ทำไง →

ออกไปสำรวจสิ

มาจากทฤษฎี

ทำ prototype

การทดลอง

เริ่มมาจาก →

งาน

วิจัย

ต่าง

ต่าง

เสา 1 : User interface requirement

ก่อนจะออกแบบก็ไปดูก่อนว่าลูกค้าต้องการอะไร ต้องตกลงกันหมดทั้งทีมตั้งแต่ก่อนเริ่มโปรเจคแล้วว่าฮาร์ดแวร์ที่จะทำ UI ลงมีสเปคยังไง ต้องทำอะไรได้มั่ง input output อะไร คุยให้เรียบร้อย

ตัวอย่าง Req. ที่ผิด : ผู้ใช้ต้องตัดสินใจว่าจะถอนเงินเท่าไหร่ใน 5 วิ

ตัวอย่าง Req. ที่ถูก : ระบบจะให้เวลาผู้ใช้ 5 วิเพื่อเลือกจำนวนเงินที่จะถอน

ถ้าถามว่าทำไงจะรู้ว่าผู้ใช้อยากได้อะไร เราต้องทำ Ethnographic Observation ซึ่งเดี๋ยวจะมีหัวข้อใหญ่ให้อ่านอีกที

เสา 2 : Guidelines documents and processes

ขัดกับนิสัยคนไทยอย่างมาก แต่ก็ต้องทำ guidelines ขึ้นมาเมื่อจะออกแบบ และอัพเดทเสมอๆ อาจ 10 หน้าในสองสัปดาห์ ความสำเร็จของ Apple ก็เพราะมี guidelines ที่ดี อ่านง่าย ทำให้ developer ทั้งหลายทำตามจนทั้งหมดเป็นหนึ่งเดียวได้ ควรเขียนเกี่ยวกับ : คำย่อคำเฉพาะ, สี, ฟอนต์, โครงสร้างหน้าจอ, สำเนียงของ error, เสียง, Response Time, อินพุต, ลำดับการทำงาน ฯลฯ

ควรทำกระบวนการ ‘สร้าง guideline’ นี้ให้เป็นกิจกรรมสม่ำเสมอ อะไรที่เป็นที่ถกเถียงเช่นเมื่อไหร่จะเล่นเสียงเตื่อนดี ก็ให้ดูๆช่วยกัน ทดสอบช่วยกัน ทำได้ตามนี้งานจะราบรื่น ไม่ต้องมานั่งโอดครวญเปลี่ยน Design บ่อยครั้ง

เสา 3 : User-interface software tools

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

เราควรทำไงก็ได้ให้ผู้ใช้หรือลูกค้าเห็นภาพให้เร็วที่สุด อาจรีบปริ้นภาพไปให้ดู หรือทำ Prototype หลอกๆขึ้นมาบนเครื่องจริง มี Form มีอะไรครบแต่ยังไม่เอาข้อมูลไปคิด ถ้าไม่ทำบนเครื่องจริงอาจใช้ Power Point / Flash / AJAX ทำขึ้นมาก็ได้ (ถ้าคิดว่าไวกว่า)

เครื่องมือทำ UI ที่เรารู้ๆกันก็เช่น Visual Studio / Java Development Kit

เสา 4 : Expert reviews and usability testing

^ ก็ทำตามที่หัวข้อบอกนั่นแหละ ทำไงนั้นไปอ่านบทต่อไป

Development Methodologies[at]

โปรเจคเขียนโปรแกรมล่มกว่าครึ่งเพราะ คุยกันไม่ดี ไม่รู้เรื่อง ระหว่างคนทำกับลูกค้า เราต้องให้ลูกค้าเป็นศูนย์กลาง Software Engineering Methodology ที่ใช้อยู่ทำให้กระบวนการเขียนโปรแกรมเป็นไปด้วยดี แต่ไม่ได้ทำให้เข้าใจลูกค้าได้ดีขึ้น หรือไม่ได้ทำให้ออกแบบหน้าจอได้ดีขึ้นเสมอไป เพราะงั้นต้องมี Methodology เฉพาะมาเพิ่ม เช่นใน IBM มี ‘Ease of Use’ Methodology ใช้กันในบริษัท ส่วนคนทั่วไปตอนนี้กำลังฮิต Agile[au] กันเพราะทำให้ปรับตัวเข้ากับลูกค้าได้อย่างรวดเร็ว

ขอเสนอตัวอย่าง… ‘Rapid Contextual Design’ Methodology (by Holtzblatt) ให้ลองเอาไปใช้กัน มีขั้นตอนดังนี้

  1. Contextual inquiry ออกสัมภาษณ์เพื่อดูว่าลูกค้าอยากจะทำอะไร
  2. Interpretation sessions and work modeling เรียกพรรคพวกมาประชุมเกี่ยวกับผลที่ได้มาจากข้อแรก มันจะกระทบด้านกฏหมายหรือวัฒนธรรมมั้ยนะ มาตีความกัน
  3. Model consolidation[av] and affinity diagram building เอาข้อ 1 และ 2 ไปให้คนที่กลุ่มใหญ่ขึ้นมาดูเพื่อหาจุดน่าสนใจใหม่ๆ สร้าง affinity diagram[aw] ของความต้องการของลูกค้า
  4. Persona development สร้างตัวละครสมมุติเพื่อแทนลูกค้า เช่น ยายแก่ที่เคยใช้คอมเพื่อส่งเมลกับแชร์รูป,เกรียนชายอายุ 22 ที่เล่นเกมมา 5 ปี
  5. Visioning เอาข้อ 4 มาแชร์กัน รีวิว และลองนึกภาพ ว่าจะมีปัญหาอะไร
  6. Storyboarding เอาสิ่งที่ลูกค้าอยากจะทำ มาเขียนเป็นภาพหรือกราฟ ว่าไอ้ที่เราจะสร้าง มันมีขั้นตอนเป็นไปยังไง เพื่อให้ทำสิ่งที่ลูกค้าอยากจะทำได้
  7. User environment design (UED[ax]) เป็นเอกสารที่บอกทุกอย่างของโปรแกรมเรา สร้างมาจากข้อ 6
  8. Interview and evaluations with paper prototypes and mock-ups เอาไปทดสอบกับคนจริง อาจเริ่มจากเป็น prototype กากๆบนกระดาษ หรือจะเป็น Mock-up หรูบนเครื่องจริง บันทึกผล และเอามาพิจารณา

Ethnographic[ay] Observation

จะเห็นว่า Methodology ข้างต้น ในขั้นตอนแรกๆก็ต้องสำรวจลูกค้า อาชีพ Ethnographer จะไปอยู่ในสภาพแวดล้อมหนึ่งๆเป็นเดือนเพื่อเข้าใจวัฒนธรรม ใช้ชีวิตร่วมกัน หรือถามคำถามพวกเขา

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

Preparation → เข้าใจกฏของเขา เตรียมคำถาม ขอความอนุมัติก่อน ไม่ใช่ไปบุกรุก

Field Study → สร้าง Rapport[az] ระหว่างกัน สัมภาษณ์เพื่อเก็บทั้งค่าที่วัดได้ และค่าที่ค่อนข้าง subjective

Analysis → ตีความข้อมูลที่อุตส่าห์เก็บมา อาจลง DB ก็ดี

Reporting → นำเสนอผลที่พบ อย่าลืมคิดด้วยว่าผู้ฟังเป็นใครบ้าง มีพื้นแค่ไหน

ถ้าอ่านแล้วคงรู้สึกว่าเป็น common sense แต่ตอนทำจริงอย่าลืมละกัน เช่นข้อแรก เขาอาจมีกฏว่าห้ามใส่ยีนส์ ก็ต้องทำตาม บางทีต้องเรียนรู้ศัพท์เฉพาะของเขาเพื่อให้สร้าง Rapport ได้ดี (เช่น ไอ้หอมซอย) สิ่งที่เราจะไปวัดมาอาจเป็นจำนวน Error ที่เกิดใน 1 ชม. ที่เราไปลงพื้นที่ หรืออาจเป็นความคิดเห็นที่ออกจะ subjective หน่อย (แต่ไม่ต้องไปอัดเสียงทุกการสนทนามานะ ไร้ประโยชน์)

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

Participatory Design

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

แต่ส่วนมากจะได้ผลดี เช่นการใช้หลักการ PICTIVE [ba]ซึ่งให้ผู้ใช้ใช้กระดาษ พลาสติก เทป ปากกา มาออกแบบ UI (สามัญชนก็ทำได้ สนุกด้วย) ระหว่างนั้นพวกเราก็อัดวิดิโอไว้ว่าผู้ใช้คิดยังไง เปลี่ยนแปลงตรงไหน อะไรมั่ง แล้วเอาผลงานที่ผู้ใช้ทำเสร็จแล้วมาวิเคราะห์กัน พร้อมทั้งดูวิดิโอ ผู้ใช้ที่สรรหามาช่วยควรคัดคนดีๆด้วย เช่นอาจให้เข้าประชุมหลายครั้งเพื่อคัดให้เหลือแต่คนที่สนใจจริง อาจโฆษณาว่า เนี่ย มาประชุมบ่อยๆก็จะได้เรียนรู้องค์กรเรา เทคโนโลยีของเราด้วยนะ

Scenario Development

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

“ครู ป.6 สอนเรื่องภูมิศาสตร์ ครูอยากได้แผนที่ประเทศไทยปัจจุบันที่บอกความสูงเป็นสีๆได้และเลือกเอามาแสดงเป็นจังหวัดๆได้ เป็นครูนั้นงานยุ่งมาก ต้องเตรียมจังหวัดที่จะเอาไปสอนเด็กภายใน 4 ชม.”

หรือเวลาเรากำลังทำโปรแกรมออกรายงานสถิติ อาจมี Scenario ว่า

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

เมื่อสร้าง Scenario มาแล้วก็ลองแสดงตามบทบาทนั้นดูว่ามีปัญหาอะไรมั้ย

บริษัทมือถือชื่อดังในญี่ปุ่น สร้างวิดิโอ Scenario เกี่ยวกับครอบครัวที่ลูกไปเรียนต่างประเทศ แล้วใช้มือถือของพวกเขา ติดต่อกันยามคิดถึงได้อย่างมีประสิทธิภาพ ขายดี เทน้้ำเทท่า

Social Impact Statement for Early Design Review

สร้างอะไรขึ้นมาแล้วมักจะกระทบผู้คนจำนวนมาก ควรร่วมกันคิด Statement ว่ามันจะกระทบอะไรยังไงบ้างให้ดี (คิดกับลูกค้าด้วย)

หลายๆคนอาจคิดว่าโปรแกรมเราอาจไปรุกรานสิทธิส่วนบุคคล อาจฆ่าคนถ้าใช้ไม่ถูก อาจไปเลย์ออฟพนักงานก็ได้ ก็เลยเกิด Social Impact Statement ขึ้น ในนั้นก็จะมีหัวข้อ เช่น

  1. อธิบายระบบและประโยชน์
  2. ความกังวลที่คาดเดาไว้ → ปัญหาความปลอดภัย ปัญหาเลย์ออฟ ความไม่ไว้ใจในระบบใหม่ ประโยชน์ต่อองค์กร ประโยชน์ต่อสังคม
  3. ขั้นตอนการพัฒนา

Legal Issue

เรื่องทางกฏหมาย น่าปวดหัวเสมอ อ้ากๆๆ = =

เรื่อง Privacy จะมาเลยเมื่อเราต้องเก็บข้อมูล เราต้องรักษาข้อมูลผู้ใช้ให้ดี ห้องเก็บข้อมูลก็ล็อคกุญแจหรือจ้างยามมาก็ได้ เราก็ควรเขียน Privacy Policy ดีๆ (ไม่เคยอ่าน Accept ลูกเดียว)

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

เรื่องที่สามคือ Copyright และ Patent ของซอฟต์แวร์ซึ่งผู้ใช้ก็ชอบเหลือเกินที่จะ Crack โปรแกรมไปใช้ อาจเขียนโปรแกรมดักไว้แต่ Hacker ดันเก่งกว่า มีองค์กรที่ไม่เห็นด้วยกับการจดสิทธิบัตรเกี่ยวกับ UI มีองค์กรอย่าง Creative Commons[bb] ที่ให้ผู้สร้างผลงานบอกได้ว่าต้องการจะให้สิทธิผู้อื่นแค่ไหน หรือแม้แต่แนวคิด Open-source ที่บอกว่าเอาไปแก้ได้เลยตามสบาย

อย่างที่ 4 คือ Copyright ของเนื้อหาออนไลน์ ถ้าไปเห็นข้อความอะไรบนเน็ต แล้วเราก๊อปลงเครื่องได้มั้ย เราแบ่งให้เพื่อนได้มั้ย คนที่ส่งเมล เป็นเจ้าของข้อมูลในเมลรึเปล่า ถ้าจะเผยแพร่งาน Copyright ทีนึงต้องขออนุญาติหรือจ่ายเงินก่อนแล้วแวดวงการศึกษาและวิทยาศาสตร์จะเป็นไงต่อไป (ซึ่งก็มี Fair-use Doctrine ส่งเสริมการแจกจ่ายเนื้อหาเพื่อการศึกษาได้) แต่ยังไงความกว้างของเน็ต ก็ทำให้ไฟล์ผิดกฎหมายกระจายไปอย่างรวดเร็ว

ข้อ 5 คือ Freedom of Speech เราสามารถถกเถียงเรื่องอื้อฉาวต่างๆในเมลหรือบอร์ดได้อย่างเสรีมั้ย? ในเน็ตนั้นเหมือนริมถนนรึเปล่าที่เราจะพูดอะไรก็ได้? หรือเป็นถิ่นที่ต้องทำตามกฏ แอดมินต้องมาคอยรับผิดชอบคนโพสของอันตรายในบอร์ดมั้ย? ISP สามารถบล๊อคเมลซึ่งส่งมาบ่นว่า ISP นั้นกากโคตรๆได้มั้ย? เราโดนด่าแล้วจะฟ้องร้องเจ้าของบอร์ดได้มั้ย? ฟ้องร้องคนด่าได้มั้ย?

จำเป็นมั้ยว่าเว็บอย่าง Yahoo! และ eBay ต้องไปไล่ดูกฏหมายของทุกประเทศที่พวกเขามีลูกค้า แถมยังต้องคอยติดตามการเปลี่ยนแปลงของกฏหมายอีก?

จะเห็นว่าโลกเรามันอยู่ยากขึ้นทุกวัน


Evaluating Interface Design

“การทดสอบว่าอะไรเป็นความจริงนั้นยากและเต็มไปด้วยขวากหนาม อะไรที่ดูดีน่ะอยู่ในความฝัน”

Introduction

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

Expert Reviews

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

Heuristic evaluation ผู้เชี่ยวชาญหยิบเอาหลักการอย่าง Eight Golden Rules มาไล่เช็คทีละข้อๆ ถ้าเป็นเกมก็จะมีหลักเช่น ต้องปรับระดับเสียงได้ ต้องข้ามฉากซ้ำๆได้

Guidelines review ผู้เชี่ยวชาญจะหยิบ guideline ของเรามาอ่านให้เข้าใจ แล้วมานั่งดูว่าพลาดตรงไหนบ้าง (ต้องให้เวลาเขาอ่านด้วย)

Consistency inspection ตรวจทั้งของโปรแกรมและ documentation ต่างๆด้วย

Cognitive walkthrough สวมบทเป็นผู้ใช้หลายๆสถานการณ์แล้วลองใช้ดู

Metaphors of human thinking[bc] (MOT) ปรับจิตลองนึกดูว่า ถ้าผู้ใช้มาใช้จริงจะรู้สึกยังไง (รู้สึกจะเก่งจัง ไอ้ Expert เนี่ย)

Formal usability inspection ผู้เชี่ยวชาญเรียกทุกคนมาเปิดประชุม เสนอจุดอ่อน และถกเถียงกันอย่างดุเดือด

แน่นอนว่าผู้เชี่ยวชาญควรอยู่ในสถานการณ์เดียวกับผู้ใช้ให้มากที่สุด รวมทั้งสิ่งรบกวนและบรรยากาศ อีกเทคนิคคือ Bird’s-eye view ซึ่งปริ้นทุกหน้าจอออกมาแปะบนกำแพง ผู้เชี่ยวชาญกวาดตาแว่บเดียวก็คงเห็นความไม่ consistence บ้างแหละ

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

เท่านี้เราก็จ้าง Expert มารีวิวได้ หรือเป็น Expert ไปรีวิวของคนอื่นได้แล้วหล่ะ!

Usability Testing and Laboratories

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

Usability Testing เป็นคนละสายกับ Controlled Experiment[bd] ซึ่งควรทำทั้งคู่

Usability labs[be]

คงอยากรู้แล้วล่ะสิว่าห้องแลปเป็นไง ที่ต้องมีก็เพราะจะทำให้รู้สึกว่าจริงจังกับ Usability มากขึ้น ขนาดซัก 10×10 ft. แบ่งครึ่งด้วยกระจกที่มองทะลุได้ด้านเดียว ให้ด้านนึงให้ผู้เข้าร่วมใช้ อีกด้านนึงเป็นผู้สังเกตการณ์ มีสตาฟซักคนสองคนซึ่งเชียวชาญด้าน UI และการ Testing ก่อนเริ่มสตาฟก็จะไปคุยกับคนที่ออกแบบ UI ก่อนเพื่อ list สิ่งที่จะทดสอบออกมาเป็น Test plan ซึ่งมีบอกจำนวนคน ประเภทคน ที่จะเอามาทดสอบด้วย สตาฟต้องระมัดระวังว่าคนๆนั้นพิการ ตาเข หรือบอดสี อะไรแบบนี้รึเปล่า

ในห้องที่ผู้ใช้มาลองนั้นก็จะมีการ Record หน้าจอ มีการ Log เม้าส์ คีย์บอร์ด ไว้หมด แถมมีไมโครโฟนอัดเสียงด้วย (ผู้ใช้จะถูกสั่งว่า ถ้าคิดอะไรในใจ ให้พูดออกมา 55) ถ้าโหดสุดก็คงมี eye-tracking ด้วยว่ามองไปทางไหน ตรงไหนถูกมองข้าม ทีนี้งานถึกก็คือเอาพวกที่อัดไว้เนี่ยมาวิเคราะห์

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

Handling participants[bf] and the Institutional Review Board (IRB)

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

Think aloud and related technique

เทคนิคคิดอะไรแล้วพูดที่บอกไป ด้วยบรรยากาศที่ไม่เป็นทางการเวลาพึมพำคนเดียว ทำให้เราได้ข้อมูลซ่อนเร้นออกมาได้ (แต่เสร็จแล้วก็ควรเรียกมาให้ comment แบบเป็นทางการนะ) เพื่อเสริมการ Think aloud อาจให้เทสทีเดียวสองคน จะได้บ่นใส่กันได้มากขึ้น

อีกเทคนิคคือ Retrospective[bg] think aloud คือทดสอบเสร็จแล้ว ค่อยถามว่า เนี่ยตอนทำอันนี้คิดอะไรอยู่เหรอ ข้อดีคือทำให้ได้คิดใช้สมาธิไปนึก ได้ผลแม่นยำ ข้อเสียคือ อาจจำไม่ได้

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

The spectrum of usability testing

หมายความว่า มันมีแบบไหนบ้าง เราอาจเทสเพื่อหาดีไซน์ที่ใช่ หรือเราอาจเทสเพื่อทดสอบดีไซน์ที่ทำเสร็จว่าดียัง ก็มีประเภทมาให้ดูดังนี้

  1. Paper mockups and prototyping เขียน UI บนกระดาษ และมีพนักงานคอยพลิกกระดาษเวลาจะเปลี่ยนจอ (เขาบอกว่าผู้ใช้เต็มใจจะคอมเม้นต์เวลาใช้กระดาษ มากกว่าเวลาสร้าง mockup บนจอคอม)
  2. Discount usability testing แปลว่า ตอนระหว่างทำ เราจะให้คนไม่มากมาเทส ‘Formative evaluation’ เพื่อหาจุดอ่อน แก้ไข UI ให้ดีขึ้่น เมื่อเสร็จแล้วเราจะให้คนจำนวนมากๆ(กว่าเดิม)มาทำ ‘Summative evaluation’ เพื่อดูความสำเร็จของผลิตภัณฑ์ (เช่น 80% ของผู้ทดสอบซื้อของเสร็จใน 4 นาที)
  3. Competitive usability testing เอาของคู่แข่ง/เวอร์ชั่นเก่า มาเทียบซะเลย
  4. Universal usability testing ให้คนหลายชาติ คนพิการ จอใหญ่ จอเล็ก เน็ตเร็ว เน็ตกาก ฯลฯ มาเทสทดสอบความ universal
  5. Field test and portable labs เอาไปทดสอบจริงข้างนอก ไม่ใช่ในห้อง ซึ่งต้องขนอุปกรณ์ record ต่างๆไปด้วย (จะดีมากถ้ามันเล็กลง)
  6. Remote usability testing เอาขึ้นเว็บให้เทสซะ ไม่ต้องเดินทางมา ได้คนหลากหลาย แต่จะตรวจวัดอะไรที่มันละเอียดอ่อนยากขึ้น
  7. Can-you-break-this test นำร่องโดยคนทำเกม ก็คือ ให้ผู้ทดสอบลองทำไงก็ได้ให้โปรแกรมมันพัง

ปล. ทั้งหมดนี่ผสมได้

ยังไง Usability testing ก็มีจุดอ่อนคือมันเป็นการใช้ครั้งแรก เราไม่รู้ว่าใช้จนชินแล้วจะเป็นแบบไหน (ต้องมี Expert review มาอุดจุดนี้) และการทดสอบนี้มันไม่อยู่ในสภาพแวดล้อมจริงที่ควรจะเป็น เช่นมือถือก็ต้องลองไปถือเดินดู โฮมเธียเตอร์ก็ต้องอยู่ในห้องนั่งเล่น จะสร้างสภาพแวดล้อมเสมือนจริงขึ้นมา ก็เปลืองเงินเกินไป และพวกถึงแก่ชีวิตอย่างขับเครื่องบินหรือผ่าตัด ยิ่งทดลองในแลปไม่ได้เลย

Usability test report

ประมาณว่ามันมีแบบฟอร์มอย่างเป็นทางการสำหรับผลของ Usability Testing ด้วยนะ

Survey Instruments

Preparing and designing survey questions

ก่อนจะทำแบบสอบถาม คิดวิธีวัดผลไว้ก่อนเลยไม่ว่าจะเป็น mean , SD , อื่นๆที่โหดกว่านี้ และคิดการนำเสนอด้วยว่าอาจเป็นกราฟแท่ง, กราฟพาย, scatter-plot และแน่ใจด้วยว่ากลุ่มคนที่ไปสำรวจนั้น ไม่ bias

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

อ้อ หลายๆคนชอบตอบแบบสอบถามสั่นๆ ออนไลน์ มากกว่าต้องเขียนบนกระดาษจริงแล้วต้องส่งคืนด้วย

คำถามควรเจาะจง มากกว่าถามความคิดเห็นโดยรวม เช่นถามไปเลยว่า ชื่อคำสั่งเข้าใจง่ายมั้ย หรือ Error message งงมั้ย

แถม นี่เรียกว่า Likert Scale → เห็นด้วยมากๆ โอเค เฉยๆ ไม่เห็นด้วย ไม่เห็นด้วยอย่างมาก

นี่เรียก Bipolar semantically anchored item → กาก 1 2 3 4 5 6 7 โหด

Sample questionnaires

เป็นชุดคำถามที่องค์กรใหญ่ๆคิดไว้ ตอนนี้หลายๆคนก็หยิบไปใช้กันเพราะมันดี อยากรู้ว่ามีไรมั่งก็ไปอ่านเอง อิ (หน้า 169)

Acceptance Test

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

สิ่งที่จะเป็นเกณฑ์ใน Acceptance Test ไม่ควรใช้คำกำกวมอย่าง “User Friendliness” แต่เอาคำที่เจาะจงอย่าง เวลาที่ต้องใช้ในการเรียนรู้โหมดนี้, Retention over time[bh] ของผู้ใช้, Subjective satisfaction, Rate of error ฯลฯ

ตัวอย่างครับ

“ผู้ร่วมทดสอบเป็นวัยรุ่นอายุ 25-45 มี 35 คน ต้องมีอย่างน้อย 30 คนที่ทำสำเร็จใน 30 นาที หลังจากนี้อีกสัปดาห์หนึ่งจะให้ผู้ทดสอบชุดเดิมมาอีกรอบ คราวนี้ ใน 20 นาที ต้องมีอย่างน้อย 8 คนที่ทำสำเร็จ”

เมื่อทำ Acceptance Test เสร็จ ส่วนมากก็จะทำ Field-testing ต่อเลย (ลงพื้นที่จริง)

ตอนนี้มีอะไรมั่งแล้วนะ : Expert Review, Usability Testing, Surveys, Acceptance Test, Field Testing พวกนี้ทำไวๆก็ดีจะได้มีเวลาแก้กัน

Evaluation During Active Use

ตรงนี้เราจะอุดจุดอ่อนที่ว่า ‘ใช้ไปนานๆแล้วเป็นไง’ กัน แน่นอนว่าเราทำให้ทุกคนพอใจไม่ได้ จำไว้

Interviews and focus-group discussions

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

Continuous user-performance data logging

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

สำคัญคือเรื่อง Privacy ต้องบอกด้วยว่าจะวัดอะไรเอาไปใช้ยังไง และจะไม่เอาข้อมูลส่วนตัวไป จะดีมากถ้าคนใช้ดูได้ด้วยว่าถูกเอาข้อมูลอะไรไปแล้วบ้าง ตัวอย่างก็เช่น Google Analytics ที่ทำกันมาแล้ว

Online or telephone consultants, e-mail, and online suggestion boxes

^ไม่มีอะไรจะบอกนอกจากหัวข้อแล้ว อ้อ โทรศัพท์น่ะน่าจะฟรีด้วย ถ้าฝั่งโน้นเห็นจอเราด้วยยิ่งดี คนใช้อุ่นใจว่า เขาจะพาเราไปถึงเป้าหมาย

Discussion groups, wiki, and newsgroup

เอาไว้เวลาผู้ใช้จะหาคนมีประสบการณ์มาคุยกันแต่ไม่รู้ว่าจะเอาใคร

Tools for automated evaluation

พวกโปรแกรมที่บอก memory หรือ RAM ที่ใช้อยู่ตอนนี้ หรือพวกที่รายงานว่าเขียนโปรแกรม error บรรทัดไหน หรือโปรแกรม log ข้อมูลต่างๆแล้วส่งผ่านเน็ตมาให้เราเลย นั่นแหละ อ่านเองถ้าสนใจ ปวดหัวขอข้าม (หน้า 178)


Controlled Psychologically Oriented Experiments

อ่านหัวข้อแล้วติดสตั๊น 5 วิ ก็ ติดต่อไป หัวข้อนี้จะพูดถึง การทดลอง ที่ควบคุมสุดๆ

Experimental approaches

เราจะประยุกต์การทดลองวิทยาศาสตร์เข้ากับ HCI กัน

มองปัญหา → โยงเข้าทฤษฎี → ตั้งสมมติฐาน → มองตัวแปรต้น,ตาม → เลือกผู้ทดสอบ และจัดเป็นกลุ่มๆ → ควบคุมปัจจัยที่ทำให้ bias → นำผลที่ได้ มาวิเคราะห์ทางสถิติ → แก้ปัญหาตอนแรกโดยอิงทฤษฏี และในที่สุดก็แนะนำว่าควรแก้อะไร

อย่างตัวแปรตาม ก็เป็น Error Rate, Retention over time แบบนี้ เอา HCI มาใช้กับวิทย์ (รายละเอียดในหัวข้อต่อไป)

ทำไมเราต้องมาทำ Controlled Experiment ขนาดนี้ด้วย ก็เพราะว่า เดี๋ยวนี้อุปกรณ์มันซับซ้อนขึ้นเรื่อยๆจนวัดขำๆไม่ได้แล้ว ต้องพึ่งวิทยาศาสตร์ หรือตลาดที่คู่แข่งสูงๆอย่าง มือถือ เราอาจทำการทดลองกับ On-screen Keyboard ว่าแบบไหนดีกว่ากัน ผลออกมาว่า Learning Time ลด 10 นาที ก็ทำให้ขายดีกว่าคู่แข่งแล้ว

Experimental design

เรามาออกแบบการทดลองเบื้องต้นกันเถอะ (จริงๆหัวข้อนี้ใหญ่มากเกินขอบเขตของหนังสือนี้) โดยเราจะเรียนรู้ศัพท์ต่างๆกันจากวิชาสถิติที่สายคอมไม่ได้เรียน

การเลือกคนมาเข้าการทดลองต้องเป็น Representative[bi] ของกลุ่มที่เราต้องการได้ ซึ่งก็จะมี Sampling Technique ต่างๆเพื่อเลือก ไม่ใช่สุ่มมา และไม่ควรมักง่ายเอา Convenience Sample อย่างพ่อ แม่ หรือเพื่อน มา เพราะอาจลำเอียงได้ จัดกลุ่มเข้าด้วยกันตาม Demographics[bj] ต่างๆ จะเลือกมาจำนวนแค่ไหนดีก็จะมี Confidence Level ว่าต้องเอาประมาณไหนถึงจะพอ

การออกแบบการทดสอบมีสองรสชาดให้เลือกคือ

Between-subjects : แต่ละกลุ่มค่อนข้างคล้ายกัน แต่ได้รับการทดสอบต่างกัน ต้องมีคนมากๆในแต่ละกลุ่มถึงจะดีเพื่อให้มั่นใจว่าในกลุ่มน่ะ มันคล้ายๆกัน เพื่อให้ผลการทดลอง ไม่เอนเอียงไปตามลักษณะของคนในกลุ่ม

Within-subjects : อันนี้ให้แต่ละคนทำการทดสอบอย่างเดียวกัน ใช้คนน้อย แต่ข้อเสียคืออาจเมื่อยล้า (ผลแย่ลง) หรืออาจเคยชินหรือเกิดความเชี่ยวชาญ (ผลดีขึ้น) เราต้องทำการ Counterbalance สิ่งที่ให้ทำโดยการจัดเรียงให้ดี เช่นถ้าเรากำลังวัด Ease-of-use อยู่ อันไหนที่ให้ทำก่อนมันจะยาก ไม่ได้ยากเพราะสิ่งที่ทำแต่ยากเพราะยังมือใหม่อยู่ อันหลังๆก็จะง่ายขึ้นเพราะชินแล้ว แบบนี้อาจวัด Ease-of-use ได้ไม่ตรงตามจริง

ประเภทของตัวแปร : Independent Variable หรือตัวแปรต้น ที่เราจะปรับค่า เช่นมีสองจอให้ลองใช้คืออันที่มีปุ่ม Help กับอันที่ไม่มี ส่วน Dependent Variable หรือตัวแปรตาม ก็เป็นผลจากตัวแปรต้น ส่วนมากอันนี้แหละที่เราจะวัดไปใช้กัน เช่น เวลาในการใช้, จำนวน Error, ความพอใจ ดังนั้นจุดสำคัญคือควบคุมดีๆ ให้ผลออกมาที่ตัวแปรตาม โยงไปสู่ตัวแปรต้นได้ว่า เนี่ย เพราะเปลี่ยนแบบนี้นะ ผลก็เลยกลายเป็นงี้ ไม่ใช่โดนตัวแปรอื่นๆที่ลืมควบคุมมารบกวนให้เรางงเล่น

นอกจากจะได้เป็นนักออกแบบ UI แล้ว ยังเป็นนักวิทยาศาสตร์ได้ด้วยนะเนี่ย



แปลหนังสือก็ จบลงตรงนี้แล้วล่ะ

ถ้าเข้ามาอ่านก็หวังว่าเพื่อนๆจะได้คะแนนเยอะๆกัน

แต่จะมีใครอ่านมาถึงตรงนี้มั้ยน้า

จะเหมือน blog ร้างที่เหมือนเขียนให้ตัวเองอ่านมั้ยน้า

เอาเถอะ อย่างน้อยก็ทำให้ไม่หลับเวลาอ่าน text ได้

แล้วก็ปี 4 แล้ว อยากจะทำอะไรเพื่อคนอื่นบ้าง

อีกซักครั้งหนึ่ง ก็ยังดี

โอกาสนั้นมันกำลังจะหมดไปในปีสุดท้ายนี้แล้ว

ก็เลยอยากลองแปลหนังสือนี้ดูเท่านั้นแหละ

ขอบคุณๆๆๆๆมากๆๆเลยสำหรับ doc นี้ ช่วยได้มากมายเลย ปายยย ^_____^//

…เก่งมากที่รัก thx naja…

V

V

V

ข้อสอบ final จากเว็บ อาจารย์

ข้อสอบปลายภาค วิชา 2044482 Human Computer Interaction

วันพฤหัสบดีที่ ๑ ตุลาคม พ.ศ. ๒๕๕๒ เวลา ๙-๑๒ น.

คำสั่ง : ข้อสอบมี ๗ ข้อ ข้อละ ๑๐ คะแนน ทำทุกข้อในสมุดคำตอบ

คำแนะนำ : อย่าพยายามใช้ common sense เพียงอย่างเดียว (แม้ว่าจำเป็นอย่างยิ่งที่ต้องใช้) ในการตอบคำถาม โปรดใช้หลักการและเหตุผลที่สนับสนุนแนวคิดของคุณ


  1. ภาควิชาวิศวกรรมคอมพิวเตอร์อยู่ในขั้นเริ่มต้นของระบบ webcast โดยนิสิตสามารถชมการบรรยายย้อนหลังได้ผ่านทางเครื่องพีซีหรือโน๊ตบุ๊ค แต่ก็เป็นที่ทราบกันว่ามีผู้ไปใช้ไม่มากนัก การลงทุนเพียงเท่านี้แม้จะได้ประโยชน์แต่อาจไม่คุ้มค่า คุณมีความคิดเห็นโดยใช้หลักการของ human computer interface อย่างไรต่อระบบ webcast ของภาควิชา จงอธิบายโดยชี้ให้เห็นถึงปัญหา และ ออกแบบวิธีการพร้อมเลือกเทคโนโลยีที่เหมาะสมในการปรับปรุง

คำตอบโดยเรียวและชาวแก๊งก์

Keyword : Video Search

ตอบ > ปัญหาที่พบคือ เวลาที่ผู้ใช้ต้องการค้นหาเนื้อหาที่บรรยายอยู่ในวีดีโอ แต่ไม่รู้ว่าเนื้อหาที่ต้องการนั้นอยู่

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

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

=============================================================================

  1. ในอนาคตอันไกลโพ้นภาควิชาวิศวกรรมคอมพิวเตอร์มีแนวคิดที่จะให้คอมพิวเตอร์มาแทนที่อาจารย์ในการให้ความรู้แก่นิสิต จงออกแบบ visualization ของการเรียนการสอนวิชา Human Computer Interaction ที่เหมาะสมสำหรับ นิสิตชั้นปีสี่สาขาวิศวกรรมคอมพิวเตอร์ และ นิสิตชั้นปีที่สองสาขาวิศวกรรมซอฟต์แวร์และความรู้ วิเคราะห์และเปรียบเทียบแนวคิดของผู้เรียนต่างกลุ่มนี้

Keyword : Visualization, universal usability

ตอบ > ออกแบบ >

ตามหลักการ visualization เริ่มแรกต้องแสดงภาพรวมของเนื้อหาที่จะเรียนก่อน โดยอธิบายว่ามีหัวข้ออะไรบ้างและแต่ละหัวข้อมีจุดประสงค์อะไร เมื่อเข้าใจภาพรวมแล้ว ก็จะค่อยๆเน้นไปที่เนื้อหาแต่ละหัวข้อ โดยมีการนำข้อมูลต่างๆที่จะสอนมาแสดงให้ชัดเจน โดยใช้ data type รูปแบบต่างๆตามความเหมาะสม เช่น 1D linear data คือการแสดงด้วยข้อความต่างๆ แต่มีการเน้นหัวข้อสำคัญ คำสำคัญโดยใช้สี ตัวหนา ตัวเอียง, 2D map data คืออาจจะเอาข้อมูลเช่น สถิติ ต่างๆ มาแสดงเป็นรูปแบบกราฟ 2 มิติ, 3D word data เอาพวกข้อมูลที่ซับซ้อนมากขึ้น มาแสดงเป็นกราฟ 3 มิติ หรือข้อมูลเช่น แผนที่ มาแสดงเป็น 3 มิติ มีเนื้อหาอย่างอื่นอีกพวก Multidimensional data, Temporal data, Tree data, Network data เป็นต้น

ในระหว่างการแสดงข้อมูลในเนื้อหาย่อยๆ ก็อาจจะมีการใช้หลักการ Related task มาใช้ได้ คืออาจจะมีการอ้างอิงเนื้อหาก่อนหน้ามาด้วย เพื่อให้เข้าใจได้ง่ายขึ้น

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

วิเคราะห์และเปรียบเทียบ > ภาษา / พื้นฐานความรู้

ต้องทำให้มีความ usability ด้วย เพราะ เป็นการสอนของนิสิต 2 กลุ่ม เช่นมี 2 ภาษาไทย อิ้ง

The Seven Basic Tasks

1. Overview Task การมองภาพรวมซึ่งแน่นอนต้องซูมออกมาเยอะๆ หรือทำ Fisheye

2. Zoom Task ซูมเข้าไปควรจะค่อยๆเข้าไปแบบนุ่มๆเพื่อให้รู้ว่าเปลี่ยนไปจากที่เดิมยังไง จะซูมโดยจิ้มที่ๆอยากเข้า หรือลาก Slider ก็ดี

3. Filter Task การกรองออกก็เช่นการทำ Dynamic Query ในบทที่แล้ว DM DM DM

4. Details-on-demand Task ถ้าอยากได้ข้อมูลของสิ่งนั้นๆส่วนมากเขาก็ทำให้คลิกแล้ว pop up เป็นหน้าใหม่ขึ้นมา ในกล่อง pop up อาจมี link ต่อไปอีกก็ได้นะ (เช่นคลิกจังหวัด)

5. Relate Task เช่นผู้ใช้คงอยากลองดูๆว่ากราฟนี้มีกลุ่มนี้ใกล้กันนะ หรือทำไมตรงนี้สีแดงเยอะจัง เชื่อมโยงตีความด้วยการกวาดตา เพราะงั้นเวลา Visualize ก็ใช้สีใช้อะไรให้ผู้ใช้สามารถ Relate ได้ง่ายๆด้วย

6. History Task เช่นผู้ใช้อาจอยากย้อนไปย้อนมาเพื่อลองทางใหม่ แน่นอนสิ่งที่นักออกแบบอย่างเราต้องทำคือ ระบบ Undo

7. Extract Task เช่นผู้ใช้คงจะอยากได้ผลลัพธ์แบบเซฟเป็นไฟล์ออกมา ก็จัดให้ซะ

=============================================================================

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

ตอบ part 1 > วิธีการวัดคุณภาพของซอฟท์แวร์มีหลายแบบ เช่น การใช้หลักการของ expert review โดยให้ผู้วัดคุณภาพเปรียบตัวเองเสมือนเป็นนิสิต ซึ่งมีทั้งการยึดหลัก Eight Golden Rule มาวิเคราะห์ การดูว่าตรงตาม guideline ที่มีหรือไม่ การลองทำตัวเป็นผู้ใช้ประเภทต่างๆ เป็นต้น

นอกจากนี้ยังมีการวัดคุณภาพแบบ Usability testing เช่น เปิดให้ผู้ใช้จริงมาลองใช้งานโปรแกรมและส่ง feedback กลับมา หรือลองทำ prototype ให้ลองใช้ก่อน ซึ่งทำตาม The spectrum of usability testing เช่น Competitive usability testing คือการเอาของคู่แข่ง/เวอร์ชั่นเก่า มาเทียบซะเลย หรือการใช้ Can-you-break-this test นำร่องโดยคนทำเกม ก็คือ ให้ผู้ทดสอบลองทำไงก็ได้ให้โปรแกรมมันพัง

ตอบ part 2 > คิดว่าน่าจะเป็นเว็บ regis.ku.ac.th (น่าจะหมายถึงให้วิเคราะห์ QoS)

ในส่วนของเรื่อง response time พบว่าเว็บมีการตอบสนองได้ค่อนข้างรวดเร็วดี และเนื่องจากเนื้อหาส่วนใหญ่ในเว็บนั้นเป็น text จึงทำให้ response time น้อย มีการใช้ Delay Masking โหลด text ก่อน โหลดรูป เพื่อไม่ให้ response time นานเกินไป

และเนื่องจากหน้าเว็บมีเนื้อหาเยอะเกินไป ทำให้ผู้ใช้ใหม่ต้องใช้ think time มาก ในการจะเลือกกดปุ่มครั้งต่อไป

Keyword : part1 >Evaluating interface Design, expert review, eigth golden rule, usability testing

part2 > QoS,respone time , user think time, delay masking

QOS คือคุณภาพของการให้บริการ มี 2 อย่างที่ถ่วงกันอยู่ก็คือ ความเร็ว และความถูกต้อง แน่นอนถ้ายิ่งมีความเร็วมากก็ยิ่งมีโอกาสผิดพลาดมาก แต่ถ้าช้าหน่อย ถึงแม้จะผิดพลาดน้อยแต่คนใช้ก็อาจจะเซ็งได้ ดังนั้นต้องหาจุดที่สมดุลที่สุด ส่วนสำคัญที่จะวัดความเร็วได้ก็คือ Response time อาจจะได้มาจาก Response time, User think time, Waiting time

ัดคุณภาพโดยการใช้หลัก Expert Reviews ทำตามขั้นตอนต่างๆดังนี้

Heuristic evaluation ผู้เชี่ยวชาญหยิบเอาหลักการอย่างEight Golden Rules มาไล่เช็คทีละข้อๆ ถ้าเป็นเกมก็จะมีหลักเช่น ต้องปรับระดับเสียงได้ ต้องข้ามฉากซ้ำๆได้

Guidelines review ผู้เชี่ยวชาญจะหยิบ guideline ของเรามาอ่านให้เข้าใจ แล้วมานั่งดูว่าพลาดตรงไหนบ้าง (ต้องให้เวลาเขาอ่านด้วย)

Consistency inspection ตรวจทั้งของโปรแกรมและ documentation ต่างๆด้วย

Cognitive walkthrough สวมบทเป็นผู้ใช้หลายๆสถานการณ์แล้วลองใช้ดู

Metaphors of human thinking (MOT) ปรับจิตลองนึกดูว่า ถ้าผู้ใช้มาใช้จริงจะรู้สึกยังไง (รู้สึกจะเก่งจัง ไอ้ Expert เนี่ย)

Formal usability inspection ผู้เชี่ยวชาญเรียกทุกคนมาเปิดประชุม เสนอจุดอ่อน และถกเถียงกันอย่างดุเดือด

Eight Golden Rules ได้แก่

  1. Strive for consistency ความถูกต้องตรงกัน… (consistency= ประมาณว่าจะใช้คำว่า Insert แล้วก็อย่ามาใช้คำว่า Add / คำย่อ ขนาดอักษร สี อื่นๆ ต้องคงที่ )
  2. Cater to universal usability ทำให้ใช้ได้กับคนทุกเพศ ทุกวัน ทุกสถานะ ทุกเชื้อชาติ แม้แต่คนพิการ
  3. Offer informative feedback เมื่อผู้ใช้ทำอะไรก็ต้องมี feedback ที่ดี
  4. Design dialog to yield closure อันนี้ก็คือ action ที่ต่อเนื่องกันนั้นมีจุดจบที่ชัดเจน เช่นซื้อของผ่านเน็ตพอเสร็จถึง checkout ก็จะพบหน้ายืนยันว่าซื้อเสร็จแล้ว
  5. Prevent error เช่นอันไหนใช้ไม่ได้ก็ทำเป็นสีเทาๆให้คลิกไม่ได้ หรือใส่รหัสไปรษณีย์ผิดก็ให้แก้ตรงนั้นไม่ใช่ลบออกให้พิมพ์ที่อยู่ใหม่ด้วย
  6. Permit easy reversal of actions ก็คือ undo ได้เยอะๆ
  7. Support internal locus of control ผู้ใช้เก่งๆเชื่อว่าเขาเป็นคนควบคุม interface ได้ดั่งใจ พวกเขาไม่ชอบการเปลี่ยนแปลงสิ่งที่คุ้นเคยแล้ว
  8. Reduce short-term memory load ก็คืออย่าให้จำ เหมือนเดิม

The spectrum of usability testing

หมายความว่า มันมีแบบไหนบ้าง เราอาจเทสเพื่อหาดีไซน์ที่ใช่ หรือเราอาจเทสเพื่อทดสอบดีไซน์ที่ทำเสร็จว่าดียัง ก็มีประเภทมาให้ดูดังนี้

  1. Paper mockups and prototyping เขียน UI บนกระดาษ และมีพนักงานคอยพลิกกระดาษเวลาจะเปลี่ยนจอ (เขาบอกว่าผู้ใช้เต็มใจจะคอมเม้นต์เวลาใช้กระดาษ มากกว่าเวลาสร้าง mockup บนจอคอม)
  2. Discount usability testing แปลว่า ตอนระหว่างทำ เราจะให้คนไม่มากมาเทส ‘Formative evaluation’ เพื่อหาจุดอ่อน แก้ไข UI ให้ดีขึ้่น เมื่อเสร็จแล้วเราจะให้คนจำนวนมากๆ(กว่าเดิม)มาทำ ‘Summative evaluation’ เพื่อดูความสำเร็จของผลิตภัณฑ์ (เช่น 80% ของผู้ทดสอบซื้อของเสร็จใน 4 นาที)
  3. Competitive usability testing เอาของคู่แข่ง/เวอร์ชั่นเก่า มาเทียบซะเลย
  4. Universal usability testing ให้คนหลายชาติ คนพิการ จอใหญ่ จอเล็ก เน็ตเร็ว เน็ตกาก ฯลฯ มาเทสทดสอบความ universal
  5. Field test and portable labs เอาไปทดสอบจริงข้างนอก ไม่ใช่ในห้อง ซึ่งต้องขนอุปกรณ์ record ต่างๆไปด้วย (จะดีมากถ้ามันเล็กลง)
  6. Remote usability testing เอาขึ้นเว็บให้เทสซะ ไม่ต้องเดินทางมา ได้คนหลากหลาย แต่จะตรวจวัดอะไรที่มันละเอียดอ่อนยากขึ้น
  7. Can-you-break-this test นำร่องโดยคนทำเกม ก็คือ ให้ผู้ทดสอบลองทำไงก็ได้ให้โปรแกรมมันพัง

=============================================================================

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

Keyword : User Document & online help

ตอบ >

– ทำในรูปแบบ online document เพื่อให้สะดวกในการเข้าถึง ดูได้จากทุกที่ทุกเวลา อัพเดทได้ง่าย

- ใช้ภาพเข้ามาช่วยในการอธิบาย (visualization) เช่น เรื่องรูปการแต่งตัวให้ถูกกฎระเบียบ แทนที่จะเขียนเป็นข้อความบอกอย่างเดียว ก็ใช้รูปสื่อ เช่นเป็นภาพเปรียบเทียบระหว่าง นิสิตที่แต่งดึวถูกกันิสิตที่แต่งตัวผิด หรือเรื่อง ห้ามลอกข้อสอบ

- มีสารบัญ > มีแถบ menu อยู่ทางซ้ายมือให้ผู้ใช้สามารถกดข้ามไปยังกฎข้อต่างๆได้

- ใช้ Context-sensitive help แบบที่ผู้ใช้เรียกขึ้นมา (User-initiated)

- จัดการกับ Special populations โดยใช้หลัก universal usability เช่นจัดทำเป็น 2 ภาษา ไทย และ อังกฤษ เป็นต้น

- มี FAQ พวกคำถามที่มีคนถามมาบ่อย

- อาจทำให้ค้นแบบ Natural language ได้ พิมพ์เป็นภาษาพูดเข้าไปเลย

- มีการจัดหมวดหมู่ของกฎต่างๆขึ้นมา เช่น กฎหรือข้อห้ามที่สำคัญ,,,

  1. Online: ดีตรงที่ ค้นหาง่าย ถูก ไม่เปลืองทรัพยากร แต่ อ่านยาก
  2. paper: อ่านง่าย ค้นหาอะไรยาก เปลืองทรัพยากร
  3. คนพัฒนาต้องเป็นคนเขียนเอง ไม่ใช่ให้คนอื่นเขียนให้
  4. มีหลายรูปแบบ อาจจะเป็น Minimal manual เหมือนพาดูคร่าวๆให้มือใหม่
  5. originalization คือเขียนปกติ ให้คำนึงถึงสิ่งที่ผู้อ่านอยากได้ อย่าลืมคิดถึงความรู้ ณ ตอนนั้นของผู้อ่านด้วย ไม่ควรอ้างถึงอนาคต

=============================================================================

  1. เนื่องจากว่าเครื่องพีซีในปัจจุบันมีแฟ้มข้อมูลอยู่จำนวนมาก ทำให้ยากต่อการจัดหมวดหมู่ และการสืบค้น โดยทั่วไปสำหรับโน๊ตบุ๊คมีความจุฮาร์ดดิสก์ 80 GB และมีแฟ้มข้อมูลมากกว่า ๑ ล้านแฟ้ม และมีการกระจายของขนาดแฟ้มเป็นแบบ normal

จงออกแบบ ระบบสืบค้นแฟ้มข้อมูลในเครื่องพีซีส่วนบุคคล ซึ่งสามารถค้นข้อมูลจากชื่อแฟ้มและสาระในตัวแฟ้ม

Keyword : Information Search,five stage framework

ตอบ[bk] > ใช้หลัก five stage frameworkในการออกแบบ ดังนี้

Formulation ควรมีการกำหนดว่าจะให้ค้นหาเฉพาะไฟล์ประเภทใด ชื่อแฟ้ม หรือ สาระในตัวแฟ้ม

Initiation of actionมีปุ่มกด search (explicit)

Review of resultsสามารถกด sort ข้อมูลที่ค้นมาได้

Refinementมีการเดาสิ่งที่ใกล้เคียงกับที่ค้น เพื่อสะดวกในกรณีที่อาจจะพิมพ์คำค้นผิด

Use อาจมีระบบ Export ไปเข้าโปรแกรมอื่น หรือเซฟเก็บไว้ได้

Five-stage Framework’ ได้แก่

Formulation : หาอะไร – ควรมีโหมดการกำหนด fields ว่าหาจากอะไร (ไม่ใช่หาจากทั่วโลกไปเลย) ทำให้รับ phrases ได้เช่นเซิจชื่อคนก็จะไม่แยกชื่อนามสกุลออกจากกันและรองรับ varient เพื่อรองรับผู้ใช้ที่ไม่รู้ว่าจริงๆต้องพิมพ์ว่าอะไร (teach → teach,teacher,teaches,teaching,teach ภาษาอื่น)

Initiation of action : กดหา – ก็คงต้องมีปุ่มเซิจ แต่บางทีให้พิมพ์ๆไปหรือปรับ Filter แล้วผลออกมาเลยก็ได้นะ (แบบ implicit ซึ่งตรงข้ามกับ explicit ซึ่งเรากดปุ่มเอง)

Review of results : ดูผล – ผลออกมาก็น่าจะปรับจำนวนผลการค้นหาต่อหน้าได้หรือ Sort ตามอะไรต่างๆได้ (อย่าคิดถึงภาพ Google อย่างเดียวนะ ค้นอย่างอื่นก็มี) หรือจัดกลุ่มด้วยตนเอง

Refinement : คิดขั้นต่อไป – หน้าต่างอาจบอกว่า Did you mean… หรือการเก็บการเซิจเก่าไว้ให้ Reuse ได้ หรืออะไรอื่นๆก็ได้ที่ทำให้ผู้ใช้เซิจครั้งต่อไปได้ดีขึ้น

Use : นำมาใช้ – อาจมีระบบ Export ไปเข้าโปรแกรมอื่น หรือเซฟเก็บไว้ได้

=============================================================================

  1. จงออกแบบ ส่วนเชื่อมต่อผู้ใช้สำหรับตู้เสื้อผ้า โดยแนวคิดการออกแบบจะต้องมีเรื่องของ QOS, Balancing function and fashion, user documentation and online help, information search และ information visualization

ตอบ > มีจอ touch screen เป็นส่วนเชื่อมต่อระหว่างตู้เสื้อผ้ากับผู้ใช้่

QOS – จัดเก็บเสื้อผ้าเป็นหมวดหมู่ เช่น แยกกางเกงไว้ด้วยกัน เสื้อไว้ด้วยกัน หรือเสื้อผ้าที่เข้าชุดกันวางไว้ด้วยกัน (relate task)/ มี db เก็บเสื้อผ้าไว้ และก็ match ให้ ทำให้ respone time น้อย

– ออกแบบ UI ของ จอ touch ให้ดี วางรูปแบบดีๆ หรือมีระบบช่วยเลือกเสื้อผ้าที่เข้าชุดกัน หรือเสื้อผ้าสำหรับงานต่างๆ เช่น ชุดไปงานศพ ก็จัดเป็นชุดมาให้เลย ช่วยให้ผู้ใช้ไม่่ต้องเลือกเอง ประหยัดเวลา จะช่วยทำให้ user think time น้อย

Balancing function and fashion, >ข้อมูลบนหน้าจอไม่ควรเยอะเกินไป การใช้สี ตัวอักษรควรจะ consistency

user documentation and online help, > มี online tutorial เพื่อสอนผู้ใช้ให้รู้จักกับ ui นี้ในครั้งแรก ใช้หลัก minimal manual พาลุยไปเลยครั้งแรก

information search > ค้นหาตามประเภทของเสื้อผ้า

information visualization > แสดงภาพเสื้อผ้าเป็นภาพ หรือ โมเดลสามมิติและมีภาพของผู้ใช้ที่ใส่เสื้อผ้านั้นๆ ให้เห็นโดยไม่ต้องเอาออกมาลอง

Keyword : QOS, Balancing function and fashion, user documentation and online help, information search และ information visualization


อีกสักฉบับ

Final Exam: Computer Human Interfaces 1/2010 (CPE)

Instructions

  1. Write your answer in either Thaior English.
  2. Closed book!
  3. Closed note!
  4. There are 8 questions. Each has 10 scores. Answer all questions in given exam booklets. Do them all. (totally, 40% of the class evaluation)

Guidelines for answering the questions

  1. You obviously need your common senses to answer the exam. However, even though you have a good one, it is not enough to get scores.
  2. References, evidences, causes, rules, laws, theories, and your justifications are supposed to be mentioned.
  3. Any design scripts without good explanation will not get good scores.
  4. You should include an example as part of your answer in an appropriate application of your choice (if not specified).
  5. Read the question carefully!

Exam

  1. Information search is one of the most important parts of websites. Explain the general framework of the search mechanism.

ตอบ > Five-stage Framework’ ได้แก่

Formulation : หาอะไร – ควรมีโหมดการกำหนด fields ว่าหาจากอะไร (ไม่ใช่หาจากทั่วโลกไปเลย) ทำให้รับ phrases ได้เช่นเซิจชื่อคนก็จะไม่แยกชื่อนามสกุลออกจากกันและรองรับ varient เพื่อรองรับผู้ใช้ที่ไม่รู้ว่าจริงๆต้องพิมพ์ว่าอะไร (teach → teach,teacher,teaches,teaching,teach ภาษาอื่น)

Initiation of action : กดหา – ก็คงต้องมีปุ่มเซิจ แต่บางทีให้พิมพ์ๆไปหรือปรับ Filter แล้วผลออกมาเลยก็ได้นะ (แบบ implicit ซึ่งตรงข้ามกับ explicit ซึ่งเรากดปุ่มเอง)

Review of results : ดูผล – ผลออกมาก็น่าจะปรับจำนวนผลการค้นหาต่อหน้าได้หรือ Sort ตามอะไรต่างๆได้ (อย่าคิดถึงภาพ Google อย่างเดียวนะ ค้นอย่างอื่นก็มี) หรือจัดกลุ่มด้วยตนเอง

Refinement : คิดขั้นต่อไป – หน้าต่างอาจบอกว่า Did you mean… หรือการเก็บการเซิจเก่าไว้ให้ Reuse ได้ หรืออะไรอื่นๆก็ได้ที่ทำให้ผู้ใช้เซิจครั้งต่อไปได้ดีขึ้น

Use : นำมาใช้ – อาจมีระบบ Export ไปเข้าโปรแกรมอื่น หรือเซฟเก็บไว้ได้

  1. How can we search information of multimedia documents? What are the challenges?

ตอบ > เพราะมันยากกกก กว่าการ search ที่เป็น text ธรรมดา คือ เราสามารถ

- search ด้วยรูปภาพ เพราะไม่รู้ว่ามันจะถ่ายรูปมามุมไหน มีหลายๆที่ลักษณะคล้ายๆกัน เช่น สี รูปร่าง

- ค้นหาใน map เพราะจุดแต่ละจุดใน map นั้นมีข้อมูลหลากหลาย,,,

- ค้นหาด้วยdesignของสิ่งของต่างๆเช่น ขนาด ลักษณะ เป็นต้น

- การค้นหาจากเสียง เช่น ร้องเพลงเพื่อค้นเพลง ยากเพราะต้องนำคลื่นเสียงตัวอย่างไปหาในคลื่นเสียงแต่ละอันที่มีอยู่ในฐานข้อมูล

- ค้นหาฉากในวิดีโอ ยาก เพราะ ไฟล์รูปแบบวีดีโอ เป็นไฟล์ที่มีความต่อเนื่อง นอกจากนี้ยังมีทั้งรูปภาพและเสียงใน ไฟล์เดียว การที่จะค้นหาด้วย วีดีโอจึงต้อง map ทั้งรูป ทั้งเสียง ให้ตรงกับช่วงเวลานั้นๆ,,,

- Animation search (ไฟล์ที่มีการเคลื่อนไหว ,ใช้ท่าทางในsearch) ยากเพราะ เราต้องตรวจสอบว่ามันมันเคลื่อนไหวยังไง

multimedia document

Image Search : ระบบอาจ Image Pro ดูภาพว่ามีชิ้นส่วนอะไรยังไงซึ่งยากเพราะไม่รู้ว่ามันจะถ่ายรูปมามุมไหน ง่ายกว่าคืออาจให้ผู้ใช้ Mark ส่วนสำคัญต่างๆเองได้ เช่นการ Tag รูปถ่ายว่าคนนี้อยู่ตรงไหน ต่อไปมันก็จะรู้ได้เอง

Map Search : เดี๋ยวนี้ก็เซิจได้หมดแล้วเพราะข้อมูลต่างๆฝังอยู่ในแผนที่เช่นจำนวนประชากรหรือระยะห่าง

Design or Diagram search : เช่นหาพาดหัวข่าวที่พาดหัวกว้างเท่าหน้ากระดาษ fหรือหามอเตอร์ที่รูน๊อตเล็กกว่า 6 cm

Sound Search : เช่นร้องเพลงหรือใส่ไฟล์เสียงเข้าไปแล้วหาให้ได้ หรือหาคำๆนึงว่าอยู่ในเพลงไหน (เทพ)

Video Search : นอกจากจะไล่หาทุก Frame แล้วยังควรแบ่งเป็นซีนๆให้ด้วย หรือเซิจจากคำพูดที่คนในวิดิโอพูดกัน (ซึ่งแปลงเป็น Text แล้ว)

Animation Search : เช่นหาว่าอะไรหมุนๆมั่งใน Flash (…เพื่ออะไรฟะ)

  1. What parts of DBMS play an important role in information search? And, what parts they cannot do?

ตอบ >DBMS คือ Database Management System หรือระบบจัดการฐานข้อมูล ระบบนี้สามารถช่วยให้การค้นหาข้อมูลประเภท text หรือข้อความได้ง่ายขึ้น

สามารถหาสิ่งที่อยากรู้ได้ เช่น ถ้าข้อมูลต่างๆนี้มีในฐานข้อมูล ก็จะสามารถทำให้ค้นหาได้,

หาแบบ มีหรือไม่มี ไม่ได้ตอบว่ามี หรือไม่มี แต่ถ้ามีจะคืนค่าสิ่งที่เราต้องการหามาให้ ถ้าไม่มีก็ไม่คืนค่า,

สามารถหาแบบต่อยอดได้ ถ้ามีการเชื่อมโยงข้อมูลต่างๆใน db ไว้ก็สามารถทำได้ หรือมีข้อมูลประเภท

แต่จะไม่สามารถการหาแบบปลายเปิดได้ นั่นคือ db จะไม่สามารถให้ความคิดเห็นต่างๆได้

keyword> information search, multimedia document searches, multilingual search, ….

  1. What are the challenges for information visualization?

ตอบ >

Challenges for Information Visualization

เข้าใจปัญหาแบบต่างๆกันแล้วแต่ก็ยังมีความท้าทาย :

● แค่ข้อมูลนำเข้าก็หืดขึ้นคอแล้วเพราะต้องมาจัดเรียงให้เข้ากับโปรแกรมเราก่อน

● บางทีวาดภาพมาสวยงามแล้ว ยังคงต้องมีตัวอักษรประกอบอีก ต้องไม่รกด้วย

● ผู้ใช้อยากได้ข้อมูลที่เกี่ยวข้องจากหลายๆแหล่ง คุณสามารถหามาประเคนให้เขาได้มั้ย

● ข้อมูลเยอะโคตรๆ เป็นภาพแล้วดูไม่รู้เรื่องเลย

● เราใส่ Data Mining เข้าไปร่วมแจมด้วยได้มั้ย พลังของ Visualization

ทำให้ค้นพบแนวโน้มใหม่ๆ (ด้วยตา) ส่วน Data Mining

ก็ทำให้พบคู่น่าสนใจที่เคลื่อนไปทางเดียวกัน มีทั้งสองอย่างคงเข้าขากันดีไม่น้อย

● เชื่อมต่อเข้ากับเครื่องมือ Decision Making ด้วย ครบเครื่องเรื่องธุรกิจไปเลย

● ช่วยกันดูกับเพื่อนได้ เช่นเซฟ State แล้วส่งให้เพื่อนช่วยวิเคราะห์

● UNIVERSAL USABILITY!! แต่ไม่ต้องถึงขั้นคนตาบอดก็ได้ (จะเห็นอะไร)

● ต้องกลับมาทบทวนได้ เพราะกว่าจะเห็นอะไรจากภาพมันต้องใช้เวลา… อาจเป็นเดือน!

  1. Supposedly, you are an academic adviser of KU. You have to supervise many students who may take different courses, get different grades, and stay in different statuses (normal, probation, retried, possibly honors, graduated, graduated with honor). Design information visualization system in order to ease the supervising task for you (as an adviser.)

key word : 1D linear data, color coding,visualization

ตอบ > แสดงในรูปแบบ 1D linear data

โดยเก็บข้อมูลในรูปแบบตาราง มีการใช้ color coding เข้ามาช่วย เช่น ช่องที่บอกเกรดก็เป็นสีเดียว ช่องบอกวิชาก็เป็นสีเดียวกัน

ID

status

course

Grade

555555555

เด็กดี

204111

A

204112

B

204113

F

  1. If you have to design a cell phone, explain the impact of response time to the design of user interface and the satisfaction of users’.

ตอบ [bl]> response time คือเวลาในการตอบสนองเมื่อผู้ใช้เลือกการทำงานต่างๆ สำหรับการใช้งาน cell phone ควรออกแบบให้การกดปุ่มต่างๆ สามารถตอบสนองได้เร็ว การเปลี่ยนหน้าต่าง เปลี่ยนโปรแกรม ก็ควรใช้วิธีการที่่ง่ายและรวดเร็วที่สุด เพราะหากการใช้งานพื้นฐานเหล่านี้มี response time ที่สูง ก็จะส่งผลให้ผู้ใช้เกิดความเซ็งได้ นอกจากการใช้งานพื้นฐานเหล่านี้แล้ว การปลดล็อคหน้าจอหรือปุ่ม ก็ควรออกแบบให้สามารถตอบสนองได้เร็วเช่นกัน แต่การใช้งานบางอย่าง ก็ควรมี response time ที่เหมาะสม เช่น การกดปุ่มค้างเพื่อเปิดหรือปิดเครื่อง ควรจะมี response time ประมาณหนึ่ง

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

  1. Design a job resume for yourself in order to get a position of a computer engineer. Make a good field layout and write excellent resume content. Explain what your future boss will think about your resume. You can put false (looks likely to be true) information in order to make your resume look very attractive but you have to underline it.

ตอบ > ใช้หลัก display design มาช่วย เรื่องการจัด field layout, empirical result

– ออกแบบ

Resume – Computer Engineer

Steve James

2230, 173, East Coast,

NY 228978

Home: 111-111-1111

Cell: 222-222-2222

Email: (include Email Address)

________________________________________________________________________

Have excellent technical skills, communication skill, and goal-focused professional offering 9 years of experience in Computer industry. I am motivated and enthusiastic by new challenges and tasks and take excellent approach to achieve success in all projects. I like to work in a complex projects which have scope for learning and challenge. I have experience in working with different operating system and platforms namely Windows, UNIX, Linux and Dos. Have expertise various quality process and techniques by which I efficiently took care of quality deliverables of myself and my team which helped in gaining satisfied customers for the organization.

Objective:

To take a challenging and high performance oriented role in the field of Computer enginnering and implement the expertise and experience gained in this field to develop complex project with efficiency and quality.

Education:

  1. BS, Computer engineering, University of Pheonix, NY,1996
  2. MS, Computer engineering, University of Georgia,1998

Professional Certification:

  1. MCSE Certified,1998

Technical Skills:

vLanguages: C, C++, Java, .NET, JavaScript, PHP, HTML, CSS, JAVA Proxy, JDK, SERVLET

vDatabases: MySQL, Oracle, Access, DB2

vOperating System: UNIX, Linux, Windows, DOS

vDesign: UML

vHave sound knowledge in networking protocols and device programming.

vHave experience in working with C and C++ compiler programming and system level

vprogramming

Strengths:

ØExcellent Communication skill to present points precisely and clearly

ØGood problem solving ability and analytic skill to solve the problem efficiently

ØGood team player and have excellent interaction skill to coordinate and work within a

Øteam

ØExcellent Technical Skill

ØHave expertise in working with various operating systems

ØGood deliver output in less time without losing efficiency

Work History:

Senior Software Engineer Nov 2005 – Till Date

Pacific Land Inc, Ny

Responsibilities:

I was responsible for system designing, code review and test review. I managed production support issues and assigned to developers and monitored that they are resolved efficiently and closed on time. Apart from this I also took the task of writing complex programs or modules. In this context I have written many utility programs. I also took the responsibility of imparting training to new team members as assigned by project manager of my project. I involved in all levels of testing from unit level of testing to integration testing and took care that the final product is delivered with good quality and efficiency to project manger and thereby to customers.

System Analyst Apr 2002 – Nov 2005

PrintWall Inc, NY

Responsibilities:

As a System Analyst I involved in analyzing the requirements of customer by visiting their place and prepared the requirement specification in detail. My communication skill was excellent which helped in presenting and communicating my views in precise and clear way to client and hence could get satisfied customers for the organization. I also analyzed the technical requirements and details required for developing the system and proposed solutions for implementing the same. I worked with major insurance and banking client and therefore expertise the business details of insurance and banking sectors in depth.

Systems Engineer Dec 2001 – Apr 2002

ABC Inc, NY

Responsibilities:

I worked in system programming using C and C++ programming language. I had sound knowledge in networking protocols and device programming which helped to develop modules as the projects developed for the organization were on this line. I used my excellent analyzing ability for analyzing the existing business requirements and proposing new solutions for the problem. I also involved in production support for maintaining the system developed and resolved the complexities and bugs raised by customers efficiently and effectively on time. I also took the task of standardizing the maintenance process which helped in maintenance of documents and process for further reference.

Developer Jun 1999 – Dec 2001

LogSeries Inc, NY

Responsibilities:

I worked in this organization as a developer in UNIX operating system. I took the task of developing the design given to me and ensured that the final products matched the quality standards. I attended the extensive training program given about quality standards namely ISO and CMM level. C and C++ are the two programming language I made use of in depth to carry out the development process.

Software Developer May 1998 – Jun 1999

Spyware Inc, NY

Responsibilities:

Apart from developing in Java in UNIX environment there are numerous other tasks I involved in the project namely documenting as per quality standards and unit level testing for which I prepared test plan and test cases. I also attended team meeting conducted by project lead and project manager at regular intervals.

– บอสจะคิดยังไงกับ resume ของเรา

Computer Engineer is involved in various tasks of computing like designing, programming related to software and also tasks with respect to hardware. So it is vital that they have proper blend of sound knowledge on both areas. Computer engineers take part in challenging and critical projects and must have the ability to work on a broad range of technologies in diversified critical project areas. For achieving a sound result on the above it is vital that the computer engineers must possess an in-depth knowledge on their subjects. It is also essential that they possess excellent communication and written skills to present their points precisely and clearly to clients and team mates. They should also be open minded and must have good interaction abilities to move in a team and get the work done efficiently.

key word : Balancing Function and Fashion, display design

Display Design

รูปลักษณ์ก็ทำให้คนใช้พอใจได้ เราต้องรวมศาสตร์และศิลป์เข้าด้วยกัน

Field layout

เราต้องใช้การ Tab, เว้นวรรค, จัด Column มาช่วย และอย่าลืมเรื่อง Label ประกอบข้อมูลเช่น First Name : SUSAN TAYLOR สังเกตุว่า Label มีทั้งพิมพ์ใหญ่เล็กเพื่อให้ดูแยกออกจากข้อมูลได้ อาจผสมตัวหนาเข้าไป หรือตีกรอบเพื่อจัดกลุ่มก็ได้ (แต่เสียพื้นที่) โดยเฉพาะ วันที่ ควรจะมี Label อย่างยิ่งเพราะคนละประเทศก็เรียงวันเดือนปีต่างกันแล้ว

Empirical results

มาดูตัวอย่างจากทั่วโลกกัน

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

อีกอันเป็น Guidelines จากคนทำเว็บบอกว่าเราควรจัดกลุ่มอะไรที่เกี่ยวข้องกันเข้าด้วยกัน ด้วยสี พื้นที่ ความสว่าง ที่เหมือนๆกัน (consistent) ทำให้คนใช้สืบ/จำข้อมูลได้ไวมาก

  1. In class, you have experience in mocking up your only own design (such as keyboard) and building only familiar scenarios (such as university registration). If you are an engineer who is assigned to design a user-interface of an information system that you have never had experiences before, what you would make your own project is successfully done and how you would assess the project results.

ตอบ[bm] > เนื่องจากเราไม่มีประสบการณ์ เลย ต้องทำตาม 4-Pillar of Design นั่นคือ

– ออกไปสำรวจความต้องการของผู้ใช้

– ทำตาม guildline

– ใช้เครื่องมือสร้างmock up / prototype เพื่อให้ลูกค้าดูตัวอย่างก่อน

– ปล่อยให้ผู้ใช้ลองใช้และ feedback กลับมา

key word : Four Pillar of Design

สิ่งที่จะได้ →

U

I

ที่

สุดยอด

ต้องทำ →

UI Requirement

Guidelines ต่างๆ

เครื่องมือช่วยสร้าง UI

รีวิว

ทำไง →

ออกไปสำรวจสิ

มาจากทฤษฎี

ทำ prototype

การทดลอง

เริ่มมาจาก →

งาน

วิจัย

ต่าง

ต่าง

เสา 1 : User interface requirement

ก่อนจะออกแบบก็ไปดูก่อนว่าลูกค้าต้องการอะไร ต้องตกลงกันหมดทั้งทีมตั้งแต่ก่อนเริ่มโปรเจคแล้วว่าฮาร์ดแวร์ที่จะทำ UI ลงมีสเปคยังไง ต้องทำอะไรได้มั่ง input output อะไร คุยให้เรียบร้อย

ตัวอย่าง Req. ที่ผิด : ผู้ใช้ต้องตัดสินใจว่าจะถอนเงินเท่าไหร่ใน 5 วิ

ตัวอย่าง Req. ที่ถูก : ระบบจะให้เวลาผู้ใช้ 5 วิเพื่อเลือกจำนวนเงินที่จะถอน

ถ้าถามว่าทำไงจะรู้ว่าผู้ใช้อยากได้อะไร เราต้องทำ Ethnographic Observation ซึ่งเดี๋ยวจะมีหัวข้อใหญ่ให้อ่านอีกที

เสา 2 : Guidelines documents and processes

ขัดกับนิสัยคนไทยอย่างมาก แต่ก็ต้องทำ guidelines ขึ้นมาเมื่อจะออกแบบ และอัพเดทเสมอๆ อาจ 10 หน้าในสองสัปดาห์ ความสำเร็จของ Apple ก็เพราะมี guidelines ที่ดี อ่านง่าย ทำให้ developer ทั้งหลายทำตามจนทั้งหมดเป็นหนึ่งเดียวได้ ควรเขียนเกี่ยวกับ : คำย่อคำเฉพาะ, สี, ฟอนต์, โครงสร้างหน้าจอ, สำเนียงของ error, เสียง, Response Time, อินพุต, ลำดับการทำงาน ฯลฯ

ควรทำกระบวนการ ‘สร้าง guideline’ นี้ให้เป็นกิจกรรมสม่ำเสมอ อะไรที่เป็นที่ถกเถียงเช่นเมื่อไหร่จะเล่นเสียงเตื่อนดี ก็ให้ดูๆช่วยกัน ทดสอบช่วยกัน ทำได้ตามนี้งานจะราบรื่น ไม่ต้องมานั่งโอดครวญเปลี่ยน Design บ่อยครั้ง

เสา 3 : User-interface software tools

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

เราควรทำไงก็ได้ให้ผู้ใช้หรือลูกค้าเห็นภาพให้เร็วที่สุด อาจรีบปริ้นภาพไปให้ดู หรือทำ Prototype หลอกๆขึ้นมาบนเครื่องจริง มี Form มีอะไรครบแต่ยังไม่เอาข้อมูลไปคิด ถ้าไม่ทำบนเครื่องจริงอาจใช้ Power Point / Flash / AJAX ทำขึ้นมาก็ได้ (ถ้าคิดว่าไวกว่า)

เครื่องมือทำ UI ที่เรารู้ๆกันก็เช่น Visual Studio / Java Development Kit

เสา 4 : Expert reviews and usability testing

^ ก็ทำตามที่หัวข้อบอกนั่นแหละ ทำไงนั้นไปอ่านบทต่อไป


อันนี้ก็จากเว็บอาจารย์เหมือนกัน

เวลาตอบสนอง (response time)

วันนี้สอนเรื่องเวลาตอบสนอง (response time) ก็เลยอยากเอามาขยายความต่อสักนิดในบล๊อกครับ

response time คือเวลาที่ตั้งแต่ตอนที่อินพุตมาถึงระบบ จนกระทั่งถึงเวลาที่ผลลัพธ์ออกมาจากระบบ

ซึ่งโดยปรกติจะประกอบด้วยเวลาสองส่วน ซึ่งก็คือ เวลาในแถวคอย (queue time) และเวลาในการบริการ (service time)

response time = queue time + service time

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

ใช้วิธีการเดิมแต่เพิ่มประสิทธิภาพการทำงาน

ทีนี้ถ้าเราต้องการลดเวลาการตอบสนอง เราก็ต้องลดเวลาในแถวคอย และ/หรือ เวลาในการบริการ

ถ้าเราอยากลดเวลาในการบริการเราสามารถทำได้โดย

  1. โดยฝึกหรือบังคับ ให้พนักงานทำงานเร็วขึ้น เช่น ให้จำราคาได้แม่นยำ หรือยิงบาร์โค้ดได้ด้วยความเร็วสูง ซึ่งวิธีนี้จะทำให้ error rate สูงตามไปด้วย และข้อจำกัดทางกายภาพก็ยังมีอยู่ดี
  2. เปลี่ยนขั้นตอนวิธีในการดำเนินการ เปลี่ยนเทคโนโลยีในการอ่านตะกร้ารถเข็น ว่ามีของอะไรอยู่บ้าง เช่นถ้าเปลี่ยนจากเครื่องอ่านบาร์โค้ดมาเป็นเครื่องอ่าน RFID ซึ่งอาจทำให้อ่านข้อมูลทั้งตะกร้ารถเข็นได้ใน ๑ วินาที อย่างไรก็ตามวิธีนี้เป็นวิธีที่ราคาต้นทุนสูง

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

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

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

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

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

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

ทำนองเดียวกัน ในการสร้าง web server ขนาดใหญ่ จะเห็นได้ว่าเราติดข้อจำกัดของ service time ของฮาร์ดดิสก์ซึ่งไม่สามารถทำให้เร็วกว่านี้ได้ด้วยเทคโนโลยีปัจจุบัน สิ่งที่เขาทำก็คือสร้าง web server ให้เป็นฟาร์ม แล้วกระจายโหลดไปเครื่องต่างๆ ทำให้ queue time ลดลง แม้ว่า service time จะไม่ลดลงก็ตาม

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

หวังว่าคงอ่านรู้เรื่องนะครับ เขียนตอนง่วงๆ

THE END

[a]Sirawat Pitaksarit:

นี่คือประเด็น

[b]Sirawat Pitaksarit:

ก็คือเห็นๆมาจากการใช้จริง มีหลักฐาน

[c]Sirawat Pitaksarit:

การรับรู้

[d]Sirawat Pitaksarit:

Cognitive, recognition ความคิดความเข้าใจ

[e]Sirawat Pitaksarit:

Perception VS Cognition

Perception – เกี่ยวกับความรู้สึก ว่าสิ่งต่างๆบนโลกนี้จะกระทำกับอวัยวะรับรู้ของเรายังไงมั่ง แสงจ้า ผิวขรุขระ หรือ เสียงดังๆ…

Cognition – จะเกี่ยวกับกระบวนการคิด เพราะคนเราไม่ใช่เครื่องจักรที่ว่า input จากโลกเป็นไงก็ output คงที่ออกไป แต่ว่าเราจะต้องผ่านการคิด ผ่านประสบการณ์ในอดีตมาผสมด้วย

http://www.auditory.org/mhonarc/2004/msg00334.html

http://www.science.mcmaster.ca/psychology/research-areas/cognition-perception.html

[f]Sirawat Pitaksarit:

มะเร็ง

[g]Sirawat Pitaksarit:

กระบวนการซึมซับการรู้คิด หมายถึง การใช้ความคิดความเข้าใจเดิม ทำความเข้าใจข้อมูลใหม่

[h]Sirawat Pitaksarit:

เป็นพักๆ ไม่ต่อเนื่อง

[i]Sirawat Pitaksarit:

LOC คือความเชือว่าสามารถควบคุมสิ่งที่เกิดขึ้นได้ แบ่งเป็น internal และ external

internal LOC – ตนเอง สามารถควบคุมสิ่งต่างๆได้ ถ้าสอบตกจะโทษว่าอ่านมาไม่พอ

external LOC – สิ่งที่เกิดขึ้นมาจากปัจจัยภายนอก เราไปยุ่งไม่ได้ ถ้าสอบตก จะโทษข้อสอบ

http://en.wikipedia.org/wiki/Locus_of_control

[j]Sirawat Pitaksarit:

ระบบจะค่อยๆ model ตัวเองให้เหมาะกับ user

http://en.wikipedia.org/wiki/User_modeling

[k]Sirawat Pitaksarit:

ปรับให้เข้ากับเรา

[l]Sirawat Pitaksarit:

Prescription – ใบสั่ง (ยา)

[m]Sirawat Pitaksarit:

การจัดแจง

http://en.wikipedia.org/wiki/Taxonomy

[n]Sirawat Pitaksarit:

Syntax

[o]Sirawat Pitaksarit:

สิ่งที่จะทำจริงๆ

[p]Sirawat Pitaksarit:

Goals, Operators, Methods, and Selection rules

แบ่ง Goals ออกเป็น Operator (action) แล้วแบ่งอีกเป็น Methods จากนั้นใช้ Selection rules ในการเลือก Method ที่ดีที่สุดที่จะทำ Goal นั้นๆได้สำเร็จ

http://en.wikipedia.org/wiki/GOMS

[q]Sirawat Pitaksarit:

อ่านว่าวิซิวิก

http://en.wikipedia.org/wiki/WYSIWYG

[r]Sirawat Pitaksarit:

เกี่ยวข้องกับ space มีตำแหน่ง มีรูปร่าง หรือมีเส้น

[s]Sirawat Pitaksarit:

Geographic information system

[t]Nuttapoom Amornpashara:

ชอบตรงนี้จัง

[u]Sirawat Pitaksarit:

sense of touch

http://en.wikipedia.org/wiki/Haptics

[v]Sirawat Pitaksarit:

alphabet

[w]Sirawat Pitaksarit:

Collaboration + Laboratory

[x]Nuttapoom Amornpashara:

สภาพแวดล้อมจำลอง = Virtual reality

[y]Nuttapoom Amornpashara:

Virtual Reality

[z]Tiney T:

ผู้ซุ่มอ่าน

[aa]Nuttapoom Amornpashara:

ประสบการณ์ส่วนตัวปะเนี่ย 55


Sirawat Pitaksarit:

เอามาจากประสบการณ์หลี แม่กุใช้ไม่เป็นซักอย่างนอกจากโทร -.-

[ab]Sirawat Pitaksarit:

ความคาดหวัง

[ac]Sirawat Pitaksarit:

ความอดทนของแต่ละคน/สายอาชีพ

[ad]Sirawat Pitaksarit:

ความได้งาน

[ae]Sirawat Pitaksarit:

ความผันแปร

[af]Sirawat Pitaksarit:

ช่วงเวลาหงุดหงิดหัวใจ

[ag]Sirawat Pitaksarit:

Perception VS Cognition

Perception – เกี่ยวกับความรู้สึก ว่าสิ่งต่างๆบนโลกนี้จะกระทำกับอวัยวะรับรู้ของเรายังไงมั่ง แสงจ้า ผิวขรุขระ หรือ เสียงดังๆ…

Cognition – จะเกี่ยวกับกระบวนการคิด เพราะคนเราไม่ใช่เครื่องจักรที่ว่า input จากโลกเป็นไงก็ output คงที่ออกไป แต่ว่าเราจะต้องผ่านการคิด ผ่านประสบการณ์ในอดีตมาผสมด้วย

http://www.auditory.org/mhonarc/2004/msg00334.html

http://www.science.mcmaster.ca/psychology/research-areas/cognition-perception.html

[ah]Sirawat Pitaksarit:

ทำให้เหมือนคน

http://en.wikipedia.org/wiki/Anthropomorphism

http://en.wikipedia.org/wiki/Moe_anthropomorphism

[ai]Sirawat Pitaksarit:

Locus of Control คือความเชือว่าสามารถควบคุมสิ่งที่เกิดขึ้นได้ แบ่งเป็น internal และ external

internal LOC – ตนเอง สามารถควบคุมสิ่งต่างๆได้ ถ้าสอบตกจะโทษว่าอ่านมาไม่พอ

external LOC – สิ่งที่เกิดขึ้นมาจากปัจจัยภายนอก เราไปยุ่งไม่ได้ ถ้าสอบตก จะโทษข้อสอบ

http://en.wikipedia.org/wiki/Locus_of_control

[aj]Sirawat Pitaksarit:

การเข้าถึงคู่มือที่เขียนขึ้นมา

[ak]Sirawat Pitaksarit:

explicit -> เจาะจง -> เราสั่ง

implicit -> โดยนัย -> มันรู้เอง

[al]Sirawat Pitaksarit:

Direct Manipulation

[am]Sirawat Pitaksarit:

facet – หน้าตัด (ของเพชร)

[an]Sirawat Pitaksarit:

metadata – ข้อมูล ที่เอาไว้อธิบายข้อมูลของจริง เช่น เป็นของกินมั้ย สีเด่นในภาพสีอะไร ฯลฯ

[ao]Nuttapoom Amornpashara:

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

หรือเหมือนจองตั๋วหนังที่มีเก้าอี้ให้ดู

[ap]Sirawat Pitaksarit:

ทำให้เป็นภาพ ดูง่ายๆ

[aq]Sirawat Pitaksarit:

การใช้สีมาเพื่อบ่งบอกอะไรบางอย่าง เช่นถ้าใกล้ปัจจุบันกว่าอาจจะออกแดง ไกลๆก็เขียว

[ar]Sirawat Pitaksarit:

Tempo -> จังหวะ,เวลา

Temporal -> ขึ้นกับเวลา

[as]Sirawat Pitaksarit:

ลงทุนเปลี่ยนแปลงองค์กรไปน่ะ ได้ผลตอบแทนคุ้มมั้ย

[at]Sirawat Pitaksarit:

แนวทางการปฎิบัติ

[au]Sirawat Pitaksarit:

agile – ถ้าสนใจจะลองใช้มั่งไปที่นี่

http://en.wikipedia.org/wiki/Agile_software_development

[av]Sirawat Pitaksarit:

consolidation – รวบรวมให้ยิ่งใหญ่ (ศัพท์ ธุรกิจ)

[aw]Sirawat Pitaksarit:

affinity diagram – เหมือนว่า ตอนแรกเป็นกระดาษไอเดียหลายแผ่นจากหลายๆคนปนๆกันไป แล้วเรามาเลือกแต่ละอันเข้าเป็นกลุ่มๆจนกว่าจะไม่เหลือให้เลือก

http://www.mindtools.com/pages/article/newTMC_86.htm

[ax]Sirawat Pitaksarit:

UED

http://en.wikipedia.org/wiki/Contextual_design#User_Environment_Design

[ay]Sirawat Pitaksarit:

ชาติพรรณวรรณา – เกี่ยวกับวัฒนธรรม เชื้อชาติ

[az]Sirawat Pitaksarit:

ความเข้าขารู้ใจกัน

http://en.wikipedia.org/wiki/Rapport

[ba]Sirawat Pitaksarit:

Plastic Interface for Collaborative Technology Initiatives through Video Exploration

http://searchenterpriselinux.techtarget.com/definition/PICTIVE

[bb]Sirawat Pitaksarit:

ตัวอย่าง (cc) เช่น เอาไปแก้ได้แต่ต้องให้ credit ด้วย , เอาไปใช้ได้แต่ห้ามแก้

[bc]Sirawat Pitaksarit:

มีทั้งหมด 5 อย่าง คือ Habit, Stream of Thought, Awareness, Utterance, and Knowing ที่ผู้เชี่ยวชาญต้องลองคิด แต่ละอันคืออะไรก็กูเกิลเอง

[bd]Sirawat Pitaksarit:

ประมาณว่าจับมาทดสอบในห้องที่ควบคุมปัจจัยต่างๆเป็นอย่างดี วัดผลละเอียดๆ แต่ไม่เป็นธรรมชาติ

[be]Sirawat Pitaksarit:

หน้าตาเป็นแบบนี้

http://www.designperspectives.com/images/usability%20lab_2.jpg

[bf]Sirawat Pitaksarit:

วิธีการดูแล คนที่มาร่วมทดสอบโปรแกรมเรา

[bg]Sirawat Pitaksarit:

ย้อนนึกถึงวันวาน

[bh]Sirawat Pitaksarit:

ถ้าลืมคำพวกนี้หมดแล้วกลับไปอ่านบทแรก

[bi]Sirawat Pitaksarit:

Representative – ตัวแทนคนเดียวจากในกลุ่มเป้าหมาย ซึ่งแทนได้ทั้งกลุ่ม

[bj]Sirawat Pitaksarit:

Demographics – เพศ อายุ ประสบการณ์ ฯลฯ

[bk]Sirawat Pitaksarit:

สิ่งที่สืบค้นเป็นแฟ้ม ซึ่งมีลักษณะโครงสร้างข้อมูลเป็น Tree โดยธรรมชาติ จึงแนะนำให้ Visualize ผลการค้นหาเป็น Tree โดยตรงนี้อาจใช้เทคนิค Visual field specification เพื่อให้ตัดกรองผลการค้นหาจากรูป Tree ด้วยการคลิก ซูม กั้นขอบเขตได้คงจะเท่ไม่น้อย

การที่ข้อมูลกระจายแบบ Normal ทำให้เวลา Response time ไม่ผันแปรนัก ทำให้เราสามารถควบคุม QoS ให้อยู่ในขั้นที่ดีได้ง่ายเวลาหาแฟ้ม นอกจากนี้ยังทำให้ Dynamic Query ได้อย่างมั่นคง ไม่ต้องกลัวว่าการปรับเกณฑ์ไหนจะทำให้ค้างนานมากหรือน้อยกว่า

(แถ)

อาจค้นจากชื่อแฟ้มมาก่อน จากผลการค้นหานั้น เราสามารถใส่ข้อมูลเนื้อหาในตัวแฟ้มได้อีกทอดหนึ่งซึ่งเป็นเทคนิค Faceted metadata search

(แถ)

[bl]Sirawat Pitaksarit:

ผู้ใช้โทรศัพท์มือถือมี Expectation สูงมากที่จะได้การตอบสนองที่รวดเร็ว เนื่องจากเวลาใช้มือถืออยู่ส่วนมากจะทำอย่างอื่นไปด้วยแต่ต้องการข้อมูลบางอย่างจากโทรศัพท์มือถือแค่ชั่วครู่ ถ้าหาก Response Time นานอาจทำให้ผู้ใช้ขาดจังหวะในกิจกรรมที่เขาทำอยู่ได้ (เป็นเรื่อง Short-Term Memory ซึ่งระหว่างรอ Response อาจหลงลืม ทั้งสิ่งที่ทำอยู่และสิ่งที่จะทำในโทรศัพท์)

[bm]Sirawat Pitaksarit:

อาจะกำหนดเกณฑ์ไว้ตามหลักการของ Acceptance test แล้วดูว่าถึงเกณฑ์นั้นหรือยัง หรือลองสร้าง Scenario มาทดสอบ UI เพื่อให้เห็นจุดเด่นจุดด้อย ในการสำรวจความต้องการผู้ใช้นั้นยิ่งสำคัญเพราะเราไม่คุ้นเคยกับ UI เราต้องทำตามกฏหลักๆของการทำ Ethnographic Observation เพื่อให้รู้จริงว่าผู้ใช้ต้องการอะไร

Comments are closed.