| Project: | Drupal core |
| Version: | 9.x-dev |
| Component: | toolbar.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | JavaScript, mobile, needs JavaScript review, toolbar-followup, Usability |
Issue Summary
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.
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.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| Screen Shot 2012-09-11 at 1.11.20 PM.png | 42.05 KB | Ignored: Check issue status. | None | None |
Comments
#1
I think it should be the branch node/1137920-responsive-toolbar-with-dropbutton-patch as patch from #1608878 is not committed yet.
#2
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.
#3
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.
#4
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
thisof 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.#5
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.
#6
I've asked tkoleary to have a look. He should chime in here shortly with some designs.
#7
@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.
#8
@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%;
}
#9
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.
#10
Presentation styling like padding, bordes, colors etc will go into
toolbar.theme.cssand 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.
#11
#12
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?
#13
Well, only browsers that recognize
type="search"will also recognize theappearanceproperty. 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;
}
#14
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.
#15
@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.
#16
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
#17
@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'.
#18
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.
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
#19
@ Boriss Any progress on this. I can't wait to see it! :)
#20
@tkoleary, boris posted a patch in #15 above. I'll set up a publicly accessible demo site with the patch in a couple hours.
#21
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
#22
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.
#23
@boriss, @Jessebeach Looks cool. Some very minor bugs I'll add. Awesome work.
#24
Looks nice and is fast ;)
I'm wondering if we could expand autocomplete.js, adding an extra method
.searchthat 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)
#25
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.
#26
+toolbar-followup tag
#27
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!
#28
Moving to 9.x.
#29
This seems like relevant information - http://engineering.twitter.com/2013/02/twitter-typeaheadjs-you-autocompl...