I have a website with the Response Header Vary set to "User-Agent". I have verified that none of the JavaScript or CSS code is blocked using the Fetch as Google tool. When looking at the Rendering tab for Googlebot type Mobile:Smartphone it is showing that Googlebot is seeing the normal web version and not the mobile version. It also shows on the Rendering tab that the visitor would have seen the page showing the mobile version correctly.
Google is showing my website as not mobile friendly. But, there is a very nice mobile version of the website for mobile that comes up when I visit with my iPhone or use the Google Chrome simulator. Also, I am not using a second URL for my mobile version (m.mysite.com).
Do I have to convert my website using Bootstrap in order to get Googlebot to see my mobile version and consider my site mobile friendly?
Here are the response Headers:
The website is built using Sitecore. Here is the rule which sends the Mobile version.
I guess that Googlebot is mainly looking if your website is using CSS3 media queries based on the screen width and the meta tag for setting the viewport on mobile devices to decide if a website is mobile friendly or not. I just tested a not even finished layout which is marked as mobile friendly. Also my other sites are all mobile friendly and i never used the user agent to determine how i should render the page, for this I use media queries.
I suggest you, if not already done, adding first the viewport meta tag, and if this doesnt work it MUST work when you switch to using media queries in general and using the user agent only when you want to prevent that media queries are being used. (for example not using the mobile media query when on a desktop)
What you need...
Viewport meta tag (for example: <meta name="viewport" content="width=device-width, initial-scale=1">)
Media queries
My unfninished layout doesnt even use media queries so i think adding the meta tag is enough. If you want an URL with the code write me a PM.
Related
I was wondering if we could embed Postmates Tracking URL in our web apps/mobile apps (Using webviews).
Right now, a tracking URLs (Ex: Sample Tracking URL) embedding in iframes and other formats are blocked. Is there a different pattern for the URL for embedding purposes? (Like YouTube does).
If not, how often does the rider location coordinates updated via the webhooks?
It is not possible to embed the tracking URL. You will need to implement a custom map using the courier lat/lng that are updated via the webhooks.
The courier location updates are sent every 10 seconds.
I've created a view in tableau online using a live connection. I want to the page to refresh automaticly every 10 minutes. It can only be done by pressing manually the refresh button in the dashboard/view in tableau online, refreshing the browser page wont refresh the dashboard. I saw a tableau discussion with this tip: "Tip: To continually refresh a view, in the <head> section of the web page, add <meta http-equiv="refresh" content="#">, where # is the number of seconds between refreshes." How can I do this? Can this be done in tableau online?
As a second option I can add parameters to the dashboard URL to fix this issue. I saw this in this discussion: https://community.tableau.com/thread/289924 At least the part ":refresh=yes" had to be added to the URL. Since I'm totally unknown in this area I was not able to fix this. Where and how I need to add this to the url so this will permantly works?
I'm also open for other suggestions.
There are a couple of ways you could approach this, which one you choose will depend on your situation, scale, and available resources.
Option 1: Embed with meta tag
This is the first option you were describing. In order to do this, you will need to embed your dashboard into your own custom separate webpage. You can get the embed code from the share button on any dashboard and can customize it using parameters and the JavaScript Embedding API. The meta tag you mentioned would then go in the header of your custom webpage where you are embedding the dashboard. So it would look something like this:
<html>
<head>
<meta http-equiv="refresh" content="600">
</head>
<body>
<script>
// Your embed code from the dashboard here
</script>
</body>
</html>
You would also want to make sure to include the :refresh tag you mentioned so you always get the latest data.
Pros: Anyone can open the page and have an auto-refreshing dashboard without installing anything.
Cons: You will need to have some form of a webserver to host your custom page. Requires some coding. Hard to scale up the number of dashboards.
Option 2: Chrome Extension
This is the second option you were describing. In this case, a chrome extension in the browser is refreshing the page for you. That means you don't need your own separate webpage. However, it will only work on the browser you install and setup the extension on. It looks like there are a couple of auto-refresh extensions in the chrome web store you can choose from. You would need to configure them to refresh the page, again make sure to include the :refresh tag on the url.
Pros: Don't need a separate webserver. No coding. Easy to scale for multiple dashboards.
Cons: Only works for the browser that the chrome extension is installed on.
Option 3: Dashboard extension
One option you didn't mention but I think is the best would be to use a Dashboard Extension. Dashboard extensions are web apps that you can bring directly into the dashboard. We currently have an Auto-Refresh extension in the gallery built for just this purpose. Once you've downloaded it simply open your dashboard, drag in a new extension object, select the downloaded file and configure for 10 minutes.
Pros: Don't need a separate webserver. No coding. Easy to scale for multiple dashboards. Anyone can open the dashboard and have it auto-refreshing without installing anything.
Cons: Auto-Refresh only works with 2019.4+.
Hope this helps!
I have a Joomla 2.5 site and I'm creating a mobile version of it. I want to use the same menus and same articles but adjust the content. For this I'm using a simple mobile detection plugin so it changes the stylesheet only. This all works fine.
However, I need an additional page that just contains the main menu. In Joomla you have a default page and this is currently my home page for both my desktop and mobile version. I want the mobile site to load my main menu page first then the user can navigate from there. Does anyone know of the best way to do this?
A site can only have one default page so you will need to redirect a user to the mobile menu page when they first visit the site. There's a couple of ways to do this would be to set a cookie indicating they have been to the main navigation or use session variables. In either case, you would need to add a plugin or code to the default page to determine if they need to be redirected or not.
That said, why not just make your template responsive. It's fairly easy to implement the Bootstrap framework (there are tons of templates already out there using Bootstrap) and then it is trivial to show or hide content based on the size of the screen the user has.
As the title implies,
I need to fetch data from certain website which need logins to use.
The login procedure might need cookies, or sessions.
Do I need QtWebkit, or can I get away with just QNetworkAccessManager?
I have no experience at both, and will start learning as I go.
So please save me a bit of time of comparing both ^^
Thank you in advance,
Evan
Edit: Having read some related answers,
I'll add some clarifications:
The website in concern does not have an API. So I will need to scrape web elements for the data myself.
Can I do that with just QNetworkAccessManager?
No, in most cases you don't need a full simulated web browser. In most cases, just performing the same web requests like a web browser would do is enough.
Try to record the web requests in your browser, using a plugin like "HTTP Live Headers" or "Firebug" in Firefox. I think Chrome provides a similar tool out of the box. These tools record the GET and POST requests done by the website when you send a form in the webpage.
Another option is to inspect the HTML code of the login page. Find the <form> tag and its fields. Put them together in a GET / POST request in your application to simulate the same form.
Remember that some pages use randomized "tokens" in their forms, some set the tokens as cookies. In such cases, you need to request the login page itself in your application first (before sending the filled in form). Both QWebView and QNetworkAccessManager have cookie support.
To sum things up, I think QWebView provides a far more elegant way to simulate user interaction with a web page. The manual way is, however, more "lightweight", as you don't need Webkit and your application might be faster (because only the HTML page is loaded, without any linked resources like images, CSS, javascript files).
QWebView as class name states is a view, so it views something (in this case web pages). If you don't need to display loaded page, then you don't need a view. QNetworkAccessManager may do the work, but you need some knowledge about HTTP protocol, and also anything about target site: how does it hande logins, what type of request you have to send to login etc.
For the past 10 days we have been getting about 800 visit/day which Google reports as
"Mozilla Compatible Agent / iPhone."
After doing some reading people seem to suggest that this is when people bookmark your website using a shortcut. Whatever it is, its completely untargeted visits and is causing our stats to be messed up. Bounce rate is 98% and page views are 1.1 from these visits.
I have isolated the 'bad' user agents as follows:
**Bad:**
Mozilla/5.0+(iPhone;+U;+CPU+iPhone+OS+4_3_3+like+Mac+OS+X;+en-gb)+AppleWebKit/533.17.9+ (KHTML,+like+Gecko)+Mobile/8J2
**Good:**
Mozilla/5.0+(iPhone;+U;+CPU+iPhone+OS+4_3_1+like+Mac+OS+X;+en-us)+AppleWebKit/533.17.9+ (KHTML,+like+Gecko)+Version/5.0.2+Mobile/8G4+Safari/6533.18.5
Note that the bad is missing 'Safari' from the end.
How would I go about creating a filter to remove these visits from our Google Analytics?
You would be wrong to filter out those visits from your Analytics - they are real views, you're just not sure of their origin.
I think the post you read about people bookmarking your website is this one:
http://www.google.com/support/forum/p/Google%20Analytics/thread?tid=61e3d404f3c9c2bb&hl=en
The bookmarking thing is a red herring - this is the more likely reason:
If you look at the string returned from the full user-agent analysis it speaks clearly:
Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0_1 like Mac OS X; fr-fr) AppleWebKit/532.9 (KHTML, like Gecko) Mobile/8A306
It's AppleWebKit.
It means that all those users come from iPhone/iPad apps using embedded functions of browsing by calling AppleWebKit capabilities inside their code.
Like it says above, most iPhone apps contain a browser that uses AppleWebKit capabilities - this is the activity you are seeing on your website.
Here are some likely scenarios:
People subscribe to your blog's RSS feed using an app like Reeder. When they view a post, it records a page view. When they click back on the iOS app, it records a bounce.
Someone shares a link to your site via Twitter. Someone who clicks that link using the native iOS Twitter app. 1 visit, 1 page view, 1 bounce.
Flipboard, Facebook, Google Mobile app, Bing app, etc, etc, etc.
Maybe you can use campaign tracking codes to see which medium (and ultimately which app) is driving the traffic?
UPDATE: here's an article from Search Engine Land on the topic of lost referrer data from mobile apps.
RIP Referrer Data! How Mobile Apps Can Kill Your Mobile Metrics (6 June 2011)
Some parts of interest:
Smartphone apps are innately unable to pass “referring page” information to your site analytics, for the same reason Word docs or PDFs are not recorded as website referrers: they’re separate applications. Even for mobile apps that embed browsers (like Facebook, Google, Twitter, Groupon), there simply is no “referring page” data to pass upon click-through.
If you’re expecting to see this traffic nicely categorized in some analytic report, you’ll be waiting a while. ...
The net result is that your “direct” traffic and sales counts are inflated, and that a sizable percentage of your actual mobile search and mobile social traffic is understated. That means you are likely under-investing in mobile, and giving conversion credit to other channels to boot.
On the Google Search app:
But for mobile organic, you’re out of luck. Not only does Google Analytics not record Google as the referrer, the mobile keywords that drove traffic also go incognito.
Finally:
You can’t manage what you can’t measure. Until you can measure the impact mobile apps are having on your mobile ROI, it’s not difficult to imagine you’re leaving money on the table.
Again, it's not your stats that are messed up, it's your measurement. Filtering out your mobile visitors is a bad idea.