Customer Portal

Get Involved. Join the Conversation.

Topic

    Barrilito van Dijk
    SearchSource widgets and problems with search terms
    Topic posted January 23, 2017 by Barrilito van DijkBlack Diamond: 60,000+ Points 
    171 Views
    Title:
    SearchSource widgets and problems with search terms
    Content:

    When the community selfservicewas introduced in OSC, the file structure of OSC customer portal changed.
    Instead of the usual answers/list, suddenly there was this combination of the home page and the result page.
    For searching, instead of the KeywordText widget, suddenly the searchsource widgets were introduced.

    These searchsource widgets don't require a report, but use a source id like "KFSearch,SocialSearch".  I understand this all has been introduced to work along with the community, but I now see some side effects.

    For instance:
    In the home page (/app/home) when you look at the reference files, you see that you can set the results url in the SourceSearchButton like this:


    <rn:widget path="searchsource/SourceSearchButton" search_results_url="/app/results"/>


    When I set this link to the /app/answers/list page instead of the /app/result page then it seems to work, all answers are listed in the /answers/list page. But if you then look in the code of the list page,you see it checks wether the url has a keyword and based on that info it either loads the searchsource widgets or the old well known KeywordText and SearchButton widgets with report 176. Like this:

     

    <rn:condition url_parameter_check="kw != null">
        <rn:container source_id="KFSearch,SocialSearch" per_page="10" history_source_id="KFSearch,SocialSearch">
        <div class="rn_Hero">
            searchsource widgets here...
        </div>
        </rn:container>
            ...
    <rn:condition_else/>
        <rn:container report_id="176">
        <div class="rn_Hero">
            old style KeywordText / SearchButton widget here...
        </div>
            ...
        </rn:container>
    </rn:condition>


    So, to me it feels strange to have two different sets of widgets here to do the same trick?! As if the new set of widgets don't work well if no keyword was defined. If you look into code of widgets you see that there are issues as well with leaving a keyword empty, it will be replaced by a "*". I have not seen situations where "*"is excepted or were working well. Old style reports give no results with "*".


    Anyway, if I do my search now on the home page, and defined in the source ID that I only want to use KFSearch, the results show on the answers/list page. That seems ok, and it looks that I get the good results.  But under the hood it is not. My search term is registered in the clickstreams table which appears to look ok, but unfortunately the term is not being transfered to the search terms table. Simply because that only is done when the search registers an "Search" action in the click stream table and a ResultList action. It now is clear that the search does not set a Search in the clickstream when using the new widgets and redirect it to the answers/list page. Comparing it to the old situation with KeywordText and SearchButton widgets shows that those widgets included an explicit "/search/1" to the url with any search. So, it seems that the new widgets don't do that or need it. That means if I change my home page from:

    <rn:widget path="searchsource/SourceSearchButton" search_results_url="/app/answers/list"/>

    to
    <rn:widget path="searchsource/SourceSearchButton" search_results_url="/app/answers/list/search/1"/>

    it will now work well under the hood as well for the statistics of search terms.

    So, as you may understand it is frustrating to spend hours and hours to understand why "standard out of the box" things don't work the same anymore and that we should now use these searchsource widgets which seem not so flexable as just creating a report and use it. How can I ever explain to my customer where I build these pages for what results will be shown? Normally my customer can verify it using his own report!

    Another issue that comes along with it is the use of the template of the pages. If you look at the pages home, result and list for instance, you see some same kind of look and feel: you see a search widget and some area underneath it. As a developer if you want to build that and see the page, your guess and good approach would be to use a template which will use one search widget that comes back in all pages and therefor will be placed in the template. In the template you could then perhaps use a conditional tag to define in which pages you show that search button. However, the new pages in the reference set are not at all ready to use in a good way in the template. The hero divs being used in each page look the same (visually) but are different when you look at the code and even use different search widgets per page). It looks like this for /app/home, /app/results, /app/answers/list:


    home page:
    <div class="rn_Hero">...</div>

    results page:
    <rn:container source_id="KFSearch,SocialSearch" per_page="5">
    <div class="rn_Hero">
        ...
    </div>
    </rn:container>

    list page:
    <rn:condition url_parameter_check="kw != null">
        <rn:container source_id="KFSearch,SocialSearch" per_page="10" history_source_id="KFSearch,SocialSearch">
        <div class="rn_Hero">
            searchsource widgets here...
        </div>
        </rn:container>
            ...
    <rn:condition_else/>
        <rn:container report_id="176">
        <div class="rn_Hero">
            old style KeywordText / SearchButton widget here...
        </div>
            ...
        </rn:container>
    </rn:condition>


    This means that you can not simply put it in the template, where I think it should be more in the right place. But the code does not work the same, and code is place outside the hero divs, that seems so weird.

    Anyway, when not using the community it seems using the old KeywordText and SearchButton combination and not using the home page / result page and searchsource widgets seems to be the way to go. That works clear and very well. But that means always having to change the standard files!!

    My questions on this topic:

    • why introduce new widgets / pages where there is not a simple report as a parameter (like the default 176). Customers/clients often want different things in the customer portal list page, adding a column to a report is then very easy. How should we do that with the searchsource widgets?
    • why does the SourceSearchButton" widget with search_results_url="/app/results" not automatically adds "/search/1" when using another url then /app/results?
    • why are the hero divs so different and were not being designed and placed in the template?

    Just my thoughts... anyone recognizes these things?

    Regards
     

    Version:
    AUG16