1 Topic by ryan (edited by ryan 2014-04-12 17:16:40)

  • ryan
  • Member
  • Offline
  • Registered: 2013-07-13
  • Posts: 12

Topic: Manual implementations of multi-size image support

Hi,

I'm excited to see that you've added multi-size/adaptive image support (which was actually a feature request of mine - http://juicebox.net/forum/viewtopic.php?pid=4042#p4042), though it's a little disappointing that it's a Pro-only feature. Anyway, my question is in regard to the specifications for this feature when programmatically creating gallery XML. I'm interested in this as I maintain the Drupal integration project for Juicebox, and I know that our users will be asking about this.

Drupal, and other frameworks like it, have their own image processing tools for managing image derivatives, and the ability seamlessly tie these tools to this new multi-image feature is obviously very enticing.

I can see from you multi-size demo XML (http://juicebox.net/demos/pro/multisize/config.xml) that you've added support for new attributes to the image tag (smallImageURL and largeImageURL), which is exactly what I was hoping for. However, there does not appear to be any documentation for all this beyond the notes at http://juicebox.net/support/multisize/, which only reference your JuiceboxBuilder tool. Will you be adding formal documentation for this, from an XML-building perspective, at some point?

Some specific questions include:

  • If "small" and "large" mode are handled by smallImageURL and largeImageURL respective, what attribute is used to define the "medium" mode source, perhaps just imageURL?

  • You say "large" mode (which I presume uses the source defined in largeImageURL) is "used in Large Screen Mode when opening image in a new window or when gallery is expanded". I originally thought this is what the linkURL attribute is for. Would you be able to clarify the distinction between these going forward along with best practices for backwards compatibility with old (pre 1.4) XML?

  • Which source is used when generating a "splash" image in small screen mode? smallImageURL?

  • If XML generated for 1.4-PRO (using smallImageURL and largeImageURL attributes) is used in a pre-1.4 version of your javascript library, or 1.4-Lite, will there be any issues?

I'm hopeful that you'll be able to provide some official specs on all this so that we don't have to reverse-engineer the details.

Thanks again for prioritizing this feature. It may not be very "sexy" for most users, but it's very important from a practical perspective.

  • Registered: 2012-04-24
  • Posts: 5,906

Re: Manual implementations of multi-size image support

If "small" and "large" mode are handled by smallImageURL and largeImageURL respective, what attribute is used to define the "medium" mode source, perhaps just imageURL?

The medium image source is handled by imageURL.

You say "large" mode (which I presume uses the source defined in largeImageURL) is "used in Large Screen Mode when opening image in a new window or when gallery is expanded". I originally thought this is what the linkURL attribute is for. Would you be able to clarify the distinction between these going forward along with best practices for backwards compatibility with old (pre 1.4) XML?

Large Screen Mode will use medium images in normal mode and large images in expanded mode and when opening an image in a new window. I have notified the developers of a couple of exceptions to this rule and will post back when I have more information.

Which source is used when generating a "splash" image in small screen mode? smallImageURL?

The smallImageURL is used for the Splash Page image in Small Screen Mode.

If XML generated for 1.4-PRO (using smallImageURL and largeImageURL attributes) is used in a pre-1.4 version of your javascript library, or 1.4-Lite, will there be any issues?

There should be no issues. Juicebox-Pro prior to v1.4.0 and Juicebox-Lite (all versions) will just use the imageURL entries as before and ignore the smallImageURL and largeImageURL entries.

3 Reply by ryan (edited by ryan 2014-04-13 18:19:52)

  • ryan
  • Member
  • Offline
  • Registered: 2013-07-13
  • Posts: 12

Re: Manual implementations of multi-size image support

Ok, thanks for the info. Will all this be officially documented somewhere at some point?

Also, the point that is still somewhat confusing to me is the handling of the linkURL attribute. Can you clarify how this will be used going forward?

I played around with things a bit and from what I can see the largeImageURL attribute seems to "take over" everything the linkURL attribute used to do in terms of custom "navigation" options. This means that when largeImageURL is define it's used for the "open image" button URL, for navigation when imageClickMode="OPEN_URL", etc. However, it does not appear to be used when the "expand" button is clicked (the imageURL appears to still be used in this case). This actually feels quite backwards to me as I would expect that "navigation" features would be strictly separated from image sizing features. I also know many users like to use Juicebox to display images, but also define non-image URLs for each image that can be linked to outside of Juicebox. For this they have been setting a non-image URL (e.g. a URL to a normal webpage) for the linkURL attribute and then using the "open image" button, or features like imageClickMode="OPEN_URL", to navigate users to these special webpages that are related each image. From what I can see this kind of setup will be broken when these users upgraded to 1.4 pro, unless of course they ensure they are not using this new multi-size feature (i.e. not defining largeImageURL).

We have built-in special features within the Drupal integration module to allow users to define custom URL patterns, or dedicated image derivatives, specifically for the imageURL value. We did this due to high demand from users who wanted to do things like what I described above (link each image to a non-image URL, or some special full-size derivative), so I want to be sure I understand how the linkURL value will be leveraged in the new version(s) of your library. On first glance it seems like there are some inconsistencies, but it's very possible that I don't understand all the details just yet. I'm thinking that linkURL and largeImageURL should always be set the same, but I'm not sure what to offer users who may expect to be able to configure them separately.

Please just let me know if I can provide more clarification on all this. I just want to fully understand these kinds of things as I now find myself in a role where I indirectly represent a few thousand of your users (who experience it via Drupal).

Also, it looks like 2 new attributes have been added to the <juicebox> tag in the XML, useLargeImages and useSmallImages. However, toggling these from TRUE to FALSE does not have any affect that I can see. Do these values also have to programmatically be set in a certain way for the multi-size features to work?

  • Registered: 2012-04-24
  • Posts: 5,906

Re: Manual implementations of multi-size image support

Will all this be officially documented somewhere at some point?

I do not know if the complete logic which Juicebox uses to determine which image URL to use will be documented.
However, it takes into consideration factors such as:

  • Display mode (expanded vs normal)

  • Display screen (retina vs non-retina)

  • Screen mode (large vs small) which also takes into account the user's device (desktop vs mobile) and screen size

Also, the point that is still somewhat confusing to me is the handling of the linkURL attribute. Can you clarify how this will be used going forward?

Currently, the largeImageURL does take precedence over the linkURL. This is a bug which we intend to fix as soon as possible.
If a linkURL is defined, then it should always be used when clicking the 'Open Image' button (and for when imageClickMode="OPEN_URL"). If a linkURL is not defined, then Juicebox should use the largeImageURL and if a largeImageURL is not defined, then Juicebox should use the imageURL.

Also, it looks like 2 new attributes have been added to the <juicebox> tag in the XML, useLargeImages and useSmallImages.

These two new attributes are used only by JuiceboxBuilder-Pro when editing an existing gallery. They are not used by Juicebox itself (and therefore not required at all) when a gallery is being displayed.

I hope this makes sense and helps to clarify things.

  • ryan
  • Member
  • Offline
  • Registered: 2013-07-13
  • Posts: 12

Re: Manual implementations of multi-size image support

Currently, the largeImageURL does take precedence over the linkURL. This is a bug which we intend to fix as soon as possible.

Thanks, that certainly helps explain things. I think this means that my conceptual understanding of things is solid, and it'll just be a matter of digging into this further one that bug is fixed (maybe a 1.4.1 release?).

Cheers

  • Registered: 2012-04-24
  • Posts: 5,906

Re: Manual implementations of multi-size image support

I think this means that my conceptual understanding of things is solid

Yes. Juicebox's behavior regarding the linkURL should be logical and easy to understand (bugs notwithstanding). If a linkURL is set, then it should be used in preference to any image URL.

maybe a 1.4.1 release?

Very likely. As I mentioned earlier, we aim to fix this bug as soon as possible. If you (or any other users reading this) would like to be kept informed of new releases, then please join our mailing list at the foot of our homepage, follow us on Twitter @JuiceboxGallery or subscribe to our blog RSS feed.

  • Registered: 2012-04-24
  • Posts: 5,906

Re: Manual implementations of multi-size image support

We have just released a hotfix version of v1.4.0 which includes a fix for the problem you reported (the largeImageURL overriding the linkURL).
Details on how to get the latest version can be found on the Upgrading Juicebox support page.

  • ryan
  • Member
  • Offline
  • Registered: 2013-07-13
  • Posts: 12

Re: Manual implementations of multi-size image support

That's great, thanks!

I'll grab a copy of that as soon as I can. At the moment it looks like I've used-up my 5 pro downloads, so I'll have to wait until someone responds to my request for a new link.

Anyone interested in the Drupal-side of things may also want to see these notes on the topic: https://drupal.org/node/2246851

Also, you may want to update the version history at http://juicebox.net/support/history/ as there does not appear to be a reference to 1.4.1 (or any new revision/build number) there yet.

Cheers

  • ryan
  • Member
  • Offline
  • Registered: 2013-07-13
  • Posts: 12

Re: Manual implementations of multi-size image support

I downloaded a copy of the most recent 1.4 and can confirm that the logic looks very good. The linkURL details appear to be handled just as before and the new smallImageURL and largeImageURL appear to be selected as expected. That's great! I'm one of this features biggest fans.

My only pending comment is that the new build, which is clearly a different public release, is still tagged as 1.4.0 as opposed to 1.4.1 (1.4.n or whatever the current patch number is). Was this an oversight? Users may reference this to confirm whether-or-not they are patched, and integration tools (like ours) may parse it to auto-detect if certain integration features should be enabled or not. It looks like you are using a semantic version scheme, but I just wanted to confirm.

  • Registered: 2012-04-24
  • Posts: 5,906

Re: Manual implementations of multi-size image support

The decision was made to swiftly release an updated version of Juicebox-Pro (with this bugfix integrated) but to not increase the version number. If you need to differentiate between versions, the Build Time (in the comments section at the top of the 'juicebox.js' file) will always differ from build to build.

  • ryan
  • Member
  • Offline
  • Registered: 2013-07-13
  • Posts: 12

Re: Manual implementations of multi-size image support

Ok, thanks for the clarification.

Whenever I see that the code/build has changed on a project, but the version number has not, I immediately assume that I've somehow got a "working" copy that's not yet tagged for stable/public use. This is why I was concerned, and suppose others could be as well. For whatever it's worth I'd encourage your developers to use a true semantic version scheme (http://semver.org/) as that might help avoid confusion in the long run... just my 2 cents.

I really appreciate the attentive response and quick turnaround on all this. Thanks very much!