UI và góc nhìn

UI là một lĩnh vực rất gần gũi, mình có thể bắt gặp bất cứ đâu , ví dụ như các sản phẩm dân dụng , hay bất cứ vật phẩm nào. Trước khi nghĩ đến công dụng, cái mà có thể cuốn hút người dùng, làm người dùng khao khát, tò mò , mong muốn được sở hữu chúng, đó là UI – User Interface. Hiểu nôm na, UI là vỏ bọc bên ngoài của một sản phẩm, hay trong khái niệm IT đó là tầng VIEW . Hầu hết anh em đi theo nghiệp fontEnd đều biết UI là cần câu cơm của mình, UI là mảnh đất rộng lớn, nơi có những tay chơi lớn có những sản phẩm mang dấu ấn định hình phong cách. Và tôi chỉ là một kẻ học lỏm , dạo chơi trong khu vườn UI đầy sắc màu này.
Như đã đề cập trong topic trước, do yêu cầu của dự án thực tế, buộc tôi lại một lần nữa bước vào khu vườn UI, tìm hiểu chắt lọc những khái niệm cơ bản để áp dụng giải quyết vấn đề của dự án.
Vấn đề của dự án ở đây là gì?
Quả thực khi đưa tài liệu Basic cho team phát triển, tôi cũng chưa lường được tình huống là team base trên đội phát triển, không có kinh nghiệm làm mockup. Mockup trong web đòi hỏi ngoài kiến thức css, html, javascript, mà còn cần người thực thi biết được các khái niệm, quy tắc sắp đặt bố trí từng item, kích thước, tỉ lệ như thế nào để khi người dùng nhìn vào thấy được sự hài hòa về bố cục, màu sắc của sản phẩm.
Như các dự án trước mà tôi triển khai, công ty bao giờ cũng có một tay Designer care công đoạn xử lý mockup này, tôi cũng phải bận tâm gì nhiều.Còn bây giờ trong quy trình xử lý thiếu mất một mắt xích Desginer, bản mockup của team khiến tôi thật sự thất vọng. Thực tế nó không khác gì bản cắt dán từ thiết kế cơ bản. Từ tỉ lệ form, màu sắc , kích thước button không ăn khớp với suy nghĩ hình dung của tôi ., khi trao đổi suy nghĩ của mình với teamlead dự án, nhận lại feedback là mọi người đều có thói quen xử lý từ phase thiết kế chi tiết, mockup là mặc nhiên đội Japan sẽ phải làm, còn team chỉ việc code tầng business thôi, chưa có kinh nghiệm tự làm mockup cả. Không quên nhắn thêm là team khi estimate là sẽ làm mockup giống hệt hình vẽ trên thiết kế cơ bản. Quá chuối phải không? , đó không phải là sản phẩm của tôi muốn nhận, thiết kế cơ bản là đưa cái ý tưởng, sắp đặt vị trí iteam thôi 
Đặt trước tình huống này, với vai trò Brse cần có những kỹ năng nào? Đầu tiên,và luôn tâm niệm trong đầu là phải biết giữ được sự chia sẻ trong team, cùng nhau bóc tách khó khăn, giải quyết công việc cùng nhau. Tuyệt đối không đẩy sự căng thẳng , quy trách nhiệm đối phó lẫn nhau.Cái này gọi là teambuilding., phải biết nhìn về mục đích chung, giữ được lửa trong team. Với quy tắc trên, buộc tôi phải có action phù hợp. Có hai cách xử lý trong tình huống này, thứ nhất có thể báo cáo lên quản lý Satou cần bổ sung thêm Designer, còn cách thứ hai là tự mình giải quyết. Căn cứ thực tế, dự án này nhỏ, việc bổ sung Desinger, đồng nghĩa tăng cost, phải thay đổi lại schedule, gần như chắc chắn sẽ không thể, hơn nữa Satou với suy nghĩ tao là người dùng, thứ tao muốn là sản phẩm giống như tao hình dung có trong thiết kế cơ bản. Mặc nhiên team từ Việt Nam sẽ phải làm điều đó.Vậy tôi chọn cách thứ hai.
Đầu tiên, tôi trao đổi trong team, lắng nghe team, thấy được team cần có những gì, Okie thứ team cần là cái định hướng sắp xếp, bố trí , màu sắc từng item. Kiểu như đến hiệu cắt tóc bên Nhật, khi tiếng nhật chưa sõi, từ vựng chưa tốt, không thể đơn giản hơn như minanihongo đã dạy “写真みたいにお願い”. Công việc của tôi là thế, cần tìm các sample, tham khảo các khái niệm làm mockup từ khu vườn UI đầy sắc màu .
Rất may mắn cho tôi, UI có cộng đồng chia sẻ rộng lớn, rất nhiều khái niệm mà tôi cần đều có thể tìm được trên kipalog, toidicodedao…Vậy đã xong cái vision cho team, tất nhiên để đảm bảo diễn đạt đúng ý muốn của mình, tôi không quên chụp các evidence cho team dễ hình dung. Việc tiếp theo , lục lọi các dự án mà trước đây tôi đã triển khai, tham khảo sample mockup tương ứng, chọn ra cái phù hợp nhất với hình dung của mình. Vậy là đã xong, stone đã được gỡ bỏ, team cùng nhau giải quyết một vấn đề thật sự cảm thấy HAPPY trong công việc.
Bài học tôi muốn note ở đây là kỹ năng xử lý vấn đề của một Brse, đừng bao giờ đặt vị trí Brse lên tầm cao, đè nén công việc cho team, thay vào đó hãy tìm cách động viên lắng nghe team, theo dõi sát sao schedule, luôn để thông tin thông suốt. Hãy tạo sự HAPPY ngay trong team.
Có lẽ chia sẻ cũng đã dài, topic này tôi sẽ quay lại ở một dịp khác. Ah, mọi người có thể tham khảo các khái niệm xử lý mockup từ link bên dưới.
Good Design

@ Tham Khảo: http://toilabrac.site/?p=202

Quy trình làm thiết kế cơ bản khi triển khai dự án phát triển phần mềm (Thiết kế cơ bản bước 4)

Bước cuối cùng trong công đoạn thiết kế sản phẩm phần mềm là bước thiết kế , làm tài liệu màn hình , hay còn gọi là tầng logic xử lý nghiệp vụ hệ thống. Có thể hiểu bước này là bước tổng hợp kết quả, tư duy từ các bước trước . Do vậy khi đọc tài liệu thiết kế bao giờ cũng phải đi từ gốc – tài liệu thiết kế I/F, thiết kế DB, sau khi đã clear được 2 tài liệu này, hiểu được ý đồ của người thiết kế rồi thì mới đọc đến tài liệu thiết kế màn hình, giải thích cho team phát triển hệ thống.
Okie, bắt tay vào việc nào !
Các step nhỏ trong công đoạn này gồm có
① Đánh chỉ số item trên màn hình
② Mô tả thao tác cơ bản màn hình
③ Mô tả Input /Output các item trên màn hình
④ Thực hiện validation các item nhập liệu
⑤ Mô tả các action thực hiện trong màn hình
⑥ Và cuối cùng mô tả di chuyển màn hình tương ứng với các action xử lý.

Để làm được bước ① cách đơn giản, hiệu quả là capture màn hình từ tài liệu I/F sau đó trên màn hình có bao nhiêu item , đánh hết chỉ số item đó. Bước ② cần mô tả được lúc khởi tạo màn hình như thế nào, ví dụ ở màn hình danh sách lúc khởi tạo ban đầu có hiện thị danh sách kết quả search mặc định hay không? . Có thể nhiều bạn nói đó là mặc nhiên mà ! Okie, trường hợp chung là vậy, tuy nhiên có nhiều hệ thống dữ liệu rất lớn, khi chiết xuất dữ liệu ra màn hình gây tốn tài nguyên database, chậm xử lý.Và với mọi trường hợp , người thiết kế cần comfirm với khách hàng, để hiểu rõ mục đích nghiệp vụ của hệ thống.

Bước ③ là bước mô tả của bước ① có nghĩa là mỗi một item đi kèm với đó là I/O trường dữ liệu trong database, kiểu dữ liệu nhập liệu / hay hiện thị .

Để từ đó có viết tiếp bước ④ validation cho các item nhập liệu đó.Kinh nghiệm khi triên khai các hệ thống WEB, hay bất cứ hệ thống nào khác  bao giờ cũng phải validate ở cả phía client, và phía server, thuận lợi là các framework hiện nay đều có các thư viện hỗ trợ xử lý validation rất tốt. Và tất nhiên không thể thiếu là các message lỗi đi kèm khi thực hiện validation item, tài liệu danh sách message lỗi các bạn download bên dưới .

Tiếp theo bước ⑤ cần phải liệt kê được các action thực hiện trong màn hình, ví dụ ở màn hình search tất nhiên phải có action search, và các action di chuyển sang màn hình khác như logout, padding…Đây là bước định hình cho người phát triển hệ thống xây dựng các class xử lý tương ứng.
Cuối cùng bước ⑥ thực hiện vẽ flow logic xử lý , kết quả tổng hợp bước ⑤ , tài liệu I/F hệ thống. Thực thi bước này , cần phải nắm được các quy tắc : hình khối chữ nhật đại diện cho action, hình thoi đại diện cho logic IF/ELSE, và tất nhiên luôn có chỉ số màn hình, và các mũi tên di chuyển giữa các màn hình trong hệ thống.

Khi bạn làm đến bước này thì xin chúc mừng bạn đã cán đích thành công !
Tuy nhiên, vâng dù rất ghét , nhưng vẫn phải nói điều này , để có một tài liệu thiết kế tốt cần phải review từ nhiều phía. Ít nhất cần phải dành thời gian đọc lại một lượt toàn bộ tài liệu mình viết, các lỗi như text, sai chỉ số màn hình rất dễ mắc phải. Đây là bước quan trọng luôn phải được thực thi trước khi đưa cho cấp cao hơn phê duyệt. Kinh nghiệm cho thấy , không nên đọc review ngay sau khi hoàn thành xong step 6, mà nên để sang hôm sau, khi đầu óc được refesh , tỉnh táo mới bắt lỗi chuẩn xác được.
Template tài liệu thiết kế màn hình.
【xxxxxxxx】会員社一覧画面設計

Danh sách message lỗi.
【xxxxxxxxxxx】メッセージ一覧

@Tham khảo: http://toilabrac.site/?p=184

Quy trình làm thiết kế cơ bản khi triển khai dự án phát triển phần mềm (Thiết kế cơ bản bước 3)

Không có gì tuyệt vời hơn sáng dậy đón ánh nắng , những cơn gió mát rượi , và nghe những giai điệu nhạc ngọt ngào.
Bước thứ 3 trong thiết kế cơ bản là tầng M – thiết kế database.
Điều kiện input đầu vào là người thiết kế phải hiểu được các khái niệm cơ bản về table, khóa ngoại, khóa chính…Để từ đó hình dung ra được mối liên kiết quan hệ xử lý logic giữa các màn hình như thế nào.Mục đích xây dựng các table sao cho các trường ít bị trùng lặp,  mỗi table đảm nhận nhiệm vụ đặc trưng của từng nghiệp vụ xử lý.
Cũng giống các bước thiết kế trước, việc chọn template thiết kế rất quan trọng, giúp người thiết kế đỡ tốn cost trong việc tạo form, chỉnh sửa khung print, macro. Điều thú vị, cũng như kinh nghiệm xây dựng các trường có trong table là gần như màn hình có item nào thì gần như trong table có các trường nhập liệu đó, có nghĩa là khi làm xong tầng V, thì mình bê gần như nguyên màn hình nhập liệu vào phần xây dựng các trường trong table. Tuy nhiên , cũng có một số trường hợp ngoại lệ ví dụ như một trường trong database lại đại diện xử lý cho nhiều trường nhập liệu trên màn hình, khi gặp case này người thiết kế cần phải đọc , phân tích kỹ càng ở mục tài liệu mô tả yêu cầu sơ khai. Cần chú ý đến yếu tố khóa chính , khóa ngoại để xác định được khi nào trường trong table đại diện cho từng item nhập liệu cho màn hình, xác định rõ case by case, mục đích để viết trong tài liệu logic nghiệp vụ sau này.
Tiếp đến phải clear được xử lý xóa logic, hay xóa vật lý. Hầu hết các hệ thống đều build trên nguyên tắc là xóa logic, trừ trường hợp các table có dữ liệu không quan trọng, thì có thể xóa vật lý lý do là đỡ tốn tài nguyên database. Ví dụ như table LOG, kể cả trong trường hợp xóa vật lý, thì người thiết kế cũng phải có kế hoạch backup định kỳ. Bởi data là tài nguyên quý giá nhất của một hệ thống.
Vậy khi xóa vật lý thì ae luôn phải có 7 trường thần thành này trong table
削除フラグ    DELFLG
削除日時        DELDATETIME
削除者コード DELUSERCD
登録日時        ADDDATETIME
登録者コード ADDUSERCD
更新日時         UPDDATETIME
更新者コード UPDUSERCD

Như bên trên đã nói khi xây dựng table phải quy định khóa chính của table có kiểu như thế nào, tự động tăng hay không…, rồi mối quan hệ giữa các table khác là quan hệ một – một, hay một nhiều? Để làm được việc này, đòi hỏi người làm thiết kế khi xây dựng thiết kế cũng đã phác thảo , hình dung được logic xử lý của hệ thống.
Sau đó, cần thêm kiến thức về database trong việc xử lý tốc độ truy xuất dữ liệu trong table, ấy là đánh chỉ số index các trường trong table. Kinh nghiệm là cứ trường nào làm key search là mình đánh index.
Okie, về cơ bản một table sẽ được thiết kế như sau

Mối quan hệ giữa các table được thể hiện qua file ERP

Và cuối cùng, cũng là kiến thức quan trọng để làm phần xử lý logic nghiệp vụ của tầng C. Đó là CRUD – viết tắt các khái niệm
C – Create
R – Read
U – Update
D – Delete
Điều kiện thực thi là liệt kê được danh sách các màn hình, mỗi màn hình tương ứng với các action tương tác với từng table.

Đã xong, phần thiết kế DB là vậy đó, trên đây là mình đã tóm lược các kiến thức hết sức sơ khai, để ae hình dung được quy trình thiết kế cơ bản là như thế nào. Với những ai coi thiết kế là nghiệp thì phải tử với nó, phải lăn vào dự án, chỉ có cách đó mới có được kiến thức trải nghiệm thực tế nhất, kinh nghiệm từ đó mới tích lũy trưởng thành được.
Về template , ae download từ link dưới nhé.
【xxxxxxxxxxxxxx】DB設計

@Tham khảo: http://toilabrac.site/?p=177

Quy trình làm thiết kế cơ bản khi triển khai dự án phát triển phần mềm (Thiết kế cơ bản bước 2)

Sau khi hoàn thành bước liệt kê danh sách chức năng, nghiệp vụ của hệ thống tiếp đến xây dựng tầng V của thiết kế cơ bản.
Để làm được bước này, cần người thiết kế phải có kinh nghiệm về lĩnh vực mình đã triển khai, ví dụ có kinh nghiệm xử lý về webapplication, hay application. Hình dung được flow chạy của hệ thống , xử lý di chuyển giữa các màn hình với nhau.
Trước tiên phải liệt kê được sơ đồ usercase hệ thống, có nghĩa là dựa vào bước 1 xem có những thành phần nào tham gia hệ thống ( ví dụ như user người dung, user quản trị, user maintain…) các màn hình chức năng sử dụng tương ứng với các thành phần đó. Mục đích của bước này là hình dung rõ ràng chức năng cần có, để từ đó xây dựng đủ I/F màn hình .
※Tham khảo file bên dưới ( do tính bảo mật của dự án, nên mình đã xóa mờ font, thay đổi nội dung trong file – ae thông cảm)

Khi xử lý I/F màn hình, cần input được các điều kiện sau:
– Style của màn hình như thế nào ( màu sắc, kiểu chữ, bố cục item…), mục này sẽ dựa vào kinh nghiệm của người làm design.
– Dự án phát triển từ phase ban đầu, hay là làm mới hoàn toàn.
– Lấy requirement từ phía endUser xem khách hàng có chỉ định style nào đó hay không?
– Liệt kê , phác thảo ra bản sơ thảo, trước khi xây dựng chi tiết.,bước này khá quan trọng cho tư duy người thiết kế. Một là giúp người thiết kế hình dung rõ ràng style mình sử dụng như thế nào, hai là tránh thiếu sót item trên màn hình…
Okie, khi đủ input vào mình là mình triển khai thôi.

Điều thú vị khi xử lý bước này là giúp định hướng rất tốt mục đích sử dụng action như thế nào trên form, Cụ thể mục search sẽ sử dụng item nào search, search như thế nào. Pagging xử lý như thế nào, thực thi config động hay fix cứng, bala bala ..Những ý tưởng dần dần thai nghén , đó là tiền đề cho bước làm tài liệu màn hình sau này.
Tiếp theo đến bước vẽ flow di chuyển màn hình, bước này cũng đơn giản là thực hiện kết nối các màn hình lại với nhau., Khi click button nào sẽ di chuyển đến màn hình đó…,với những dự án số lượng màn hình it thì có thể vẽ trực tiếp, còn không sẽ phải làm trên excel thần thánh, có nghĩa là mình đánh mã màn hình, sử dụng ma trận cell để di chuyển.

Okie vậy là xong bước thực thi I/F , flow màn hình.
Tóm lại để triển khai bước này cần có là kinh nghiệm của người làm design ( xác định style, đọc hiểu ý đồ của EndUser..) với những người mới vào nghề thì không có gì tốt hơn là tham khảo các template , càng làm càng vỡ .
Công nghệ sử dụng 100% excel thần thánh ae nhé, mọi người cần phân tách rõ ràng Designer với người viết thiết kế hệ thống.Hai khái niệm hoàn toàn khác nhau, Desginer là người sử dụng các công cụ như photoshop, hay illustrator để làm mockup ( cắt html, css ) cung cấp cho ae Developer .Còn người viết thiết hệ thống là khai niệm chỉ tụi mình – những người làm thiết kế hệ thống cơ bản, thiết kế chi tiết.
Template bên dưới, ae nào cần tham khảo thì download về nhé.

【xxxxxxxx】業務フロー

@Tham khao: http://toilabrac.site/?p=168

Quy trình làm thiết kế cơ bản khi triển khai dự án phát triển phần mềm (Thiết kế cơ bản bước 1)

Như đã hứa trong bài viết trước , hôm nay tôi sẽ viết tổng kết lại quy trình làm thiết kế cơ bản khi triển khai dự án phát triển phần mềm.

Ai đã làm về phần mềm , hoặc đã từng code thì đã từng biết hoặc nghe nói đến mô hình MVC . Và thiết kế cũng dựa trên nguyên lý này làm nền tảng thiết kế. Cụ thể M ( Module ) đại diện cho tầng thiết kế cơ sở dữ liệu database, V (View) đại diện cho tầng giao diện I/F màn hình, cuối cùng C ( Control ) đại diện cho tầng bussiness xử lý logic nghiệp vụ. Thường thì flow làm thiết kế mình đi từ V →M→C, lý do là luôn cần phải có sự review comfirm từ phía endUser . Khách hàng đồng ý mình đưa ý tưởng về style I/F màn hình, flow xử lý rồi mới triển khai tiếp các tầng, các lớp tiếp theo. Tuyệt đối cứ hùng hục làm, cuối cùng khách hàng không đồng ý , hoặc không thích một điểm nào đó ở tầng V thì công sức sửa, hay có thể phải đập đi toàn bộ làm lại, rất tốn cost, và gây stress .
Kinh nghiệm này cũng nên áp dụng cho Phase phát triển code, luôn cần có teamlead review lại source, đảm bảo code đúng theo ý tưởng của thiết kế chi tiết hay không? thực hiện đúng ý đồ của nhà thiết kế hay không?

Ấy là nguyên lý nền tảng khi viết thiết kế.
Tuy nhiên rất nhiều người khi bắt đầu viết, lại quên, hoặc không để ý đến step ban đầu là liệt kê chức năng, nghiệp vụ của hệ thống ( 業務一覧・機能一覧）Theo mình đánh giá bước này quan trọng bởi khi thực hiện viết step này, đảm bảo cho mình thực sự hiểu hệ thống, hiểu ý đồ của khách hàng. Nếu có thiếu, hay mô tả chưa đúng thì khách hàng sẽ feedback lại, mình sẽ sửa đến khi khách hàng gật đầu đồng ý, okie mày làm tiếp đi, thì đến lúc đó mới áp dụng mô hình MVC để làm thiết kế như trên.
Và đừng có quên là phải thống nhất được template khi viết thiết kế, bởi công ty nhật là những ông trùm sử dụng excel, nên mỗi công ty có thể sử dụng riêng template để làm thiết kế. Mình thì hay dùng template bên dưới

Ưu điểm của template này là nó bóc tách được các phân lớp chức năng nhỏ của hệ thống, giúp mình vừa dễ viết, và estimate sau này.

Khi nhìn vào cột 業務 bạn sẽ thấy được chia thành 3 phân lớp nhỏ LV1, LV2, LV3. Và từng ID chức năng sẽ được sắp xếp vào từng phân lớp nhỏ ( tùy vào hệ thống sẽ thêm hoặc bớt số phân lớp). Tiếp theo trong template có các cột thông tin cho phần mô tả nghiệp vụ ( tên nghiệp vụ , nội dung nghiệp vụ, bộ phận sử dụng màn hình này, điều kiện , và giới hạn tác vụ ).Mình sẽ dựa vào nội dung được mô tả trong file (概要定義) để mô tả cho màn hình, hay chức năng đó. Tiếp theo đến phần mô tả tính năng cho một màn hình, phần này sẽ dựa trên kinh nghiệm của người đã triển khai phase phát triển phần mềm. Nội dung viết sát kỹ thuật, gần phía tư duy của đội phát triển ( Developer ), ví dụ khi viết cho màn hình đăng nhập, ta phải lưu ý đến xử lý cookies, session, api,…cách mã hóa password như thế nào.Đây là tiền đề để sau này mình dựa vào đó để viết tài liệu mô tả màn hình xử lý nghiệp vụ.
Template này có ở phần dưới bài viết, ae nào muốn sử dụng thì tham khảo nhé.
【xxxxxxxシステム】業務一覧・機能一覧