AB breadcrumb menu glitches

[Jibz]

Last, but not least, in all the plethora of words, we haven't heard of any advantages for flat list style as opposed to Vista/W7 location-based approach. A flat list style may be of use in certain functions of a file manager, but for AB breadcrumbs it is less efficient and user-friendly than other styles.

There are two advantages to the current list I can think of -- it's (marginally) easier to navigate with the keyboard (thought it's just silly it doesn't focus the current folder by default), and it's probably a lot easier to code since it's just a popup menu instead of actually having to implement breadcrumbs.

That being said, there are some drawbacks as well, like it's harder to navigate with the mouse, it doesn't allow some operations like drag'n'drop to a parent folder, and if you're in a deeply nested folder the menu is just hopelessly wide and duplicates all the pre-paths making it hard to get an overview of.

[j_c_hallgren]

the first may take a lot of screen space, the second one you've shown doesn't make it at all clear the hierarchy and I find it quite confusing as I read them as all being children of the same parent...even Google Toolbar uses the first method.

A problem is that both try to represent the breadcrumb trail vertically while, in all other cases that I have witnessed, it is typically shown horizontally. And rightly so, as a lot of monitors these days are wider than they are taller.

I'll agree that most do it vertically, but I have seen it done vertically like XY (but can't recall where just now -- was likely some product(s) I use very rarely) and that's why I gave the most common variant that I use: Google Toolbar (via the "up" button)

Now as to width of present style: If the path segments were possibly ellipsed as needed, it would still clearly show hierarchy but not be as wide, as in:

Code: Select all

C:\
C:\Program Files (x86)\
C:\Pro...\Research In Motion\
C:\Pro...\Res...\BlackBerry\
C:\Pro...\Res...\Bla...\IS71 Connectors\
C:\Pro...\Res...\Bla...\IS7...\OE Connector\
C:\Pro...\Res...\Bla...\IS7...\OE ...\Microsoft.VC80.ATL

I have nothing against showing additional folders as long as they are not restricted to the MRU data as that is a very reductionist approach.

And that approach is what makes XY handling of this better than other methods....but as I said, this can NOT be compared to the Vista/Win7 style as that's a totally separate way of doing it, and both styles meet the criteria of 'breadcrumb' to me.

I strongly disagree that XY's handling is better than other methods, namely Vista/W7 style. A significant number of wishes for that style are a further testament to that. And just because XY's handling is different, it does not make it immune from comparison to other approaches.

You'll notice that I did NOT say that XY's was better than Vista/W7, ok? I said it was a different style and was only saying that XY's showing of MRU was better than not doing so...and much preferable to showing all children which would make it unwieldy and unusable in the current style.

Yes, there have been a number of wishes for the Vista/W7 style and also for clickable path segments and if either of those approaches was done, then that could be much better then present but for now, I feel we can't directly compare the 'apples and oranges'.

[Jibz]

Now as to width of present style: If the path segments were possibly ellipsed as needed, it would still clearly show hierarchy but not be as wide, as in:

Code: Select all

C:\
C:\Program Files (x86)\
C:\Pro...\Research In Motion\
C:\Pro...\Res...\BlackBerry\
C:\Pro...\Res...\Bla...\IS71 Connectors\
C:\Pro...\Res...\Bla...\IS7...\OE Connector\
C:\Pro...\Res...\Bla...\IS7...\OE ...\Microsoft.VC80.ATL

If you don't mind me saying that would be worse, because then the paths do not line up and it's even harder to get an idea of what the folders are.

You'll notice that I did NOT say that XY's was better than Vista/W7, ok? I said it was a different style and was only saying that XY's showing of MRU was better than not doing so...and much preferable to showing all children which would make it unwieldy and unusable in the current style.

Yes, there have been a number of wishes for the Vista/W7 style and also for clickable path segments and if either of those approaches was done, then that could be much better then present but for now, I feel we can't directly compare the 'apples and oranges'.

I agree, the way XY does it has some benefits as well, I just perhaps think it might be better to not call it breadcrumbs .. maybe "pathlist" or something.

Maybe it would be a good idea to add a divider between the actual folders on the path and the guesses from the MRU? just to show people that what is below the current folder is not all the subfolders as they might expect.

And I am hoping there will be a proper breadcrumb implementation in the address bar at some point as well .

[j_c_hallgren]

If you don't mind me saying that would be worse, because then the paths do not line up and it's even harder to get an idea of what the folders are.

I wasn't saying it was great, but it's (I do believe) much better than

Code: Select all

C:
Program Files (x86)
Research In Motion
BlackBerry
IS71 Connectors
OE Connector
Microsoft.VC80.ATL

Because without some sort of indent or tree, that appears way too confusing...using elipses, you at least see that there is a nested situation and see the full names of the parts at least once.

I just perhaps think it might be better to not call it breadcrumbs .. maybe "pathlist" or something.

Maybe...but I don't have quite as narrow a definition of 'breadcrumbs' as some might and thus XY's falls within understanding of the limits of what that term implies.

[zer0]

If you don't mind me saying that would be worse, because then the paths do not line up and it's even harder to get an idea of what the folders are.

I wasn't saying it was great, but it's (I do believe) much better than

Code: Select all

C:
Program Files (x86)
Research In Motion
BlackBerry
IS71 Connectors
OE Connector
Microsoft.VC80.ATL

Because without some sort of indent or tree, that appears way too confusing...using elipses, you at least see that there is a nested situation and see the full names of the parts at least once.

In that example, I tried to apply location-based approach to a flat list style. It didn't work as the flat list style is inherently stifling and inefficient for navigation. A better way would be this

Code: Select all

C: >> Program Files (x86) >> Research In Motion >> BlackBerry >> IS71 Connectors >> OE Connector >> Microsoft.VC80.ATL

...and, depending on the width of AB, varying number of path components would show. But, of course, we know this way as that in Vista/W7

I just perhaps think it might be better to not call it breadcrumbs .. maybe "pathlist" or something.

Maybe...but I don't have quite as narrow a definition of 'breadcrumbs' as some might and thus XY's falls within understanding of the limits of what that term implies.

Path List does seem more appropriate -- it is a flat list style of the current path. Calling XY's representation 'breadcrumbs' is most certainly not appropriate as neither its style nor functionality matches said navigation aid's definition.

Breadcrumbs are almost always implemented the same way, with a horizontal line that

* progresses from the highest level to the lowest, one step at a time;
* starts with the root and ends with the current location;
* has a simple caption link for each level (except for the current location, because you should never have a link that does nothing); and
* has a simple, one-character separator between the levels (usually ">").

This consistency means that people know a breadcrumb trail when they see one and immediately know how to use it. Consistency breeds familiarity and predictability, which breed usability

P.S. I right-clicked on AB's drop-down, current tab's icon and left-clicked 'Up' TB button's drop-down and in all 3 situations I was presented with the same flat list trail. Is such duplication really necessary?

[j_c_hallgren]

P.S. I right-clicked on AB's drop-down, current tab's icon and left-clicked 'Up' TB button's drop-down and in all 3 situations I was presented with the same flat list trail. Is such duplication really necessary?

I believe it doesn't hurt anything and also provides choices for user so they can use whatever method they find most convenient...what you may find easy to use, I may not, and vice-versa...

[zer0]

P.S. I right-clicked on AB's drop-down, current tab's icon and left-clicked 'Up' TB button's drop-down and in all 3 situations I was presented with the same flat list trail. Is such duplication really necessary?

I believe it doesn't hurt anything and also provides choices for user so they can use whatever method they find most convenient...what you may find easy to use, I may not, and vice-versa...

If primary functions of 3 distinct controls differ, then so should their secondary purposes. Besides, I would expect an advocate of choice to say that only one of the above should provide a flat list trail. This would allow remaining 2 to supply different information through their context/drop-down menus