2

Take the general case of entries classified based on tags - a QA forum such as SO, a traditional forum that's to be designed without categories, a list of articles or blog entries, or other entity types such as pictures, bookmarks, etc.

There are few navigation or filtering techniques that are in common use, such as search boxes(common), progressive filtering (delicious?), and tag clouds (nobody likes them!).

There is also an interesting design that relies on 'interesting tags' and 'ignored tags', which is the focus point of this posting. The design basically provides text entry fields so that the user can add to either the interesting tag set or the ignored tag set, then options are provided to filter based on either of the sets.

Here are some examples of possible variations on this design (the O's are radio buttons or exclusionary selection):

Design one: Simple design, uses both interesting and ignored:

Interesting tags: |___________________|  (X)tagA  (X)tagB 
Ignored tags: |_____________________|  (X)tagC  (X)tagD   

O. Show all tags (ie ignore filters)
O. Show entries with any interesting             
O. Hide entries with any ignored

Used here: http://askbot.org/en/questions/. Also used at SO, but with highlighting and graying out, not actual filtering out.

Design two: give choice for the logical combination of the tags in each set 

Interesting tags: |___________________|  (X)tagA  (X)tagB
Ignored tags: |_____________________|  (X)tagC  (X)tagD

O. Show all tags (ie ignore filters)
O. Show entries with any interesting    O. Show entries with all interesting 
O. Hide entries with any ignored        O. Hide entries with all ignored

Design three: drop ignored tags altogether:

Interesting tags: |___________________|  (X)tagA  (X)tagB

O. show all tags (ie ignore filters)
O. show entries with any interesting             
O. Show entries with all interesting

Some comments on the above:

  • More complex combinations can be provided by the search box. GUI based filtering should focus on the simple use-cases that are common to most users.

  • On design two: I really think that for the case of interesting tags, there should be provided a choice between applying ALL or ANY of the tags in the set. The reason behind this is that tags can have hidden facets in them, for example a subset of the tags can be related to places (country names for example) another set to topics. It would be useful in this case to AND tags from more than one facet (eg: 'Paris', 'museums'). In other situations, where tags are related, the user could be interested in ORing the tags (eg: 'UX','GUI'). On the other hand, ANDing on ignored tags is not of much value, and adds some complexity.

Considering all of the above, which of the designs do you think would provide better usability and utility. Do you have experience in providing any of such designs and how it was received by the users. Do you have ideas for better designs to fulfill the same goals.

Improve this question
4
  • No data, personal preference: The way SO does it. Possibly with the added option of hiding ignored entries all together. Filtering on individual tags is easily done by clicking on one. Showing only items that have ALL interesting tags is going to be futile very quickly. Also, more complicated options are likely not to be used. A more flexible and easier to use/understand design is to provide tag filtering in a search box by using [tag] and allow for exclusion using - signs.
    – Marjan Venema
    Jul 8, 2012 at 9:44
  • The use case I'm concerned about is when some tags do in fact represent categories, as the countries example I pointed out. I have a site where entries are related to countries, but predominantly not consistently. So using tags seems to be acceptable. In this case it would be natural for users to do AND filtering, with one tag as a category tag (country). AND filtering is what SO does in the search box on tags. The question then arises, is using the search box with the features you pointed out suitable for non-tech users? If so, one might do away completely with the GUI path.
    – Basel Shishani
    Jul 8, 2012 at 11:17
  • You could make it easier by not requiring the [] around tags, but have the search engine solve it. If a word is a tag, filter on that tag, but also include entries that don't have it as a tag, but only as a word somewhere in the searchable text. In other words: on top of normal word filtering, entries would be included that do not have the word in the searchable text, but do have it as a tag. And that does happen: questions being tagged for a development language hardly ever repeat that in the actual question.
    – Marjan Venema
    Jul 8, 2012 at 17:56
  • Ok, something to look into. I always thought [term] vs 'term' would be an issue for non-tech-savvy users.
    – Basel Shishani
    Jul 9, 2012 at 22:40

1 Answer 1

Reset to default
3

Once I heard (and I wish I could quote it) that having advanced search was useless. Leave that for advanced users, and it got stuck.

Google provides several operators, such as site:, filetype:, -, "" and some boolean types, I use them right within the textbox, and seldom visit the Advanced Search page which happens to be pretty hidden, where the average user is unlikely find it.

Google Screenshot

This probably to match user expertise to the ability to find the advanced search features which are commonly used by advanced users.

Nonetheless, if you really, really want to have that kind of feature, just keep it simple and go for 3. It's more likely that people will search for things they want and not the ones they want to omit.

But if you really, really, really want those features added, try adding them on the results page, in a column somewhere like Yahoo! Mails does. The column can contain checkboxes with the tags found in the documents that matched your query.

Yahoo! Mail Screenshot

IMO: you should replicate Google's model, leaving Advanced Search to Advanced Users, this will save you lot's of design headaches. Having a clean search interface that can be tweaked with operators in a standard way might be more useful too.

Improve this answer
2
  • 1
    Thx. The filtering form is not meant to be advanced search, to the contrary, it's meant to be simplified navigation. In my thinking, the search box is eqv to CLI, where you can do logic combinations and so on, while the form is eqv to navigation. When using categories we offer users things to click on where they can go to a desired bucket. When using tags, it also makes sense to offer something similar. We can offer clicking on single tags, but because of the nature of tags, that's not really good enough.
    – Basel Shishani
    Jul 15, 2012 at 3:09
  • 1
    So basically, we are after a design that strikes this balance, something that offers bit more utility than isolated tags, but in the mean time isn't too complex to intimidate users.
    – Basel Shishani
    Jul 15, 2012 at 3:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.