Ví dụ về giao diện người dùng tốt để chọn nhiều bản ghi

Question

Tôi hiện đang xem lại một phần của phần mềm dựa trên Windows của mình và xem xét thay đổi mối quan hệ từ 1-> M thành M-> M. Kết quả là, tôi cần phải điều chỉnh giao diện người dùng để phù hợp với việc chọn nhiều bản ghi có liên quan.

Có rất nhiều cách để xử lý việc này phổ biến, nhưng thường khá khó khăn. Ví dụ bao gồm danh sách hai ngăn của tất cả các mục và danh sách các mục đã chọn hoặc danh sách tất cả các bản ghi và hộp kiểm bên cạnh mỗi mục được áp dụng.

Trong trường hợp của tôi, có thể có rất nhiều (trong hàng chục nghìn) bản ghi có thể được liên kết, vì vậy tôi có thể cần bao gồm một số loại cơ chế tìm kiếm.

Tôi không tìm kiếm câu trả lời khó và nhanh - Tôi có thể thực hiện một điều gì đó khá dễ dàng, đó là cách để xem liệu có ai ở đây đã đưa ra (hoặc nhìn thấy) bất kỳ giao diện người dùng tuyệt vời nào để thực hiện loại điều này, cho dù đó là web dựa trên, Windows, Mac, Unix, bất cứ điều gì.

Hình ảnh hoặc liên kết tới chúng sẽ được đánh giá cao!

Edit: đây là một ví dụ về những gì tôi đang xem xét:

Answer 1

Tôi thích cách StackOverflow liên quan nhiều thẻ với nhiều câu hỏi:

alt text http://img11.imageshack.us/img11/7062/imagen9n.png

_{mục được hiển thị như các loại dùng}

1. Bạn bắt đầu rõ ràng với các bản ghi bạn muốn để liên kết nhiều mục với.

2. Như bạn gõ tìm kiếm hiển thị các trận đấu (không cần phải bấm vào "Tìm kiếm")

3. Người dùng chọn các bản ghi mong muốn (Sorting sẽ được tốt đẹp. SO sử dụng "tag liên quan". Ví dụ gõ 'a' mang Java chứ không phải asp vì Java có nhiều câu hỏi hơn asp, trong trường hợp phù hợp của bạn có thể là tên người dùng)

4. hệ thống này tạo ra các mối quan hệ (trong bộ nhớ)

5. Nếu một số kỷ lục (5+) đang điền vào trường nhập, chúng được chuyển vào khu vực bán regid (không phải là một vấn đề SO bởi vì nó chỉ có 5 thẻ withing một câu hỏi duy nhất, nhưng trong trường hợp một cái gì đó của bạn như "thẻ thú vị" tính năng sẽ là cần thiết)

alt text http://img7.imageshack.us/img7/8753/imagen12p.png

_{mặt hàng có liên quan được chuyển đến một "cứng nhắc" khu vực}

Tất nhiên một cách ra lệnh (sử dụng một bảng)

012.351.
• Cuối cùng khi người dùng kết thúc với liên kết, nhấp vào nút SAVE hoặc CANCEL.

Cách tiếp cận này có hiệu quả cao hơn do không cần người dùng nhấn vào "tìm kiếm" hoặc "thêm người khác" làm họ mất tập trung vào những gì họ đang làm.

Ngoài ra, nếu bạn làm cho người dùng lấy con chuột bấm vào một cái gì đó trong khi họ đang gõ UI là kém hiệu quả (Tôi nghĩ có cái gì đó gọi là Hick's law về điều đó, nhưng khá thẳng thắn Tôi có thể sai)

Như bạn thấy cách tiếp cận này là khá nhiều những gì bạn có trong tâm trí, nhưng thêm một số cơ sở để làm cho người dùng hạnh phúc hơn (Sự nguy hiểm sẽ là nếu người dùng yêu cách này và muốn nó trong các phần khác của hệ thống)

Answer 2

Một tính năng tìm kiếm để lọc các bản ghi trong thời gian thực khi bạn gõ có lẽ sẽ là một ý tưởng tốt để bao gồm. Khác sẽ là khả năng để sắp xếp các hồ sơ.

Vì có thể có nhiều bản ghi, lựa chọn tốt nhất trong trường hợp này có thể là khu vực riêng biệt hiển thị những gì bạn đã chọn để người dùng không phải cuộn quanh khu vực lựa chọn để tìm những gì họ đã có.

Answer 3

Tôi nghĩ rằng những gì bạn đã chế nhạo là một cách khá tốt để làm điều đó. Khi bạn nghĩ về mối quan hệ gắn thẻ trên blog (hoặc trên SO ngay cả), đó là nhiều người và thường được triển khai rất giống nhau: đối với một bài đăng, bạn tìm kiếm (hoặc, vì chúng đơn giản chuỗi, nhập trực tiếp) dưới dạng nhiều thẻ như bạn muốn liên kết với nó. Tôi không thể thực sự nghĩ về bất kỳ mối quan hệ nhiều-nhiều mà tôi gặp thường xuyên, mặc dù tôi biết có thể nhiều người ...

Answer 4

Tôi khuyên bạn không phải nhấp vào để thêm để có thể tìm kiếm. Các cảnh báo ở bên phải là tốt đẹp, nhưng IMHO nó chỉ nên nói tìm kiếm hiển thị kết quả như là loại người dùng.

Sắp xếp một cột (có thể cùng với tìm kiếm) cũng sẽ là một chức năng tốt. Tôi cho rằng nó đang được thực hiện bằng cách nhấp vào tiêu đề của bảng, với một số biểu tượng cho biết loại sắp xếp tăng dần hay giảm dần.

Tôi cũng khuyên bạn nên tìm kiếm để thực hiện approximate string matching trong trường hợp không có hoặc ít kết quả. Thật khó chịu khi không thể tìm thấy thứ gì đó mà bạn không nhớ chính xác.

Cuối cùng, để thử nghiệm lần hiển thị đầu tiên (mặc dù không phải là chính chức năng), tôi khuyên bạn nên tải nó lên 5 second test và xem những gì bạn nhận được.

Answer 5

self-explanatory GUI http://img25.imageshack.us/img25/8568/28666917.png

Liên kết với các original image

Một điều nữa là, mà theo ý kiến ​​của tôi vấn đề của bạn không phải là về việc chọn lựa nhiều hồ sơ, nhưng lọc những hàng chục ngàn hồ sơ.Liên kết M-> M có thể được thực hiện theo nhiều cách, nhưng phần phức tạp là cung cấp một cách thuận tiện và hợp lý để duyệt/tìm kiếm lượng dữ liệu khổng lồ.

Answer 6

Đó là một vấn đề giao diện người dùng thú vị và khá phổ biến, cách chọn mục hiệu quả. Tôi giả định rằng bạn đang có ý định có người dùng đầu tiên chọn một mục duy nhất và cơ chế bạn quan tâm là cách chọn các mục khác có liên quan đến mục đơn đầu tiên này.

Có nhiều phương pháp chọn khác nhau. Từ quan điểm khả năng sử dụng, sẽ tốt hơn nếu chỉ có MỘT phương thức được sử dụng cho từng kịch bản. Sau đó, khi người dùng nhìn thấy nó, họ sẽ biết phải làm gì.

kỹ thuật khác nhau lựa chọn:

1. danh sách thả xuống - rõ ràng cho Selects duy nhất.
2. mở danh sách đa chọn - ví dụ: một textbox multiline cho thấy 10 hoặc 20 dòng và có một thanh cuộn
3. danh sách thả xuống mà bạn chọn sau đó nhấn và 'thêm' liên kết hoặc nút để thêm nhiều Selects
4. danh sách di chuyển - nơi bạn có hai danh sách mở, với tất cả các lựa chọn có sẵn trong danh sách bên trái, bạn chọn một vài sau đó bấm vào một nút để di chuyển lựa chọn của bạn vào danh sách bên phải.
5. Hộp kiểm - tốt cho chỉ một vài lựa chọn về nhiều khả năng lựa chọn.
6. Danh sách các hạng mục, mỗi một 'thêm' nút bên cạnh họ - tốt cho các danh sách ngắn

Bạn đã cho biết rằng bạn sẽ có hàng ngàn sự lựa chọn tốt, để loại bỏ 1 và 5. Thật , hàng ngàn sẽ loại bỏ tất cả chúng, vì khả năng sử dụng không mở rộng tốt với hơn một vài trăm trong danh sách.

Nếu bạn có thể dựa vào người dùng để lọc danh sách, như trong ví dụ của bạn, thì 6 có thể phù hợp. Nếu bạn nghĩ cách gắn thẻ hình ảnh Facebook hoạt động, tôi nghĩ rằng nó khá hiệu quả cho các danh sách dài: nền: Gắn thẻ hình ảnh Facebook là một cơ chế cho phép bạn gán một hoặc nhiều người cho các phần của một hình ảnh - tức là 'gắn thẻ' chúng.

Khi bạn chọn một hình ảnh để gắn thẻ (tức là 'một mục duy nhất') và muốn liên kết các mục khác (người) với nó, một hộp thoại bật lên. Nó chứa 6 hoặc nhiều tên mà bạn đã sử dụng trong quá khứ và một hộp văn bản nơi bạn có thể bắt đầu nhập tên của người mà bạn muốn sử dụng. Khi bạn nhập, danh sách sẽ tự động thay đổi để giảm số người chỉ với những người chứa chuỗi ký tự bạn đã nhập. Điều này hoạt động rất tốt cho các danh sách lớn, nhưng nó dựa vào việc gõ người dùng để lọc. Nó cũng sẽ dựa vào việc sử dụng kịch bản để giảm thông minh danh sách dựa trên đầu vào của người dùng.

Đối với ứng dụng của bạn, nó sẽ dựa vào người dùng thực hiện bước này một lần cho mỗi liên kết, vì tôi giả định rằng các mục khác sẽ không có cùng tên!

Dưới đây là một hình ảnh của ứng dụng gắn thẻ Facebook: http://screencast.com/t/9MPlpJQJzBQ

Answer 7

Có một số câu hỏi quan trọng để xem xét - có bao nhiêu hồ sơ thông thường sẽ được sử dụng (như trái ngược với sẵn cho hiệp hội)? Sẽ có một số lượng lớn các hồ sơ ở một bên của hiệp hội (được chuyển đổi từ 1-> M, điều này có vẻ như có khả năng)?

Nếu một trong số lượng bản ghi thường rất nhỏ (< 10, tôi muốn nói), gọi đây là LHS (vì thường là), thì cách tốt nhất để liên kết có thể là cho phép tìm kiếm LHS và RHS mục, sau đó kéo và thả chúng vào một danh sách - LHS mục vào danh sách thích hợp; RHS mục vào các mục LHS hiện có. Bằng cách đó, nó trực quan để xác định mối quan hệ giữa các mục. Bạn cũng có thể thêm các tùy chọn khác như "liên kết với tất cả" hoặc bút nhóm để bạn có thể gán nhiều bản ghi cho một số bản ghi khác - không có gì tẻ nhạt như phải thực hiện 15 lần kéo và thả cùng một bản ghi.

Thực tế, tôi nghĩ đó là phần quan trọng nhất của bất kỳ thiết kế M-> M UI nào - giảm thiểu sự lặp lại. Làm điều tương tự cho hơn 100 bản ghi (hãy nhớ rằng nếu "không ai sẽ ...", họ sẽ) là không thích hợp, đặc biệt là nếu nó phức tạp. Tôi biết điều này dường như mâu thuẫn với lời khuyên trước đây của tôi, nhưng tôi không nghĩ rằng nó - thiết kế cho trường hợp sử dụng điển hình, nhưng chắc chắn rằng những người không điển hình không làm cho chương trình không sử dụng được.