14 điểm bởi GN⁺ 2025-10-31 | 9 bình luận | Chia sẻ qua WhatsApp
  • Giao diện người dùng (UI) phức tạp của phần mềm tự do tạo thành rào cản gia nhập đối với người dùng phổ thông
  • Ngay cả tác vụ đơn giản như chuyển đổi video cũng khiến người dùng phổ thông bỏ cuộc vì UI hướng tới chuyên gia của các công cụ như Handbrake
  • Để giải quyết điều này, tác giả đã tạo một frontend đơn giản tên là Magicbrake với giao diện chỉ có một nút, chỉ cung cấp chức năng "chuyển các tệp video kỳ lạ thành MP4 bình thường"
  • Nếu ẩn bớt các tính năng phức tạp và chỉ hiển thị 20% chức năng mà đa số người dùng thực sự cần, năng suất và mức độ hài lòng sẽ tăng lên
  • Hệ sinh thái phần mềm tự do chỉ có thể mở rộng phạm vi ứng dụng nếu áp dụng thiết kế thân thiện với người dùng phổ thông

Khoảng cách giữa phần mềm tự do và người dùng phổ thông

  • Người dùng phổ thông gặp khó khăn với các vấn đề định dạng ngay cả trong những tác vụ cơ bản như chuyển đổi, tải lên và phát video
    • Những định dạng không phát được trên QuickTime hoặc Facebook đều bị xem là “kỳ lạ”
  • Handbrake rất mạnh mẽ, nhưng do UI hướng tới người dùng chuyên nghiệp nên khiến người dùng phổ thông cảm thấy khó chịu và bối rối
  • Vấn đề này phổ biến trong toàn bộ FOSS (Free and Open Source Software), và kết quả là người dùng phổ thông либо từ bỏ, либо phải nhờ chuyên gia giúp đỡ

Trường hợp của Magicbrake

  • Magicbrake ẩn đi các chức năng phức tạp của Handbrake và chỉ thực hiện một chức năng duy nhất: "chuyển video kỳ lạ thành MP4 bình thường"
    • Kết quả chuyển đổi là tệp MP4 nhỏ hoạt động được trong hầu hết môi trường
    • Giao diện chỉ có một nút
  • Cách tiếp cận này là một giải pháp nhanh và đơn giản, phù hợp với những người dùng không cần các chức năng phức tạp

Phản biện về sự đơn giản hóa và cách đáp lại

  • Một số người đặt câu hỏi như “tại sao lại làm Handbrake bớt mạnh đi”, “nếu cần định dạng khác thì sao?”, “còn các tính năng đặc biệt thì sao?”
  • Câu trả lời rất rõ ràng: ai cần tính năng nâng cao thì cứ dùng nguyên Handbrake, còn ai không cần thì dùng công cụ đơn giản
  • Điều này giống với việc dùng băng keo che các nút không cần thiết trên điều khiển TV: khi cần thì chức năng vẫn còn đó, nhưng trong sử dụng cơ bản thì không gây cản trở

Giá trị của UI đơn giản

  • Có rất nhiều công cụ như máy chủ media khó cấu hình với người dùng phổ thông, trình biên tập âm thanh đòi hỏi phải học ngay cả cho tác vụ cơ bản, hay công cụ giám sát mạng khiến người mới bắt đầu bị loại khỏi cuộc chơi
  • Những công cụ này có chức năng rất tốt, nhưng người dùng phổ thông không thể tiếp cận vì thiết kế cố nhồi mọi tính năng vào một UI duy nhất
  • 80% người dùng chỉ cần 20% chức năng, nên việc ẩn phần còn lại có thể mang đến trải nghiệm năng suất hơn và hài lòng hơn

Đề xuất dành cho nhà phát triển

  • Thiết kế giao diện đơn giản cho người dùng phổ thông là việc có thể làm chỉ trong một buổi tối và mang lại giá trị thực tế lớn
  • Thay vì phơi bày toàn bộ chức năng phức tạp, triết lý thiết kế chỉ hiển thị những gì cần thiết sẽ nâng cao khả năng tiếp cận của phần mềm tự do
  • Tác giả khuyến khích các nhà phát triển tạo ra nhiều công cụ được đơn giản hóa như vậy hơn

9 bình luận

 
bumjins 2025-11-01

Có thể diễn đạt đây là sự phức tạp của UI/UX,
nhưng tôi nghĩ vấn đề là phần mềm được tạo ra dạo này, dù là tự do hay thương mại, thường chỉ được làm để duy nhất 1 trường hợp “đi qua được” thì đi qua được, còn những trải nghiệm khác ra sao thì không mấy được quan tâm.
Ví dụ như khi chỉnh sửa cấu hình toml hay yaml, có những lúc rõ ràng đáng lẽ phải được mà lại không được. Thường thì những chuyện như đây là vấn đề mã hóa, vấn đề thụt lề, hay là tính năng không dùng được khi có một flag nhất định hay không, đều không được tài liệu hóa tử tế. Người dùng phải thử từng trường hợp đủ kiểu rồi mới khó nhọc tìm ra đáp án đúng.

Trong UI thì còn nghiêm trọng hơn. Như chuyện mọi người hay gặp khi đặt lại mật khẩu đã lan truyền thành meme, nếu trên màn hình có 100 trường, thì mối liên hệ giữa chúng là gì, thay đổi thế nào là tối ưu, đều là những thứ “không thử thì không thể biết được”.

Đây vừa là vấn đề UI/UX, vừa là vấn đề của “chuyên môn” bị che giấu. Trong tình trạng không có sẵn một đường cong học tập theo từng nấc, những bài toán mà người có chuyên môn có thể điền ngay đáp án đúng lại đóng vai trò như một bài kiểm tra hay cửa ải đối với người mới bắt đầu, khiến họ phải trải qua vô số lần bị từ chối.

 
lunamoth 2025-10-31

Trong bối cảnh tương tự, có vẻ như GUI vẫn tiện hơn CLI, nên tôi cũng đang dùng yt-dlp qua giao diện GUI là yt-dlg. Với ffmpeg thì tôi ghi chú lại những lệnh hay dùng rồi sử dụng, nhưng có lẽ cũng có thể làm một GUI cho nó.

 
shakespeares 2025-10-31

Đúng là do UI/UX!!

 
euphcat 2025-10-31

Cá nhân tôi cũng đã nghĩ khá nhiều theo hướng tương tự nên thấy khá đồng cảm. Khi tôi cố tìm trên Linux những ứng dụng kiểu như Paint, Notepad, Media Player thời WinXP~7, tức là loại “cứ mở nhanh lên rồi dùng đại là được”, thì may mắn lắm cũng phải cài thử 5~6 cái mới tìm được một cái vừa ý.

Chỉ cần chụp màn hình rồi cắt xén thôi thì không thể dùng Gimp được, tôi không nhớ đã thử những gì, nhưng trong số các ứng dụng gtk lại không tìm ra cái phù hợp nên cuối cùng chốt với Kolourpaint. Còn Notepad thì có Gedit, Kate, Mousepad, Leafpad, Xed các kiểu; nếu muốn tìm cái còn nhẹ hơn nữa thì lại phải chuyển sang những thứ gần như từ bỏ hẳn ý định thân thiện với người dùng như xedit, nano, vim. Chỉ cần nghĩ đến media player như mpv, VLC, mplayer thôi cũng đã thấy ngột ngạt rồi.

 
skageektp 2025-10-31

Những bài như thế này khẳng định là đúng mà còn chẳng có cả thống kê gì, nên thấy hơi khó chấp nhận.

 
xguru 2025-10-31

Người dùng chỉ quan tâm đến 20% của một ứng dụng
Nghĩ kỹ thì có vẻ cũng liên quan đến bài viết ở trên.

 
kayws426 2025-10-31

"Hầu hết người dùng chỉ tận dụng khoảng 20% tính năng của ứng dụng mà họ cần, nhưng 20% đó lại khác nhau ở mỗi người dùng"
Đó chẳng phải mới là điểm cốt lõi sao?

 
ndrgrd 2025-11-01

Cứ hễ có gì là lại nhận được câu trả lời kiểu "hãy đọc man/readme/docs trước đi".
Thực ra, điều quan trọng trong UX là ngay cả khi cứ dùng thử thì cũng có thể lập tức hiểu cách sử dụng.

Vì đây không phải việc làm để lấy tiền nên thường cũng cho qua, nhưng nếu nhìn từ góc độ người dùng không phải lập trình viên thì đúng là trải nghiệm sử dụng không tốt.

 
GN⁺ 2025-10-31
Ý kiến trên Hacker News
  • Đây là một bài viết hay, nhưng tôi nghĩ lập luận bị sai
    Việc tạo ra một giao diện đơn giản, súc tích hoàn toàn không hề dễ
    Làm UI phù hợp với một trường hợp sử dụng cụ thể thì không quá khó, nhưng điều thực sự khó là xác định được đúng “trường hợp sử dụng đó”, rồi ngăn các yêu cầu kiểu “xin thêm mỗi cái này chút nữa”
    Sự đơn giản như vậy là điều đáng mong muốn, nhưng lại ở trong trạng thái không ổn định

    • Thế giới lập trình viên không trực quan hiểu được độ khó của việc thiết kế giao diện tốt cho người không phải lập trình viên
      Độ phức tạp của mã nguồn thì nhìn thấy được, còn độ phức tạp của UI thì không
      Nút bấm và ô nhập liệu trông có vẻ đơn giản, nhưng giải quyết vấn đề bằng thứ ngôn ngữ đó lại cực kỳ phức tạp
      Thất bại thì rõ ràng, nhưng thành công lại mơ hồ và khác nhau với từng người dùng
      Nhiều phần của một giao diện tốt được truyền tải theo kiểu ‘ngầm hiểu’, và đó là phần khó nhất
    • Người dùng phổ thông thường hay đưa ra những yêu cầu lạc quẻ kiểu “nút này có thể làm X không?”
      Dù nút đó gần như không liên quan gì đến chức năng gốc Y, họ vẫn khăng khăng nó phải làm được việc ấy
      Những yêu cầu kiểu ‘chỉ sửa một chút thôi’ như vậy tích tụ dần khiến UI ngày càng phức tạp rồi cuối cùng sụp đổ
    • Phần lớn người đóng góp mã nguồn mở đều là power user, nên họ chỉ tập trung vào việc quy trình làm việc của chính họ có vận hành tốt hay không
      Họ không muốn hy sinh sự tiện lợi của mình để đổi lấy khả năng dùng tốt hơn cho 80% người dùng phổ thông
    • Một cách được đề xuất để ngăn sự sụp đổ UI/UX này là ‘feature freezing’
      Tức là chốt bộ tính năng từ trước rồi sau đó chỉ tập trung vào sửa lỗi và cải thiện hiệu quả
      Tính năng mới chỉ có thể thêm vào sau khi trải qua đánh giá nghiêm ngặt
      Cách này sẽ khó áp dụng với phần mềm thay đổi nhanh, nhưng có lẽ hiệu quả với đa số lĩnh vực đã ổn định
    • Trong ngắn hạn, có lẽ người dùng sẽ giải quyết bằng cách hỏi AI như ChatGPT kiểu “hãy làm cho video của tôi phát được trên điện thoại”, rồi nhận hướng dẫn từng bước
      Về dài hạn, bản thân ứng dụng có thể tích hợp AI để tự động tạo ra UI đúng theo điều người dùng muốn
  • Tôi nghĩ vấn đề này rốt cuộc là chuyện của sự quen thuộc
    Vợ tôi không rành công nghệ nhưng vẫn là người dùng Linux
    Khi bắt đầu công việc kinh doanh mới, cô ấy phải dùng Windows, nhưng thấy quá bất tiện nên muốn quay lại Linux
    Tôi cũng có trải nghiệm tương tự với Mac vs PC
    Khi bị buộc phải dùng Mac, năng suất của tôi rơi xuống còn khoảng 10% và rất khổ sở
    Cuối cùng thì con người làm việc tốt nhất trong môi trường mà họ quen thuộc

    • Hồi học cấp hai, máy tính gia đình bị hỏng nên tôi cài Ubuntu, và mẹ tôi thích nghi rất nhanh
      Rốt cuộc nó cũng chỉ là ‘một cái máy tính’ thôi
    • Tôi cũng được công ty cấp Mac nhưng hầu như không dùng
      May là VPN và các ứng dụng cần thiết đều dùng được bằng Linux + giao diện web
    • Trong các cuộc bàn luận về phổ cập desktop Linux, tầm quan trọng của sự quen thuộc thường bị đánh giá thấp
      Cần một bản phân phối ổn định, có UI gần như giống hệt các OS thương mại và không cần mở terminal
      Điều quan trọng không phải là “na ná giống”, mà là độ hoàn thiện ở từng chi tiết
  • UI của mã nguồn mở ban đầu thường tạo cảm giác xa lạ và phức tạp
    Vì được xây dựng xoay quanh lập trình viên nên nguyên tắc ‘đừng làm người dùng giật mình’ không được giữ vững
    Nhưng nếu dùng đều đặn thì dần dần người ta sẽ quen với triết lý mới và có thể sử dụng thành công
    Tôi cũng đang dùng tốt Firefox, LibreOffice, Avidemux, Virt-manager

    • Dạo này tôi thấy Firefox và Chrome gần như chẳng khác nhau mấy
      Vấn đề là thiếu nhân lực thiết kế
      FOSS chủ yếu có các lập trình viên rảnh thời gian tham gia, còn nghệ sĩ hay nhà thiết kế thì tương đối ít
      Vì vậy nhiều trường hợp chỉ cung cấp được UI ở mức cơ bản
  • Vấn đề UX của trình chỉnh sửa âm thanh miễn phí Audacity thì các nhà thiết kế đã biết rõ
    Họ đã đăng video thiết kế lại UX nhằm giải quyết vấn đề “mode” và “Audacity says no”
    Sau này sẽ còn được cải thiện, và trong mã nguồn mở, UX tốt vẫn còn thiếu nhưng đang dần thay đổi

    • UX là khoản nợ lớn nhất
      Ban đầu đó là ứng dụng được tạo ra để tự dùng, nhưng về sau mọi người lại nói “chức năng thì tốt nhưng UX dở”
      Ngược lại, nếu cải thiện UX thì lại bị chê là “thiếu tính năng”
      Cuối cùng, vì cố làm hài lòng tất cả mọi người mà rơi vào địa ngục redesign bất tận
      Cũng có nhiều trường hợp dự án sụp đổ vì đi làm những thứ như theme engine
    • Vấn đề của Audacity mới không phải bản mới tự thân nó, mà là việc nó thay thế bản cũ
      Nếu chỉ đổi tên rồi phát hành như một sản phẩm mới thì có lẽ chẳng ai phàn nàn
  • Tôi nghĩ lời giải cho vấn đề này nằm ở chuẩn hóa ở cấp độ OS
    OS phải cung cấp UI và workflow một cách nhất quán
    Ví dụ, thay vì “Handbrake” thì sẽ có một ứng dụng mặc định tên “Video Converter”,
    hiểu được các lệnh như “hãy chuyển để phát được trên Facebook” rồi tự áp dụng cấu hình phù hợp
    Cần giảm thiểu thương hiệu ứng dụng, đồng thời người dùng phải có thể kiểm soát hoàn toàn theme và font
    Cũng cần một ngôn ngữ shell tiêu chuẩn liên kết với các chức năng GUI

  • Cuối cùng thì con người vẫn muốn tính năng
    Dù UI phức tạp, nếu học xong mà làm được điều mình muốn thì họ vẫn chấp nhận
    Phần mềm chỉ có các tùy chọn đơn giản thì thị trường nhỏ
    Người không hiểu định dạng video rồi cũng sẽ lên web tìm “convert x to y” để giải quyết
    Nếu đã dùng đến công cụ chuyên nghiệp thì tức là đã bước vào vùng của người dùng chuyên môn

    • Nhưng điều đó không có nghĩa là bắt buộc phải có “phần mềm phức tạp”
      Một UI đơn giản kiểu “thả file vào đây rồi bấm Fix It” vẫn hoàn toàn khả thi
      Tôi nghĩ đó chính là ý cốt lõi mà bài gốc muốn nói
  • Có nhiều lý do khiến mã nguồn mở trở nên phức tạp

    1. Lập trình viên làm ra để phục vụ nhu cầu của chính mình
    2. Chi phí thêm tùy chọn là thấp
    3. Không nghiên cứu người dùng
    4. Bản thân người cài được nó vốn đã là power user
    • Ví dụ như Sonobus được cả người dùng phổ thông đánh giá tốt
      Nhưng phần lớn FOSS có cấu trúc đòi hỏi trình độ hiểu biết kỹ thuật
      Việc học phần mềm phức tạp đôi khi lại hiệu quả hơn về lâu dài
    • Để giữ được giao diện tối giản cần rất nhiều thời gian và năng lượng
      Lập trình viên mã nguồn mở khó có thể ưu tiên chuyện đó trong quỹ thời gian hạn chế
  • Có câu đùa rằng nếu thấy Handbrake khó thì đừng bao giờ cho họ xem ffmpeg
    Bản thân tôi khi lần đầu dùng Handbrake cũng thấy nó dễ hơn ffmpeg rất nhiều

    • Với ffmpeg, trong đa số trường hợp chỉ cần lên Google tìm “cách làm X bằng ffmpeg” là có ngay câu lệnh copy-paste
      Trong khi đó, công cụ GUI thì phải xem video mới học được
    • Nếu chỉ muốn chuyển đổi đơn giản thì ffmpeg lại là UI đơn giản nhất
      ffmpeg -i input.avi output.mp4 là xong chỉ với một dòng
    • Với người quen dòng lệnh thì ffmpeg còn đơn giản hơn Handbrake
      Handbrake hiển thị mọi tùy chọn, còn ffmpeg chỉ nhập thứ mình cần
      Khi đã quen thì có thể điều khiển rất chính xác
      Chính sự đơn giản kiểu “chỉ nhập đầu vào và đầu ra là xong” lại là điểm hấp dẫn
    • Tôi vẫn thường dùng tìm kiếm bằng LLM khi cần tìm lệnh chuyển đổi ffmpeg
      Không hoàn hảo nhưng tôi thấy nó vẫn giỏi hơn mình
    • Tôi lại thấy Handbrake đơn giản chính nhờ workflow dựa trên preset
      Vì thế tôi thấy nó hơi lạ khi được dùng làm ví dụ trong bài gốc
  • Kiểu người như tôi thì lại thích giao diện phức tạp
    Tôi muốn công cụ mặc định coi tôi là người thông minh
    Công cụ dùng thường xuyên thì dù phức tạp hơn một chút, miễn làm việc nhanh hơn là tốt

  • Vấn đề là mỗi người đều muốn một 20% tính năng khác nhau
    UI/UX tốt đòi hỏi vòng phản hồi chặt chẽ giữa tester–designer–developer–user
    FOSS thiếu nguồn lực để làm điều đó

    • Thực ra 80% người dùng phổ thông chỉ muốn cùng một 20% tính năng tương tự nhau
      Nhưng người dùng trung bình của FOSS lại là power user top 1%, nên họ không hiểu điều đó
      Vì vậy cứ hễ cố chuyển sang hướng phục vụ người dùng phổ thông là cộng đồng lại phản đối
    • Nhiều khi FOSS vốn dĩ không phải làm ra cho “khách hàng”
      Lập trình viên tạo ra vì nhu cầu của chính mình, nên sự hài lòng của người dùng có thể không phải mục tiêu
      Đó không phải thất bại, chỉ đơn giản là mục đích khác nhau
    • Với trường hợp như Handbrake, đa số chỉ muốn giảm dung lượng video
      Tính năng nâng cao chỉ có một số ít dùng
      Vì vậy tách thành UI cơ bản + chế độ nâng cao là cách thực tế
    • Vòng phản hồi của FOSS mang tính tự củng cố
      Vì chỉ những người đã quen với UI đó mới đi thử nghiệm, nên thường xuất hiện nhiều ý kiến kiểu “đừng thay đổi gì cả”
      Trong khi đó, các công ty lớn có thể làm user test trả phí với người dùng mới
      Vì thế việc cải thiện UX diễn ra nhanh hơn
    • 99% cộng đồng FOSS là lập trình viên
      Khi mời chuyên gia UI/UX đóng góp thì phần lớn họ không được thấu hiểu