Announcing Mobile Responsive Early Access Launch

That looks awesome!
Emailing for the Beta group as we speak.

Coool!

This is great! Although images aren’t retina ready (or maybe I’m missing something). Any news in supporting @2x?

I generatet a variant B of a page and resized al elements intothe mobile format but when I open this variant with a smarphone there is no responsivness. Still the desktop version appears

Hi Gian, 
Perhaps I can give a bit of clarity here. Our Mobile Responsive functionality works by utilizing a single breakpoint that defines if the page should be displayed as  desktop _ or  _mobile _. This breakpoint is based on browser width, so if a browser under 600px wide tries to view the page - it will automatically display the mobile version. This ensures that your users will get the best experience, whether they’re on desktop or mobile. 

Tablets are a bit different. Generally, when a full-size website loads up on a tablet in landscape view, it will display just as it would on a desktop browser. However, when a page is loaded on Safari in portrait view, the browser will either attempt to load the full-size website zoomed out; or load a tablet specific version of the page. 

Although we don’t have tablet specific mobile break-points, you should be able to load the desktop version on both landscape and desktop without too much of an issue. We’re currently seeing a small bug when initially loading responsive pages in portrait view (only 95% of the page is visible), but this is something we’re aware of and should have a fix for in the future. In the meantime the user might need to pinch-to-zoom to see the entire page, which is something any tablet user will intuitively understand to do. 

Our Mobile Responsive functionality has been implemented to ease the pain point of developing separate mobile/desktop versions of each page. We’re still in Beta, which means some things aren’t final just yet, but we’re almost there and we’re happy to hear any feedback you have about the feature. 

Hi Ben!

There shouldn’t be any issues cross platform, but just to be sure I’m going to open up a support ticket so we can take a look. Look out for my email. 🙂

Hi Tudor - segmenting stats isn’t built into Unbounce, but you can do this with Google Analytics. Johnny wrote up a guide to doing this here

Hi,

I create unbounce templates for sale and I’m very happy to see some progress on mobile “responsive” feature.

I really enjoy creating templates with unbounce but this “responsive” feature is not that good. Why there is scaling option for text if templates are not true responsive. There is no benefit from this, it just makes creating mobile version harder and not precise.

In this case text size, alignment and line height should not be shared between mobile and desktop version.

"Form fields will be the same across desktop and mobile. You cannot change form fields across the different views at this time."
I hope this is not some kind a joke?
What now? Should I hide forms on mobile version? This is ridiculous.

Hey Elvis I hearya…

Could be called “One Click Page Narrower Before You Still Have to Resize / Realign Everything One at a Time Anyways” LOL

(Sorry guys I do love the rest of the platform but this one is a dud;-(
Give us some MORE FONTS w/text Shadow/Stroke feature, a simple tilt/rotation tool for text boxes and images and a countdown timer and most of us will be thrilled I think?)

Hey Dave and Elvis,
First of all, thanks for trying the feature out and providing feedback. I know the biggest challenge right now is in converting old pages to be responsive. The first time you switch on “mobile” for an existing page it can seem like a daunting task. We built a feature that highlights out-of-bounds elements in red to make it easier to see what elements need re-sizing and moving. We’ll be constantly evolving this experience though, and have even started testing out a feature to help automatically layout your mobile version when you enable it. This is why we’ve upgraded all of our templates to already be responsive though.

Dave, you mentioned “Why don’t I just duplicate the page and narrow my margins by hand” Ñ the big difference here is that the “mobile” version you’re seeing now is sharing the same content as your desktop version. It’s the same page with the same content and the same URL. This is what Google and other services want to see when you provide a mobile experience.

Outside of having to shift elements over manually, we’ve made sure our mobile layouts have as much flexibility and customization as the desktop version. As you pointed out Elvis, you can style elements completely differently for mobile if you wish. You can make form labels appear on top of fields for mobile, but left aligned in desktop for example.

The issue you identified with text elements sharing line height and alignment between breakpoints is a tough one that we want to fix. It really comes down to the text editing component we are using that hardcodes most of those values as inline CSS. This makes it pretty difficult to let you have different values between breakpoints. Improving our text-editing component is on our roadmap though, and allowing unique line-height and font-size properties between mobile and desktop layouts will be one of the top requirements.

Keep the feedback coming, and I hope you’re able to work through a few of this issues to still make some great mobile-ready landing pages.

Carter

P.S. If you want to read a bit about the process for deciding on our approach to this feature, check out a blog post I made a few months back: http://inside.unbounce.com/product-de… Ñ I’ll be adding a new post soon once we have an official launch.

Just started creating my first mobile responsive page. Initial feedback is that it’s not at all clear when I should or should not hold command when moving elements around the page. I find myself having to switch back and forth frequently, finding that elements have unexpectedly moved on my desktop version and having to hit the undo button a lot.

I don’t see myself ever wanting my desktop version to change when I’m editing the mobile version, so I’m wondering if there’s a reason it doesn’t act as if the command button is always being held.

Hi Chris - we’ve been discussing this internally as well. Initially, the decision was made to have command+click unparent items, to create consistency with the way some other features of the page editor are built. That said, you’re not the first person who has brought this up, so it’s something we’re revisiting. I’d love to hear from anyone else about what they feel is more intuitive for them as well.