I. GUI là gì?

Chắc hẳn đối với tất cả các lập trình viên, hoặc các tester thì sẽ không lạ gì với cụm từ UI, nhưng lại hơi lạ lẫm hơn với cụm từ GUI, đặc biệt là các bạn fresher khi mới bắt đầu được học và tìm hiểu về lập trình.

GUI - viết tắt của cụm từ Graphical User Interface, tạm dịch là Giao diện đồ họa người dùng, là nơi mà bạn tương tác với một ứng dụng hoặc bất kì một sản phẩm lập trình nào, bằng hình ảnh chứ không phải bất kì một cái gì khác như văn bản, giọng nói… Hiểu đơn giản, GUI là một cửa sổ (màn hình) chứa các controls (button, label, textfield..) và người dùng tương tác trực tiếp với giao diện đó.

Khác nhau giữa GUI và UI được thể hiện chỉ bởi 1 chữ G: Graphical - Đồ họa . UI có thể bao gồm rất nhiều tương tác khác với user mà không chỉ là đồ họa như giọng nói, sinh trắc.. . GUI chỉ là một tập hợp con của UI.

II. GUI Checklist.

Có lẽ, một số dev đọc đến đây chắc lại suy nghĩ: “Bài này dành cho tester rồi” . Nhưng không, checklist này em/mình đưa ra là hoàn toàn cho dev, vì checklist của tester nó kinh khủng hơn thế này nhiều :D

Vậy tại sao, dev lại cần phải kiểm tra lại theo checklist dù đã có tester? Đơn giản là vì chẳng có dev nào thích bị hơi tí là tester réo tên chỉ vì 1 lỗi GUI đơn giản đâu, đúng không nhỉ? Nên là sau khi dựng xong giao diện, mất công ngồi check lại 1 tí, để tester đỡ réo tên nhiều, gây mất tình cảm 2 bên :D

Checklist này mà em/mình đưa ra ở đây điều là những cái khá cơ bản, nhưng thấy khá nhiều dev chủ quan bỏ qua, nên cá nhân, nhận thấy nó rất hữu ích đó ạ :D.

Bắt đầu check list.

1. Thiết kế giao diện đã được review hoặc đáp ứng bởi khách hàng chưa?

Đơn giản chẳng ai thích việc mình mất công dựng xong giao diện với animation rất perfect, nhưng khách hàng :” Tao ứ thích cái này, nó quê mùa vch” . Và vì khách hàng là thượng đế, dù rất thích cái UI vừa dựng và công sức mình làm, bạn vẫn phải nuốt nước mắt đập đi làm lại. Vì thế, hãy để khách hàng, hoặc người review chốt xong giao diện, hoặc ít nhất cái khung, thì hãy bắt tay vào UI. Trước mắt có thể implement logic trc cũng dc :D

2. Các label, button.. đã được căn chỉnh thống nhất hay chưa?

Nếu không có design, hoặc tự design, thì hãy kiểm tra lại xem các thành phần của view đã đươc đồng nhất với nhau hay chưa? Không thể 1 cái padding 16px, cái dưới lại padding 25px dc.

Nếu có design, thì hãy tuân theo design hết mức có thể.

3. Kiểm tra lỗi chính tả, dù là nhỏ nhất.

Tester rất thích bắt lỗi chính tả, và khi bị bắt lỗi chính tả thì bạn quê vch, thật đấy! Vì thế, hãy cố soát lại thật kĩ các lỗi chính tả nhé.

4. Có sử dụng hourglass để cho biết tiến trình đang xử lý không ?

Để tránh bị tester log bug vô lý rằng app bị đơ không thao tác dc, với một màn hình trắng xóa mà thực tế nó đang load dữ liệu, thì hãy thêm 1 hourglass để cho biết app đang sử lý 1 tiến trình nào đó.

5. Sau khi thực hiện task, giao diện có quay lại trạng thái bình thường, hoặc update trạng thái mới không ?

Đây là một bug mà em/mình thấy gặp khá nhiều mà nhiều dev khá chủ quan. Ví dụ như khi bấm vào 1 tableview cell, thao tác xử lý xong, nhưng cell đó vẫn hiện trạng thái đang bấm, như vậy sẽ có thể gây hiểu nhầm đến người dùng, và chắc chắn sẽ lại bị tester réo tên đấy ạ.

6. Các trường có phù hợp với độ dài dữ liệu không ?

Hãy kiểm tra lại xem, dữ liệu của bạn đã được hiển thị hết chưa, tránh để tình trạng 1 label quá dài cho dữ liệu quá ngắn (ví dụ như id, tuổi) mà dữ liệu dài (như tên, địa chỉ..) lại quá ngắn để hiện thị.

7. Các từ viết tắt, hoặc cùng nghĩa có được thống nhất xuyên suốt toàn app không ? Nếu có từ viết tắt thì có đảm bảo người dùng hiểu được không ?

Cái vấn đề này khá đơn giản, nhưng bị nhiều dev bỏ qua, nhưng đôi khi sẽ tạo sự khó chịu cho người dùng.

Có nhiều cái mà dev mình viết tắt mặc định hiểu, nhưng đối với người dùng thì họ lại không biết đó là cái gì. Vì vậy hãy chú ý sử dụng các cụm từ viết tắt thông dụng nếu cần, và sử dụng 1 cach nhất quán giữa các màn hình .

8. Các thông báo lỗi có được hiển thị khi có lỗi? Thông báo lỗi có sử dụng từ ngữ kĩ thuật, có dễ hiểu với người dùng không ?

Người dùng sẽ cực kì khó chịu khi tự dưng một ngày không thể login vào dc ứng dụng mà không có bất kì một thông báo lỗi nào. Vì vậy, hãy đặt 1 thông báo khi người dùng thực hiện một thao tác lỗi.

Và đặc biệt, không sử dụng từ ngữ kĩ thuật vào alert. Người dùng không hiểu và không quan tâm đến điều đó, thay vì hiển thị “mã lỗi”, hãy dùng 1 cụm từ thân thiện nào đó, để ng dùng có thiện cảm hơn.

9. Các thông báo lỗi có hiện thị đúng thông tin, và không đổ lỗi cho người dùng không?

Vì người dùng là thượng đế, vì vậy, đừng hiện thị thông báo có khuynh hướng để người dùng hiểu lầm là, lỗi này là do tao và cảm khó chịu , (mặc dù có thể là thế thật).

Ví dụ, nếu người dùng quên không nhập ID, hãy hiện thị lỗi “Xin vui lòng nhập ID của bạn ”, đừng hiện thị “Chưa nhập ID, hãy nhập lại.”

10. Trước những hành động quan trọng (như xóa dữ liệu) hãy hỏi lại người dùng.

Nhiều khi người dùng chỉ vô tình bấm vào button “Xóa dữ liệu”, hãy cho người dùng cơ hội để sửa sai, hoặc xác định lựa chọn của mình :D

11. Các định dạng ngày tháng, số có được thống nhất không ?

Hãy kiểm tra lại định dạng ngày tháng, số.. ở tất cả các màn hình khác nhau. Đừng để màn hình này định dạng dd/MM/yyyy , ngay màn hình sau lại là yy/MM/dd. Dù nó rất nhỏ, nhưng vẫn có thể gây khó chịu cho người dùng. Và tester cũng k thích điều đó.

12. Các sự kiện điều khiển đã được tuân theo các quy luật bình thường (trên, dưới, trái, phải ) hay chưa?

Dù người Nhật khi đọc sách có đọc ngược hơn so với chúng ta thật, nhưng khi thao tác, nhập các sự kiện, vẫn tuân theo quy luật trên, dưới, trái, phải.

Vì vậy, khi làm UI, hãy chú ý xem mình đã tuân theo quy luật này chưa nhé. ’

Ví dụ, người dùng input user -> enter : thì con trỏ phải di chuyển sang textfield bên phải, hoặc bên dưới, đừng làm theo chiều ngược lại .

13. Các màn hình, component đã ánh xạ chính xác chưa?

Cái này, dev sẽ phải check lại trong code, hãy đảm bảo các component đã được ánh xạ chính xác với chức năng của nó. :D

III. Kết luận.

Trên đây, là GUI checklist mà em/mình đưa ra dựa trên 1 ít kinh nghiệm và tìm tòi, giúp các a/c/e trong quá trình lập trình, phát triển 1 ứng dụng, hay web.

Vì không phải tester, và kinh nghiệm còn ít ỏi, nên checklist có thể còn nhiều thiếu sót và mang ý kiến chủ quan nhiều. Vì vậy, a/c/em có ý kiến có thể cmt hoặc viết 1 bài blog khác để bổ sung nhé ạ :D

Thank m.n vì đã đọc đến đây :3