Closed chrisdavenport closed 8 years ago
andrepereiradasilva
commented
8 years ago ok. i never really understanded the com_finder. never tried to.
In my view all terms should be as more usable as possible for users with little knowledge.
For instance, what exactly does the "Contents Maps" page do? I guess is some type of categorization of the "Indexed Content" and you can disable the whole "category" here. right?
rgmears
commented
8 years ago I'm with @andrepereiradasilva on this @chrisdavenport. I have never understood the Smart Search component, aside from indexing pages.
chrisdavenport
commented
8 years ago Here goes...
As well as indexing terms and phrases within the content, you can also add attributes to the index that you might want to search on. These are typically used in the UI as filters. In the default Smart Search component/module they are used to populate the advanced search drop-downs, but they can be rendered in many different ways. For example, on this site they are rendered as checkboxes: http://www.ivr.org.uk/ivr-evidence-bank (that's actually an old site which is using Finder, but nothing much has changed).
A more up-to-date example is http://www.stentonsestateagents.com/ where I used drop-downs for several attributes including some numerical ranges which was achieved by defining a taxonomy of overlapping sets. It's all powered by Smart Search, so you can see it's pretty flexible.
It's important to remember that Smart Search is content-agnostic; so these attributes, like the terms and phrases, can be present in different content types. To make it possible to filter a specific content type, the Type branch is always present across all content types. All the other branches are optional. Since categories are a type of content, they appear in this branch.
There is also a branch called Category because many content items have a concept of category and we might want to filter on that. Similarly with Author and Language. But it's up to the plugins (in the finder plugin group) to define the different attributes that are to be searchable. If you look at the code you will see them referred to as "taxonomies", which is the generally accepted term used in the information retrieval literature. But it was felt that Content Maps was a bit more meaningful to general users.
When filtering on these taxonomies, any selections made within a branch are logically ORed together, whereas selections made across different branches are logically ANDed. As well as using drop-downs or checkboxes to render a user-friendly UI, you can, in theory, include taxonomies in search queries (ie. in the text box in the component/module search form). This is known to be a bit buggy at the present time (it's long been on my list of things I want to fix), but it does partially work. The syntax is very crude and it would be interesting to make it more powerful/flexible. For example, you should be able to enter a search query like:
author:joomla and einstein and before:2015-01-01
which will search for content items containing the word "einstein" with an author of Joomla that were created before 1st January 2015. I'm not sure how much of that is actually working right now, but the code is all there, it just needs debugging. In theory this is also multi-lingual, so the taxonomy names and values are all passed through the translation system (including the logical operators "and", "or" and "not") so you can enter search queries in your own language. (There is a known bug in that "before", "after" and "exact", which are used in date queries, are not currently translated).
Hope that makes a bit more sense!
brianteeman
commented
8 years ago It does make sense that instead of branches they are called map groups or perhaps even just groups
brianteeman
commented
8 years ago Presumably this string on the statistics modal would changed from The indexed content on this site includes 13,762 terms across 147 links with 43 attributes in 6 branches. to The indexed content on this site includes 13,762 terms across 147 links with 43 attributes in 6 map groups.
rgmears
commented
8 years ago Why not
The indexed content on this site includes 13,762 terms across 147 links with 43 attributes in 6 Categories.
Categories being more akin to Joomla jargon.
Thanks for the explanation @chrisdavenport. I think a chart would make more sense, though.
andrepereiradasilva
commented
8 years ago Thanks for the explanation!
IMHO:
Index GroupsStatus, Group Title, Indexed Content
(yes, i would drop the Maps columns, if is only for debug we can activated it only in debug view)
Note: if possible the values in "Indexed Content" with link to "Indexed Content" view with the indexed content filtered (ex: search filter auto populated with the query command).- Select Main Group -The indexed content on this site includes 13,762 terms across 147 links with 43 attributes in 6 groups.rgmears
commented
8 years ago Inasmuch as I am going off into the woods a bit here, perhaps the word "cluster" would be more appropriate.
RCheesley
commented
8 years ago If we could choose, I'd go with taxonomies, as I feel that using the word 'content' is misleading and taxonomies is becoming much more widely understood with the use of schema. Content map would be the next best thing, as the term 'map' is relatively commonly used with search stemming and users are probably more likely to understand it.
I don't think that branches and nodes is a sensible way of explaining this setup and found it somewhat confusing to have Content Maps in the side bar and branches in the dropdown, so it definitely needs normalising. I'd agree with @chrisdavenport's original suggestion as to the terms to be used.
For reference I just checked the help screens which also need a bit of attention here I guess! https://help.joomla.org/proxy/index.php?option=com_help&keyref=Help35:Components_Finder_Manage_Content_Maps
michaelhq
commented
8 years ago brianteeman
commented
8 years ago
For the original inspiration see https://github.com/joomla/joomla-cms/pull/10068
I've been giving this a little thought and I think that "map group" would be a better term than "branch" in this context. We already refer to the page as "Content Maps" so I think we should reinforce that term rather than introducing any new ones.
I'm thinking that the page should show a list with columns "Status", "Title", "Maps" and "Content items". The drop-down "Select branch" becomes "Select map group". The column "Maps" contains the number of maps within the map groups (this is something that was dropped in this PR, but is actually quite useful). The column "Content items" replaces "Nodes".