Linking to browse page of collection?

[espenmoe]

Is there a link we can use in all collections to navigate to its browse page?

I have been digging around on this page:https://helpx.adobe.com/digital-publishing-solution/help/hyperlinks.html  but I can not find anything else than this:

"Linking to collections  navto://collection/collectionname?openTo=browsePage"

Is it possible to combine it with navto://relative/parent - and have something like this:

navto://relative/parent?openTo=browsePage

[Bob_Bringhurst_]

No, that wouldn't work. The "navto://relative/parent" is a variation of the Back button, which can either take users back to the page in which they tapped (not swiped) to jump to the current article, or it takes users to the article's browse page. If the parent is a browse page, there's no need to specify "openTo=browsePage." If the parent is an article, an article itself doesn't have a browse page.

I'm not aware of a button that will jump up a level to the article's parent browse page. In iOS apps, swiping from the left side does that automatically (it's an iOS convention).

[espenmoe]

Te level above the article is always a collection, but we would like to use Content Vew, and not the Browse page on the option "Collection open default". BUT we would like to be able to navigate to the Browse page from all articles.

So if the parent is a collection with Content Vew , would not navto://relative/parent?openTo=browsePage be an option?

[NMarroquin]

The navto://relative/parent link follows the end-users navigation history to bring the user up a level from their current view.

It sounds like you are need some sort of way to trigger the browse page of the current view that is independent of the user's navigation history. Something like showing the browse page as a modal overlay on top of the current article, which you can either close, or tap another article and navigate to it. The viewers don't have that capability.

[Neil_Enns_-_Ado · Accepted solution]

"Te level above the article is always a collection". This isn't strictly true. You can get to articles via navto links, which puts an article above it in the user's navigation hierarchy.

There is no navigation method currently that is the equivalent of "show the browse page for this collection".

Neil

[espenmoe]

Then this is something we would like to have :-)

[espenmoe]

Now I tested this link:

navto://collection/collectionname?openTo=browsePage"

And it is possible with this link to open the browse page of a collection - but not the collection you are inside of. A could trigger it from articles in other collections.

Could a solution be to let us link to our active collection's browse page?

[Neil_Enns_-_Ado]

Yes, and that's the feature I mentioned above: Allow links to your current collection's browse page. We would like to add support for that, but there is no way to do it currently.

Neil

[samoftheanna]

Our tests show that "swiping from the left side" is not something that our users intuitively try. (Although once they are taught, it's very nice and easy)

Is there a recommended way to indicate or teach this gesture? (preferably without text since we're working in 13 languages)

Can you still create a one-time "welcome screen" for apps?

Alternatively, is there any approximate timeline for when a button that links to the current collection's browse page might be available?

[aziegler]

I read it a few times now and I still don't get it. You mean, that the parent link doesn't go to the parent element in the content structure, but the parent element in navigation history? What is the difference to a back button then?

I would find it just logical if the parent link would follow this structure in the other direction:

http://blogs.adobe.com/digitalpublishing/files/2015/10/Collections-1.png

And this is not the case?

[Neil_Enns_-_Ado]

Correct, it follows the navigation history, not the content structure. It can differ if the user uses a bunch of hyperlinks to navigate between articles in the same collection. In that case back would take you through the articles viewed within that collection, and parent would take you up to how you got in the collection in the first place.

Neil

[aziegler]

I'm still not sure that I understood that fully.

But other than that:

Don't you think that it's illogical that "parent" is not describing the parent element in the content structure?

I certainly wouldn't expect anything else.

[Neil_Enns_-_Ado]

It’s not illogical if parent is defined to describe the parent in the user’s navigation flow instead of parent in the content structure ☺

There are many ways to get into content and navigate around that do not follow the defined content structure in the portal. Navto hyperlinks can be used to create pretty much any navigation flow you can imagine, and that flow can be completely independent of how the content is structured in the dashboard.

Neil

[samoftheanna]

I think the issue brought up in this discussion is that Navto hyperlinks cannot be used to create the, very imaginable, flow of going back to the parent in the content structure.

Is there a way to do that that we are overlooking?

[Neil_Enns_-_Ado]

As mentioned in this thread higher up, a way to guarantee that you can display the browse page for the current collection is not currently available.

Neil

[aziegler]

But the navigation flow is linear and has no tree structure. Therefore I wouldn't expect a previous element in navigation history to be called navto://relative/parent but navto://relative/previous or something similar.

As espenmoe, I believe that a link to the parent browse page has to be created and if you do, how would you call it then without creating a lot of confusion?

Toni

[Neil_Enns_-_Ado]

It's not linear, it builds out a tree. Every time you tap on a card or a navto:// link to something outside of the collection it's a down navigation in a navigation tree that's being built as the reader navigates.

We'll come up with a name that won't be confusing Something like goto://browsepage or something, in keeping with what other goto navigation elements are for.

[aziegler]

Well, I'm looking forward to it.

Thanks!

[IDEXX_AEM_Mobil]

Hello, has any thing like goto://browsepage been released?

[NMarroquin]

No, nothing like that has been released.