Platinum Album

Responsive design is kind of hard.

Tools like Bootstrap are awesome.  They make a developer’s life much easier, because it takes some of the design element questions away.  But there’s a lot of css in those Bootstrap files.  And trying to customize it can be quite tricky.

For example: we’re currently trying to upgrade our photo album feature.  The current setup is straight out of 2003.  A grid (created using tables) of tiny images- click one for a round trip to the server to get the large image, which may be 4000X3000 pixels, if the site admin didn’t feel like resizing.  Want the next or previous image?  Another trip to the server.  On the first image or last image?  No looping- sorry.

So, we’re taking advantage of Bootstrap’s awesome modal element.  It’s so smooth with just a few tweaks (found that the header/body traditional layout wasn’t going to work with the way our images displayed- too much vertical space lost, so we moved the ‘header’ to a right column instead.  Think Facebook’s image viewer layout).  After we added our own ajax setup to get the images, a little looping logic to allow users to cycle through, and a bit of responsive design (and extra ‘prettying’) of the default grid of images, we were just about good to go.

Then I checked my phone.

One of the main goals with all these upgrades is to bring everything mobile friendly.  A dedicated app may be in the future, but it seems like one direction things are going is into making an entire site work on mobile almost as smoothly as a native app does.  So, while upgrading the album feature, we are working in some mobile aspects.  The grid resize was fairly easy, but there are some stray styles on the modal that just won’t cooperate.  Mainly: when resized to a small device, our image automatically goes left-aligned (it’s vertical and horizontal centered in large view).  The modal also expands past 100% of the viewport on a phone, which has to be fixed.  I’m sure there’s some style in the bootstrap.css file that I need to overwrite, but it’s playing hard to get.

The other hurdle is touch events.  I thought jQuery touch would work- and it partly worked great, but it had some bad side effects when interacting with our system.  For some reason, it wanted to reload each page with an ajax fade in effect.  However, on our php-driven system, important info is often transported in the url string (like the id of the album we’re viewing).  When we enabled jQuery touch, this broke- links would fade the screen out, then in, but not change the actual content.

So we found an alternative: TouchSwipe – it’s working pretty well so far.  It’s not as responsive (in the action sense, not in the sizing sense) as a native app would be, but a user can swipe left or right to get the prev/next image.  The way we structured our JS functions, it was also super simple to add (just included a .swipe function call, with returns for swipeLeft and swipeRight).

So we’re getting there.  Not quite up to standard yet, but with this release, we’ll be another huge step forward.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s