Hi Kevin, Many thanks for the detailed feedback. I've had quite a but of feedback spread around various places around the web, but your extra effort to make suggestions has been great.
URL linking / permalink is a key feature that was missing on launch and will be place very soon - so we'll be able to bookmark *and* use the back button (I hope - though there's no ajax, so I'm having to play with the history plugin a bit to see if I can port it to what I'm doing). Navigation - this is definitely the main change that will take place. I'm working on a tree-like accordion approach. It looks like an accordion (style-wise) but acts like a tree - i.e. nested leaves don't automatically collapse when changing subject. This also allows for the 'close' icons to be ditched. In addition, I'd like to add the 'fav' icons on the navigation - which should help the eye scan back and forth between the two you want to compare. The main down side of the tree approach (but isn't stopping me putting it in), is that once you open up a couple of subcategories, the number of visible items becomes quiet a lot. For example - just viewing the 3 functions: Traversing - Filtering - filter Traversing - Finding - find Traversing - Chaining - end Actually has all the top levels exposed (Core, Attributes, etc), then all the subcategories for the Traversing, then all the methods for Filtering, Finding and Chaining (which is why - I think - having the fav icon on the navigation as a visual cue will help skim back and forth to the 3 you were interested in). However, I hope that the more experienced user will twig that you can just view these 3 even faster via the fav filter (which won't show the tree navigation - just a plain list as it does now). Again, many thanks for the feedback. Remy. On Jan 18, 7:46 pm, Kevin Dalman <[email protected]> wrote: > As a front-end designer for complex web-apps and freelance usability > consultant, I want to offer some feedback on the NEW jQuery API > section: > > --------------------------------------------------------- > 1. Bookmarking / Browser Favorites > > When using Ajax to populate pages, it is recommended to use an URL > hash-syntax to allow pages to be 'bookmarked'. This allows direct-link > to a topic to be copied and pasted into a discussion. Since I provide > support to jQuery users, I am constantly providing links like this one > to users: > > http://docs.jquery.com/UI/Droppable/droppable#options > > The new API does not provide a quick or intuitive way to create/copy > such a link. So I recommend that each time page-data is loaded, the > 'path' to that data be reflected on the URL, like: > > http://api.jquery.com/#UI_Droppable_options > > A simple JS function can run on $(document).ready() to check for and > parse the URL hash when one exists - and load the corresponding data, > as well as put the 'main menu' in the correct state. This would > provide bookmark/favorite compatibility with very little effort, and > meet the basic usabilty requirements for URLs. > > --------------------------------------------------------- > 2. Main Menu Usability > > The current design of the main menu in the API is not ideal. Here are > a few ideas for consideration. > > 2-A. TOP-Level title/link > > If the top-level of the menu is going to disappear when you start to > drill-down, then there should be a top-level 'header' to bring them > back. This is more intuitive than 'closing' an item. For example: > > CURRENT Menu Display: > > Attributes > HTML > html() > html(val) > > RECOMMENDED Menu Display > > API Menu (or 'TOP') > Attributes > HTML > html() > html(val) > > By adding a top-level title/link to the menu - that is ALWAYS visible > - it provides a very intuitive way to return to the top-level links. > With this design, the "X" icons should be replaced with more intuitive > 'arrows' that indicate that an item (eg, "HTML") is 'expanded', like: > > API Menu > Attributes [v] > HTML [v] > html() > html(val) > > 2-B. Navigation for Power Users > > The current drill-down method - showing only one menu-branch at a time > - is simple at the sacrifice of speed and flexibility. It is common > for developers to reference *multiple topics* and switch between them > as needed. IDEALLY, this could be done with *a single click*. The > current drill-down-menu can get back to the top-level with a single- > click, but then you ALWAYS have to drill-down to the specific > information - repeatedly. If you are switching between 2 different > topics, this means a lot of clicks! > > A tree-list may seem old-school, but there is a reason they are > standard in applications: They are great for power users, and also > intuitive for beginners. For power users, the big advantage of a tree- > list is that *multiple sub-branches* can be visible at the same time, > allowing movement between any of them with just a single click. This > includes pages within the same parent-branch, but not in the exact > same branch - for example: > > Traversing - Filtering - filter > Traversing - Finding - find > Traversing - Chaining - end > > With the current menu, moving between these 3 closely related topics > requires navigating up/down, up/down, up/down - repeatedly! > > It is even worse when the topics are not related. This means > constantly going back to the top-level menu and drill-down 3 or 4 > levels each time you want to change pages - ie, up/down/down/down, up/ > down/down/down. > > It is even worse if you don't have the 'path' to the information > memorized, ie: > > TOP - Manipulation - Inserting Around - wrapInner(elem) > > It is easy to accidently go down the wrong path and be forced to 'back > up' and try again. For beginners and pros alike, it is frustrating > when you cannot *quickly* find the information you were looking at > earlier. A tree-list cures this by guiding you to previous topics - > because the 'full path' is still displayed for every page you have > viewed (if you choose to leave the tree expanded. > > There are alternative ways to address these usability issues without > using a tree-list, but the tree-list is the easiest and most intuitive > option I can see at the moment. > > --------------------------------------------------------- > > API usablity may seem unimportant compared to getting version 1.3 out > the door, but if a new documentation API is going to be implemented, > I'd like to see its design have the same high quality and usability as > the jQuery code. I have already encountered some of the annoyances > mentioned above, which is why I took the time to contribute this > feeback. > > That's my 2-cents worth. Disagreement and alternate suggestions are > welcome. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
