Automatically generating your monthly income?

Hello, good afternoon. My name is [INAUDIBLE]. I'm from the Google
Search Quality Team, and welcome to this week's
installment of basics of a mobile website for SMBs. This is a series of
four presentations over the month of
March, where we hope we'll be able to give you
quick, actionable tips for you who probably own a website
for a small medium business, and that will allow you to very
quickly implement the changes yourself or have a very
meaningful conversation with the people who do your web
development so that you can be informed as to what actually
it entails to create a mobile-friendly website. This is in preparation
for an algorithmic change in mobile search
results that we will be releasing on April
21, at which point mobile-friendly
websites will be given– the mobile-friendliness
of a website will be considered as a
ranking factor in mobile search results.

So this presentation will
be about 5 to 10 minutes, and then we will take
questions, questions presented through the Q&A
feature of the Hangout On-Air. You can click on the little
Q&A bubble, ask a question, and we will make our
best effort to answer it. If we can't answer
it on air today, we will answer it
through the discussion thread of this Hangout. So let's get started. [INAUDIBLE] Let's present it
a different way. Let's present it like this. Here we go. All right. And I have two colleagues here
who will tell me whether or not we're actually displaying
the full presentation. Great, excellent. So let's get started. We have for today's
agenda, we will be talking about viewports,
zoom, and plugins.

This is the second
installment in a series of four presentations. Last Thursday, we
talked about the tools you can use to check your
website's mobile-friendliness. If you didn't get a chance
to see the presentation, you can still see it on YouTube
or here through the Google Webmasters community. You can check it out
after this presentation, or you can catch this
presentation afterwards as well and then follow with
two-way sequence. Today, we will be talking about
viewports, zooms, and plugins, as I mentioned. Viewports and zooms. I will explain how
viewports and zooming affect mobile-friendliness,
and then I will explain very specific things
you can do on your website to make that change. So first, let's show you a
simple but typical web page that has the common features
shown on a desktop website. You've seen your website
might look somewhat like this, or you may have seen websites
that look very much like this. It has a header. It has a navigation bar, a
central [? part ?] of content, a footer with a number of links.

And usually, it has a
variety of pages that kind of follow a similar structure. Now, think about what happens
or what has happened to you when you've tried to see
this page on a smartphone. What you will often see is this. You will see the page completely
zoomed down and squeezed into the browser. This is because the page is
lacking a viewport metatag. A viewport is a
tag, an attribute in the header of the HTML
document at the top of the page that tells the browser
how to display that web page on a mobile device. When you don't have a
viewport, or when a viewport isn't specified, the
browser on a mobile device will try to render the
page at what it considers to be a typical
desktop screen width, and the general
assumption is that you're in the 800 to 1,000 pixels
required for a standard web page.

And what it will do is it
will reduce the whole page, zoom out completely so
that it will actually all fit in the screen. And what you end up having
are tiny little buttons, tiny little text. And you basically have to
almost swim into the page, if you will. You have to pinch and zoom
to try to get at the content. That's not a particularly
mobile-friendly experience. Users will frequently
cite that as one of the examples of the website
just doesn't work on mobile. Think about it when you've
used a website like that. You have to zoom in,
you have to scroll, you have to tap
all over the place. It's hard to figure
where to tap. So the first step to actually
making a mobile-friendly page is to actually including
a meta viewport in the head of documents.

It's a tag that you put inside
the header tag of your HTML document. And what you're telling
the browser at that point is specifically
that for this page, you should treat the content
as having the width equivalent to the width of the device
and an initial scale of one. The scale is the way that it
correlates a virtual pixel, if you will, of the
number of virtual pixels wide that the browser is
with the actual resolution of the device, and
that's how you're able to actually have a
consistent display of a web page across multiple different
types of mobile devices, even though those
devices may actually have different pixel
resolutions of the screens.

And you may be able to get
retina displays on iOS devices to devices of particular
pixel widths or densities, and you're getting
more and more devices with greater pixel density. That doesn't necessarily
mean that an eye can detect all of that without zooming in. So the viewport tag
is a key component of telling the browser
render this page and don't try to zoom out on it. When you do that,
that's the first step in making your web
page mobile-friendly. But as you can see here, if
you've made previous design decisions on your
web page, you may have to take additional steps. In this case, now you
can see that the browser isn't trying to zoom the
page all the way across. But in fact, if you were
to look at this page, you'd have to scroll sideways
and laterally to see it.

So it's at full
zoom, but you still have to scroll
and drag laterally and sideways to use
all of those pieces. So I'll talk now
about what it is, what are the design choices
that may actually cause your web page to look like this once
you have a viewport tag. Generally speaking,
this is a result of having fixed width
elements inside your page. A fixed width element
is a component. Maybe it's a box,
a header, an image that has had a fixed width
set to it in the style sheet.

And when you have a design
that assumes a fixed width, it can actually yield a poor
experience on a mobile device, because usually
fixed widths don't accommodate for the narrower
view of a mobile browser. And these are two examples
of what a fixed width element can do. On one mobile device, let's
say, on one mobile device, it might actually look
fantastic at 344 pixels wide, but in another one,
it will actually be truncated and chopped.

How does this happen? This happens because
usually either within the actual
attribute, a designer added the style element. Or in the style sheet at
the head of the document, in the cascading style sheet
at the head of the document, a specific value
was implemented. Firstly, you will hear in
the rest of this discussion a discussion about CSS,
Cascading StyleSheets. And that is the recommended
way of specifying how content should look on a page. You may have used
web page management tools in the past that put
a lot of style descriptions into each individual little
element part of the page, and that's generally not
a recommended practice. Usually, you want to
use CSS and style sheets and define those at the
top of your document when relevant to indicate how
the page should actually look, and how it should
actually be displayed.

In any event, designers will
often prefer fixed widths and specify fixed widths for
particular elements for design and layout, and this is
actually perfectly fine. It's a well accepted practice,
and this can actually yield very good results. However, when you have elements
with very wide fixed widths, it can make it more
difficult for your website to be mobile-friendly,
and you may find yourself that you have this
situation in your website, that you have a design that
you developed a few years ago, or that somebody developed
for you a few years ago.

And if you are to look in
the source code of the page, you might see a lot
of elements that say width, and
then a big number, and px, which is pixels. And that usually is
going to get in the way of being mobile-friendly
[? immediately. ?] There are two straightforward
ways of addressing this, and then there's an additional
one which combines the two. The first straightforward
way to do it, which might be a
little bit more work, is to actually make a change
on all those fixed widths. And instead of going with
a fixed number of pixels wide that it can be, actually
use a percentage of the window width that you might be. So if you want something to span
all the way across the screen, you can specify 100%. If you want something
that's just 80% that has a margin of
10% on either side, you might use a 10%
margin on either side and specify that something's
80% the width of the screen or the containing element.

That can actually be
a very effective way of over time getting into a
practice of not being stuck with a particular width,
but actually having a design that adjusts to when
the browser shrinks, or the desktop
shrinks, or expands to the width of the browser
screen, or on [INAUDIBLE] to adjust for future
mobile devices when they have completely
different widths. This can get tricky,
though, because it can make your design
more complicated, and it can make
debugging your CSS for particularly fussy designs
or layouts a little bit more tricky. So you have a
second option, which is you don't touch
all of the stuff that you already have that
works on your mobile device– on your browser, I mean,
on your desktop browser. And instead, you use something
called the @media queries, which is an attribute of
cascading style sheets that tells it that everything
inside those brackets would only apply to
particular types of devices. So in this case, you can look
at an @media screen and max width of 640 px.

What this is telling the
browser that renders this page, it's saying look
at the style sheet, and then if you happen
to be on an actual screen as opposed to other
media types, like print, if you happen to be displaying
this page on a screen and you are in a window that has
a maximum width of 640 pixels, then apply these style
attributes as well and maybe override the
ones that you saw above. In this case, what are we
specifying, for example? We're saying that in the
upper part for standard, just set the width of
the body at 1,024 pixels and set the images inside
the main content paragraph to have a width of 80%.

And in this case,
what we're telling it is when you are
on a screen that is no wider than 640 pixels,
make the body width 100% of the width of the
screen, and make the main image having a width
of 100% as opposed to 80%. And with that as well, you can
override some other elements. For example, we're doing
a couple more things here. We're saying there's a Home
button in the main navigation screen, for example. And instead of wanting it
to be a tiny little button on the left of the nav bar,
what we're going to want to do is move it to the
top and to the right. So we're adding in
absolute positioning, and we're giving it a position.

It's 1% from the top
and 1% to the right, and giving it a
different color, just to show that you can apply
not just different widths but different colors, schemes,
and positioning for elements, depending on your screen width. This allows you to
then have a page that is actually responding
to your device's width. So here, we have an example
of this exact same page we had before where we
have a viewport that's defined to match the
width of the device and where we adjusted
the heights, the widths, and the positions
of certain elements only on a mobile device
and a mobile page.

We can see, for example,
that the little Home icon is on the top right now
as opposed to on the left next to Catalog. We can see that the footer is
actually fixed at the bottom. So if you scroll the
page up and down, these links will
always remain there. We added a couple
of other practices. And the best part
about this approach is that we didn't have to change
how it looks on the desktop. So we haven't affected
our desktop display. We're optimizing
for mobile-friendly. We're making a
mobile-friendly web page, and we haven't actually
fundamentally changed how the web page behaves
on a desktop, which might actually alleviate
some concerns that you might have [? or that your ?]
developers might [? bring in ?] about saying, well, we might
be affecting how the web page operates on the desktop.

You can do this on the same
page just using style sheets. This gives you two things. One is, again, you can
have a mobile-friendly page without having to change
your desktop site. On the other hand,
you can actually have the same page working
on multiple devices, which is much easier to manage,
much less expensive to manage than to try to manage two
different websites– one for mobile devices and
one for desktop devices, and maybe even another
one for tablets. So we talked about
viewpoints and zooms, and now there's one
additional piece I want to talk to you
about, which is plugins. Generally speaking,
how many times have you ever tried to view a
page on a mobile and seen this? It's a little icon that says
this plugin is not supported. Avoid unsupported plugins. Make sure that you test your
application and your web page on a mobile device.

Make sure that you're
not using things that aren't supported
on a mobile device, because ultimately, you're going
to end up with users that can't actually use your website. Sometimes, there have
been plenty of websites– so this used to be a
very common practice years ago– of just
using a big Flash presentation as the
main source that created a lot of interactive,
very animated schemes for the user. And it was very pretty, but
it's not machine readable. It's just visual. And what that meant
is that first of all, on a user that was on a device
that didn't support Flash, they couldn't access it. And on a mobile
device in particular, you can't access it. If you are using things
like videos on your website, test them to make sure that
you're not relying on a Flash plugin, but that you're
instead relying on core video elements, HTML5 video elements
that may be supported– and that are supported
on mobile devices.

And if you can, add captions and
add text descriptions to videos and other elements so that users
who might have chosen to turn off video or cannot see video
because they're on a low bandwidth or slow network,
or they don't want to use up their mobile data traffic can
still get a sense as to what content you have on your site. And that concludes today's
presentation, the formal part of our presentation. I want to encourage
you to do a few things. First, take the Mobile-Friendly
Test on your website if you haven't already. I encourage you to visit
the Webmasters Mobile Guide to read in more
detail about the topics that I've discussed today. I'm walking you through
the different tests that the Mobile-Friendly
Test tool will run on your site and the
explanations that we provide. If you want more
detail more quickly and can't wait
until next Thursday to see what other fun things
the Mobile-Friendly Test has in store, go to the
Webmasters Mobile Guide. We'll guide you through that.

And if you need
help with your site, if you really are struggling,
you don't know where to begin, you don't know
where to start, we have a fantastic community on
the Google Webmasters Forum where you have a very
helpful set of both Googlers and other community
members that will be happy to give you advice and
guidance as to how to proceed. I encourage you to take
advantage of these resources. Also, if you're visiting this,
you're already probably already following us on Google
Webmasters and Google+. If you aren't, definitely
I encourage you to do so.

And follow us on Twitter. We post announcements, both on
the Google+ channels as well on Twitter, announcements,
news, and invitations to future events. And with that, we
will be shifting over to questions and answers
for the remaining part of the presentation. So let's go to Q&A
what we have in store. All right. Let's pick the first question. This is a question from
[? Rene ?] [? DesMontes ?]. As smartphones get higher
screen resolutions, such as the Galaxy
X, which viewport does Google recommend for a
modern mobile-friendly website, and how are these phones
seen using Google search? You want to think more
about the device width property in your browser than
the actual physical pixel resolution of the
device, because browsers have by and large settled
on a virtual pixel width, if you will, that match the
physical pixels on the device to a virtual pixel
on the browser.

That allows you to
have a consistent set of mobile devices that
run the spectrum of sizes and just a little
bit of aspect ratios without having to worry too
much about the proportions. Generally speaking, you
do want to think about, when it comes to devices
with super high resolutions, on whether your
images, whether you want to actually include
two versions of your images and respond to that
in terms of providing much higher resolution images.

Sometimes you can get really
visually enriching experiences on super high
resolution displays, like the retina
displays [INAUDIBLE]. If you provide a much
higher double-width or double-density resolution,
even just for background images, you can get a lot
more visual depth than that. That's a little bit more
of an advanced technique, but if you Google something like
retina display or high density background images, you'll be
able to get a good perspective on that. But by and large,
the viewport setting that we're
recommending here will allow you to cover the broad
range of [INAUDIBLE] positions, because you're not specifying
a particular width. You're just saying give
me the device width and assume that when I talk
about a pixel in the CSS, it's one pixel, one of the
virtual pixels [INAUDIBLE]. I hope that answers
the question. Let's go to the next one. So here's a question from
[? Luka ?] [? Chersnifsky ?]. Your suggestions are great, but
what when we have most of these already added and our
ranking is still bad? Then we go back to the basics. Mobile-friendliness isn't going
to somehow make a bad website good.

And that doesn't mean that if
your ranking [INAUDIBLE] what you would want it to be that
your website isn't good, but you want to focus in on
the quality of your content. Are you giving your
users the content that they're looking for? Are you responding to the things
that they're searching for? And when they land on your page,
are you actually giving them something that encourages to
both come back and recommend your site, your [INAUDIBLE]
service, to other people. This isn't going to fix
basic ranking issues. You still have to think
about the core guidelines that we always provide
when it comes to ranking. Focus on content quality. Focus on providing
the user experience. Focus on following our
webmaster guidelines, and that should get you
across [? the board. ?] But this is definitely
not going to– this isn't going to address
a systemic problem, but this is definitely
going to allow you to provide a good experience
on mobile if you don't already have one.

I hope that addresses that. OK, here's another
question from [? Luka ?], and I'll follow
that one as well. We implemented responsive
design for a website. All looks good on mobile,
Chrome, and Firefox, but the footer is missing
in Fetch and the Render tool in Google Webmaster Tools. Why? You don't support display
block on CSS command? I have no reason to believe
that we don't actually support display block on CSS command. We do render the
pages, and based on everything I've
seen, on websites I've built where I actually
physically use display block for defining how
the browser should render a particular CSS element, a
particular element based off of that CSS command,
there's no reason to believe that we don't
actually support it.

What would be important
to do is actually look at your specific page and
then figure out whether or not there's something about how
that page is displaying, or how that page is being
seen by Googlebot in rendering that causes that to not appear. I don't have any
reason to believe that that would actually
affect the mobile-friendliness perspective of your
page, but I certainly would encourage you to take that
specifically to our Webmaster Forums where we might be
able to take a look at it in a little bit more detail.

I hope that answers that. Here's a question, what is an
OK score on page speed insights? I'll answer this question
a little bit differently. Instead of aiming for
what's just good enough, think about all of
the recommendations in both Mobile-Friendly
Tests and [INAUDIBLE] as really well distilled
best practices that have been gathered by both
good web practitioners, Googlers, and folks who have
been in the web industry for a very long time. It's just sort of almost
fundamentally basic thanks to having a great website.

There aren't a whole lot of
things in those recommendations that are really things
you should skip. There are some things that
you can get away with, but ultimately, you're not
providing the best experience to your users. You're missing out
on basic things you can do to really address
very systemic problems. So I would not
necessarily treat it as what's a good enough
score, but rather saying if you haven't already
gotten to the point where you're addressing the criticals
and the you-should fixes, you're probably
not doing all you can do to give your users
the best experience.

All right. I hope that addresses that. Here's another question. This is a question from Claire. In Google Developers and
many other credible sources, I have seen that it
is not recommended to use maximum scale
on a responsive site. Would this negatively affect
ranking mobile-friendliness if this was kept on the website? If the Mobile-Friendly
Test labels you as having a mobile-friendly page
and mobile-friendly websites, then for the perspective
of mobile-friendly ranking, you should be fine. When it comes to not using
maximum scale on a responsive site, following
that recommendation, I think the main key
you want to focus on is if you are making
a design choice that is making it difficult for
users to actually interact with your page, if the first
thing I have to do when I land on your web page is start
zooming in swimming into it to actually get at elements,
if I can't actually tap on the things that
will allow me to convert, to act, to take that
business, to sort of do the thing that you want
me to do on your website, I might not come back for it.

I might not actually do it. So think about
whether or not you're sticking with the choice
of actually staying with maximum scale– I assume
you'd have good reasons to do so– think about whether or
not that's actually helping your users accomplish that. If that's the case, then
by and large, your users will be happy. And as long as you've
addressed whatever elements are defined in
a Mobile-Friendly Test, you should be fine. And hoping that answers
the question as well. All right. Let's see. This is a question that
I'm not sure I completely understand it, but I think
I hope we answered it.

How do I lock a viewport so
it's the same on any device, and is it even possible? What I would say is that
if you define a viewport as– if you define the
viewport indicator on the pages we're recommending,
what you're telling the browser is just don't
try to scale my page, or don't try to do some magic
adjustment so that things fit in here. Just assume that when I'm
talking about a CSS pixel, I'm talking about
one of the pixels that the browser understands. But I'm not sure
if that's actually addressing your question. If that wasn't
your question, I'd invite you to
re-ask the question. Maybe we might end
up in the forum, or even on the
discussion thread, we might be able to get to it.

All right. Let's see from [INAUDIBLE]. Is having an M-DOT
site OK for ranking? And [? G ?] [? scale ?]
[? ID ?] URL path, is that OK, or should I remove it? I'll go on the M-DOT site. On the M-DOT site, it
shouldn't be an issue. The thing is, it can make things
a lot more difficult for you. If you do, we will have
in the fourth installment on this discussion, we will be
talking about canonicalization, which is how you map
URLs on your M-DOT sites to your main page and
to sort of show which ones are corresponding
results for one and the other. That's doable and feasible,
but it can be tricky to manage. It can be a little
bit complex to keep sorted on an ongoing basis. So when it's OK for ranking,
it's for your M-DOT site, that's– as long as your website
is getting value to users on mobile devices, or even
on non-mobile devices, it should be fine.

But think about
whether or not you want to maintain that
over the long term. And if you're committed
to that, then definitely make sure you're properly
canonicalizing your URLs, and doing proper mapping between
your mobile and your desktop so that callers
know which page is a corresponding
page to another one so that when we're calculating
page relevance we understand. We understand
[? this ?] as well. Let me look at the
next [INAUDIBLE]. Let's see. Here's a question
from Steve Cooper. This is one that comes
up a fair amount. We use several third party
tools, like social sharing buttons, and it's
recommended that we minify the code to
speed things up, but it's not our code to change. Recommendations? Generally speaking,
my experience has been with using social
sharing buttons and things that large providers
will create, they will often provide those
resources already minified. So look through the resources
through which you actually obtained this code, whether
it's by the provider, whether it's Google, or
Facebook, or Twitter, or any other social
networking sites, or other sites
that you're using, and look as to whether or not
they actually give you a .gz or even a .min version
of that JavaScript code.

My experience has
been that they usually will provide that
because it's just a good practice for everybody. It good for web hosts,
it's good for them. If they're serving
it, they don't want to be serving
[? more bots ?] than the need to. And if you're not
able to do that, then the [INAUDIBLE]
piece is consider loading that JavaScript
at the foot of the page, not in the head of the
page, but in the foot. Or consider loading
it asynchronously so that you're not blocking
the rendering of the page until those scripts load. Those are not fundamental
to the first things that users are going to
be doing on your page. And so you may want to consider
putting those at the foot. And that may also help
address that concern. All right. This is a question from
[? Milton ?] [? Fullick ?]. What do you recommend
as a safe breakpoint for a smartphone version? You can see both
320, and 600, and I want to say 80 used as
very common breakpoints. Those generally tend to fit
the different types of devices.

If you think behind the
principle of responsive design, the answer should be
don't worry so much about the devices and
the smartphone versions, think about how to design your
page so that at logical widths, it functions, and therefore,
how to adjust flexibly so that whatever buffers
you need on the sides are actually not
all that important. So if you think about
how can this page work when you are listing it
as a long, narrow column? How can this page look
when you're seeing it on a very large browser? How does this page look when
you're both wide and tall, and think about the layout
of that page that way, then you might actually land
on natural breakpoints that fit within narrow smartphone,
or wider smartphone, tablet, and a desktop browser.

That's more of the
principal of the question. But if you want a pixel
number, generally we'd be sitting in the
mid-600s range, and it'll depend on
which devices you think are going to be more
prevalent for your device. But we've been
showing 640 and 680. I think we [? settled on ?]
680 recently. Hope that answers that question. Here's another question from
Specialized Digital Marketing. How to best get rid of
render-blocking Java and CSS in the header? Put it lower down.

Put it in the footer. You can put the script
element pretty much anywhere on your page as long
as CSS can be render-blocking, but you can actually put
non-render-blocking CSS further down. JavaScript doesn't have
to render-blocking, but the loading of
that can actually– if the loading of
the JavaScript is fundamental to the
display of your page– let's say that you're actually
doing something in JavaScript that's modifying the
look of the page, you want to load that quickly. But then everything
else that may be plugins or additional
components and so on, you can just put them
lower in the page.

And that way, all
the other resources necessary to render your page
are loaded first, [INAUDIBLE]. Let's see. Here is a question
from [INAUDIBLE]. My site is mobile-friendly,
but having 13 resources which are blocked by robots.txt. Will it be a problem? Do I have to fix it or not? Thank you. If those resources are critical
for Googlebot to actually see your website as
mobile-friendly, then that will be an issue
because we will not be able to know that your
page is mobile-friendly. So if your CSS is blocked, if
your JavaScript is blocked, if the images are necessary
for your mobile-friendly layout to work are not
[? probable ?] by Google, then we will not
be able to see– Googlebot will not be able
to see that your page is mobile-friendly. So that will get in the way. The general thing
we're asking is let us call your JavaScript
[INAUDIBLE], call your CSS, and let us view your page like
a browser [INAUDIBLE] the page. And if you're able to
let Googlebot do that, then we'll be able to
determine if your page is mobile-friendly. Here's another
question from– I'll have time for one more question.

And let's ask from
this specific question from Dave, which we saw
earlier, which I thought made sense from
Dave [? Griffins ?]. Website is marked as
mobile-friendly in mobile search, which means that it
has passed the mobile test and the CSS and JavaScript
are not blocked by robots.txt, but there's a separate mobile
version at /mobile which is blocked by robots.txt and
doesn't have canonicals and alternate tags on
desktop and mobile versions. Is this a problem? I would say it is. It's a problem to the extent
that you actually want pages on your desktop site
and your mobile sites to be considered equivalent
because it can actually be particularly irritating
if I'm in a mobile browser and I find a page that is
relevant to my results, and it's a desktop page,
I go to that desktop page and you redirect me not
to the right page, that's not a great experience. And the second thing
is Google will actually identify whether or not
you probably do a redirect and skip that redirect.

And if you're sending
[? me out ?] to the wrong page, that may also be a problem. If you put in the right
canonicals and alternate tags, then it actually allows
Googlebot to say, hey, here's this page
that ranks or here's this page that's relevant. Here's the other page
that's corresponding to it might actually
be mobile-friendly. This page may be
equivalent to this one. [? Let's try this one. ?] Let's
take them to this because this is the mobile page. I would say, if you do need
to have two mobile websites, the first thing is if Googlebot
can't call JavaScript and CSS, then Googlebot can't tell
if you're mobile-friendly. And if you don't have good
canonicalization or alternate, then you may be missing
out on relationships and common understanding
of those pages, telling Google these pages
are actually equivalent, treat them similarly,
which may actually be affecting some
of your results that you get in terms of
users going to your site.

We didn't have the time to
answer all the questions during this broadcast, but we'll
take the remaining questions and answer them in
the discussion thread. Again, thank you
for taking the time. I hope this has been
useful and valuable to you, and we look forward
to talking to you in the next iteration of
this next Thursday afternoon. We have two more
sessions along the lines. In the meantime, if
you want to get started on making these changes
and want some support, the Webmaster Mobile
Guide is there. I Encourage you to take
the Mobile-Friendly Test and follow the advice and go
to our Google Webmaster Forums for questions and support. There are plenty
of helpful people who are happy to
give you assistance. Thank you for your
time, and good luck. Take good care. Bye-bye..

As found on YouTube

AI Magic Studio