Using jQuery UI Tooltips With Autocomplete

The jQuery UI autocomplete widget can transform the way each individual item is rendered. By default, it only renders the data label. But that's easy to change by extending the autocomplete widget, and overriding the _renderItem() method. For example, if each object in the autocomplete source has some specific field you would like rendered in the autocomplete drop-down, that's not difficult to implement. The challenge lies with finding enough space on the page to render this additional information. The auto complete already utilizes the menu widget to render the drop-down component — so why not utilize the tooltip widget as well?

jQuery UI: Highlight Selected Menu Item

The jQuery UI menu widget doesn't actually show the user which item they've clicked. It's helpful, however, if the user knows what they're looking at. Selecting a menu item will probably change the content elsewhere on the page, and the last thing clicked should give an indication of what we're looking at. With the select event, we can change the display state of the selected menu item.

jQuery UI: Menu Dividers

The jQuery UI menu widget has a great feature — one I should probably use more often — dividers. These dividers are great, speaking from the user perspective, because they allow me visually differentiate the various option groups within a menu. For example, printing options are grouped together while saving options are grouped together. And this is really easy to do in a jQuery UI menu. Although it's documented, it's not demonstrated. So allow me to provide an example, if you will.

Menu Icon Fix For jQuery UI

With a few additional elements in the markup, it's easy to add icons to jQuery UI menu widgets. We simply place spans to the left of the menu item text. We also have to add the relevant icon classes from the theme framework. That's the easy part. However, since we're manually changing the way the widget is rendered, there's no guarantee that it'll look how it's supposed to. And in fact, there is a minor issue with the icon placement — they're slightly too high.

jQuery UI Select Menu

jQuery UI 1.8 is now at release candidate 3 and is looking like a 1.8 final release will be available any time now. After looking at the button demos, I haven't yet decided if I'm going to replace my existing custom buttons with these new widgets.

The auto-complete widget does look very promising, especially for large data sets. However, I have several instances where I have only a small data set and using an auto-complete widget would be overkill.

The select-menu widget looks perfect and I'm looking forward to a stable version in jQuery UI. It will be nice to replace the standard select elements, which look really out of place in a jQuery UI theme.

Exploring Application Menu Data Structures

All modern GUI applications have menus in one form or another. These menus offer the end user an easy way to navigate throughout the application while consuming minimal real estate. This is achieved because menus in applications are often hierarchical, which means that only the top level of the hierarchy needs to be displayed when the menu is not being navigated. Not only do menus help make efficient use of the application GUI space, but they also help with the logical organization of the actions the user may perform within the application. As the user navigates to lower levels in the hierarchy, the more specific the available actions become. Horizontal, desktop-like menus are becoming more frequent in web browser GUI applications. This further complicates the task of designing a portable menu data structure.

The hierarchical menu data structure is by far the most commonly encountered menu structure. The data structure for GUI menus changes drastically when the structure is built dynamically verses a static menu structure. For statically built menus, which are represented by HTML, there is no concern about changing menu items. Although this approach is a poor design, the developer simply edits the HTML menu structure to add in the new menu items as needed. With static menus such as these, the structure is entirely dictated by the surrounding page and CSS styles. Another reason for avoiding static menu data structures. Consider the requirement of dynamically building a menu data structure that is functional for both hierarchical and non-hierarchical menu styles. If the data structure used for this is dynamically constructed, it can be reused. If we want to use this dynamic menu-building code to construct a single-level GUI menu, we simply use the code to build hierarchy data structure with multiple roots an no children. However, this calls for flexible presentation code which transforms the data structure into the GUI. This is another challenging problem in its' own right.

Here is an example data structure that could potentially be used to build a GUI menu.

{\
  "File":[{"Exit":{"action":exit()}}],\
  "Edit":[{"Heading":[{"H1":{action:h1()}},\
                      {"H2":{"action":h2()}}]\
         }]\
}

Here, we have two root elements in the hierarchy. Here is another example of representing the same menu data structure.

[
   {"title":"File",\
    "children":[{"title":"Exit",\
                 "action":exit()}]},\
   {"title":"Edit",\
    "children":[{"title":"Heading",\
                 "children":[{"title":"H1",\
                              "action":h1()},\
                             {"title":"H2",\
                              "action":h2()}]\
               }]\
   }\
]

Here, children are explicitly specified for each node in the hierarchy. Both approaches are valid ones, one preferred by one developer over the other. However, the boss of what this data structure should look like, ultimately, is the code that uses it to build the GUI menu.

The chief idea behind using data structures such as these, and building them dynamically, is to achieve better portability and reuse with GUI code. However, much GUI code, especially in web applications, change the menu data structure simply to change the style of the GUI. This is invalid since the menu items do not change. It would be much nicer, for developers hailing from all walks of life, if a consistent GUI menu data structure could be used and reused. This is especially important for cross-browser compatibility in web applications. The good news is that many modern javascript toolkits support the notion of widgets. The widgets within these widget sets comply with one another to offer a consistent style framework. This gives developers an opportunity to use a consistent menu data structure. Widgets aren't always needed for this purpose. If developers write their own code to build the intermediary HTML representation of the menu data structure, that works too. Just be consistent about it.

Trouble extending Trac navigation.

I'm in the process of building a new Trac site. I wanted to add new menu items to the main navigation. Hiding or rearranging the default menu items in Trac 0.11 is quite straightforward. It can all be done in the Trac configuration. However, new menu items need to be part of a component. Hence, the need for the NavAdd plugin.

It looks like the plugin has not yet been updated to fit the 0.11 plugin architecture, although it does work with 0.11. The Trac plugin API changes weren't too drastic. I did notice some strange behaviour though. It turns out that any menu items added with the NavAdd plugin can not be considered active.

What? No active menu items? Well, it isn't really the NavAdd plugins' fault. It turns out, that in order to have an active menu item, the current request needs to be handled by the same component that produces the menu item. I discovered this by looking at the timeline Trac component. This component actually implements the IRequestHandler interface. This is necessary because the timeline component handles requests to the /timeline URI. The menu item produced by this component becomes active anytime the /timeline URI is visited.

So, this design works well for components that have URIs. But what if I want to add menu items that point to wiki pages? And what if I want to have my menu item become active when visiting those pages? There is currently no way to do this. My suggestion would be that the INavigationContributor interface adds a new uri field to be returned from get_navigation_items(). When page corresponding to this uri becomes active, so does the custom menu item.