Two things bother me more: - James' #3 point, that other categories hide when you click one, an accordion would be a better fit for quick navigation. - the subcategories. I like to see the method's names directly, deciding between "Hierarchy" or "Child filters" is not an intuitive task. They should be in a kind of tree with the subcategories as separators.
These two things would speed up navigation a lot. As it is, it's quite interesting the first time, but gets irritating after a while. Thanks for this Remy, and long live JSBin! :) cheers, - ricardo On Jan 15, 6:35 pm, Remy Sharp <r...@leftlogic.com> wrote: > Hi James, > > Thank you for your detailed feedback - all good points. > > I want to push out another release when 1.3.1 goes live - so I'd like > to get some, if not all, of the feedback addressed (including others). > > 1 + 2) almost the same thing - the first problem I see is the AIR > browser, which obviously doesn't have a back browser button (which > would be solved by your first point). This needs some UI input (which > I'll come on to in a minute). > > 3) I've talked with Yehuda Katz, the original author of Visual jQuery, > about navigation interfaces - there's two options (as alternatives to > what I have now) that we talked about: tree nav and accordion. > > Generally speaking, the tree navigation didn't take as well as the > Visual jQuery approach. An accordion (I think) would solve the issues > you've specifically mentioned, but would also solve some similar > feedback I've read, i.e. wanting to be able to scan a category whilst > maintaining some hierarchy. (note that you can do this - but it > doesn't quite solve the problem:http://api.jquery.com?category=attributes > ). > > 4) Easy to solve - I didn't have access to a designer (I'm a coder > through and through) but a few simple tweaks to the CSS (I suspect) > should sort this out. > > 5) I've had the same feedback, but both as a pro *and* as a con (as > you have) - so I was going to create an options area that would > maintain some certain settings - the focus opacity being one of them. > > 6) This is common piece of feedback - and simply a technical block I > ran in to and ran out of time. Permalinks are my to priority right > now, I want people to link straight in to a specific function. I > won't be able to have the URL change as the user browses - but the > title of the function (and probably some other visual que, i.e. icon) > will give the user a permalink to the function. > > I also want this to work for categories too, so: > > http://api.jquery.com/attr- would show a list of all the matched > functions (alahttp://api.jquery.com/?attr) - but I'd like it if the > category hierarchy would also show in left sidebar. > > In addition: > > http://api.jquery.com/Core- would land open the Core category - and > so on through the subcategories. > > I'd be more than happy if you contact me offline to lend a hand with > some of the UI changes required. > > @Pappy - there's more I want to do with landing pages, but it's a > slightly more complicated job (given that, I think, 1.3.1 is supposed > to be going out next week) - but some fast view on all the functions > would be useful - I agree. > > If there's more feedback - I'd love to hear it - particular the issues > people have. > > Many thanks, > > Remy. > > On Jan 15, 4:22 am, James Van Dyke <jame...@gmail.com> wrote: > > > Does anyone else find the new API browser to be a bit cumbersome? > > > My gripes: > > > 1) No "back" link at top of vertical navigation list. You must click > > the category to cancel your choice and essentially go back. However, > > this isn't very intuitive and there aren't any affordances to this > > behavior save for a small 'x' in the highlighted category box that > > doesn't do anything on hover or even have a tooltip. > > > 2) The browser's back button is broken. Kind of a big annoyance when > > you're not used to the application. > > > 3) Recovering from a mistake is more punishing than it should be. > > Clicking on a category hide the other categories. Since the title of > > the category moved from under your mouse, you now have to scan to the > > top of the list. Once you make sure you're in the category you meant > > to click on, but don't find the function you were looking for, you > > click the category name and wait as everything moves around, then > > repeat scanning through list again. A good example of this is trying > > to find an unfamiliar selector in the Selectors category. > > > 4) Little distinction between categories, subcategories, and items. > > They're all the same color and categories and subcategories share the > > same faded 'x' icon. The only difference is that the category has bold > > text and the subcategory has a white line under the box, but not > > between it and its category. > > > 5) When hovering over a list of options for a function (e.g., $.ajax) > > only the item you're hovering over has full opacity making the others > > hard to read. I'm ok with the distinction, but I think it's a little > > extreme. I found myself avoiding hovering over the list, which is > > hard since I tend to scan the page with my eyes as my mouse follows my > > line of sight. Try scrolling through the options for $.ajax while > > trying to read them. > > > 6) The window title changes when viewing an item, which makes one > > think that the URL will map to that page. However, the URL does not > > change and I can't find a permanent link to paste to a co-worker. > > > Don't get me wrong, I think Remy has made a great step towards a > > better API, but design efforts seem to have favored neat effects over > > human factors. I deal with a lot of these design issues at work so I > > tend to have a keen eye for these things and can be too picky at > > times. > > > Has anyone else been bothered by this? If not, what do you like or > > what makes up for the negatives? Maybe we can compile a list of > > existing *good* things as well so that those features can be brought > > to the fore while the problems are resolved.
