June 22, 2008
Dan Switzer has been up to more good with jQuery releasing a multi-column dropdown plugin developed for Giva that can handle an arbitrary number of elements from a series of nested unordered lists.
There are two things that I like about this plugin in particular:
- Full support for keyboard input
- Designed to handle a lot of data
I have been working with RIAs for a long time, trying to bridge the gap between the power of desktop applications and the distribution model of web applications. When trying to build data-heavy applications, we were regularly disappointed by either the lack of design for lots of data or the poor performance experienced once we exceeded a sample screen of data. I’m glad to see more emphasis on this type of performance at the requirements gathering phase.
All Categories from Feedburner
Dan G. Switzer, II said:
on June 23, 2008 at 6:21 am
@Brian:
Thanks for the kind words. I still think there’s a ton of work to be done with UI controls in general, it’s an area that I think has grown pretty stagnate. So what ends up happening, is developers hack existing controls to try and fit their needs.
I’ve never been a big fan of the whole n-Select model (where you choose something from select element one, that opens up options in another element and so on.) While it solves the technical issue of drilling the user down from a large list to a really focused list, it’s not the best solution from a UI standpoint.
I’d just love to see more people developing different UI solutions to these old problems. While the solution we came up with doesn’t work for every situation, we think it fits our needs really well.
-Dan
brian said:
on June 23, 2008 at 6:53 am
Dan – A change or option that I would see as valuable would be the ability for the type-ahead to filter on any node rather than the current level you’re working at. In the demo, this would enable typing “Humor” and having it find the appropriate node beneath “Entertainment”. I realize this is a potential performance issue but would have some nice usability improvements in that it would help you find whatever you’re looking for as opposed to enforcing the hierarchy on you (where the taxonomy at hand may or may not be familiar to you)
I have to say – the way the type-ahead and auto-select of the level you’re working on behaves, both adding and deleting, is really nice and I’m sure was a PITA to build. That’s the real challenge of UI control; getting that last 5% that makes it feel perfect takes 90% of your effort and thus most people ignore it.
Dan G. Switzer, II said:
on June 23, 2008 at 7:13 am
@Brian:
The issue with your suggestion about Humor, is that it brought up a lot of UI issues I didn’t have good solutions for (it was something I toyed with early on.) For example:
1) If you type “Hu” and it jumps you to “Entertainment:Humor”, what if the “Hu” was a typo and you mean “He” for “Health?”
2) How do you display multiple matches in different branches of the tree? (i.e. if “Hu” matches many items in multiple branches.)
The biggest issue is I just thought the jumping around of the input cursor was a foreign behavior. You could radically be changing what appears in the input box by jumping around to options in various nodes.
I definitely see the benefit of this and it may be a problem I need to eventually solve if feedback dictates, but I opted for what I perceived more expected keyboard behavior. Right now options appear as you type them left-to-right.
Also, knowledge of the menu can make for quick entry. To enter “Entertainment:Humor” I just need to type: “En:H[TAB]” Since we deal with an application that users are very familiar with (they’re on this data entry screen sometimes hundreds of times a day) I’m hoping this learning curve is quick to learn.
Your suggestion is definitely something I keep thinking about though. If you have any recommendations on actual behavior on searching for matches in all nodes, we’d love to hear them. It quite possible feedback from our users will have us re-evaluating things.