AB breadcrumb menu glitches

[zer0]

As per screenshot below, non-existent folders are still shown in AB's breadcrumb menu.

ab_breadcrumb_bug.png (27.34 KiB) Viewed 2852 times

Also, screenshot below seems to show breadcrumb menu not for the current path

ab_breadcrumb_bug2.png (24.05 KiB) Viewed 2852 times

[admin]

The bold one is the current path. I thought you know that XY's breadcrumb goes up and down. Ain't it cool?

The "down-part" is based on the MRU data. If they are out of synch with reality, well... I guess the user knows what happened to that recently visited path that does not exist anymore. I see no problem in showing this.

[zer0]

The bold one is the current path. I thought you know that XY's breadcrumb goes up and down. Ain't it cool?

Not really, at least not IMO. The description for AB's breadcrumb menu says "current path", so I was not expecting additional folders

The "down-part" is based on the MRU data. If they are out of synch with reality, well... I guess the user knows what happened to that recently visited path that does not exist anymore. I see no problem in showing this.

It's quite redundant to show it. A breadcrumb menu is an navigational aid tool, so showing location(s) to which a user cannot navigate -- or can try, but gets an "Not found" message -- bears little merit

[admin]

It can be survived.

General Note: I don't like this tendency in some posts here to speculate what an abstract user might expect or not expect. This kind of speculation is my job and I do it all day long. What helps me to do this job better is direct first-hand user feedback. Not another one who does his idle guessing. I won't take part anymore in discussions based on speculations.

[PeterH]

Only partly agree with both...

- showing a longer last-used path can be helpful - especially going up and down, while
- showing a no-more-existent path isn't really expected.

[zer0]

OK, I will rephrase: there is no point in showing me breadcrumb entries for non-existent folders. They are irrelevant as I can't navigate to them.

Likewise, if the current path has child folders, show all of them (not those in MRU data) as that's typical breadcrumb behaviour.

[j_c_hallgren]

OK, I will rephrase: there is no point in showing me breadcrumb entries for non-existent folders. They are irrelevant as I can't navigate to them.

I would tend to agree with this...showing places that aren't possible doesn't seem ideal, but it's also not a show-stopping issue either.

Likewise, if the current path has child folders, show all of them (not those in MRU data) as that's typical breadcrumb behaviour.

Personally, I don't want to see all the children! That's what I use the tree for...Showing all child folders could make the breadcrumb take over the entire screen, if one was pointed to certain system folders...so just showing me MRU is much more beneficial!

Now if we're talking about the Vista/Win7 style clickable parts breadcrumb, then that's a totally diff situation but the XY breadcrumb is best as is.

The bold one is the current path. I thought you know that XY's breadcrumb goes up and down. Ain't it cool?

Not really, at least not IMO. The description for AB's breadcrumb menu says "current path", so I was not expecting additional folders

Well, if we interpret "current path" strictly to not show additional folders, then the breadcrumb menu ceases to exist as the only true current path is the folder we're in at that time.

[zer0]

OK, I will rephrase: there is no point in showing me breadcrumb entries for non-existent folders. They are irrelevant as I can't navigate to them.

I would tend to agree with this...showing places that aren't possible doesn't seem ideal, but it's also not a show-stopping issue either.

I can't think of any possible use in showing non-existent folders. If they can't be actioned, they shouldn't clutter the menu.

Likewise, if the current path has child folders, show all of them (not those in MRU data) as that's typical breadcrumb behaviour.

Personally, I don't want to see all the children! That's what I use the tree for...Showing all child folders could make the breadcrumb take over the entire screen, if one was pointed to certain system folders...so just showing me MRU is much more beneficial!

With breadcrumbs, it's everything or nothing. They are supposed to represent the hierarchy of multi-level directories and folders. Restricting it to just the MRU redefines what a breadcrumb menu is and is not in line with breadcrumb menus in other applications.

And in showing complete paths to all locations in the breadcrumb menu lies another problem: that's not how breadcrumb menu should work. Let's take a deeply nested location -- C:\Program Files (x86)\Research In Motion\BlackBerry\IS71 Connectors\OE Connector\Microsoft.VC80.ATL\ -- as an example of how current menu can take over a large part of the screen. Its breadcrumb menu is as follows:

Code: Select all

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

And that's very wide! A text-book breadcrumb approach would make the menu look like this

Code: Select all

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

Significantly less wider and not imposing on the screen

The bold one is the current path. I thought you know that XY's breadcrumb goes up and down. Ain't it cool?

Not really, at least not IMO. The description for AB's breadcrumb menu says "current path", so I was not expecting additional folders

Well, if we interpret "current path" strictly to not show additional folders, then the breadcrumb menu ceases to exist as the only true current path is the folder we're in at that time.

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.

[grindax]

.

[zer0]

With breadcrumbs, it's everything or nothing. They are supposed to represent the hierarchy of multi-level directories and folders. Restricting it to just the MRU redefines what a breadcrumb menu is and is not in line with breadcrumb menus in other applications.

Except what's being spoken about in this context is what is displayed down-level from the current location. Other applications don't show anything going downwards in a breadcrumb view. You would never want to view everything below, just locations you've visited.

That's not strictly true. Vista/W7 address bar, when in breadcrumb mode, can show all children of current folder's/dir's parent via a click on a drop-down chevron immediately to the left of current folder's/dir's.

[grindax]

.

[zer0]

Because XYplorer currently uses a "flat list" approach to showing a breadcrumb trail, it can only show you what's above and below. In the current confines, I think it makes sense that it shows everything above, and a few of the visited locations below.

Of course I would agree that there are certain advantages to the implementation of a breadcrumb function that has chevrons at every level of the hierarchy where you can choose to branch off from, but that's not possible in the flat list approach currently implemented in XYplorer.

The thing is, "flat list" does not represent the folder/dir hierarchy, so it is not semantically-appropriate as a breadcrumb approach. One may wish to nest items in a flat list to remedy, but then it's no longer a flat list. Further, when in a deeply nested folder, flat list breadcrumb menu becomes very wide with at least half of its footprint wasted.

"Flat list" approach doesn't resemble breadcrumbs in real life either. This is because breadcrumbs are meant to be roughly the same size, but with a flat list their size increases when navigating deeper into the dir/folder structure. Likewise, when navigating up to the root folder, I start with a loaf of bread (full current path) and get slices and then crumbs as I get closer to the top level.

XY's flat list representation of the breadcrumb menu seems to have little resemblance to the breadcrumb concept both in terms of functionality and real-life equivalents. This is why numerous people have been asking for a Vista/W7-like implementation as that is a true location-based breadcrumb approach.

[Jibz]

I think zer0 is right in his criticism.

However, I think the problem is not so much with what the XYplorer menu shows, but more with terming it breadcrumbs when it is not.

Maybe it would be a good idea to call it something else to avoid people getting confused when it doesn't work as breadcrumbs in other tools?

Btw, why doesn't it pop up with the current folder focused?

[j_c_hallgren]

With breadcrumbs, it's everything or nothing. They are supposed to represent the hierarchy of multi-level directories and folders. Restricting it to just the MRU redefines what a breadcrumb menu is and is not in line with breadcrumb menus in other applications.

No, it's not everything or nothing! I've seen various approaches to it and while XY's may be a bit different, it's because it's adding a worthwhile feature...just because XY is not consistent with some applications doesn't make it wrong...or make them correct either.

And in showing complete paths to all locations in the breadcrumb menu lies another problem: that's not how breadcrumb menu should work. Let's take a deeply nested location -- C:\Program Files (x86)\Research In Motion\BlackBerry\IS71 Connectors\OE Connector\Microsoft.VC80.ATL\ -- as an example of how current menu can take over a large part of the screen. Its breadcrumb menu is as follows:

Code: Select all

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

And that's very wide! A text-book breadcrumb approach would make the menu look like this

Code: Select all

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

Significantly less wider and not imposing on the screen

It's your opinion that the breadcrumb menu should work that way, ok? I don't share that...because while 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.

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.

[zer0]

With breadcrumbs, it's everything or nothing. They are supposed to represent the hierarchy of multi-level directories and folders. Restricting it to just the MRU redefines what a breadcrumb menu is and is not in line with breadcrumb menus in other applications.

No, it's not everything or nothing! I've seen various approaches to it and while XY's may be a bit different, it's because it's adding a worthwhile feature...just because XY is not consistent with some applications doesn't make it wrong...or make them correct either.

There are 3 ways of representing breadcrumbs: path-based, location-based and attribute-based. For file managers, the most appropriate one is location-based. And consistency is important, because it allows me -- giving direct first-hand user feed back here -- to move to another product and have one less thing to learn/adapt to.

It's your opinion that the breadcrumb menu should work that way, ok? I don't share that...because while 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 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. If anything, being different predisposes it to comparison.

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.