Khi nào một ứng dụng quá tùy biến? [đóng cửa]

Giả sử bạn đang phát triển một ứng dụng máy tính để bàn và bạn muốn người dùng có thể tùy chỉnh các menu, nút, sơ đồ bàn phím và các lệnh và thành phần khác. Bao nhiêu tùy chỉnh nên được cho phép?

Tôi thích môi trường của tôi có thể tùy biến khá nhiều. Tôi cũng muốn môi trường có một bộ mặc định tốt để tôi chỉ có thể điều chỉnh các cài đặt tôi cần thay vì phải thiết lập toàn bộ. Có ai có bất kỳ kinh nghiệm người dùng để chỉ để hỗ trợ hoặc mâu thuẫn với sở thích của tôi không?

Hãy nhớ rằng mọi tùy chọn / tùy chỉnh mà bạn thêm sẽ tạo ra một chương trình phức tạp hơn, sẽ khó sử dụng và duy trì hơn. Nếu đó là thứ mà chỉ một tỷ lệ nhỏ mọi người sẽ sử dụng, tôi sẽ hỏi liệu nó có đáng không.

Khi nó sẽ tạo ra một sự khác biệt tích cực đáng kể cho người dùng để cho phép tùy chỉnh.

Về cơ bản, nó giống như bất kỳ yêu cầu nào khác - nó cần phải chứng minh chi phí / nỗ lực để thực hiện nó. Đó có thể là tăng năng suất hoặc khả năng sử dụng, hoặc có thể là một mức độ nào đó làm tăng sự hài lòng của người dùng, nhưng cần có một số lý do để làm điều đó nhằm chứng minh cho nỗ lực liên quan.

Là một người thích tùy biến, các câu hỏi bạn nên tự hỏi mình là:

• Nếu tôi đang trả tiền, tôi sẽ trả gì cho mức độ tùy chỉnh này? Có bao nhiêu người như tôi? Và điều đó sẽ bao gồm chi phí phát triển nó?

• Đối thủ của tôi làm gì? Kỳ vọng cho các sản phẩm trong lĩnh vực này là gì?

• Nếu thay vì dành nỗ lực để làm cho nó có thể tùy chỉnh, tôi đã dành nỗ lực đó cho các tính năng khác, tôi thích cái nào hơn? Điều này có đúng với người dùng thông thường không?

Hãy nhớ rằng, mọi thứ bạn chọn để thực hiện thực sự là điều mà bạn chọn không làm (ít nhất là bây giờ) vì vậy mọi thứ cần phải chứng minh cho nỗ lực cần thiết.

Hãy tự hỏi tại sao bạn muốn để người dùng tùy chỉnh từng điều nhỏ. Có phải để tránh tự mình đưa ra quyết định thiết kế, thay vào đó buộc họ phải sử dụng?

Đây là một bài viết hay của Jeff về chủ đề này: http : //www.codinghorror.com/blog/2005/09/the-probols-with-configurability.html

Người dùng, nói chung, ghét các ứng dụng được cho là kém đến mức họ phải tùy chỉnh để đáp ứng nhu cầu của họ. Theo kinh nghiệm của tôi, hầu hết người dùng không thoải mái khi sử dụng máy tính như người CNTT và sẽ không tùy chỉnh ngay cả khi được cung cấp tùy chọn.

Nếu bạn đang tùy chỉnh để tránh thực hiện một công việc thiết kế phù hợp, bạn đang tùy chỉnh quá nhiều. Nếu bạn đang tùy chỉnh vì bạn thích tùy chỉnh và không phải vì đó là một yêu cầu, bạn đang tùy chỉnh quá nhiều. Nếu bạn có một yêu cầu chính xác để tùy chỉnh, bạn vẫn nên đặt câu hỏi nếu đó là một ý tưởng tốt và tìm hiểu lý do cơ bản tại sao họ nghĩ rằng họ cần tùy chỉnh. Thường thì bạn sẽ tìm thấy một yêu cầu mới mà họ đã đề cập nếu bạn sử dụng yêu cầu tùy chỉnh làm nơi bắt đầu quay số với người thực hiện các yêu cầu.

Nó phụ thuộc vào ứng dụng

Điều này nghe có vẻ như là một cảnh sát, nhưng nó thực sự không (hoặc, ít nhất, không có nghĩa là như vậy).

Số lượng tùy chỉnh nên, một phần, phụ thuộc vào độ tinh vi của người dùng cuối dự kiến. Các loại kỹ sư có nhiều khả năng tham gia và sửa đổi cài đặt người dùng hơn, giả sử, bà tôi chơi trò chơi bài trên máy Win98.

Nó cũng phụ thuộc vào bản thân ứng dụng là gì. Nếu quan điểm của ứng dụng là dễ sử dụng, bạn không muốn làm vấy bẩn điều đó với một loạt các tùy chọn có thể định cấu hình người dùng.

Quá nhiều tùy chọn cấu hình làm cho một ứng dụng dường như quá phức tạp. Nếu bạn tạo một ứng dụng có nhiều tùy chọn này, ít nhất tôi sẽ "ẩn" chúng trong màn hình hoặc hộp thoại cấu hình "Nâng cao ..." và chỉ đặt một tập hợp con những thứ mà người dùng trung bình của ứng dụng đó sẽ muốn thay đổi trên màn hình tùy chọn "thông thường".

Một cách khác là "lột da" một cái gì đó. Điều đó có thể có nghĩa là công cụ "lột da" truyền thống (ví dụ: tab "Giao diện" trên Thuộc tính hiển thị của Windows) hoặc có thể có nghĩa là một tập hợp các tùy chọn được đặt cùng một lúc (ví dụ: tab "Chủ đề" trên cùng hộp thoại).

Tôi thường không bận tâm. Tôi đã phải làm việc trên rất nhiều máy móc khác nhau và việc giữ cho tất cả chúng được tùy chỉnh sẽ gây phiền toái hơn là có vẻ đáng giá. Nếu tôi thực hiện tùy chỉnh trên một máy, tôi sẽ khó chịu khi máy khác không có. Làm cho việc di chuyển các tùy chỉnh xung quanh dễ dàng hơn sẽ giúp ích phần nào (xem xét người dùng emacs và các tệp không thể truy cập trang web của họ), nhưng thường thì tôi vẫn thấy quá nhiều phiền phức.

Nếu ứng dụng của bạn không hoạt động tốt, nhưng cần được tùy chỉnh, bạn đã thất bại.

Tôi thực sự muốn phần mềm yêu thích của mình trên máy, nhưng tôi không nghĩ đó là ý nghĩa của bạn khi tùy chỉnh.

Một vấn đề với khả năng tùy biến là đó là một lời hứa với mỗi và mọi khách hàng mà bạn phải tôn trọng. Bạn gửi phiên bản A, và khách hàng của bạn tùy chỉnh. Tất cả đều tốt và tốt. Bây giờ, bạn làm gì với phiên bản B? Nếu bạn phá vỡ các tùy chỉnh của khách hàng, họ sẽ khó chịu và nếu bạn làm điều đó nhiều lần, họ sẽ rất miễn cưỡng tùy chỉnh, vì vậy bạn sẽ bị bỏ lại với chức năng tùy chỉnh mà rất ít người sử dụng, cùng với đó là khó chịu khách hàng

Điều này có nghĩa là bạn phải chú ý đến những tùy chỉnh mà bạn đã tham gia với mỗi lần nâng cấp. Điều này có thể khiến bạn đau đầu, khi bạn muốn cơ cấu lại một thứ gì đó dễ thực hiện, ngoại trừ việc nó sẽ làm rối tung các tùy chỉnh. Bạn phải chú ý đến các kết hợp tùy chỉnh có thể có thể tương tác xấu.

Một chương trình quá tùy biến khi bất kỳ điều nào sau đây là đúng:

1. Không có mặc định bên ngoài hợp lý cho mọi thứ. Khả năng tùy biến sẽ hợp lý hơn rất nhiều nếu công cụ hoạt động hợp lý ngay cả khi bạn không tùy chỉnh nó. Ví dụ, tôi ghét vi vì hành vi vượt trội của nó về mặt phím phím lùi và phím mũi tên làm gì quá khác so với quy ước trên phần còn lại của máy. Tôi biết điều này có thể được tùy chỉnh đi, nhưng khi tôi đi đến một máy chứng khoán, về cơ bản nó không thể sử dụng được cho đến khi tôi lãng phí một đống thời gian.

2. Bạn đã làm cho chương trình của mình có thể tùy chỉnh sao cho giao diện của nó khác nhau một cách hiệu quả trên mọi máy, bản phân phối Linux, v.v. và bạn thực sự không thể "học một lần, sử dụng ở mọi nơi". Một lần nữa, xem vi.

3. Bạn đã xây dựng một nền tảng bên trong sao cho người dùng sẽ tốt hơn nếu chỉ sử dụng nền tảng bên ngoài để thực hiện những gì họ muốn. Ví dụ: một khi trình soạn thảo văn bản hoặc công cụ xử lý văn bản dòng lệnh trở nên quá mạnh mẽ, có thể dễ dàng hơn để viết một tập lệnh Python nhanh và bẩn để thực hiện các thao tác văn bản phức tạp hơn là tìm hiểu cách sử dụng chúng nền tảng bên trong. Tương tự, một khi thư viện âm mưu trở nên quá mạnh, có lẽ tốt hơn là chỉ để người dùng tương tác trực tiếp với thư viện GUI được xây dựng trên đầu trang để tùy chỉnh các chi tiết tốt hơn của cốt truyện.

TL; DR: Khi ứng dụng của bạn trở thành một khung đáng sợ.

Từ quan điểm của nhà phát triển ứng dụng , đó là khi tùy chỉnh sẽ cho phép ứng dụng phá vỡ theo cách mà việc hỗ trợ trở nên bất khả thi, vì người dùng không thể báo cáo cách anh ta thiết lập ứng dụng hoặc do các tương tác cài đặt khác nhau trở nên quá phức tạp để tạo ra các đầu hoặc đuôi. Hãy suy nghĩ hệ thống tùy biến kỹ lưỡng và cho phép thông tin lấy lại cho bạn một cách có ý nghĩa.

Từ quan điểm của người dùng ứng dụng , đó là khi người dùng cảm thấy muốn thiết lập ứng dụng rất khó khăn, thường là do nó giống với lập trình, cho một định nghĩa lỏng lẻo về "lập trình" (Điều này bao gồm lập trình theo định hướng GUI hoặc Blinkenswitches ).

Có dòng là một mờ .

Có, đôi khi một mã hoặc thiết kế GUI (re) tốt có thể làm cho bảng chuyển đổi ứng dụng ngay cả với cùng một bộ tính năng tùy chỉnh .

Tạo một đường cong học tập giữa các cài đặt "thông thường", "nâng cao" và "chuyên gia". Nó có thể đi tất cả các cách để cung cấp API và / hoặc tập lệnh. Tất cả người dùng không bắt đầu bằng một chân bằng nhau: một hệ thống xếp tầng sẽ khiến mỗi người cảm thấy như ở nhà . Nó cũng có thể tạo ra cảm giác tiến bộ và thành tích khi người mới bắt đầu chuyển từ "giám tuyển" sang "nâng cao".

Các ví dụ điển hình trong các lĩnh vực khác nhau bao gồm Firefox (tùy chọn, about: config, userchrome.css & al.), Chrome (cài đặt cơ bản so với "Dưới mui xe"), Mac OS X (pan trước, "mặc định (1)", applescript / automator) hoặc thậm chí là vimrc của Vim. Ví dụ xấu bao gồm bất kỳ ứng dụng nào có khung cài đặt cảm thấy như một mê cung. Tôi chắc chắn rằng bạn có thể đặt tên cho một nửa tá từ đỉnh đầu của bạn (trừ khi họ làm tổn thương bạn để quên họ).

Firefox có thể là một ví dụ điển hình - người dùng có khả năng tùy chỉnh giao diện người dùng và thêm vào các tiện ích mở rộng khác nhau khi cần. Chương trình cốt lõi không thể tùy chỉnh, nhưng phần còn lại là trò chơi công bằng.

Khi ứng dụng của bạn bị hỏng quá thường xuyên vì lợi ích của khách hàng hoặc sự tỉnh táo của nhà phát triển, bạn có thể có quá nhiều.

Tôi đang làm việc với một ứng dụng máy chủ máy tính để bàn .NET, SQL Server cho phép:

    Custom Tables
    Custom Stored Procs & Views (These can have data modification capabilities as well)
    Creation of custom data sources in the application (Inside or outside the 'live' database)
    Creation of custom grid forms based on custom data source or combining of custom data sources
    Creation of custom reports based on custom data sources
    Creation of custom logic script on data entry fields 
    Customizable data import functionality
    Customizable workflow process data entry and notifications
    Customizable selection and placement of data entry fields/controls on standard forms
    Detailed user security settings to all forms, data CRUD, app functionality and reports

Nghiêm túc, công ty này tạo ra một con thú tùy biến. Nó được thiết kế cho một thị trường dọc, nhưng các triển khai khác có thể là vô hạn.

Tôi thích thiết kế để có thể tùy chỉnh, nhưng trước khi tôi bắt đầu thực hiện nó, tôi muốn có được mọi thứ khác thực sự vững chắc. Trong thực tế, tôi có thể muốn đưa phiên bản 1.0 ra khỏi cửa nơi người dùng có thể xử lý nó trước khi tôi bắt đầu nghĩ về việc thêm các tính năng tùy chỉnh của người dùng.

Trước đó tôi chỉ không biết những tùy chỉnh nào sẽ hữu ích cho người dùng trong thế giới thực của tôi. Có thể họ hài lòng với cách giao diện hoạt động và muốn có nhiều tính năng hơn thay vì có đủ khả năng tùy chỉnh để họ có thể thay đổi vị trí của các nút hoặc các mục menu.

Tôi thà có một giao diện thực sự tuyệt vời buộc tay người dùng phải chịu một chút, hơn là có rất nhiều tùy chỉnh đang diễn ra, nhưng đợi thêm sáu tháng hoặc năm cho đến khi ứng dụng của tôi có thể được phát hành. Vận chuyển là một tính năng!

Ngoại lệ duy nhất cho điều này là nếu tôi yêu cầu tổ hợp phím, trong hầu hết các trường hợp, tôi muốn thực hiện các tùy chỉnh đó, bởi vì bạn không bao giờ biết người dùng nào đang chạy và sẽ rất khó chịu khi va chạm với ứng dụng khác trong một cách mà người dùng không thể dễ dàng làm việc xung quanh.

Bạn có thể thêm các cấu hình ý nghĩa cơ bản và phổ biến nhất vào một menu, để chúng có thể được điều chỉnh trực tiếp từ giao diện người dùng. Mọi thứ khác, phức tạp hơn, bạn có thể đưa vào một số tệp cấu hình hoặc một số phương tiện khác có thể truy cập được từ một công cụ cấu hình hoặc một cái gì đó.

Bằng cách đó, người dùng phổ biến nhất, không chuyên biệt của bạn có quyền truy cập vào các cấu hình cơ bản họ cần để sử dụng ứng dụng, trong khi người dùng chuyên môn, chuyên gia hoặc người dùng quan tâm hơn của bạn có thể sử dụng các cấu hình bổ sung để phù hợp với nhu cầu chuyên môn cao của họ.

Tôi nghĩ rằng đây là sự đánh đổi tốt nhất giữa việc có một ứng dụng thân thiện với người dùng và có khả năng tùy biến cao. Tuy nhiên, sự thành công của việc này là cách bạn phân chia các cấu hình. Đó là những cái quan trọng, chỉ dành cho các tinh chỉnh ưa thích? Đó là phần khó tôi nghĩ. Và đừng quên thêm nút đặt lại vào nút mặc định, trong trường hợp ai đó làm hỏng thứ gì đó.