+1 Also, with directly linkable pages as Kevin suggested, you could easily allow for opening pages in new tabs by using the hashed URL within links.
-- Zach Carter http://zach.carter.name On Sun, Jan 18, 2009 at 2: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 -~----------~----~----~----~------~----~------~--~---
