Processing math: 100%
Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics complex complex-geometry computable-mathematics computer-science constructive cosmology definitions deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nforum nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
    • CommentRowNumber1.
    • CommentAuthorTim_Porter
    • CommentTimeDec 7th 2010

    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.

    • CommentRowNumber2.
    • CommentAuthorAndrew Stacey
    • CommentTimeDec 7th 2010

    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).

    • CommentRowNumber3.
    • CommentAuthorTim_Porter
    • CommentTimeDec 7th 2010

    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.

    • CommentRowNumber4.
    • CommentAuthorUrs
    • CommentTimeDec 7th 2010
    • (edited Dec 7th 2010)

    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 nLab. 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 nLab 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 nLab 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 nLab 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.

    • CommentRowNumber5.
    • CommentAuthorTim_Porter
    • CommentTimeDec 7th 2010

    @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.

    • CommentRowNumber6.
    • CommentAuthorUrs
    • CommentTimeDec 7th 2010

    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.

    • CommentRowNumber7.
    • CommentAuthorTobyBartels
    • CommentTimeDec 12th 2010
    • (edited Dec 12th 2010)

    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.)

    • CommentRowNumber8.
    • CommentAuthorTim_Porter
    • CommentTimeDec 12th 2010

    I think that sounds good. I have yet to write a FAQ!

    • CommentRowNumber9.
    • CommentAuthorTim_Porter
    • CommentTimeDec 12th 2010

    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.

    • CommentRowNumber10.
    • CommentAuthorTobyBartels
    • CommentTimeDec 12th 2010

    Tim, does your last comment belong here?

    • CommentRowNumber11.
    • CommentAuthorTim_Porter
    • CommentTimeDec 12th 2010

    Oh ! That was where it went!!! I thought I had put that elsewhere. :-( Silly me! I then thought it had got lost.