New Breadcrumb column type for LD/LT + Replace title/location?

Hi devs,

Right now we display both title and location in LD/LT so that users can filter on what they want. However this can have some drawbacks:

  • It takes 2 columns
  • If the user is using technical page ids (like using some kind of UUIDs) they may not want the users to see them in the LD/LT, they might prefer the users to see the page titles instead.
  • It doesn’t allow to filter on the titles of parent pages from the document path/breadcrumb. Imagine a document with reference XX1.XX2.YY1 displayed in the location column. Also imagine that the titles are XX1=title 1, XX2=title2, YY1=My Page title. It would be nice for the user to see title 1 / title 2 / My Page title and be able to filter on any part of it.

So, WDYT about introducing a doc.breadcrumb(maybe not the best name?) new column type to do that?

Problems I see:

  • We need to compute the titles for all the reference parts and that’s more costly

I wonder if the extra title cost means we need to finally introduce a title cache as we discussed in the past.

Then, the next question is whether we would be ok to replace the title + locations columns in the LT/LD that we currently use (like in the Page Index) by this new “breadcrumb” column.

WDYT?

Thanks

My only worry on that topic is about the usage of filters: let’s say I have 2 pages with following reference=title: Bar=Another page, Baz=Baz.

If we decide that it should always filter on both the computed title and the reference, there will be some weird behaviour, e.g. if I filter on “Ba” I’ll see “Another page” and “Baz”. Which is not really intuitive for the first one.
So I’m wondering if for going in this direction we shouldn’t have some dynamic switches to display the references or the computed title, to better understand the filter results.

Now besides that issue I’m +1 to have a single column with a breadcrumb.

For the breadcrumb column type, I would filter only on the computed title as otherwise the user wouldn’t understand the reason it’s matched (e.g. you type “main” and it returns “Home” (for Main.WebHome).

Yes that’s another idea but I think it defeats the idea of not showing the technical document ids to the user and relying only on the title. What could work though, is that this switch and filtering behavior could be controlled depending on whether you’re an advanced user or not:

  • simple user: filter ony on titles
  • advanced users: filter on both titles and references + have a button to switch the column display

The question that would remain is: where would that switch be located and what would it look like :wink:

There’s still my worry on the performance to solve too.

About that I guess we could imagine some cache mechanism: since the computed title for a space would be used for any nested page of that space, it could quickly improve perf.

That’s:

+1 for the general idea, having one less column is always nice.

We might even want to store titles if we want to be able to provide accurate and efficient sorting of columns involving the titles.

you can use velocity in title, so they might be dynamic depending on the context user.

Yes that’s one reason for the title cache. See the 2 links I provided.

Yes that’s one difficulty but the cache could still work for titles not using scripts.

Related to this, titles can also be generated from the content, this is why in the proposal at Title Cache (Proposal.TitleCache) - XWiki there was the idea of removing this feature. Since then, we’ve introduced a config param to turn it on (it’s off by default now).

Yes, because this way:

  • we can emphasize the page title, which most of the time is more important than the rest of the path; the best practice is to put the important information on the left (for left to right readers) so that our eyes find it first
  • and the user can sort on the page title independent of the rest of the path

With a single column we loose this:

  • the page title is “hidden” at the end of the path: it doesn’t start at the same location vertically and you need to visually scan (left to right) the entire path (which can be very long BTW) to identify the page title; I know there can be pages with the same (or almost the same) title in various places of the hierarchy and for these the path is important, but for most pages the title is kind of unique in the hierarchy, meaning that the user identifies and knows them by their title.
  • you won’t be able to sort on the page title, but only on the path

Both Live Data and Live Table are currently using a database (HQL) source, so the pagination, sorting and filtering has to be done through a HQL query. We currently cannot sort or filter on the title-based location because we cannot compute it at query time (HQL): we would have to join ancestor documents / spaces but the path length is variable. Adding support for this is not trivial at all:

  • either add a column to the database to hold the title-based location (but adds redundancy and we need to handle synchronization, which can be very costly when changing the title of a top level page that has a huge hierarchy beneath)
    • to the xwikispace table to hold the title-based equivalent of its reference column
    • or to the xwikidoc table to hold the title-based equivalent of its fullName or space column
  • or switch to a Solr-based data source (will be a pain to migrate some of the existing live data / table instances that rely on HQL)

Realistically, I think we have 3 options:

  1. display the raw location, but allow sort and filtering (current behavior)
  2. display the title-based location, but disable the sort and filtering
  3. display the title-based location, but sort and filter on the raw location as we currently do (we could show a note below the live data when we detect that the raw location is different than the title-based location at least for one entry / row, as we do for title filtering)

No, I don’t think it’s a good idea, for the reasons mentioned above (it emphasizes too much the location / path to the detriment of the page title which is more important). I’d be OK to replace current location column with a title-based location that is sorted and filtered on the raw location (it’s not perfect but similar to the behavior of the title column).

Thanks,
Marius

1 Like

Thanks @mflorea for your answer. Very useful.

So for the usage I have in mind (it’s a wiki where all pages have UUID-generated names), any solution that doesn’t filter/order based on the title is not going to cut it. Thus I’d like to estimate the cost of implementing a title cache.

I’ve started a thread to brainstorm about it at Title Cache Design