Adaptive Views: Pages and Masters not syncing

#1

Hey there - have spotted something that desperately needs addressing, thought I’d post here rather than anywhere else - is that the best option @Jane_Axure ?

The Problem

  1. Create your Adaptive View Set
  2. Create and ‘adaptive-ize’ a widget
  3. Convert it to a Master
  4. Drop that Master on to the page, or any other page with the same adaptive view set
  5. Cycle through your adaptive views and see how the Master doesn’t adapt along with the page, even though it has the adaptive behaviour for the corresponding views.

Copying and pasting an already working Master (i.e. the one you created from the adaptive-ized widget) works, but is far less than ideal. You create Masters to drag them on from the Masters library.

Can this please be fixed as a matter of urgency?

Also, while I’m here:

How Adaptive Widgets Need To Work
Let’s say I have a Master widget, or widget from a library, that has been ‘adaptive-ized’ with a complete set of widths: 320, 360, 375, 411, 414, 768, 800

If the canvas where this widget is placed has ANY of those views (e.g. just the iOS ones [320, 375, 414, 728])… the widget should adapt as appropriate!

It is so limiting for this not to be the case.

E.g. I want to make a master widget that is fully adaptive, and then make an iOS and Android version of it, and then apply that widget to iOS and Android pages, and it automatically uses the relevant views.

Does this make sense? Surely you can see how this is what should happen?

Great work on the rest of the beta by the way. Lots of overdue no brainer quick wins.

Master views vs. adaptive views
Master Views not acting the same for Adaptive Screen Sizes in ARP9 vs ARP8.... HELP!
#2

How Adaptive Widgets Need To Work

I love this idea. It makes total sense. Right now we have a shared library and we have to set strict rules around adaptive sizes. It would be great to make the library widgets be a lot more flexible in the way you’ve stated. Especially, since we have to support not only mobile screens sizes but console and TV sizes now as well.

#3

Waaaaaait a second.

Just re-reading over the ‘new features’ list, and I see “Master views (replaces adaptive views on masters”:

Ugggh, I’ve just figured it out.

So, a Master View and Adaptive Views for Masters are basically the same function it seems.

To make my ‘adaptive-ised’ master adapt properly to the adaptive canvas, I have to select the Master View to apply separately to each adaptive view of the canvas.

Manually.

Whhhuuuuuuuu?

Whuuuu.png732×405 18.3 KB

Are you serious Axure?

Is there any plan to make this “intelligent” and automatically match the adaptive view its in?

#4

Thinking about this some more, does this mean you can also only have one ‘view’ of a master per adaptive view?

For example, at 320px could I have a 320-iOS view and a 320-Android view, or only one view for the 320px width?

Any help much appreciated @Jane_Axure and team :thumbsup:

#5

Hi Will,

Thinking about this some more, does this mean you can also only have one ‘view’ of a master per adaptive view?

You could have three instances of the same master on a page (in any adaptive view), and each one could be set to a different master view. Master views are independent of adaptive views in that sense.

The big compromise to get that flexibility (as you noticed) is that master views are no longer automatically matched up with the page’s adaptive views. Since master views are independent of the page dimensions, we are considering matching automatically from master view name to adaptive view name when a master is added to a page… but there are some cases where that could be unpredictable or not intentional. Do you think matching by name would be better for you?

#6

Hey @victor thanks for reaching out!

I should say a huge well done on 9, there’s a ton of no brainer quick wins that you and the team have addressed.

I see what you mean now.

The thing I find with Master Views is that… isn’t that what widget styles are for? I can’t yet get my around the differences and applications.

It would take user testing of course, but I do think to have, even as a toggle option somewhere, to auto apply master view to matching adaptive views makes a ton of sense.

#7

Thanks @willjohnsnow. We really appreciate that.

Here’s my shot at describing the difference…

In 8 and earlier, adaptive views on masters made them work best as template elements like navigation, headers, footers, etc… where their views necessarily matched the adaptive views of a page. This also made them only useful when using adaptive views on pages.

In 9, master views on masters make them more like components. A simple example might be an “icon + text” button having master views with different icon placement. Another might be a product listing with an “available” view and a “out of stock” view that vary by some widget visibility. Differences that can’t be accomplished with only widget styles. And they can be used on any page, adaptive or not.

Built into a widget library (using masters) and adding the ability to override text and images on instances of a master and use raised events, and things could come together pretty nicely. i.e Drag and drop the product listing widget, select the “out of stock” view, override the product name and image, realize you want the “available” view, change it back to the “available” view, add an interaction to the “OnAddToCart” event.

Definitely, one of the primary uses is still views like “iPhone” and “iPad”. I agree that it makes a lot of sense for those to match the adaptive views by default.

#8

Aaaaaah, this makes total sense. I get it now, a great example.

Yes as you say, until now I’ve been using Masters as navigation and such, but also everywhere else as much as possible.

Essentially what I’m trying to do is create a ‘forkable’ master prototype of an app, with both iOS and Android flavours. I think I see how it’s done now, and also how Master Views can help with other buttons, for example, as you say.

Do you know if there gets to be any load penalty after adding in lots and lots of views? For example:
320, 375, 414, 768, 1024 for an iOS set, and
360, 411, 800, and 1280 for an Android set.

To put both of these in each page and master navigation widget would be a lot of views!

That’s a lot of views for navigation and similar elements. Hopefully most buttons etc wouldn’t need different sizes per view.

What are your thoughts?

Thanks again for getting involved, much appreciated!

W:)

#9

p.s. @victor I see the Master View is not an interaction action that’s available.

I think it’s definitely worth having that to go with the above use cases, akin to Set Panel State, ‘Set Master View’ would be essential I’d say.

W:)

#10

There is some extra load time for additional views, but we do try to optimize around that. I think the performance will likely be much more affected by the number of widgets on the page or master.

… and yes, dynamically setting the master view in the prototype could be very useful. Unfortunately, can’t promise that yet.

#11

This is a truly interesting yet mind-boggling discussion and I must admit I have not yet gained a solid understanding of how this thing works.
If I understand it correctly, the master views are meant to be viewport independent and aimed at showing ‘functional’ alternatives as described by @victor.
However, I have imported my current RP8-based project which uses a header area with adaptive views such as ‘tablet landscape’ ‘large screen’ etc. These views are (after conversion) availble within the page as well as within the master. Hence: Adaptive page view == Master Views.
Changing the view within the page automatically switches to the corresponding master view - so the ‘adaptive behaviour’ is pretty much as before. So, now I’m wondering:

  • How is this match between adaptive page view and master view accomplishes? Interestingly, it’s not done by (visible) name, since I’ve change on of the master view’s names, but the mapping still works.

  • The master views user the names of the adaptive views but have not settings related to viewport size

  • If I now would like to create ‘functional’ views for the master (in case of my header: Anonymous vs. logged in), how would I do this? Would I need to delete the ‘adaptive’ master views? Or would I need to create a matrix of views like ‘tablet landscape - anonymous’, ‘tablet landscape - logged in’ etc.?

Still a lot of question remaining (at least for me) - and I would be most happy for some further clarification.

Thanks - Jens

Creating an Adaptive Header in Axure 9
#12

Yes I agree. I’ve been trying to figure it out myself. My initial thought was that it would allow me to create button states beyond the simple MouseOver, Selected, Disabled etc. I’ve tried to do this but have no idea how to change the state. So I’m a little lost.

#13

After playing around with this some more. I see the potential of this capability. It seems to be missing a feature though that would make it useful. We need the ability to use actions to set the state of Master Views. So for example I could create an email form with a submit button. The fields on the form could be Masters with several states; default, success and error. When a user clicks the Submit button I could use conditional logic to determine which state of the field I need to display. Currently this doesn’t look possible.

If we can’t do this then this feature just becomes a wire-framing widget that I can choose the views for, which is useful but not valuable.

#14

Wow it took me 3 hours to work this out… so frustrating… I use the old way 99% of the time. I really feel it should act the same way as RP 8 < and then be able to manually override when you want.

#15

I am also missing the AdaptiveView for masters - though I also see benefits of the new Master View approach.
Maybe it would be good to have an option (e.g. a check-box) to enable re-use of the adaptive view settings for Master views (if this is what the user needs.).

Even better would be having Master view as an additional layer on top of the Adaptive view…
But as already mentioned - that could be complicated to use …

closed #16
#17

Hi everyone–thanks for all the feedback on master views in the Axure RP 9 beta thus far! Per our new forum policy we’re going to close this thread, but if you have any additional feedback or feature requests regarding the beta that you’d like to send our way go ahead and email it to us directly at support@axure.com so that we can get it filed. Everything currently in this thread has already been filed with our product team–thank you again for your input! :slight_smile: