6.11 beta 1: Feedback on the new URL copy link format

I think I understand why you've updated the URL format to support Ref.ly. I presume it's so that Mac users don't run into problems in non-Logos applications. However, I think the current implementation is flawed:

I don't think you should change the behaviour of the existing URL option. Personally, I would prefer it if there was a new Ref.ly option (which you could perhaps call 'web').
The HTML option is very strange for Bible passages. It looks like this: James 1:23 ». The reference opens any Bible, whereas the » opens the specific resource. That's very odd, particularly when you're trying to link to a commentary.
Calling the old link "L4" in Logos 6 is just.. well.. curious. The hover text is also wrong (it refers to the logos4 protocol, whereas it actually uses the logosres protocol). The fact that you can't think of a better name than that rather suggests that it ought to be left as "URL"!
The hovertext for URL/L4 (or Web/URL) could be much improved. I think it should say something like:

A link formatted for the web. Uses your web browser to open Logos. It can be used in any application but requires an internet connection to work.
A direct link to Logos Bible Software. Opens Logos directly, without requiring an internet connection. However some applications block these links.

I think it's very important that people understand the pros and cons of the old way and the new way, and the hovertext ought to make that clear.

Find more posts tagged with

Comments

Bradley Grainger (Logos)

Changing the default behaviour of "URL" was intentional.
"It's always been that way." The only change in it was to change the "logosres:" URL (in the second hyperlink) to the equivalent ref.ly URL. I don't actually know who would want to use this format or if it's meeting their needs, so we're open to changing it if there are better suggestions.
It will use the "logos4", "logosres", or "logosref" protocol as appropriate. We wanted to indicate that this is a "legacy" feature.
Thanks for the suggestions; we'll see about rewording these.

Mark Barnes

https://community.logos.com/discussion/comment/810129#Comment_810129

We wanted to indicate that this is a "legacy" feature.

Part of my point is that I don't think the existing system (which works perfectly well on Windows) should be deprecated in favour of a system dependent on a browser and an internet connection.

MJ. Smith

https://community.logos.com/discussion/comment/810163#Comment_810163

I don't think the existing system (which works perfectly well on Windows) should be deprecated in favour of a system dependent on a browser and an internet connection.

[Y]

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/810163#Comment_810163

Part of my point is that I don't think the existing system (which works perfectly well on Windows) should be deprecated in favour of a system dependent on a browser and an internet connection.

We initially planned to replace the existing system with ref.ly URLs, but based on earlier feedback, decided to continue to provide the "L4" option for power users who are familiar with it and know its limitations.

We do not intend for the custom protocols to be the default, even on Windows. (Yes, it works now, but historically, custom protocols have been one of the most finicky integration points, as different browsers and OSes each have their own interpretation of the URI RFCs and mangle the URI data in unpredictable ways, and we can't predict how this will be handled in the future.)

BTW, we do intend for Logos 6 to completely handle any ref.ly URL internally, without going out to the Internet. (That is, the software should rewrite the link to go directly to the destination inside the software, without launching a browser.) If you find a place where that doesn't happen, please let us know.

Mark Barnes

https://community.logos.com/discussion/comment/810220#Comment_810220

BTW, we do intend for Logos 6 to completely handle any ref.ly URL internally, without going out to the Internet. (That is, the software should rewrite the link to go directly to the destination inside the software, without launching a browser.) If you find a place where that doesn't happen, please let us know.

I saw that, and that's certainly a big help. It seems to work well.

And although I'm disappointed your deprecating the existing system, I appreciate the fact that you've left it in.

I see I'm fighting a losing battle here [:)]. As a minimum, then I believe strongly that users need to be fully informed before they choose a new reference system. They need to know that they're making a choice between full interoperability on Mac and dependency on a browser/internet connection. The way things are presented now, (1) Most users won't even know they have to make a choice, and (2) Those who do know will only read about the advantages of the new option, not the disadvantages.