Edgewall Software
Modify

Opened 16 years ago

Closed 6 years ago

Last modified 4 years ago

#4309 closed enhancement (fixed)

Enable quickjump in the Search preference panel

Reported by: anonymous Owned by: Ryan J Ollos
Priority: normal Milestone: 1.2
Component: search system Version: 0.10.2
Severity: normal Keywords: quickjump, preferences
Cc: Branch:
Release Notes:

Add a notice when quick-jumping from the search box to a resource.

API Changes:
Internal Changes:

Description (last modified by Emmanuel Blot)

If you in the search box write a name that is interpreted as a WikiPage ie in camelcase you dont get search results instead you get the wikipage.

To try it out search for ex AfdBfd. In the search box in the right top corner.

Attachments (2)

quickjump_explicit_r5237.diff (517 bytes ) - added by Waldemar Kornewald <wkornewald> 15 years ago.
with this patch you have to prepend a search with '!' in order to do the quickjump. otherwise you do a normal search
quickjump_explicit_r5237_colon.diff (819 bytes ) - added by Waldemar Kornewald <wkornewald> 15 years ago.
in order to not introduce inconsistencies I changed the code to use ':' for executing a quickjump

Download all attachments as: .zip

Change History (32)

comment:1 by Emmanuel Blot, 16 years ago

Description: modified (diff)
Resolution: worksforme
Status: newclosed

This is not a bug, this is a feature ;-)

Add a ! before the searched word: !AfdBfd. See TracSearch#DisablingQuickjumps

comment:2 by Christian Boos, 16 years ago

Yes, and besisdes this has been discussed before: see #1269 and #2532.

We thought about not jumping to a page known to be missing, but some people are using that behavior as a shortcut to create new pages…

comment:3 by anonymous, 16 years ago

Resolution: worksforme
Status: closedreopened

I would say that this is viewed as a bug for somebody that doesnt know that it is intended. And it is not really intuitive to know how you should do to disable it.

I would say that if you want to do quickjump you should do something active and not the other way around. As you now disable quick jumps, this could instead be used to enable them.

If the current behavior isnt changing. Somehow information that one did a quickjump and how to disable it should be showed for the user. For example a red box on top when you have done a quickjump that explains what happened.

In any case I think that if it is kept as it is know, this bug will reappear many times….

Best regards,

T

comment:4 by Christian Boos, 16 years ago

Keywords: quickjump added
Milestone: 0.11

Well, as we now have fancy preference panels, we could think about making that a user preference:

  • new users won't have the quickjump active, so they don't risk to get confused
  • advanced users will keep having that behavior, which they rely on for daily work…

… and you make the transition from new user to advanced user by reading the documentation displayed next to the Enable Quickjump checkbox in the Search preference panel.

comment:5 by Christian Boos, 16 years ago

Component: generalsearch system
Keywords: preferences added
Summary: When searchin with a term in CamelCase you dont get search results instead you go the page.Enable quickjump in the Search preference panel

in reply to:  4 ; comment:6 by Emmanuel Blot, 16 years ago

Replying to cboos:

Well, as we now have fancy preference panels, we could think about making that a user preference:

Why not, although it will require a DB table update (session) so that the default settings do not change for existing users.

BTW, I really think we should stop adding features for 0.11

Last edited 6 years ago by Ryan J Ollos (previous) (diff)

comment:7 by Emmanuel Blot, 16 years ago

s/does/do/

in reply to:  6 comment:8 by Christian Boos, 16 years ago

Milestone: 0.111.0

Replying to eblot:

BTW, I really think we should stop adding features for 0.11

Well, this one (and a lot of other minor stuff currently scheduled for 0.11) will not prevent 0.11 to be released. I only used that milestone as a rough estimate/wish. But probably 1.0 would be more appropriate in those cases, yes.

(which doesn't mean it couldn't be done earlier of course, e.g. if someone contributes a patch!)

by Waldemar Kornewald <wkornewald>, 15 years ago

with this patch you have to prepend a search with '!' in order to do the quickjump. otherwise you do a normal search

comment:9 by Waldemar Kornewald <wkornewald>, 15 years ago

Our developers have problems with the default behavior. They didn't know how to disable this function and so they were unable to find a bug by entering a CamelCase function name. This was really annoying. I think that quickjump should always be explicit. With my patch you can enter "WikiWord" and you get to the respective wiki page. If you just enter "WikiWord" the search results still suggest to do a quickjump.

comment:10 by Emmanuel Blot, 15 years ago

The proposed syntax reverts the convention of "!" which is to disable wikification. In this case, "!" would indicate to use the wiki format. This is inconsistent with Trac.

Moreover, I'd like to keep the syntax as it is as Trac-aware people are used to this syntax and use it a lot. It does not mean that disabling quick jumps is not an option, but I think we need something easier to use: why not a checkbox close to the search field (the checkbox status being stored along with the user preferences)?

comment:11 by Waldemar Kornewald <wkornewald>, 15 years ago

A checkbox takes up quite a bit of space and IMHO doesn't work very well because when you've only used quickjump once you have to disable it, again, with the next search. You can't even disable quickjump immediately.

Since this is about consistency, what about using some other character, then? E.g., ':'. This solution is much more accessible.

by Waldemar Kornewald <wkornewald>, 15 years ago

in order to not introduce inconsistencies I changed the code to use ':' for executing a quickjump

in reply to:  11 ; comment:12 by Emmanuel Blot, 15 years ago

Replying to Waldemar Kornewald <wkornewald>:

Since this is about consistency, what about using some other character, then? E.g., ':'. This solution is much more accessible.

Sounds a bit "geeky" to add escape characters to perform (or not) a feature. Still, wiki is on everywhere, but would be off by default in the search box: in one case wiki is disabled with an escape char, in the other case it is enable with another escape char.

Another solution would be to replace the search button w/ two small buttons, one for search, the other for quickjump.

in reply to:  12 comment:13 by Waldemar Kornewald <wkornewald>, 15 years ago

Replying to eblot:

Replying to Waldemar Kornewald <wkornewald>:

Since this is about consistency, what about using some other character, then? E.g., ':'. This solution is much more accessible.

Sounds a bit "geeky" to add escape characters to perform (or not) a feature. Still, wiki is on everywhere, but would be off by default in the search box: in one case wiki is disabled with an escape char, in the other case it is enable with another escape char.

Is '!' better in this regard? :)

Well, at least it makes sense to have the wiki disabled in the search box, by default. You're not writing an article there. ;)

Another solution would be to replace the search button w/ two small buttons, one for search, the other for quickjump.

Hmm, that would work, too, but then you have to use the mouse to click on "Quickjump". Since this is a power-user feature you'd decrease its efficiency for those who appreciate the feature the most, so I doubt that this alone will solve the problem.

I think that only these two solutions are good enough:

  • it's a power-user feature, so let power-users learn that they can use ':'
  • allow for using ':', but also add a quickjump button for those who don't know ':'

comment:14 by Christian Boos, 15 years ago

Well, I'd rather see a search panel preference used for this, rather than to clutter the interface and/or the search syntax.

comment:15 by Waldemar Kornewald <wkornewald>, 15 years ago

Aren't preference panels cluttering the UI, too? Will everything where no agreement can be found get a new entry in the preferences panel? Why can't things just work and those who need quick-access features can learn a new function? I mean, this function is still available for everyone because it shows up in the search results, anyway. It's just about saving exactly one mouse click for the experts.

in reply to:  15 comment:16 by Emmanuel Blot, 15 years ago

Replying to Waldemar Kornewald <wkornewald>:

It's just about saving exactly one mouse click for the experts.

It is also about usability: in my team, we use the the search box 9 time out of 10 for quick jumping, not for searching. So yes, "one mouse click" does matter, a lot. I still do not like the ':' thing, but I guess Matt would recommend us to move this discussion to Trac-Dev, so let's discuss this point in Trac-Dev ML.

comment:17 by Christian Boos, 12 years ago

Milestone: 1.0unscheduled

Milestone 1.0 deleted

comment:18 by Ryan J Ollos, 8 years ago

Keywords: quickjump preferences → quickjump, preferences

in reply to:  3 ; comment:19 by Ryan J Ollos, 8 years ago

Cc: Ryan J Ollos added

Replying to anonymous:

If the current behavior isnt changing. Somehow information that one did a quickjump and how to disable it should be showed for the user. For example a red box on top when you have done a quickjump that explains what happened.

This is an interesting idea. In a notice box, along with the message about the quickjump, we could display a link to the search results. We can also display a message about disabling quickjump through the preferences panel, though users won't want to see that message every time and it will be better if it can be dismissed with a [x] don't show this again.

comment:20 by Ryan J Ollos, 7 years ago

Owner: Jonas Borgström removed
Status: reopenednew

comment:21 by anonymous, 7 years ago

+1 for changing something. E.g. show both the search results and the form to create a new page.

in reply to:  19 comment:22 by Ryan J Ollos, 6 years ago

Replying to Ryan J Ollos:

This is an interesting idea. In a notice box, along with the message about the quickjump, we could display a link to the search results. We can also display a message about disabling quickjump through the preferences panel, though users won't want to see that message every time and it will be better if it can be dismissed with a [x] don't show this again.

I propose to add a message like the following:

close You arrived here through the quick-jump search feature. To instead search for the term WikiStart, click here.

If we get more requests we can add the preference, but it's always best to avoid the additional complexity if possible.

Initial cut at implementation in log:rjollos.git:t4309, but I'll review again and add tests.

comment:23 by Ryan J Ollos, 6 years ago

Cc: Ryan J Ollos removed
Milestone: unscheduled1.2
Owner: set to Ryan J Ollos
Release Notes: modified (diff)
Status: newassigned
Type: defectenhancement

comment:24 by Jun Omae, 6 years ago

The here word without context is a general word. I would like to avoid extraction because it's difficult to translate such a word which is used in another extracted text.

comment:25 by Jun Omae, 6 years ago

We could use tag(Markup(_("..."))) and escape() but not elegant.

  • trac/search/web_ui.py

    diff --git a/trac/search/web_ui.py b/trac/search/web_ui.py
    index 987744a42..f7f96affb 100644
    a b from trac.core import *  
    2222from trac.perm import IPermissionRequestor
    2323from trac.search.api import ISearchSource
    2424from trac.util.datefmt import format_datetime, user_time
    25 from trac.util.html import find_element, tag
     25from trac.util.html import Markup, escape, find_element, tag
    2626from trac.util.presentation import Paginator
    2727from trac.util.text import quote_query_string
    28 from trac.util.translation import _, tag_
     28from trac.util.translation import _
    2929from trac.web.api import IRequestHandler
    3030from trac.web.chrome import (INavigationContributor, ITemplateProvider,
    3131                             add_link, add_notice, add_stylesheet,
    class SearchModule(Component):  
    180180                return {'href': quickjump_href, 'name': tag.em(name),
    181181                        'description': description}
    182182            else:
    183                 help_link = tag.a(_("quick-jump"),
    184                                     href=req.href.wiki('TracSearch') +
    185                                          '#Quicksearches')
    186                 search_link = tag.a(_("here"),
    187                                     href=req.href.search(q=kwd,
    188                                                          noquickjump=True))
    189                 add_notice(req,
    190                     tag_("You arrived here through the %(help_link)s search "
    191                          "feature. To instead search for the term %(term)s, "
    192                          "click %(search_link)s.", help_link=help_link,
    193                          term=tag.b(kwd), search_link=search_link))
     183                help_url = req.href.wiki('TracSearch') + '#Quicksearches'
     184                search_url = req.href.search(q=kwd, noquickjump=1)
     185                add_notice(req, tag(Markup(_(
     186                    'You arrived here through the <a href="%(help_url)s">'
     187                    'quick-jump</a> search feature. To instead search for the '
     188                    'term <strong>%(term)s</strong>, click <a '
     189                    'href="%(search_url)s">here</a>.',
     190                    help_url=escape(help_url), term=escape(kwd),
     191                    search_url=escape(search_url)))))
    194192                req.redirect(quickjump_href)
    195193
    196194    def _get_search_terms(self, query):

If Genshi i18n translation format could be used in *.py, we could make it simple like this:

You arrived here through the [1:quick-jump] search feature. ..., click [2:here].

comment:26 by Ryan J Ollos, 6 years ago

I considered whether the sentence could be reworded, but any solution that looks like the comment:22 changes will break the sentence to multiple fragments.

Unrelated, I considered only adding the notice when the term length is ≥ [search] min_query_length, but that seems like too much complication.

log:rjollos.git:t4309.1 adds a test for the comment:25 changes.

Last edited 6 years ago by Ryan J Ollos (previous) (diff)

comment:27 by Ryan J Ollos, 6 years ago

Resolution: fixed
Status: assignedclosed

Committed to trunk in [14830].

comment:28 by anonymous, 4 years ago

I have just upgraded from 1.0.8 to 1.2.2, and find the "you arrived here…" notice at the top of each page to be useless and annoying/distracting, since I use the quick-search feature very often.

what happened to the idea from comment:19 ?

… though users won't want to see that message every time and it will be better if it can be dismissed with a [x] don't show this again.

I would like that feature very much; or else I would like to disable this annoying new banner. I've been using Trac for 11+ years and needless to say this is not helpful / not necessary for experienced users.

comment:29 by jeremy.j.dunn@…, 4 years ago

sorry, previous anonymous comment by me. I would like to receive notifications of comments to this ticket.

comment:30 by Ryan J Ollos, 4 years ago

Please ask on MailingList if you'd like help on creating a plugin to remove the notification.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Ryan J Ollos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Ryan J Ollos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.