Archive for IT

Auto Sync time for your computer

July 4, 2015 IT No comments

I have a very old laptop, it is out of battery for CMOS, so each time a unplug it , the time is jump back to 2002 (i guest this is its birth year :) , I had to sync its time everytime I turn it on. It’s old so it is not easy to open its components and replace the CMOS battery.

So I think, that must has some programs to sync the time for this case,right? And I googled it. But most of these programs required you to install it. I dont like this, I thought it is a very simple job, no need to install a program, just find some ones can run directly. In several hours, I could not find any tool which is small and run directly as I want. I even though that I will code one.

Luckily, I fought this very small one, which will sync your computer’time with internet time. It’s very small, does not have a UI, too. I like it.

All I need to do is quite simple: I wrote a small batch file with some commands, and put this batch file to startup folder.

At first, it has only one command:

“cmdtime3.exe” /q sync /m:7200000

It runs well, except sometime, when the LAN to internet was not ready so It could not sync time.

So I put more commands into the batch file, the idea is wait until internet connection is ready and sync after that. I use ping command to wait until internet is ok:
:start
ping -n 1 google.com
if %errorlevel% == 0 goto remote_desktop

rem wait for 10 seconds before trying again
@echo Waiting 10 seconds…
ping -n 10 127.0.0.1 > nul

rem loopback to start
goto start

And after these ones is the suync time command.

You can download all here: cmdtime

Hope this can help someone wants to find a simple and small solution. :)

 

Very Small tool to ask password without logout or switch user on Windows

July 2, 2015 IT No comments

When working at Vinecom, I have to join many quick meetings or sometimes , I had to go home and need run teamviewer to remote access my working computer. In both cases, I did not want to logout or switch user because some programs in running, it takes time when logining in again and teamviewer can not run remote control mode (even when you just switch user only)

So I create a small program, called Lockwin, by VB6 (not my favourite language but it has portable compiler) . This program do 2 very simple tasks:

– Display an “always on top” form, asking to input your computer ‘s password (the system password you used to login) . So no one can see any other programs running or your data

– Check if “Task manger” called, it will shutdown your computer . I assume that if “Task manager” called in this case, someone wants to close the program illegallty.

In addition, I often turn on my computer and leave it to do other things, and when I return, I login and wait for startup programs run. I feel it costs time. So I change to policy in Windows to bypass login screen at the first time to run startup programs.

But what about the security? I put Lockwin in Startup, and the problem is solved, Startup programs can run without waiting login and nobody can use my computer until I login. Perfect as I need.

The source code and program here: lockwin

Hope this help someone’s demand. :)

UX layers

June 13, 2015 IT No comments

*Một bài viết rất hay của lou.vn, xin về khi nào cần đoc lại

Thỉnh thoảng Phowr nhận được một số câu hỏi như sau: “Sản phẩm của em cần cải thiện UX chỗ nào?”, “Nhờ đánh giá giúp UX của sản phẩm này”, “Em cảm thấy sản phẩm chưa tốt lắm nhưng chưa biết bắt đầu từ đâu?”, “Em đã tối ưu giao diện hết mức như goodui.org rồi nhưng kết quả vẫn chưa như kì vọng”…

Những câu hỏi bên trên xuất phát từ việc chưa có guideline (chi dẫn) chuẩn nào trong tiếp gia tăng trải nghiệm người dùng. Bài viết này sẽ cung cấp một trong số các guideline tiếp cận dưới hình thức UX layers để các bạn tham khảo.

Read more

SCRUM – Một số quy tắc trong quy trình thực hiện

April 27, 2015 IT, Quản lý No comments

ScrumMaster là người chịu trách nhiệm đảm bảo tất cả những ai liên quan đến dự án, kể cả “gà” và “heo”, đều phải tuân thủ theo những quy tắc đặt ra của Scrum. Những quy tắc này được đút kết qua quá trình thực hiện thành công của hàng nghìn dự án trước đó.

Sprint Planning Meeting

Cuộc họp được cố định thời gian diễn ra trong vòng 8 giờ, bao gồm 2 phần, mỗi phần cố định 4 giờ. Phần thứ nhất là xác định Product Backlog, phần thứ hai là dành cho việc chuẩn bị một Sprint Backlog.

– Những người tham gia là ScrumMaster, Product Owner và Scrum Team. Ngoài ra, có thể mời thêm những người khác tham dự (nếu cần thiết khi cần thêm thông tin hoặc tư vấn về nghiệp vụ hoặc công nghệ). “Gà” không có chỗ trong cuộc họp này.

– Product Owner phải chuẩn bị trước Product Backlog. Trong trường hợp vắng Product Owner hoặc thiếu Product Backlog, ScrumMaster phải thực hiện xây dựng trước Product Backlog và đảm nhiệm vị trí của Product Owner.

– Mục tiêu của phần đầu, của 4 giờ đầu tiên, là để cho Scrum Team chọn các Product Backlog item mà họ cảm thấy đó tính năng quan trọng trong sản phẩm cần thực hiện. Scrum Team sẽ chứng minh cho Product Owner và các stakeholder tại Sprint Review Meeting và cuối Sprint về những gì mà họ đã chọn.

– Team có thể đưa ra các gợi ý, nhưng quyết định chọn Product Backlog nào để thực hiện trong Sprint là trách nhiệm của Product Owner.

– Team chịu trách nhiệm xác định có bao nhiêu Product Backlog mà Product Owner muốn thực hiện trong suốt Sprint.

– Phần thứ hai của cuộc họp, 4 giờ tiếp theo, Product Owner phải luôn có mặt để trả lời các câu hỏi về Product Backlog của Scrum Team.

– Kết quả của phần thứ 2 của cuộc họp này là một danh sách, được gọi là Sprint Backlog, bao gồm các công việc, ước lượng của từng công việc, và phần chỉ định.

Daily Scrum Meeting

Cuộc họp được cố định thời gian diễn ra trong vòng 15 phút bất kể có bao nhiêu thành viên của Scrum Team lúc đó.

– Tổ chức cuộc họp tại cùng địa điểm vào cùng thời điểm mỗi ngày làm việc. Cuộc họp nên được tổ chức vào đầu ngày làm việc để Scrum Team có thể tổng kết lại những gì đã làm được ngày hôm trước và vạch ra kế hoạch thực hiện ngày hôm nay.

– Thành phần tham dự là tất cả thành viên của Scrum Team. Nếu vì lý do nào đó mà thành viên không thể tham dự, người đó phải tham gia theo hình thức khác (như qua điện thoại, chat voice, live meeting,…), hoặc nhờ 1 thành viên khác báo cáo về tình trạng vắng mặt của mình.

– Các thành viên của nhóm phải được nhắc nhở. ScrumMaster bắt đầu cuộc họp vào thời gian đã thông báo, bất kể lúc đó có thành viên nào hiện diện. Bất kỳ thành viên nào trễ đều phải bị phạt ngay lập tức Smile.

– ScrumMaster bắt đầu cuộc họp bằng việc chọn một thành viên nào đó trong Team để báo cáo, và xoay vòng cho đến khi tất cả thành viên đều đã báo cáo.

– Mỗi thành viên chỉ nên trả lời 3 câu hỏi sau đây:

+ Bạn đã làm gì từ sau cuộc họp trước mà liên quan đến dự án này?

+ Bạn sẽ làm gì sau khi cuộc họp này kết thúc?

+ Điều gì cản trở bạn thực hiện công việc của mình?

– Các thành viên không nên lạc đề khỏi 3 câu hỏi trên vào các lỗi, thiết kế, thảo luận cách giải quyết vấn đề, hoặc nói linh tinh. ScrumMaster chịu trách nhiệm luân phiên việc báo cáo từ người này sang người khác.

– Trong suốt cuộc họp, chỉ duy nhất 1 người nói vào 1 thời điểm. Người đó là người đang thực hiện việc báo cáo tình trạng của mình, những người còn lại lắng nghe. Không ai được lên tiếng hoặc làm việc riêng lúc này.

– Sau khi một thành viên nào đó báo cáo về một điều gì đó gây thích thú cho các thành viên còn lại, hoặc cần sự trợ giúp của các thành viên khác, bất kỳ thành viên nào cũng có thể ngay lập tức sắp xếp tham gia cùng nhau sau khi cuộc họp kết thúc.

– “Gà” không có “tiếng nói” trong cuộc họp này. “Gà” đứng ở khu vực ngoại vi của Team để không gây ảnh hưởng đến cuộc họp này.

– Nếu có quá nhiều “gà” tham dự cuộc họp này, ScrumMaster có thể giới hạn lại số lượng người tham dự để đảm bảo sự ổn định và tập trung.

– “Heo” hoặc “gà” người mà không thể hoặc không theo những quy tắc ở trên sẽ bị loại khỏi cuộc họp (“gà”) hoặc loại khỏi nhóm (“heo”).

Sprint Review Meeting

Cuộc họp được cố định thời gian diễn ra trong vòng 4 giờ.

– Team không nên mất hơn 1 giờ để chuẩn bị cho cuộc họp.

– Mục đích của cuộc họp là để cho Team trình bày cho Product Owner và stakeholder về những gì mà họ đã làm được.

– Những phần chưa hoàn thành xong sẽ không được trình bày.

– Những phần không thuộc về chức năng có thể không được trình bày ngoại trừ khi nó được dùng để hỗ trợ. Những thành phần không được trình bày chẳng hạn như những work product, và việc sử dụng của chúng phải được tối giản nhất để tránh gây nhầm lẫn cho stakeholder hoặc yêu cầu họ hiểu việc phát triển các hệ thống làm việc như thế nào.

– Chức năng nên được trình bày trên máy trạm của thành viên trong nhóm và được thực thi từ máy chủ gần nhất để release – thông thường là một máy chủ môi trường đảm bảo chất lượng (quality assurance environment server).

– Cuộc họp bắt đầu với một thành viên trong nhóm trình bày về mục tiêu của Sprint, Product Backlog đã cam kết và Product Backlog đã hoàn thành. Những thành viên khác sau đó có thể tham gia thảo luận về những gì đã làm được và những gì chưa làm được trong Sprint đó.

– Vào cuối những bài trình bày, các stakeholder được biểu quyết để lấy ý kiến, cũng như những thay đổi mong muốn và độ ưu tiên của chúng.

– Product Owner thảo luận với stakeholder và Team về việc xếp lại Product Backlog dựa trên đánh giá phản hồi.

– Stakeholder có thể xác định tính năng nào không được giao hoặc không được giao như mong đợi và yêu cầu tính năng thay thế trong Product Backlog.

– Stakeholder có thể xác định bất kỳ tính năng mới xuất hiện khi họ xem phần trình bày và yêu cầu bổ sung tính năng mới vào trong Product Backlog.

– ScrumMaster nên “cố gắng” xác định số lượng mong muốn tham dự cuộc họp và tổ chức cộc họp để phù họp với họ.

– Vào cuối cuộc họp, ScrumMaster công bố thời gian và địa điểm của cuộc họp kế tiếp cho Product Owner và stakeholder.

Theo blog của bạn Huy Tran

10 Mẹo Mobile UX

December 30, 2014 IT, Mobile No comments

Khi kênh mobile ngày càng tăng trưởng cùng với công nghệ, lĩnh vực nghiên cứu tương tác người dùng mobile (Mobile UX) cũng phát triển theo. UX tốt là điểm khác biệt chính giữa app thành công và không thành công, làm những ứng dụng mới chiến thắng những tên tuổi lớn bằng cách tạo ra những ứng dụng hấp dẫn hơn. Tôi xin chia sẻ 10 mẹo để tạo bản thiết kế tuyêtk vời dành cho mobile. Ngay cả nếu bạn không trực tiếp làm thiết kế, những mẹo này cũng sẽ giúp bạn có các khái niệm tốt hơn để trao đổi với ngừoi làm thiết kế cũng như kiểm thử các ứng dụng. Những mẹo này theo tôi cũng có thể áp dụng với bản web mobile

1. Đi từ cơ bản

Mặc dù thiết kế UX cho mobile về lý thuyết có một số điểm chung với thiết kế web và phần mềm, nhưng việc đi từ bản thiết kế của phần mềm, thu gọn lại để ra bản app sẽ không hiệu quả. Để thiết kế bản app tốt, cần bắt đầu từ những trải nghiệm người dùng từ mức cơ bản, thêm dần từ những thành phần riêng của bạn. Một bản thiết kế app tuyệt vời sẽ là độc nhất vì vậy cần được xây dựng một cách riêng, không giống với bất kỳ cái nào khác đã có

2. Xác định người dùng

Người dùng di động hiện tại có thể chia làm 2 kiểu: kiểu thợ săn (kiểu tìm kiếm thông tin hoặc làm việc xác định rõ thật nhanh) và kiểu hái lượm (đi lòng vòng thu thập thông tin). Nếu đối tượng người dùng của bạn là kiểu thợ săn, bạn cần tập trung vào các tính năng cho phép họ hoàn thành mục tiêu với ít bước nhất, giảm thiểu các chức năng không thực sự cần thiết. Nếu đối tượng của bạn là kiểu hái lượm, hãy tìm cách giúp họ truy cập nhanh nhất vào các mục thông tin, sau đó xác định cách giữ họ ở lại trong app. Bạn cũng có thể làm cả 2 cách nhưng nên thận trọng, nhiều khi ít hơn là nhiều hơn.

3. Ghi nhớ luật 80/20

Thông thường 80% người dùng app chỉ dùng 20% chức năng của app. Nếu bạn đã có bản online thì cách đơn giản để xác định là nhìn vào cách ngừoi dùng tương tác với bản online của bạn. Có thể xem cụ thể trong dữ liệu với người dùng bản mobile bằng google analytics. Xác định chức năng được sử dụng nhiều nhất, sử dụng dữ liệu này để xác định khoảng 20% kia và đưa vào app để có thể dễ dùng và thuận tiện nhất.

4. Thiết kế theo mục đích sử dụng

Ngừoi dùng mobile muốn hoàn thành mục tiêu nhanh nhất, dù là việc xem lướt (như xem sản phẩm mới) hay có mục tiêu cụ thể (mua hàng). Mọi chức năng trong app nên hướng đến việc giúp người dùng xác định và hoàn thành mục tiêu. Mọi vấn đề râu ria khác nên được bỏ qua. Xu hướng của người dùng mobile là ít thời gian và không gian thiết kế của bạn cũng rất nhỏ, vì vậy không thể để lãng phí không gian và thời gian. Cố gắng phán đoán mục tiêu của người dùng, sau đó xây dựng các khả năng có liên quan có thể xảy ra. Như vậy người dùng có thể nhanh chóng hoàn thành mục tiêu một cách mượt mà.

5. Giữ sự đơn giản

Người dùng mobile không mong muốn đọc các hướng dẫn sử dụng. Các nhắc nhở ngắn cũng tốt nhưng nếu bạn thấy mình phải đưa cả các hướng dẫn dạng FAQ vào thì có nghĩa là không ổn. Hãy ghi nhớ rằng bản mobile không có không gian cho các chú thích kiểu trên web nên việc suy nghĩ sử dung các biểu tượng là cần thiết để tiết kiệm không gian. Về lâu dài, app càng đơn giản càng tốt, dễ bảo trì, nâng cấp hơn. Ghi nhớ câu thần chú:  tính năng càng nhiều người dùng càng ít.

6. Đừng bỏ qua UX của nền tảng hệ thống

Apple, Google và các hãng khác đã bỏ ra hàng tỷ  USD để đào tạo người dùng biết chính xác điều gì tiếp theo khi họ ấn 1 nút, swipe màn hình hay chạm vào 1 icon. Tạo ra các giao diện không theo các chuẩn này có thể làm đội thiết kế vui nhưng sẽ làm người dùng bị bối rối, giảm khả năng tương tác. Thay vào đó, nên tuân theo các chuẩn đã có của hệ thống, thêm các tinh chỉnh của bạn mà không cần thay đổi các chức năng cơ bản. Đọc các hướng dẫn của hệ thống (platform guidelines) để chắc chắn bạn đang dùng đúng thành phần của UI cho 1 chức năng , cũng như nên tuân theo các hướng dẫn ở các vấn đề liên quan khác .  Những hướng dẫn này đều có lý do của nó. Nên dùng một thiết bị bạn đang thiết kế app cho nó trong ít nhất 1 tháng để hiểu và cảm nhận những hướng dẫn này.

7. Người dùng có nhiều hơn một hành động đơn lẻ

Người dùng có thể tương tác với thiết bị nhiều hơn so với bản mô tả. Rất nhiều yếu tố tác động cùng lúc tới người dùng mobile như : âm thanh, sự chuyển động, thông tin từ các cảm ứng trong thiết bị, từ các ứng dụng khác đang chạy… Hãy suy nghĩ về việc bạn sẽ cải thiện trải nghiệm của người dùng một cách thông minh như thế nào, sử dụng các dữ liệu mà người dùng thậm chí không nghĩ đến là cách rất tốt để tạo ra những kết quả ngạc nhiên và đáng nhớ.

8. Thiết kế theo giai đoạn

Một vấn đề không may với các sản phẩm mobile (vốn dĩ có thể di chuyển đến bất kỳ đâu và làm rất nhiều thứ) là có vấn đề gì đó ngắt quãng sử dụng của người dùng. Nguyên nhân có thể đến từ cuộc sống thực của người dùng hoặc đến từ chính chiếc điện thoại. Giữ giao diện app đơn giản và rõ ràng sẽ giúp giảm thời gian nhận thức lại vấn đề của người dùng khi phải quay lại app sau khi bị ngắt quãng sử dụng. Đồng thời , cần hỗ trợ người dùng quay lại vị trí bị ngắt quãng trước đó , điều rất dễ xảy ra khi dùng điện thoại (nhận cuộc gọi , tin nhắn, có việc gấp cần xử lý…)

9. Nhớ rằng bản thiết kế của bạn không phải là hoàn hảo

Ngay cả những người cẩn thận nhất cũng sẽ bỏ sót một vài vấn đề UX. Thậm chí những vấn đề này có thể phát sinh ngay cả khi đã được tính trước. Trong quá trình xây dựng app, một vài ý tưởng về mặt kỹ thuật là bất khả thi, đừng vội bỏ nó đi mà nên quay lại từ đầu, tìm cách thay thế nó bằng cách gần tương tự nhất. Với sự phát triển của công nghệ hiện nay, việc không làm được hôm nay hoàn toàn có thể thực hiện được trogn tương lại gần. Đưa app của bạn vào vòng lặp tiến hóa, sử dụng dữ liệu từ analytics, phản hồi của người dùng, ứng dụng các công nghệ mới để đánh giá lại và cải thiện.

10.   Hơn tất cả ,hãy theo các kinh nghiệm thực tế và trải nghiệm của riêng bạn

Sự khác biệt giữ thiết bị trên mobile và thiết kế thông thường nằm ở chỗ có rất ít không gian dành cho các tính năng và giao diện. Thậm chí nếu bạn không có kinh nghiệm gì trong thiết kế mobile, việc bị ép phải phù hợp với yêu cầu này cùng với trải nghiệm của riêng bạn sẽ giúp bạn có bản thiết kế một cách tự nhiên , tuy nhiên sẽ phải dành nhiều thời gian hơn để cải tiến sản phẩm.

Khi kênh mobile ngày càng tăng trưởng cùng với công nghệ, lĩnh vực nghiên cứu tương tác người dùng mobile (Mobile UX) cũng phát triển theo. UX tốt là điểm khác biệt chính giữa app thành công và không thành công, làm những ứng dụng mới chiến thắng những tên tuổi lớn bằng cách tạo ra những ứng dụng hấp dẫn hơn. Tôi xin chia sẻ 10 mẹo để tạo bản thiết kế tuyêtk vời dành cho mobile. Ngay cả nếu bạn không trực tiếp làm thiết kế, những mẹo này cũng sẽ giúp bạn có các khái niệm tốt hơn để trao đổi với ngừoi làm thiết kế cũng như kiểm thử các ứng dụng. Những mẹo này theo tôi cũng có thể áp dụng với bản web mobile

1.       Đi từ cơ bản

Mặc dù thiết kế UX cho mobile về lý thuyết có một số điểm chung với thiết kế web và phần mềm, nhưng việc đi từ bản thiết kế của phần mềm, thu gọn lại để ra bản app sẽ không hiệu quả. Để thiết kế bản app tốt, cần bắt đầu từ những trải nghiệm người dùng từ mức cơ bản, thêm dần từ những thành phần riêng của bạn. Một bản thiết kế app tuyệt vời sẽ là độc nhất vì vậy cần được xây dựng một cách riêng, không giống với bất kỳ cái nào khác đã có

2.       Xác định người dùng

Người dùng di động hiện tại có thể chia làm 2 kiểu: kiểu thợ săn (kiểu tìm kiếm thông tin hoặc làm việc xác định rõ thật nhanh) và kiểu hái lượm (đi lòng vòng thu thập thông tin). Nếu đối tượng người dùng của bạn là kiểu thợ săn, bạn cần tập trung vào các tính năng cho phép họ hoàn thành mục tiêu với ít bước nhất, giảm thiểu các chức năng không thực sự cần thiết. Nếu đối tượng của bạn là kiểu hái lượm, hãy tìm cách giúp họ truy cập nhanh nhất vào các mục thông tin, sau đó xác định cách giữ họ ở lại trong app. Bạn cũng có thể làm cả 2 cách nhưng nên thận trọng, nhiều khi ít hơn là nhiều hơn.

3.       Ghi nhớ luật 80/20

Thông thường 80% người dùng app chỉ dùng 20% chức năng của app. Nếu bạn đã có bản online thì cách đơn giản để xác định là nhìn vào cách ngừoi dùng tương tác với bản online của bạn. Có thể xem cụ thể trong dữ liệu với người dùng bản mobile bằng google analytics. Xác định chức năng được sử dụng nhiều nhất, sử dụng dữ liệu này để xác định khoảng 20% kia và đưa vào app để có thể dễ dùng và thuận tiện nhất.

4.       Thiết kế theo mục đích sử dụng

Ngừoi dùng mobile muốn hoàn thành mục tiêu nhanh nhất, dù là việc xem lướt (như xem sản phẩm mới) hay có mục tiêu cụ thể (mua hàng). Mọi chức năng trong app nên hướng đến việc giúp người dùng xác định và hoàn thành mục tiêu. Mọi vấn đề râu ria khác nên được bỏ qua. Xu hướng của người dùng mobile là ít thời gian và không gian thiết kế của bạn cũng rất nhỏ, vì vậy không thể để lãng phí không gian và thời gian. Cố gắng phán đoán mục tiêu của người dùng, sau đó xây dựng các khả năng có liên quan có thể xảy ra. Như vậy người dùng có thể nhanh chóng hoàn thành mục tiêu một cách mượt mà.

5.       Giữ sự đơn giản

Người dùng mobile không mong muốn đọc các hướng dẫn sử dụng. Các nhắc nhở ngắn cũng tốt nhưng nếu bạn thấy mình phải đưa cả các hướng dẫn dạng FAQ vào thì có nghĩa là không ổn. Hãy ghi nhớ rằng bản mobile không có không gian cho các chú thích kiểu trên web nên việc suy nghĩ sử dung các biểu tượng là cần thiết để tiết kiệm không gian. Về lâu dài, app càng đơn giản càng tốt, dễ bảo trì, nâng cấp hơn. Ghi nhớ câu thần chú:  tính năng càng nhiều người dùng càng ít.

6.       Đừng bỏ qua UX của nền tảng hệ thống

Apple, Google và các hãng khác đã bỏ ra hàng tỷ  USD để đào tạo người dùng biết chính xác điều gì tiếp theo khi họ ấn 1 nút, swipe màn hình hay chạm vào 1 icon. Tạo ra các giao diện không theo các chuẩn này có thể làm đội thiết kế vui nhưng sẽ làm người dùng bị bối rối, giảm khả năng tương tác. Thay vào đó, nên tuân theo các chuẩn đã có của hệ thống, thêm các tinh chỉnh của bạn mà không cần thay đổi các chức năng cơ bản. Đọc các hướng dẫn của hệ thống (platform guidelines) để chắc chắn bạn đang dùng đúng thành phần của UI cho 1 chức năng , cũng như nên tuân theo các hướng dẫn ở các vấn đề liên quan khác .  Những hướng dẫn này đều có lý do của nó. Nên dùng một thiết bị bạn đang thiết kế app cho nó trong ít nhất 1 tháng để hiểu và cảm nhận những hướng dẫn này.

7.       Người dùng có nhiều hơn một hành động đơn lẻ

Người dùng có thể tương tác với thiết bị nhiều hơn so với bản mô tả. Rất nhiều yếu tố tác động cùng lúc tới người dùng mobile như : âm thanh, sự chuyển động, thông tin từ các cảm ứng trong thiết bị, từ các ứng dụng khác đang chạy… Hãy suy nghĩ về việc bạn sẽ cải thiện trải nghiệm của người dùng một cách thông minh như thế nào, sử dụng các dữ liệu mà người dùng thậm chí không nghĩ đến là cách rất tốt để tạo ra những kết quả ngạc nhiên và đáng nhớ.

8.       Thiết kế theo giai đoạn

Một vấn đề không may với các sản phẩm mobile (vốn dĩ có thể di chuyển đến bất kỳ đâu và làm rất nhiều thứ) là có vấn đề gì đó ngắt quãng sử dụng của người dùng. Nguyên nhân có thể đến từ cuộc sống thực của người dùng hoặc đến từ chính chiếc điện thoại. Giữ giao diện app đơn giản và rõ ràng sẽ giúp giảm thời gian nhận thức lại vấn đề của người dùng khi phải quay lại app sau khi bị ngắt quãng sử dụng. Đồng thời , cần hỗ trợ người dùng quay lại vị trí bị ngắt quãng trước đó , điều rất dễ xảy ra khi dùng điện thoại (nhận cuộc gọi , tin nhắn, có việc gấp cần xử lý…)

9.       Nhớ rằng bản thiết kế của bạn không phải là hoàn hảo

Ngay cả những người cẩn thận nhất cũng sẽ bỏ sót một vài vấn đề UX. Thậm chí những vấn đề này có thể phát sinh ngay cả khi đã được tính trước. Trong quá trình xây dựng app, một vài ý tưởng về mặt kỹ thuật là bất khả thi, đừng vội bỏ nó đi mà nên quay lại từ đầu, tìm cách thay thế nó bằng cách gần tương tự nhất. Với sự phát triển của công nghệ hiện nay, việc không làm được hôm nay hoàn toàn có thể thực hiện được trogn tương lại gần. Đưa app của bạn vào vòng lặp tiến hóa, sử dụng dữ liệu từ analytics, phản hồi của người dùng, ứng dụng các công nghệ mới để đánh giá lại và cải thiện.

10.   Hơn tất cả ,hãy theo các kinh nghiệm thực tế và trải nghiệm của riêng bạn

Sự khác biệt giữ thiết bị trên mobile và thiết kế thông thường nằm ở chỗ có rất ít không gian dành cho các tính năng và giao diện. Thậm chí nếu bạn không có kinh nghiệm gì trong thiết kế mobile, việc bị ép phải phù hợp với yêu cầu này cùng với trải nghiệm của riêng bạn sẽ giúp bạn có bản thiết kế một cách tự nhiên , tuy nhiên sẽ phải dành nhiều thời gian hơn để cải tiến sản phẩm.

Xóa history trình duyệt

October 17, 2013 IT No comments

Sang khách hàng, đang demo sản phẩm ngon lành, tự nhiên khách hàng bảo muốn làm 1 hiệu ứng giống lazada.vn. Ok chuyện nhỏ, mở ngay tab mới, gõ luôn tên vào xem hiệu ứng nó thế nào. Vừa gõ chữ “l” thì trời ơi, FF nó list ra cả loạt các site bắt đầu bằng chữ l … và mấy cái dầu tiên đều từ lauxanh …hihcic, ngượng vãi. đành nhanh chóng gõ tiếp 2 chữ sau để nó mất đi . Vẫn còn đỡ là chỉ 1 khách chứ chưa phải demo cho cả BGD bên khách 😀

Về phải nhanh chóng tìm cách xem có cách nào xóa history của trình duyệt với 1 site nào đó k0!? Hóa ra cũng khá đơn giản, thậm chí là tính năng có sẵn luôn trong, k0 cần addon. Chắc mấy bạn làm FF cũng hay bị dính “bug” này như mình :))

Cách làm là vào menu History -> Show All -> trên cửa sổ History, chọn site cần xóa -> click chuột phải -> chọn “Forget about this site” . Thế là xong vấn đề đã được giải quyết.

Bắt đầu đi xóa các site k0 nên hiển thị đây 😀

 
Follow

Get the latest posts delivered to your mailbox: