- ประวัติ
- Ruby of Rails
- แนะนำหนังสือ

ภาษา Python (ภาษาไทยเขียน “ไพธอน” หรือ “ไพทอน”)

แนะนำหนังสือ

โครงการแปลหนังสือภาษาไทยของ Blognone Library

• Dive into Python
• Python Tutorial

เว็บไซต์ที่น่าสนใจ

• เว็บไซต์อย่างเป็นทางการของ Python
• วิกิพีเดีย: อังกฤษ, ไทย
• ร่วมสนทนาตอบปัญหาภาษา Python ได้ที่ กระทู้ Python

ตอนที่ 6 เราพูดถึงการจัดลำดับของ menu จึงขอยกตัวอย่างอีกสักตัว

โปรแกรม Mac Journal ที่เคยได้รับรางวับ Apple Design award แต่ก็ยังมีความผิดพลาดเล็กๆ ในเรื่อง menu

โปรแกรมนี้เป็นโปรแกรมสำหรับเขียนบทความดังนั้นส่วนที่เป็น “Journal” จึงเป็นส่วนที่อยู่บนสุดของ Hierarchy (ความสัมพันธ์แบบแผนภูมิต้นไม้) แล้วมี “Entry” ต่างๆ เป็นเนื้อหาอยู่ด้านใน

Journal เป็น parent controler object และ มี Entry เป็น sub class ดังรูปด้านล่าง

จากตัวอย่างที่ผ่านๆ มาในตอนที่ 6 จะเห็นว่า menu ควรจัดวางตามลำดับชั้นของความสัมพันธ์ของ Object ในโปรแกรม แต่โปรแกรม Mac Journal กลับนำเอา Entry มาไว้ด้านหน้า Journal ก็ควรที่จะจัดการสลับที่กัน

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

เคยคิดเหมือนกันว่า windows user จะรู้สึกแบบนี้หรือเปล่า เพราะ menu บน windows ไม่ได้อยู่ที่เดิมตลอดเวลา และโปรแกรมส่วนมากก็เรียง menu กันตามใจชอบ ทำให้ผู้ใช้ไม่เกิดระบบการคิดแบบนี้ในหัว (mental model) แต่จริงๆ ไม่ใช่ครับ แทบทุกระบบปฏิบัติการจะมี File Edit … อยู่และนี่เป็นจุดเริ่มต้นของการเรียงลำดับ ถ้าโปรแกรมเน้นจัดการกับไฟล์ ก็จะเอาไฟล์ไว้ด้านหน้า แต่ถ้าไม่มี File ในกรณีของ MacJournal ก็ควรจะเป็น journal แทน เพราะเมื่อผมต้องการเปิดไฟล์ Journal อื่นๆ ผมควรจะกด Journal -> Open ไม่ใช่ Extry -> Open

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

ตัวอย่างต่อไปเป็นโปรแกรมบริหารจัดการ todo list

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

แต่!!!

ลองนึกดูดีดีว่าเราต้องการอะไรจากโปรแกรม todo list คืออะไร สิ่งที่เราต้องการน่าจะเป็นโปรแกรมเล็กๆ ทำงานเร็วๆ

“be there when i need and go away when i don’t need it”

ไม่ต้องมี feature มากมายเพราะ todo เป็นสิ่งที่เราต้องเรียกใช้บ่อยๆ และ ไม่ต้องการเปิดให้มันใหญ่มากๆ เพราะบางทีเราก็ต้องการเปิดมันทิ้งเอาไว้ (สุดท้ายกลายเป็น dashboard) ใครคันไม้คันมือจะหยิบ Photoshop หรือ OmniGraffle มาออกแบบโปรแกรม todo list แบบใหม่ แล้วส่งมาให้ดูกันบ้่างก็ได้นะครับ :)

@Configuration
public class Ex1Config {
	@Bean
	public NamePrinter namePrinter() {
		ItsNamePrinter printer =  new ItsNamePrinter();
		printer.setName("FSF");
		return printer;
	}
}

ชอบ codenone (drupal) นะ post code มันดี