The responsive toolbar update for D8 includes a neat little component that power-users and casual users alike should find very useful. The jumpbar search field will allow a user to start typing and be presented with menu options in an auto-complete style just like a Google or Bing search.

You can have a look at the Administration menu module for an existing implementation. We're looking to do something like this as simply as possible and allow for contrib authors to extend the functionality.

Screen Shot 2012-09-11 at 1.11.20 PM.png

Details

This development work should take place as a branch of the main sandbox for D8 administration toolbar work:
http://drupal.org/sandbox/jessebeach/1749042

The branch for this work will be: node/1137920-responsive-toolbar, which is rebased on 8.x often.

Contact jessebeach for details and commit access to the sandbox.

Files: 
CommentFileSizeAuthor
#21 1781422_toolbar-jump-menu_21.patch10.36 KBjessebeach
#15 1781422_toolbar-jump-menu_15.patch8.52 KBboris sondagh
#15 search.png22.71 KBboris sondagh
#15 search_hover.png30.76 KBboris sondagh
#7 jump_box.zip95.14 KBtkoleary
#4 1781422_toolbar-jump-menu_4.patch6.59 KBjessebeach
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1781422_toolbar-jump-menu_4.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#3 implement-auto-complete-menu-1781422-3.patch5.17 KBboris sondagh
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch implement-auto-complete-menu-1781422-3.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
Screen Shot 2012-09-11 at 1.11.20 PM.png42.05 KBjessebeach

Comments

I think it should be the branch node/1137920-responsive-toolbar-with-dropbutton-patch as patch from #1608878 is not committed yet.

Boriss, there's no work against this issue yet from my side. The dropbutton patch should land any time now. Just a couple styling issues. After that, we'll be working on the the node/1137920-responsive-toolbar branch. In fact, you'd be totally safe to work against node/1137920-responsive-toolbar now.

StatusFileSize
new5.17 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch implement-auto-complete-menu-1781422-3.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Ok first try, this code is largely from the Administration menu module. I left out the part where the menu item get's displayed / highlighted when you hover over the auto-complete drop down, as that doesn't make sense for a mobile device. It's just the JS now, it needs some styling.

Status:Active» Needs work
StatusFileSize
new6.59 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1781422_toolbar-jump-menu_4.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

This is great! I refactored the JS into the prototype format we've got going in core lately. I hope the refactor helps to illuminate how we'd like these objects to be structured.

Seems like your still working in the styling.

The one thing I'd suggest you have a look at is jQuery.proxy(). The event handlers are established as proxied functions so that the this of the handler function when it's called is the ToolbarFilter object, not the HTML element that triggered the event. This is an important distinction. To get the triggering element, you have to go into the event object.

Thanks for the feedback. I will look into the proxy function, and implement where applicable.

As far as the styling goes, I'm a bit reluctant to 'design in code'. As far as I can tell there is no mockup for this functionality, if that's true I'll just have a go, but a design would help.

I've asked tkoleary to have a look. He should chime in here shortly with some designs.

StatusFileSize
new95.14 KB

@Boriss Hi. I slapped together a quick prototype of this (attached). I don't do js so it's just static html but you should be able to use most of the markup and CSS. Feel free to change the class names if there are namespace conflicts.

@Boriss Oops. Just realized I had local links in those files.

Also I think it looks a little better with these attributes changed:

.searchbox_open {
border-top: 1px solid #ddd;
border-left: 1px solid #ddd;
border-right: 1px solid #aaa;
border-bottom: 1px solid #aaa;
overflow: hidden;
}

.searchbox_open li:hover {
padding-left: 20px;
margin-left: -20px;
width: 120%;
}

Category:task» feature
Status:Needs work» Needs review
Issue tags:+JavaScript, +Usability, +needs JavaScript review

I don't fully understand why we are discussing style already :) This probably shouldn't be too tightly coupled to the toolbar, so admin_menu can reuse the api's.

Let's get some more discussion around this, I'd be interested in knowing if we can also incorporate actual content/user title searching.

Status:Needs work» Needs review

Presentation styling like padding, bordes, colors etc will go into toolbar.theme.css and be removeable.

Let's not extend this issue beyond simply making the jump-to search bar bring up menu items. We can add another issue to extend it to content or let contrib do that. If we make this issue too big, we'll never get the foundations in.

Status:Needs review» Needs work

Status:Needs review» Needs work

Sorry, for the late reply, I was trying to get this sorted over IRC, but timezones don't match I think. Anyway, at the moment the original code from the sandbox has an <input type="search">. This allows for very limited styling. You can get around this partly by:

input[type=search] {
   -moz-appearance:none;
   -webkit-appearance:none;
}

But I don't know if you want to go and override default search styles on all the devices that might use the search box?

Well, only browsers that recognize type="search" will also recognize the appearance property. All other browsers will render the input element as a text element.

I think the only property we'll want to eliminate is the border on the field, no?

If not, we can be confident that the appearance property will only target those browsers that render the input as a search box. I'd write it like this.

input[type=search] {
   -khtml-appearance:none;
   -moz-appearance:none;
   -o-appearance:none;
   -webkit-appearance:none;
   appearance:none;
}

It would be super super good if we built a Command Bar for Drupal. It would let you zip to Nodes, Users, Menu items, etc. See
https://github.com/blog/1264-introducing-the-command-bar for a terrific implementation. The spark team is pretty swamped right now, so if anyone else could pick up this effortl, you'll be a Drupal Hero forever.

StatusFileSize
new30.76 KB
new22.71 KB
new8.52 KB

@moshe weitzman: that would certainly be great or more fuzzy like search / command as is implemented in the Sublime Text Command Pallet. But at the moment I think thats beyond the scope of searching through the menu. As much as anyone wants to be a Drupal hero.

I've implemented most of the styling in the new patch. Attached as well are the screenshots of this functionality.

search.pngsearch_hover.png

FWIW, I think this is missing a crucial point - I don't think I would have added the search box to admin_menu without the major underlying idea of discovery and learning. #806350: Add a search widget to find links in admin menu

@sun: with "missing a crucial point" do you mean the proposed command bar in #14? Because the patch is about finding links, so I don't see how that differs from 'discovery and learning'.

I think sun is referring to the type of real-time indication of where the menu item you've searched for is found in the menu structure, with a kind of scripted navigation of the menu.

Screenshot of a user searching for a menu item and that menu item being located in the menu structure with an automatic navigation of the pulldown menus

I really really really like that type of 'discovery and learning' model. What I'd like to suggest is we at least get a simple menu item search proposed in this issue and then open another issue to improve the UX.

I want to make sure we get some kind of quick menu searching into the core toolbar and not miss that mark because we shot for the moon and missed.

44 days until feature freeze

@ Boriss Any progress on this. I can't wait to see it! :)

@tkoleary, boris posted a patch in #15 above. I'll set up a publicly accessible demo site with the patch in a couple hours.

StatusFileSize
new10.36 KB

I did a little refactoring to get this to apply to the latest stable patch (1137920_responsive-toolbar_69.patch) at #1137920: Fix toolbar on small screen sizes and redesign toolbar for desktop.

The demo is up at http://toolbar.qemistry.us
u: toolbar_tester
p: uS8593!k

OMG :) Nice, that works pretty good. Could you outline what needs to be done to get this near core level except reviews?

@sun You'r concern is valid, but also an attribute to the way admin_menu works. Given that admin_menu is not in core, I do not see it being necessary in this patch.

@boriss, @Jessebeach Looks cool. Some very minor bugs I'll add. Awesome work.

Looks nice and is fast ;)

I'm wondering if we could expand autocomplete.js, adding an extra method .search that doesn't make an AJAX call, but searches inside a built-in collection.

Otherwise, autocomplete.js is very well tested and has all kind of accessibility parameters, keyboard events, etc .. and is not bloated

It also has highlighting of the matched substring.

------------------------------------
@sun , if we manage to show in the vertical menu a constant reference of "where I am" now, it could add that extra factor of "learning". (Although it won't show it until you land in the page and see the menu again)

We're going to postpone this work until after our must-have-before-feature-freeze work.

Also, the decision has been made (since we were able to come up with consensus) that, for the horizontal/desktop toolbar, it will remain as-is without any 2nd level or deeper menus. So some of the above discussions are now moot.

Issue tags:+toolbar-followup

+toolbar-followup tag

Version:8.x-dev» 9.x-dev

I think this is a great idea, makes it feel like a modern app. But sadly the effort involved in making this truly awesome, is not in scope of the current cleanup phase. I'd be open to move this back, but it seems like few people are involved in making it happen - and it needs quite some work and thinking still (possibly to include actual pages).

Thanks for all the effort so far!

Issue tags:-#d8ux, -d8mux

Moving to 9.x.

Title:Implement the auto-complete menu jumpbar in the responsive core toolbar updateImplement the auto-complete search menu jumpbar in the responsive core toolbar update

(I'm adding the word 'search' to the title since that's what I was looking for in the issue)

I realize this has been listed as something that won't get into D8, but it feels like it would make such a huge difference for discovery and help new Drupal 8 users map their current experience with other CMSes and software (and Drupal 6 and 7) to Drupal 8's information architecture. It's not just a quick way to get around, it seems like it would be truly significant as a way to find things for the first time. A lot of users bail on Drupal because it's confusing and being able to simply find stuff initially is a big deal.

I'm going to reach out to Jesse and Boris to see how close this is to being worthy of inclusion and what major hurdles there still are, an to figure out what I can do to help.

Sorry I only discovered this now, for some reason I was assuming that search was going to be shipped with the new toolbar and found out in PDX from Kevin that it wasn't.

Also talked about this with cweagans and some relevant comments were posted here on #1340626: Add a search/autocomplete to the toolbar:

+1

This would be awesome, and I think it could stop most developers from using the URL bar as a sort of "command line" for Drupal. I don't think it'd be too difficult to do this, and it could almost be built into its own module, rather than being bundled with the toolbar by default. This would also serve as a good example for people wanting to extend the toolbar.

I think this could still be done if somebody wants to really crank on it for the next couple of weeks, and if it's built as a self contained module, hopefully it won't be too hard to review.

I'm going to reach out to Jesse and Boris to see how close this is to being worthy of inclusion and what major hurdles there still are, an to figure out what I can do to help.

chrisshattuck, this feature isn't being actively worked on as far as I know. The chances of it getting into D8 core are slim slim slim. This'll be something that contrib will need to produce.

Issue summary:View changes

Updated the participation details.