Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
1 to 11 of 11
I wished to check if there was anything on ’dessins d’enfants’ already on the Lab, so I did a search on ’dessin’ . I got 6 entries and only one has the search text in evidence. Of course it must be there but a Firefox search of the page does not give it. It is there but hidden in a link address to Bruno Kahn’s slides. The search thus is correct but gives different criteria than the Firefox one which searches the visible text (as given by the html code) rather than the source code. Interesting. I mention it as it explains some search results that I have obtained in the past and failed to understand.
Your supposition is correct: Instiki searches the source text of each page when you do a search using Instiki’s search engine. This is the only sensible behaviour for Instiki to do. If you want to search the rendered text, the best option is to ask your local friendly web search engine to do it (I think that specifying site:ncatlab.org restricts the search to just that domain).
Once I realised what was happening, it was obviously the best way for the systems to proceed, but I was confused for a moment or two untillthe penny dropped. I wonder if it is a useful thing to note somehwere with an example.
This is the only sensible behaviour for Instiki to do.
Andrew, I am not sure why you say that. This is not too important, but since the issue keeps coming up, I’ll make a remark.
I think if a piece of software with a user interface shows behaviour that consistently perplexes the user, then things are suboptimal.
It may well be true that the software is developed only by volunteers, and that it be way too much to ask that it be free of bugs and misbehaviour, and that we have lots of reason to be very grateful for the software that we do have – but I think we should still call a bug a bug and not a feature. In our own interest.
We had a similar discussion recently about the “TeX”-functionality of the Lab. For all practical purposes it is broken. For it to work the user has to have detailed knowledge about the inner workings of the routine and may have to intervene considerably by hand to get any output at all. The random user who just opens an Lab page, sees the “TeX” button and hits it will just be perplexed by the result. That’s a bug. It’s something that does not improve the impression that the Lab makes in the public.
I can well accept that this is the way things are, given that I did not pay a cent for this software. But it seems umwise to try to convince myself that this is the only sensible behaviour of the software.
Here, if people who wish to search the Lab have to know that for doing so they should rather not use instiki’s search function seems hardly sensible behaviour! Possibly this is the most easily implemented behaviour. This I can believe. And probably we have no right to expect anyone to sit down and implement better behaviour. This I can believe, too.
But if we don’t even allow ourselves to mention the functionalities that need to be improved, then the chance that some day somebody will do it decreases even more.
@Urs As far as the search in Instiki goes, it is not that it is not efficient, it is very good. The point that I was making is that it also finds hidden mentions of the search term. (so one might think it is finding anomalous instances of the term). I realised what was happening when I rested the cursor on the point that the search had produced. I then saw that the term ’dessin’ occurred in the address of the link, i.e. in the link there is the part one sees on the screen and the URL of the link and you do not see that bit. This was clear from the source. Knowing about the difference is all that is needed. It in fact could be very useful, and better than search of the (html) page.
I suggest that in FAQs there should be mention (if there isn’t already) of the fact. Something to the effect of:
When searching, please note that the Instiki search will look for your term not just in the visible pages but in the source, so if you see some extra pages which do not seem to have your search term in them, look again. Look below the surface clicking on source to see the Instiki source code. This may provide you with additional information. Whether that information is useful or not depends on the situation, of course.
It in fact could be very useful, and better than search of the (html) page.
All right, then my point is moot.
I suggest that in FAQs there should be
Go ahead.
I agree with Andrew; I like the current thorough search behaviour. I’m having a hard time coming up with a realistic situation where I would want to search only the visible text (and so would have to go to an external search engine). But I’m glad that I can search for text hidden in URIs, iTeX source, redirect commands, etc, all of which external search engines won’t do.
However, confusing the user is still a bad thing. A FAQ entry would be fine, but more directly, perhaps a useful message at the top of the search results? Specifically, instead of
containing search string in the page text
how about
containing the search string in the source text of the page
? (I also fixed the grammar.)
I think that sounds good. I have yet to write a FAQ!
I remember that IBN leads to some nice other consequences, …. but for the life of me I cannot remember what. Probably something to do with derived functors of Lim as when I knew about IBN that was the sort of thing I was doing.
Tim, does your last comment belong here?
Oh ! That was where it went!!! I thought I had put that elsewhere. :-( Silly me! I then thought it had got lost.
1 to 11 of 11