Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
i have generated a patch that does a simple menu search on the admin_menu. i added a textfield right of the menu items. if you type some letter in it, a new menu will appear with the filtered menu elements. (look attachments)
it works on the client-side with jquery script.
Remaining tasks
Doesn't work with admin_menu only; i.e., without admin_menu_toolbar.Overlay: Search results are not cleared after clicking on a search result entry.- Missing search icon image. (referenced in CSS but doesn't exist)
- Resolve the @todos in the JavaScript.
- Better styling/visualization for "highlighted" elements in the dropdown menu tree.
- White background on highlighted links makes them hard to read.
- Search results appear below the entire menu + shortcuts bar. Enable Shortcut module to see what this means.
- Caused by
top: 100%
in the CSS, but removing that makes the search results cover the search input field. No idea what's happening there, didn't have enough time to debug further.
- Caused by
- Output parent link label instead of top-level category name to provide better context for tabs/local-task links.
- Add a way to remove/cancel a search + search results.
- Potentially using input[type=search] for the form element to leverage native browser functionality?
- Add a pointer/marker for the highlighted dropdown menu link (like Apple)?
- "Group" results by top-level category?
- Allow to disable the highlighting of search results in module settings?
- Add a keyboard shortcut to jump into the search field.
- Ensure to not clash with Coffee or Teleport modules as well as native browser keyboard shortcuts.
Separate follow-up issues
- #331982: Add support for keyboard navigation
- #293768: Allow to enable/disable menu additions
- #220100: Add support to detect hover intent (no dependencies added)
Related projects
(there are at least 2-3 more projects providing this kind of functionality)
Comment | File | Size | Author |
---|---|---|---|
#67 | add_a_search_widget_to-806350-67.patch | 848 bytes | helmo |
#65 | add_a_search_widget_to-806350-65.patch | 1.12 KB | helmo |
#64 | admin_menu-fix_for_search_overlap-806350-64.patch | 1.48 KB | emmonsaz |
#63 | admin_menu-fix_for_search_overlap-806350-63.patch | 1.24 KB | emmonsaz |
#59 | Screenshot_3_1_13_11_11_AM.png | 48.87 KB | chippper |
Comments
Comment #2
sun#1340634: Add a search/autocomplete widget to find links in admin menu was a duplicate - copying the OP by @jenlampton:
Comment #2.0
sunUpdated issue summary.
Comment #3
jenlamptonSomething like that would be much less-useful for toolbar since there are no drop-downs. admin_menu++
Comment #4
fubhy CreditAttribution: fubhy commentedThe attached patch is for 7.x-3.x.
It does have the features described above plus it opens up the admin menu trail up to the actual link and highlights it when you hover a result.
There were some problems with the CSS and jQuery (I particulary found the delayed mouseout jquery odd and rewrote that because it didn't work with the original code) and I removed the
left: -999em;
stuff as there was simply no need for it (display: none;
is being used everywhere anyways).Comment #5
fubhy CreditAttribution: fubhy commentedThis is how it looks... (The white arrows are just for illustration purposes... They are not included in the patch of course, heh).
Comment #6
yched CreditAttribution: yched commentedLooks plain awesome !
If i can push it a little :
- Would it be doable to have a keyboard shortcut to give focus to the searchbox ?
- Once we're here, I guess we'll want the ability to use the up/down keys to navigate through the results ?
Comment #7
fubhy CreditAttribution: fubhy commentedUp and down navigation is working (jumps to first / last element if no focus exists (yet), based on wether the down- or up- arrow has been pressed).
Initial focus based on a shortcut doesn't work yet but should be rather simple.
However, we still need to find a way to invoke the "hover" event for both, css and jquery, when an element has the focus via up- or down- arrow. We could also change the rest of the jquery / css to also accept :focus instead of only :hover.
EDIT:
I also simplified the rest of the jQuery code from my previous patch.
Comment #8
jenlamptonWow, This is so amazing. I want this for D7 too :)
We should probably get a designer involved at some point and see if we should add rounded corners, a non-white background color, a search icon or anything else into that search box.
Comment #9
jponch CreditAttribution: jponch commentedSuper neato! It would probably be good to make it visually akin to search fields users are accustomed to seeing, having a small search icon within the field. Rounded sides may also help it feel more like the search fields users are accustomed to seeing in the top right of their browsers (some browsers) and operating systems. Are you looking for some sort of mock for this or just some quick CSS or just designer opinions? :-)
Comment #10
fubhy CreditAttribution: fubhy commentedLike this? :)
I also removed the keyboard navigation for now... This issue should include that feature: #331982: Add support for keyboard navigation - I will fix that part over there when I am back from the translation code sprint in Zurich this week.
So now we just need a few reviews for this part :). Is it ok if I set this back to 7.x-3.x?
Comment #11
fubhy CreditAttribution: fubhy commentedSorry, there was a code artifact in the last patch (should use e.target.value everywhere and not intermix it with $(this).val()).
Comment #12
sunThere's a 7.x-3.x-search branch now. And @fubhy has write access to that, as long as he stays in there. ;)
Apparently, the search.png image was not contained in the patch. Where does that come from?
Next to #331982: Add support for keyboard navigation, it looks like you're also trying to sneak in #220100: Add support to detect hover intent (no dependencies added) with this patch? :P (also, this code doesn't work right now for non-IE browsers, since the :hover CSS is still in effect)
Committed and pushed a code clean-up, as well as major logic and performance improvements. See attached interdiff to #11.
Comment #13
sunReverted all changes that are unrelated to this issue, as a result of aforementioned clean-ups and improvements.
See attached full interdiff since #11 and actual current diff against 7.x-3.x.
Comment #14
sunMinor follow-up fix.
Comment #15
sunJust FYI: @Rob Loach pointed out http://bugs.jquery.com/ticket/278 to my question whether it should be :containsi() or :icontains().
Comment #16
jenlamptonOh man, this is so hot :)
A few comments:
- when there are only 2 items in the drop-down it's not clear that the white is the highlighted and the black is the un-highlighted.
- the text is sometimes hard to read over the white gradient when there's text (or a busy logo) behind it.
Would it be too obtrusive to use the red color + gradient from behind "Hello username" to indicate the highlight?
EDIT by @sun: http://drupal.org/files/which-one-is-the-highlight%3F.png (Don't use reserved URI characters in attachment filenames)
Comment #17
sunFor the record:
In 3 years from now, I want to see this feature to highlight the items in 3D. (use Safari/Chrome)
:-D
Comment #18
aschiwi CreditAttribution: aschiwi commentedVery cool you guys!
A note to people who want to test and are similarly unable to figure out how from this thread: There's a branch you can check out at http://drupal.org/node/108746/git-instructions/7.x-3.x-search. Don't run updates, they will tell you confusing things (System (Version >7.10 required)) and this search box just works without running updates.
I second jenlampton's comments plus I noticed trying to use the arrow keys to move down in the list, which does not work yet.
+1 on using the red from "Hello username" to indicate the highlight - to make it perfect use that color on the whole path like Mac OS X's help does.
Comment #19
Bojhan CreditAttribution: Bojhan commentedFollowing, the few things I imagine we could iterate more on
1) Searching beyond just admin items, content, terms, users - it could be the go-to place.
2) There could be more sensible grouping of the results, currently all results are of equal importance. With grouping you can make it easier and faster to find the right thing. I imagine when you have a lot of results, grouping will be even more important.
3) Its position might require, removing or moving of certain items on the left to allow it to breath more visually.
4) The hovering over the search result correlating to the admin_menu location is great, you would have to research whether its not too much auto-magic.
Comment #20
sunComment #21
sunComment #22
webcultist CreditAttribution: webcultist commentedJust want to say, that this thing is one of the coolest things I've seen in last time and one of the greatest workflow improvements!
Will never use another branch =)
Thank you guys =)
Comment #23
sunSorry, this code/branch fell totally behind.
I've merged the latest 7.x-3.x code into the 7.x-3.x-search branch now and applied some stop-gap fixes... incomplete.
The implementation needs to be properly updated to account for #1564934: Separate toolbar and dropdown menu markup
Comment #24
Bojhan CreditAttribution: Bojhan commentedUpdating this to a critical feature request after chatting with @sun. This little piece of functionality could create such a boost in UX, for all of our users. It is also a good test run, if we want to do something like this in core.
Comment #25
sunYup :)
I'll commit this to 7.x-3.x as soon as it reaches the previous minimum working state of #5 again. The code is in the 7.x-3.x-search branch and just needs to be "properly" updated for most recent changes. I already synced it to very basic extents in #23, but the entire output is displaced currently. Shouldn't be too hard to fix.
Also, don't be afraid of changing how this gets output. Above mentioned changes in #1564934: Separate toolbar and dropdown menu markup really just strived for exactly that in mind: Additional "widgets" to the toolbar that are not menus (much like the Shortcuts bar).
Lastly, yes, committing this will put it in front of everyone's face - even though it might not be picture-perfect yet. But at the same time, that will inherently trigger much more visibility and lots of improvements. In turn, expect another RC soon after this lands ;)
Comment #26
nod_It's for jquery 1.4+ won't work on D6. against the search branch.
changed a few things: build a cache of links first time, and on keykup $.grep() it to find matching strings.
The code would need to have theme function and all that to make it in core at some point.
Well for now it works and profiling shows that there are a lot of stuff taking more time than building the cache. I don't trust jQuery cache and the code isn't actually easier to understand when it's used. This should be easier to understand than previously.
Comment #28
nod_I guess search doesn't apply to the default branch :p
Also I haven't touched the styling. It still need some work.
Comment #29
sunThanks for working on this, @nod_! :)
I was very tempted to commit your patch, but quick manual testing showed:
Also, but super-minor compared to the above; there's a stray "var cache;" outside of the behavior, which doesn't seem to be used anywhere.
Comment #30
sunOh, and hm, let me also add:
Comment #31
nod_So that's what those things were supposed to do :D
I haven't tried the search before, thanks for the feedback it makes more sense now. I'll update the patch.
Comment #32
nod_Ok should account for 1) 2) and 3)
I binded on focus/blur as well so it's more or less keyboard friendly.
Had to work around the delayed hiding of the menu. It starts building the cache at the 3rd character entered in the input. I kinda fixed the styling.
The interaction might need some work, you can't close the search results when you're navigation with keyboard but well, just delete the search text.
Comment #33
nod_Comment #35
nod_meah forgot the do-not-test
Comment #36
sunThanks @nod_! Committed #32 as well as a larger clean-up including some bug fixes on top of that.
Attached is a combined patch of the 7.x-3.x-search branch for the testbot.
Comment #37
nod_Nice, and you were able to get rid of some ugly parts of my code too :)
Comment #38
sunAaaaaand...
Thanks for reporting, reviewing, and testing! Merged into 7.x-3.x, and cherry-picked the merge commit into 8.x-3.x! :)
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
Reverting to active instead of fixed, because there will have to be a couple of follow-up adjustments:
Caused by
top: 100%
in the CSS, but removing that makes the search results cover the search input field. No idea what's happening there, didn't have enough time to debug further.Comment #39
davidneedhamWow, what a great UX improvement! May I add to the todo list? It only seems to work when the Administration menu Toolbar style module is enabled. If you point me in the right direction I can try to help.
Comment #40
marcvangendExcellent work, thank you all. I have one more follow-up adjustment, not sure if this should be a separate issue:
When the overlay module is enabled, the search results are not cleared when you follow a link. Without overlay this happens automatically because the page is reloaded. I think it would be logical to clear the search results explicitly when overlay-parent.js triggers the drupalOverlayBeforeLoad or drupalOverlayLoad event.
Comment #41
fubhy CreditAttribution: fubhy commentedI know that this code originally comes from me but thinking about it now it probably makes more sense to generate the input field for the search widget with Javascript, no?
Comment #41.0
fubhy CreditAttribution: fubhy commentedUpdated issue summary.
Comment #41.1
sunUpdated issue summary.
Comment #42
sunI created a list of remaining tasks in the issue summary to collect all feedback thus far.
@fubhy: For now, I think we want to keep it in the markup generated on the server-side. It will allow the module(s) to control the location/placement of the search widget, and possibly also to toggle its addition.
@davidneedham: Thanks for testing! Not testing the regular admin_menu obviously was a blatant mistake ;) I've committed attached patch to fix it.
Comment #43
davidneedhamI applied that patch on a couple sites but I didn't notice a difference so I pulled the most recent dev version, which seems to work great with and without the toolbar style enabled. Thanks!!
Comment #44
nod_new patch fixing:
// @todo Limit to links in dropdown menus; i.e., skip menu additions.
Looks like what it does already, moved code around to show it.@todo Check whether this indirection is really required.
not mandatory but delegated event tends to be more expensive than binding to each elements since for any event binded to it they need to filter on the DOM tree. Keeping it in one function helps. Since there are a lot of links I'm pretty sure delegation is still better. if it's about the named function, whatever works, like this it helps profiling.// @todo Add a HTML ID.
Tried #attributes['id'] on the form input and gave up :D// @todo Consider using same visual appearance as regular hover.
See 3)Extra
I've added the hoverIntent plugin to the patch since messing around with timer is no fun. It's not very hard to get rid of it but I didn't want to spend time on that.
Comment #45
Bojhan CreditAttribution: Bojhan commentedLet me start by saying, that this is really exciting!
Alright, so I was finally able to install it. I have a few concerns, although arguably many of them don't have to be solved in this initial feature release.
Oh, on another note. Should we aim to include content in the results, for this patch?
Comment #46
nod_updated the patch, the text input is replaced with a search input displaying the X from #2 on supporting browsers (chrome and safari in osx as far as i know). Need to bind to the new "search" event while typing (which is awesome for textfields!).
Comment #47
rsvelko CreditAttribution: rsvelko commentedWOW - this is awesome!
My 2 cents -
1. I need to be able to press Down and go through the search results and press enter.
2. The expose menu feature where one sees the menu opens to the left on hovering search results should be switchable like on/off in the settings. Via a poll we can see whether most of us want it on / off by default.
3. A keyboard shortcut to focus the search box - like ctrl+m or sth... also settable via the config of the module... for simplicity ctrl /alt can be selectable via radiobuttons and in a second input field - the letter.
4. We need a simple version of this pushed to non-dev fast.
Comment #48
sunI've committed most parts of @nod_'s follow-up patch; see attached interdiff.txt.
Please note that usage of jQuery hoverIntent is a separate issue #220100: Add support to detect hover intent (no dependencies added) having its own problems; e.g., committing and loading the hoverIntent library has a high chance of leading to conflicts with other modules that also load the library, version conflicts, and more. Further discussion on that should ideally stay on that issue ;)
On @Bojhan's review:
I think it's rather unlikely that those will be "fixed" anytime soon, since most of the ambiguous links are tabs/local-tasks (and thus, inherently also contextual links) in reality. Adding more textual context to those links would make the tabs/tasks too large and wordy in the regular interface.
So this looks like something we'll have to resolve in the search results. One possible solution would be to output the parent link's label instead of the top-level category for each link.
By doing that we'll probably run into width/size issues of the search results. That could be mitigated by using a wider dropdown for the search results.
For D7, I'm not sure whether we can go with that approach, I'd want to produce the HTML5 input type="search" on the server-side already, but D7 sites do not necessarily use a HTML5 doctype, so all pages containing the admin_menu would be invalid HTML. That said, I also don't really care for valid/invalid HTML anymore, and since this markup only appears for logged in and privileged admin users, I care even less.
What's more concerning is the possibly limited support for the browser-based Cancel functionality on the search input element. (That said, I did not actually test which current major browsers support it.)
Comment #49
jenlamptonIt would also be great if we could kill the transparency on the "it's over here" highlight. It's hard to read the actual link if theres text or something behind.
Also, it looks like Apple solved the overlap problem by aligning the right edge of the drop-down with the left edge of the search results, so the only over lap is the floating arrow indicator that "points" at the result you want.
Comment #49.0
jenlamptonUpdated issue summary.
Comment #50
jenlamptonI was also curious how apple handled their second level items conflicting with search, so here's a screenshot of that, too.
Comment #51
sunyay, thanks for the screenshots, @jenlampton! Very helpful :)
Alrighty, as an attempt to make us focus on the right remaining issues, I'm going to make an early decision:
admin_menu will ignore the problem of a potentially overlapping expanded link tree when hovering a search result (i.e., the case visible in #45 and #50). That is, because a solution for that would have to be along the lines of Apple's, which would require some extensive JavaScript for determining whether every sub-list of links overlaps with something else, so the visual appearance and placement can be conditionally adjusted, also via JavaScript. At the same time, the actual goal for admin_menu's basic dropdown behavior is to get rid of most of the JS and leverage (require) the latest and greatest CSS3 instead (separate issue).
I've also updated the issue summary to reflect all remaining tasks. My plan is to create a new RC as soon as the ~10 first main/major issues have been resolved.
Comment #52
Adam S CreditAttribution: Adam S commentedDoes the search.png still need to be provided?
Comment #53
sunYes, all remaining tasks listed in the OP/issue summary still need to be done. Including search icon. :)
Comment #54
ctyar CreditAttribution: ctyar commentedjust a suggestion:
another permission for accessing search would be great because regular users may think this is a site wide search
Comment #55
donquixote CreditAttribution: donquixote commentedHi,
as a note, that other module has a search box since a long time. I do not claim it is superior - probably it is not. But, maybe there are a few ideas to take away.
Things to learn from DQX AdminMenu search box:
You don't have to click the search box. Just hover the menu anywhere, and start typing. (unfortunately, it only works if the browser window has focus)
If you type only one letter, it will only search for items beginning with this letter.
If you type two letters, it will search for items where any word in the item title begins with these two letters.
If you type three or more letter, it will find any item where one of the words does contain the string.
Instead of a dropdown list, the search will set a text color on found items, and on submenus that contain those items.
These color codes give a hint where the thing you want is in the menu, so next time you can find it directly.
On the other hand, they are more subtle than opening all those menus.
Just a using space key is enough to clear the search box.
Things that suck in DQX AdminMenu search box:
I suspect that a majority of users will not notice the search thing. I think we need a trade-off between "looks like a site search" and "wtf is this tiny box".
Besides, yes, the DQX AdminMenu search lacks a dropdown.
--------------
Some general comments:
At first when I saw the search box (that was today, when I updated to 7.x-3.x), I thought that it is the same as a site search. It also reminded me of the contact search in CiviCRM menu. This definitely needs some more thinking.
The dropdown is great. Although it should support up/down arrow keys (see comment #18 by aschiwi).
Revealing the submenu tree when hovering the dropdown, can be debated.
It does seem a bit agressive to me, like too much happening on the screen at once. On the other hand, it is definitely useful for learning where the items are.
"Learning where this stuff is located in the menu" seems like a goal we should try to achieve with all this.
Comment #56
chippper CreditAttribution: chippper commentedI am posting a couple CSS fixes that I made to admin_menu.css, primarily to fix the disconnect with search results when the shortcuts bar is toggled. See “Remaining tasks” number 6.
I’m bringing a few other minor tweaks along for the ride, such as a greater admin-menu z-index (999 -> 9999), and explicitly declaring background:none on the search form item, because the search box looked weird with the Rubik admin theme enabled.
I hope this helps!
Comment #57
sunDid you test that with both the Shortcut module being enabled and disabled?
Note: You can enable/disable individual admin_menu components on the settings page now to easily test this; i.e., you do not have to enable/disable the Shortcut module.
Comment #58
chippper CreditAttribution: chippper commentedI had not specifically tried it with shortcuts disabled, no. I was simply relying on the toggle - I figured it was a CSS placement issue, after all.
I've gone back and tried it with shortcuts specifically disabled, and it still works for me. Is it not working for you?
FWIW, I went with "2.7em" to push the search results down by a specific amount, but it still scales up if the user increases their text size in the browser. It's only an issue when they increase their text size to the point where the search box runs to the next line.
Comment #59
chippper CreditAttribution: chippper commentedJust wanted to throw up some screenshots to show what I'm seeing
Comment #60
chippper CreditAttribution: chippper commentedI know this isn't exactly the hottest issue in the world, but would like to know if someone else got a chance to take a look at this patch. Thanks!
Comment #60.0
chippper CreditAttribution: chippper commentedUpdated issue summary.
Comment #61
helmo CreditAttribution: helmo commentedOn a fresh install(7.x-3.0-rc4+3-dev) I don't see the search field. Only after I visit /admin/config/administration/admin_menu .. I don't even have to submit that config page.
The 'Search bar' checkbox is enabled by default, could it be that the default is not used in all places?
PS: Not sure if this is known issue... I'll make a new issue if you like.
Comment #62
kopeboy CreditAttribution: kopeboy commentedI have exactly the same issue.
Clean install on Pantheon, dev envinronment, with Adaptive Theme, I couldnt see the search box.
As soon as I visited /admin/config/administration/admin_menu it appeared (the option was already check by default) but not working.
I tried to disable and re-enable and it's now always showing, but still not working! I also tried to disable caching with no success..
I type and it doesn't find anything.
I have another website on a standard shared hosting and with Omega Theme 4, and it works.. Can't understand the difference.
Comment #63
emmonsaz CreditAttribution: emmonsaz as a volunteer commentedRe-rolled #56 with a few mobile responsive breakpoints
Comment #64
emmonsaz CreditAttribution: emmonsaz as a volunteer commentedOne more tweak to fix a flicker issue when hovering on the users dropdown (next to logout link on right)
Comment #65
helmo CreditAttribution: helmo at Initfour websolutions commented#61 can be fixed by this patch. The config value was just not initialized.
The patch also removed a title that's not used in the 'seven' theme and looks bad in a bootstrap bases theme. The input field overlapped the 'Search' label.
Comment #67
helmo CreditAttribution: helmo at Initfour websolutions commentedComment #68
truls1502I am sorry for no reply until now.
There are many issues regarding this module admin_menu which is a bit difficult for us to follow up since some of the issues might be already outdated, or is already fixed by the module or any other modules or itself core which means that the problem might no longer need to be fixed.
We can see that the issue has been created for a few years ago, I hope it is okay for you that I am postponing the issue, and give you around two weeks. If you still face the problem, could you tell us the step by step when until you get the error message or what is frustrated you, and a list of modules you are using related to admin_menu and a screenshot that might help us? So it makes us easier to reproduce your issue.
However, after two weeks with no feedback - we will close this issue. So in case, you noticed it after the issue is closed, do not hesitate to reopen it like and fill information which is mentioned above.
So before giving us a feedback, do you mind to test it again with our latest 7.x-3.x-dev?
Thank you for understanding! :)
Comment #69
truls1502This issue has been automatically marked as closed because it has not had recent activity after the last post.
However, if you or someone is still facing the same issue as described to the issue, could you please to re-open the issue by changing the status of the issue, and add an explanation with more details which can help us to reproduce your situation.
Again, thank you for your contributions! :)