Copy link to clipboard
Copied
Hello,
Unfortunately, picture elements move in an undesired horizontal direction, although they should only be movable vertically (see screen clip):
I mean, I did not place anything outside of the content area / screen except anchor points? (see Muse project screenshot):
In addition, the IB test page does not work on the "Galaxy Tab A 2016 has 1024x768" of my customer (see screen clip 2). Here even the menu moves although it is fixed?:
What is wrong? I'm asking for your help.
Best regards, Patrick
I updated the update. It´s a little trial and error to set the text inside this button.
By pushing it a little to the right, it does not bleed outside at 800.
But I tried another approach by using a simple text box and set it as desired – you may change font of course and colour.
Now you are able to play around like with all textboxes with spacing and stuff:
That way you have best control, I guess.
About your vertical approach: As soon as you have set your menu as desired (don`t
...Copy link to clipboard
Copied
From the screenshot I realize quite a lot of breakpoints. It is recommended (don`t ask me by whom this is recommended ), to use 3 to 5 breakpoints, in order to reduce the ftp-space needed (and therefor time to load?).
It seems, without seeing a .muse, that unpinnning most objects could help a lot.
But this regards to wether you used rectangles (M) and filled those with images or used frames (F) and filled those with images.
Resizing options are quite different.
Elements pinned and have resize options behave weird, though. Resizing elements unpinned, mostly stay where intended.
Your next step could be to reduce your file to one page with maybe one or two elements and share a link with us.
Easiest way to do so: save the file with a new name into your Creative Cloud Files-folder and by right click this file:
Of course you could first try it by yourself in the same way, reduce your file as much as possible, save it with a new name, and check for pinning and unpinning those misbehaving elements.
Be aware, while using the scrubber, that at no time elements should leave the canvas at no time:
This happens mostly, when a fixed width breakpoint is set and elements are outside the guides for the next smaller breakpoint:
Best Regards,
Uwe
Copy link to clipboard
Copied
Hallo Uwe,
thanks for your quick reply. Ichecked your tips, but unfortunately ist doesn't help solving the problem.
It seems, that every object, that isn't pinned to a corner (vertically) is „wobbly" can be moved.
Here is the test .muse:
Patrick
Copy link to clipboard
Copied
Muse does exactly(!) what you tell it to do!
You definitely have to make clear, what scaling and pinning in essence is.
The text elements and the circle image are pinned to the browser window. That means: They stay at exactly the vertical position from top, where you have pinned them. There is nothing „wobby“ about that at all.
You have a quite complicated situation:
The background images scales proportionally, the circle in front and the text is forbidden to scale.
Consequence: The background image shrinks in both directions, what makes the circle and the text to visually move downwards. This isn’t the case: They stay, where they are told to stay.
A solution is, to unpin these elements and tell Muse, that the circle/text should not keep the distance from the top of the page, but move synchronously with the background image. This can be achieved by placing a "guiding frame" above the circle/text and group this „guiding frame" with the circle/text element. The guiding frame has to scale in the same way as the background image – proportionally – and isn’t allowed to overlap the circle/text elements.
Look at this screencast:
The rest, what may look „wobby“ to you, is simply the fact, that the circle/text keeps its size, while the background image is scaling. If you want to avoid this, the circle and the text have to be allowed to scale too. This will end up in placing the „text“ as a SVG graphic, since text doesn’t scale proportionally.
You see: A layout like yours has a lot of pitfalls, which aren’t „Muse issues“, but „issues of web pages, which are built to react responsively.
Finally one word: With a layout like this (mixing differently scaling elements, which overlap each other) you will run into heavy layout issues, if you don’t really make yourself very clear, how scaling and pinning is working.
I’d suggest to read these threads, which are all dealing with this problem:
https://forums.adobe.com/thread/2345133
https://forums.adobe.com/thread/2271454
https://forums.adobe.com/thread/2410624
https://forums.adobe.com/thread/2377071
https://forums.adobe.com/thread/2440719
And „one more thing“ (© Steve Jobs): You have way too much breakpoint. If you need more than 4 breakpoints, you definitly should re-think your layout. (Again: This is no Muse problem, this is a general approach to responsive layout.)
Copy link to clipboard
Copied
Hello Günter,
I thank you for your useful tips!
The way you explain things is really understandable and vivid. (Please forgive me my not perfect english).
Your words may well describe the topics of my site, but I still do not understand the connection to the first of my two problem topics (excuse me, please):
1. On the Samsung the menu "disappears" including the surface (please see clip again). It seems as if the device (upright) selects a breakpoint version that is horizontal and scaled? And under the background picture you can see a white background area that does not belong there either.
For all other tablets, phones, desktops it is as desired.
2. Issue 2 for me is not the problem of the menu: Element (groups) such as the the gallery should only move horizontally from top to bottom, not horizontally.
I found out that the problem is with the gallery (so far I have to update the .muse document (where the gallery was missing).
The original site doesn't have this problem without using the gallery widget (clip 2c):
Just as I install the gallery it comes to extreme, lateral, unwanted mobility: (clip 2b):
As suggested by you, I have tried to lead the mediacontainer (incl. gallery) with a guide frame. The test page works fine but used the copied gallery in the original page at the same breakpoint (1366 px) that does not work anymore. I tried to recreate the guide frame on the original page, but this also does not work. My tests have shown that it can not have anything to do with the (too many) breakpoints or the master page.
Test site (updated):
Original site:
Can you please help me, because the gallery problem, I currently have several pages.
Thanks in advance
Patrick
Copy link to clipboard
Copied
Perhaps someone else chimes in here. To find all the issues of this page, would mean, to rebuild it from scratch. I don’t have the time for this.
One hint: You have much, much, much to much breakpoints! If 3, maximal 4 aren’t enough, your layout is not suitable for responsive web design.
Copy link to clipboard
Copied
Not the solution, but the breakpoint at 320 is not usefull. There are no smaller devices than 320. Set it t mimimum width of 320 should pretty much do the job.
Even on master you use so many breakpoints, while I see no big difference betweenn 375n and 414, to say just one.
Between 414 and 568 you have these two layouts:
You really have to do it with less breakpoints, as Günter Heißenbüttel​ already recommended.
Your design really must work with less breakpoints as well on the page. From a design point of view you create a magazine but
for screendesign, which changes its size all the time.
I gave it a try with your master here: Adobe Creative Cloud ​
I followed Günter Heißenbüttel​ advice with using a frame on top of the menu, so it follows this all time, which I find quite nice.
Feel free to do your changes as desired. Of course these layers should be transparent finally.
On desktop I grouped the top image and the menu – on mobile I simply hided that layer in other breakpoints and added a new one.
This one dosn´t need to be grouped – it makes the menu follow all the way up towards the minimum width of 320.
Like this you should treat your pages as well.
Best Regards,
Uwe
Copy link to clipboard
Copied
I updated the master, becauase the accordion was outside the canvas – moved it down.
I´m not sure if the link still links to the same file: Adobe Creative Cloud https://adobe.ly/2Ca3uLQ
Watch for accordion.
On page you use anchor links. This will behave badly on fluid width design, as thy don`t move accordingly with browser size.
Just not important in this case but the anchors were not ligned up and should be placed just on the left side of the canvas and not off the canvas.
Your frame has no function if you use like this:
It does its job when set to resize in width and height and grouped. You grouped it but with no resizing.
I changed it on the current version AND found that the gallery thumbs have to set to resize in width and height, too.
Why this has to be done seperately? No idea.
Next and prev buttons have to be here:
Otherwise they move out.
I changed some only for the bigger breakpoint 1400 (yes I set master and page to 1400).
Decisions on 1024 need to be made.
Best Regards,
Uwe
Copy link to clipboard
Copied
Hello Uwe,
thanks Uwe for spending your time.
fotoroeder schrieb
I updated the master, becauase the accordion was outside the canvas – moved it down.
I´m not sure if the link still links to the same file: Adobe Creative Cloud https://adobe.ly/2Ca3uLQ
Watch for accordion.
Did I use/do you used a accordion? we are talkin about the menu, right?
I'm afraid I can not access the updated version. The version I see has two breakpoints, which is definitely desirable. Only then I have problems in various browser window settings (that's why I built so many breakpoints):
Width 1920 and 1366 px looking fine:
Width 800 px the menue points overlapping the cricle fond:
768 x 1024 px the menue points touching the cricle fond + the background pic needs to be the upright version (wich I used before in the upright browser situation)?:
414 x736 px (also > 320 x 568 px) the background pic needs to be the upright version (wich I used before in the upright browser situation)?:
667 x 375 px (also 568 x 320 px) the menue is out of canvas:
... Is my design so impractical for responsive websites?
fotoroeder schrieb
It does its job when set to resize in width and height and grouped. You grouped it but with no resizing.
I changed it on the current version AND found that the gallery thumbs have to set to resize in width and height, too.
... Where can I find your revised .muse file?
Best regards, Patrick
Copy link to clipboard
Copied
I updated the update. It´s a little trial and error to set the text inside this button.
By pushing it a little to the right, it does not bleed outside at 800.
But I tried another approach by using a simple text box and set it as desired – you may change font of course and colour.
Now you are able to play around like with all textboxes with spacing and stuff:
That way you have best control, I guess.
About your vertical approach: As soon as you have set your menu as desired (don`t forget to set the rectangle to transparent, only if you like the framed Headshot, feel free to use it), in your case I would set the image on page only, because of the interference of image and galleries and other content. Now you could use horizontal, vertical approach es wanted and needed much better, than jumping between master and page.
But, seeing upcoming issues with your anchors, I recommend to try it with fixed width breakpoints.
In your case, of course I would create the site left aligned then instead of centered as usually.
Best Regards,
Uwe
Copy link to clipboard
Copied
Hello once again,
I still have not figured out why exactly the grouped elements can move extremely horizontally?
Here is a simple Tets2 document.
In the range between 1366 and 1920 pixels, the grouped elements can be moved horizontally. It makes no difference whether fixed width or fluif width is set in the breakpoint.
BUT:
When I remove the gallery, the agility is minimal.
Can you change the problem that seems to have something to do with the gallery widget?
Best regards
Patrick
Copy link to clipboard
Copied
I solved it by ungrouping everything, unpinning everything in all breakpoints (your thumbs had been pinned for some reason-maybe accidentially), then I pinned the background and its shadow and the slideshow as a whole to the right (three dots pinning):
Don`t know if you still need the empty rectangle on top of this construction anymore.
Best Regards,
Uwe
Copy link to clipboard
Copied
Thanks Uwe,
I was so happy to read your solution, so I tried to implement it.
In the preview in Muse (by breakpoint scrubbing) it also works as desired:
Unfortunately, it does not work in the browser preview:
Even if I group all elements in every breakpojnt I have the same result.
What am I doing wrong?
Best regards, Patrick
Copy link to clipboard
Copied
Looks horrible, yes. I check what´s going wrong.
Copy link to clipboard
Copied
Call me nuts, but now, as I pin all elements (container, image, thumbs, background layers) to the right (3 dot pinning), it keeps its position. Check it out …
Uwe
Copy link to clipboard
Copied
Thanks Uwe,
strange – now it works!
Unfortunately, the procedure leaves a slight aftertaste, because I think that I was already at this point, and it did not work, and here alone I have lost so much time ...
Muse seems to be really idiosyncratic sometimes. In between, was the flush of the caption in one of the breakpoints changed from left to right by itself? And this is just one of many.
Nevertheless - thank you for your time!
Copy link to clipboard
Copied
I think, we really are dealing with a bug here. I can’t get this to work:
If you get this to work, please post the link to a small working .muse file.
Copy link to clipboard
Copied
Hello Günther,
currently it works with Uwe's solution:
All elements (not grouped),3-point-pinned to the right, in each breakpoint.
I had tried that before, but it did not work. Now it works! (?) - at least in the test document. I'm curious how it works in the original then. Sometimes it seems to me, as if Muse stores any old acts / information and thus comes in confusion.
Copy link to clipboard
Copied
I also think, it´s a bug but there´s a workaround – should not ne necessary, though.
I had to pin every single element in this construction: container, image, thumbs, next-prev buttons, background layers.
In 768 I changed to set any single element to resize in width and height – text to resize in width only, of course.
In 768 no pinning necessary.
Best TRegards,
Uwe
Copy link to clipboard
Copied
Hmm. Now let us try a most simple variant:
Now try all pinning variants, which come to your mind, to avoid this and make the heroes and the thumbnail container move synchronously.
I can’t …
Copy link to clipboard
Copied
Works only with pinning container and hero to the left.
Works with no pinning not at all and with pinning to center better than with pinning to the right.
BTW, it is solved in the prerelease as I checked.
Best Regards,
Uwe
Copy link to clipboard
Copied
fotoroeder schrieb
BTW, it is solved in the prerelease as I checked.
No, definitely not. Check my sample file in Prerelease forum.
Your samples deal with other issues. My sample is based on thumbs to the left, hero to the right and no left pinning (we didn’t loose a single word about left pinning until now). And Patrick’s sample doesn’t really work to. You can see that the thumbs and the hero don’t move synchronously. the are shifting – slightly but really visible.
Copy link to clipboard
Copied
I check in prerelease forum over the day, I hope.
Uwe
Copy link to clipboard
Copied
... yes, I can!
Both need to be pinned:
- the hero
and
- the hero container
(The reason why I choosed "freeform thumbnail" before, was that I can't 3-dot-pinn the thumbnail container.)
Back to my clients project:
It works now also with the "freeform thumbs" version, but unfortunately i still have the unwanted agility of the elements between breakpoints 1366 and 1920 px:
Copy link to clipboard
Copied
Seems like there are some elements outside the canvas in this breakpoint?
Uwe