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

  1. Doesn't work with admin_menu only; i.e., without admin_menu_toolbar.
  2. Overlay: Search results are not cleared after clicking on a search result entry.
  3. Missing search icon image. (referenced in CSS but doesn't exist)
  4. Resolve the @todos in the JavaScript.
  5. Better styling/visualization for "highlighted" elements in the dropdown menu tree.
    • White background on highlighted links makes them hard to read.
  6. 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.
  7. Output parent link label instead of top-level category name to provide better context for tabs/local-task links.
  8. Add a way to remove/cancel a search + search results.
    • Potentially using input[type=search] for the form element to leverage native browser functionality?
  9. Add a pointer/marker for the highlighted dropdown menu link (like Apple)?
  10. "Group" results by top-level category?
  11. Allow to disable the highlighting of search results in module settings?
  12. 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

Related projects

(there are at least 2-3 more projects providing this kind of functionality)

CommentFileSizeAuthor
#67 add_a_search_widget_to-806350-67.patch848 byteshelmo
#65 add_a_search_widget_to-806350-65.patch1.12 KBhelmo
#64 admin_menu-fix_for_search_overlap-806350-64.patch1.48 KBemmonsaz
#63 admin_menu-fix_for_search_overlap-806350-63.patch1.24 KBemmonsaz
#59 Screenshot_3_1_13_11_11_AM.png48.87 KBchippper
#59 Screenshot_3_1_13_11_12_AM-3.png45.66 KBchippper
#56 admin_menu-fix_for_search_overlap-806350-56.patch851 byteschippper
#49 still-hard-to-read.png68.92 KBjenlampton
#49 apple-non-overlap.png156.82 KBjenlampton
#50 apple-second-level-search-result.png263.66 KBjenlampton
#48 interdiff.txt3.88 KBsun
#46 admin_menu-search-better-806350-47.patch7.13 KBnod_
#45 admin_menu_wierdnes.png38.23 KBBojhan
#44 admin_menu-search-better-806350-43.patch6.49 KBnod_
#42 admin_menu.search.42.patch597 bytessun
#36 search.36.patch7.73 KBsun
#32 admin_menu-search-better-806350-32.patch7.11 KBnod_
#26 admin_menu-search-better-806350-26.patch4.79 KBnod_
#18 search.png205.36 KBaschiwi
#16 which-one-is-the-highlight?.png61.12 KBjenlampton
#16 hard-to-read.png64.5 KBjenlampton
#14 admin_menu.search.14.patch5.42 KBsun
#14 interdiff.txt2.29 KBsun
#13 admin_menu.search.13.patch5.35 KBsun
#13 interdiff.txt17.37 KBsun
#12 interdiff.txt10.94 KBsun
#11 admin-menu-search-bar-4.patch8.36 KBfubhy
#10 admin-menu-search-bar-3.patch8.36 KBfubhy
#10 sample.png24.79 KBfubhy
#7 admin-menu-search-bar-2.patch9.1 KBfubhy
#5 sample.png25.84 KBfubhy
#4 admin-menu-search-bar.patch8.58 KBfubhy
admin_menu_patch_search_2.png9.27 KBHaehnchen
admin_menu_patch_search_1.png11.55 KBHaehnchen
admin_menu-DRUPAL-6--3-search.patch4.34 KBHaehnchen
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch, admin_menu-DRUPAL-6--3-search.patch, failed testing.

sun’s picture

Title: menu item searching » Add a search/autocomplete widget to find links in admin menu
Version: 6.x-3.x-dev » 8.x-3.x-dev

#1340634: Add a search/autocomplete widget to find links in admin menu was a duplicate - copying the OP by @jenlampton:

Mac OS X has this handy "search" feature in the menu that not only will help users find the item they were trying to locate, but also show them where in the menu it was located - for the next time they need it.

Can we add something like this into admin menu? Even if we can't get to the "show people where to find it" part - a search/autocomplete that searches on both the menu title and description would be very valuable!

screenshot of mac OS X help system

See similar issue opened against toolbar #1340626: Add a search/autocomplete to the toolbar

sun’s picture

Issue summary: View changes

Updated issue summary.

jenlampton’s picture

Something like that would be much less-useful for toolbar since there are no drop-downs. admin_menu++

fubhy’s picture

Status: Needs work » Needs review
FileSize
8.58 KB

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

fubhy’s picture

FileSize
25.84 KB

This is how it looks... (The white arrows are just for illustration purposes... They are not included in the patch of course, heh).

yched’s picture

Looks 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 ?

fubhy’s picture

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

jenlampton’s picture

Wow, 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.

jponch’s picture

Super 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? :-)

fubhy’s picture

Version: 8.x-3.x-dev » 7.x-3.x-dev
FileSize
24.79 KB
8.36 KB

Like 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?

fubhy’s picture

Sorry, there was a code artifact in the last patch (should use e.target.value everywhere and not intermix it with $(this).val()).

sun’s picture

FileSize
10.94 KB

There'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.

sun’s picture

FileSize
17.37 KB
5.35 KB

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

sun’s picture

FileSize
2.29 KB
5.42 KB

Minor follow-up fix.

sun’s picture

Just FYI: @Rob Loach pointed out http://bugs.jquery.com/ticket/278 to my question whether it should be :containsi() or :icontains().

jenlampton’s picture

Status: Needs review » Needs work
FileSize
64.5 KB
61.12 KB

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

sun’s picture

For the record:

In 3 years from now, I want to see this feature to highlight the items in 3D. (use Safari/Chrome)

:-D

aschiwi’s picture

FileSize
205.36 KB

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

admin_menu search - highlight whole path

Bojhan’s picture

Following, 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.

sun’s picture

sun’s picture

Issue tags: +GoogleUX2012
webcultist’s picture

Just 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 =)

sun’s picture

Sorry, 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

Bojhan’s picture

Priority: Normal » Critical

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

sun’s picture

Yup :)

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

nod_’s picture

Status: Needs work » Needs review
FileSize
4.79 KB

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.

Status: Needs review » Needs work

The last submitted patch, admin_menu-search-better-806350-26.patch, failed testing.

nod_’s picture

Status: Needs work » Needs review

I guess search doesn't apply to the default branch :p

Also I haven't touched the styling. It still need some work.

sun’s picture

Status: Needs review » Needs work

Thanks for working on this, @nod_! :)

I was very tempted to commit your patch, but quick manual testing showed:

  1. When entering a search term, the search results are not immediately shown. The results only appear after hovering over the search field. That's not the expected behavior - unlike the other dropdown menus, the results should automatically show upon typing.
  2. When hovering over a search result, the corresponding link in the admin menu dropdown menus is not automatically opened/revealed. Instead, the new CSS now seems to apply to the search results only. So this is actually breaking one of the main intentions of this feature; i.e., showing the user where he can find a certain link in the dropdown structure, so the location can be learned and the user does not have to search the next time.

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.

sun’s picture

Oh, and hm, let me also add:

  1. The search functionality is most probably not always used. Therefore, the original/current code did not attempt to build a map/list of links in the menu, unless first invocation of the search functionality. In other words: Until used, the search feature/behavior does not do anything to the menu. I.e., it's a bare input element and there are no search results or markup modifications until the user actually starts to type something in. Just focusing/leaving/tabbing-in-and-out the field without entering something should not trigger the functionality either.
nod_’s picture

Assigned: Unassigned » 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.

nod_’s picture

Status: Needs work » Needs review
FileSize
7.11 KB

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.

nod_’s picture

Assigned: nod_ » Unassigned

Status: Needs review » Needs work

The last submitted patch, admin_menu-search-better-806350-32.patch, failed testing.

nod_’s picture

Status: Needs work » Needs review

meah forgot the do-not-test

sun’s picture

FileSize
7.73 KB

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

nod_’s picture

Nice, and you were able to get rid of some ugly parts of my code too :)

sun’s picture

Status: Needs review » Active

Aaaaaand...

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:

  1. Resolve the @todos in the JavaScript.
  2. The list of search results appears a bit oddly below the entire menu; i.e., below the shortcuts bar.

    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.

  3. Proper styling/visualization for "highlighted" elements in the dropdown menu tree.
  4. Separate: #331982: Add support for keyboard navigation
  5. Separate: #293768: Allow to enable/disable menu additions
davidneedham’s picture

Wow, 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.

marcvangend’s picture

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

fubhy’s picture

Status: Active » Needs work
+++ b/admin_menu.incundefined
@@ -572,6 +572,28 @@ function admin_menu_links_user() {
+function admin_menu_links_search() {
+  $links = array(
+    '#theme' => 'admin_menu_links',
+    '#weight' => 150,
+  );
+  $links['search'] = array(
+    '#type' => 'textfield',
+    '#title' => t('Search'),
+    '#title_display' => 'attribute',
+    '#attributes' => array(
+      'placeholder' => t('Search'),
+      'class' => array('admin-menu-search'),
+    ),
+  );
+  return $links;
+}

I 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?

fubhy’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Title: Add a search/autocomplete widget to find links in admin menu » Add a search widget to find links in admin menu
Status: Needs work » Active
FileSize
597 bytes

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

davidneedham’s picture

I 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!!

nod_’s picture

Status: Active » Needs review
FileSize
6.49 KB

new patch fixing:

  1. « works for me »™ without admin_menu_toolbar.
  2. That looks ok to me, not sure what to fix.
  3. Can't programatically trigger :hover style, it means relying on classes, easy but tedious to do.
    • // @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)
  4. fix the overlay thing

Extra

  • Added the category text only if there is a category text to prefix the link title with.
  • result list works better

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.

Bojhan’s picture

FileSize
38.23 KB

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

  1. The menu is exposed, when you hover over a search result. Although I know the conceptual idea behind this, I still feel its too much *magic* for the user. It creates this effect, where suddenly loads of deeps menu appear as you hover over the different search results. Its not a common pattern, elsewhere on the web or in applications and creates legibility issues as shown below.
  2. Occasionally the search results are somewhat ambiguous, I have found this in several spots but the most striking example is when you look up "tags" or "menu". Again this might be a core issue, where we should always have Edit "*" menu. Although showing where it is, accounts for some of it - I think its either way not usable to have search results that are basically indistinguishably.
  3. There is no easy way to remove the result, can we implement something like a "X" as shown in #2 ?
  4. The hover effect is very small, this probably won't pass a11y standards. This is an admin_menu issue however.

Oh, on another note. Should we aim to include content in the results, for this patch?

admin_menu_wierdnes.png

nod_’s picture

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

rsvelko’s picture

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

sun’s picture

FileSize
3.88 KB

I'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:

  1. Can someone check whether and how Apple resolved the potential overlap of the expanded menu with the search result? (That said, I didn't encounter this issue myself, due to a larger screen size...)
  2. Ambiguous search result labels are definitely caused by the original menu link labels in core and elsewhere.

    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.

  3. @nod_'s patch in #46 attempts to resolve the missing way for canceling a search by turning the search input element into an HTML5 input[type=search]. As he stated, only Chrome and Safari are injecting a native "Cancel"/Reset button/behavior. I'm not sure whether that is part of the official HTML5 standard or a proprietary implementation though.

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

  4. Sorry, I don't understand what "the hover effect is very small" means. Can you clarify?
jenlampton’s picture

FileSize
156.82 KB
68.92 KB

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

jenlampton’s picture

Issue summary: View changes

Updated issue summary.

jenlampton’s picture

I was also curious how apple handled their second level items conflicting with search, so here's a screenshot of that, too.

sun’s picture

yay, 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.

Adam S’s picture

Does the search.png still need to be provided?

sun’s picture

Yes, all remaining tasks listed in the OP/issue summary still need to be done. Including search icon. :)

ctyar’s picture

just a suggestion:
another permission for accessing search would be great because regular users may think this is a site wide search

donquixote’s picture

Hi,
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:

  • find-as-you-type:
    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)
  • incremental filter:
    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.
  • Color hints:
    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.
  • Easy reset:
    Just a using space key is enough to clear the search box.

Things that suck in DQX AdminMenu search box:

  • Discoverability:
    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.

chippper’s picture

I 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!

sun’s picture

+++ b/admin_menu.css
@@ -208,7 +209,7 @@ body.admin-menu {
-  top: 100%;
+  top: 2.7em;

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

chippper’s picture

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

chippper’s picture

Just wanted to throw up some screenshots to show what I'm seeing

w/ Shortcuts disabled

w/ Shortcuts enabled

chippper’s picture

I 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!

chippper’s picture

Issue summary: View changes

Updated issue summary.

helmo’s picture

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

kopeboy’s picture

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

emmonsaz’s picture

Re-rolled #56 with a few mobile responsive breakpoints

emmonsaz’s picture

One more tweak to fix a flicker issue when hovering on the users dropdown (next to logout link on right)

helmo’s picture

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

Status: Needs review » Needs work

The last submitted patch, 65: add_a_search_widget_to-806350-65.patch, failed testing.

helmo’s picture

Status: Needs work » Needs review
FileSize
848 bytes
truls1502’s picture

Status: Needs review » Postponed (maintainer needs more info)
Issue tags: +postponed2w

I 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! :)

truls1502’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)
Issue tags: -postponed2w

This 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! :)