Hiển thị các bài đăng có nhãn mobile. Hiển thị tất cả bài đăng
Hiển thị các bài đăng có nhãn mobile. Hiển thị tất cả bài đăng

Thứ Tư, 17 tháng 8, 2016

Developing Mobile Web Apps: When, Why, and How

There are 6.8 billion people on the planet, 5.1 billion of whom own a cell phone (source). And today, an ever-growing percentage of these devices are smartphones. According to a recent Pew Research Center Study, the number of users accessing the Internet on their smartphones has more than doubled in the past 5 years, as has the number of users downloading and using mobile apps. Of those who use the Internet or email on their phones, more than a third go online primarily through their handheld devices.
Indeed, mobile computing is becoming increasingly ubiquitous… and it’s awesome.
Except, of course, when it’s not.
As a mobile device user, few things are as frustrating and difficult to fat-finger-navigate as a poorly designed mobile web or native app.
And as a mobile app developer, few things can be as intensely irritating as striving to support as wide a range of mobile clients as possible, each of which has its own frustrating set of idiosyncrasies. Whether you choose to develop a mobile web, native, or hybrid app, the quest to support multiple mobile browsersmore-exotic devices, and platforms can be quite a gut wrenching experience indeed.
This web app development tutorial seeks to help you navigate different browsers and platforms.As a mobile device user, few things are as frustrating and difficult to fat-finger-navigate as a poorly designed mobile web or native app. And as a mobile app developer, few things can be as intensely irritating as striving to support as wide a range of mobile clients as possible, each of which has its own frustrating set of idiosyncrasies.
Of course, not every developer today needs to worry about supporting mobile clients. But the increasingly omnipresent nature of mobile devices and applications strongly suggests that those who don’t need to support mobile clients today will more than likely need to do so in the not-too-distant future. So if you’re not already thinking about mobile app development, you probably should be.

Mobile app: Web vs. native vs. hybrid (help me choose!)

As is true with most technology selections, there’s no one-size-fits-all answer when it comes to the type of mobile app to develop. There are numerous web app best practices to consider, not all of which are technical. Who is your target audience? Are they more likely to prefer a mobile web or a native app? What development resources do you have and which mobile technologies are they most familiar with? What is the licensing and sales model that you’re envisioning for your product?
Generally speaking (although there are always exceptions), the mobile web route is faster and cheaper than the native app route, especially when the objective is to support a wide range of devices. Conversely, there may be capabilities native to the mobile device (such as the movement sensor and so on) that are essential to your app, but which are only accessible via a native app (which would therefore make the mobile web app choice a non-starter for you).
And beyond the web vs. native question, a hybrid app may be the right answer for you, depending on your requirements and resource constraints. Hybrid apps, like native apps, run on the device itself (as opposed to inside a browser), but are written with web technologies (HTML5, CSS and JavaScript). More specifically, hybrid apps run inside a native container, and leverage the device’s browser engine (but not the browser) to render the HTML and process the JavaScript locally. A web-to-native abstraction layer enables access to device capabilities that are not accessible in mobile web applications, such as the accelerometer, camera, and local storage.
But whatever choice you make – whether it be mobile web, native or hybrid app – be careful to adequately research and confirm your assumptions. As an example for the purposes of this mobile web app development tutorial, you may have decided to develop a native app for e-commerce to sell your products, but according toHubspot, 73% of smartphone users say they use the mobile web more than native apps to do their shopping… so you may have bet on the wrong horse.
But whatever choice you make – whether it be mobile web, native or hybrid app – be careful to adequately research and confirm your assumptions.
And then, of course, there are the practical considerations of time and budget. As one of my favorite sayings goes, “faster, better, cheaper… pick any two”. While time-to-market and cost constraints are of paramount importance in web application development, it’s crucial not to compromise too heavily on quality in the process. It’s quite difficult to recover the confidence of a user who has had a bad first experience.
Indeed, mobile web, native, and hybrid apps are all radically different beasts, each with their own unique set of benefits and challenges. This development tutorial specifically focuses on methodologies and tools to employ, and pitfalls to avoid, in the development of highly functional, intuitive, and easy-to-use mobile web applications.
A critical best practice in determining how to develop a mobile web application is to know your customer.

Plan ahead (“if you don’t know where you’re going, you just might end up there…”)

Identifying your (or your customer’s) requirements is one of the most essential best practices in app development, mobile or otherwise. Carefully research the targeted capabilities to determine if they are achievable in a web app. It’s quite frustrating, and highly unproductive, to realize that one or more of your essential client functions aren’t supported, when you’ve already invested the time and resources to design the web-based interface and supporting infrastructure.
Another common gotcha for mobile web app developer newbies is to ass-u-me that web-based code for a desktop browser will work “as is” in a mobile browser. Not. There most definitely are differences and, if you’re not aware of them, they can definitely bite you. The HTML5 <video> tag’s autoplay functionality, for example, doesn’t work on mobile browsers. Similarly, the CSS transition and opacity properties are not supported (or at least are not consistently supported) in most mobile browsers nowadays. You will also have problems with some web API methods on a mobile platform, such as the SoundCloud music streaming API that requires Adobe Flash which is not supported on most mobile devices.
A common gotcha for mobile web app developer newbies is to ass-u-me that web-based code for a desktop browser will work “as is” in a mobile browser.
A particularly complicating factor in mobile web application development is that the lifespan of mobile devices tends to be much shorter than that of desktop displays (the average lifespan of a cell phone in the U.S. is around 21 months). These shorter device life spans, accompanied by constant releases of new mobile devices and technologies, yield an ever-changing landscape of to-be-targeted devices. While working in a browser does somewhat alleviate this issue by shielding you from a number of device-specific issues, you will still need to design a browser-based view that supports many different screen resolutions (as well as adjusting appropriately for landscape and portrait orientations).
Thought needs to be given as well to supporting Apple’s Retina Displays (liquid crystal displays that have a pixel density high enough that the human eye is unable to discern individual pixels at a typical viewing distance). Several Apple products – including the iPhone, iPod Touch, iPad, MacBook Pro, iPad Mini, and iPad Air – offer Retina displays. For a mobile web app in particular, it’s important to be aware that a Retina display makes low resolution images (which are typically served to mobile devices) look fuzzy and pixelation can occur. The best app development solution in these cases is to have the server recognize that the request is coming from a Retina device and to then provide an alternate higher resolution image to the client.
If you want to use some of the cool HTML5 stuff, remember to verify in advance that the functionality you’re looking for is supported across the device landscape that your customers are likely to be using. For example, in iOS 6 and above, there is no support for the navigator getUserMedia functionality since the camera is only accessible through native apps. Two great resources for checking what’s supported on specific devices and browsers are caniuse.com and html5test.com.
Remember to verify in advance that the functionality you’re looking for is supported across the device landscape that your customers are likely to be using.
CSS3 media queries can also help you provide customized content for each device. Here’s some example code for capturing different device characteristics, such as pixel density, screen resolution, and orientation:
/* For lower than 700px resolutions */
@media (max-width: 700px) { ... }
/* Same as last but with the device orientation on land scape */
@media (max-width: 700px) and (orientation: landscape) { ... }
/* Including width and orientation you can add a media type clause,
in this case 'tv' */
@media tv and (min-width: 700px) and (orientation: landscape) { ... }
/* for low resolution display with background-image */
.image {
background-image: url(/path/to/my/image.png);
background-size: 200px 300px;
height: 300px;
width: 200px;
}
/* for high resolution (Retina) display with background-image */
@media only screen and (min--moz-device-pixel-ratio: 2),
only screen and (-o-min-device-pixel-ratio: 2/1),
only screen and (-webkit-min-device-pixel-ratio: 2),
only screen and (min-device-pixel-ratio: 2) {
-repeat;
background-size: 200px 400px;
/* rest of your styles... */
}
}

Performance, performance, performance

“OMG, this thing is sooooo slow!” As a mobile web app developer, those are probably the very last words you ever want to hear from one of your users. You must therefore think carefully about how to reduce and optimize each byte and server transfer to reduce the user’s wait time. It’s unrealistic to expect that transfers will always be done over a WiFi network, and you should know that 60% of mobile web users say they expect a site to load on their mobile phone in 3 seconds or less (source). Similarly, Google found that, for every extra 5 seconds of load time, traffic dropped by 20% (and it is also worth noting that search engines look at load times as part of their calculation of page quality score).
60% of mobile web users say they expect a site to load on their mobile phone in 3 seconds or less.
As a part of this web app development tutorial, here are a few tips that can help optimize the performance of your mobile web app and minimize latency:
  • Image Optimization. Image load time is well-known to be one of the biggest performance issues affecting page load on mobile devices. Use of online image optimizers, such as smushit.com, can be helpful in addressing this issue.
  • Code compression. Compressing your JavaScript and CSS files, depending on the amount of code you have, can potentially have a significant impact on performance. A useful tool for compressing your code isrefresh-sh.com.
  • Database queries.
    • Some mobile device browsers don’t accept as many cookies as desktop browsers do, which can result in the need to execute even more queries than usual. Server-side caching is therefore especially crucial when supporting mobile web app clients.
    • Remember to employ the appropriate filters to preclude SQL query injection that could otherwise compromise the security of your site and server.
  • Content delivery networks (CDN). If you are planning to provide lots of videos, images, audio files, or other types of media, use of a CDN is highly recommended. Some of the more common commercial CDNs include Amazon S3Microsoft Windows Azure, and MaxCDN. The advantages of using a CDN are numerous and include:
    • Improved download performance. Leveraging a CDN’s resources enables you to distribute load, save bandwidth, and boost performance. The better CDNs offer higher availability, lower network latency, and lower packet loss. Moreover, many CDNs provide a globally distributed selection of data centers, enabling downloads to occur from a server closer to the user’s location (resulting in fewer network hops and faster downloads).
    • More concurrent downloads. Browsers typically limit the number of concurrent connections to a single domain, after which additional downloads are blocked until one of the previous downloads has completed. You can often see this limit in action when downloading many large files from the same site. Each additional CDN (on a different domain) allows for additional concurrent downloads.
    • Enhanced analytics. Many commercial CDNs provide usage reports that can supplement your own website analytics and which may offer a better quantification of video views and downloads. GTmetrix, for example, has an excellent website reporting tool for monitoring and optimizing the sources loaded on your site.

Your mobile web app development toolbox

“The right tools for the right job” is an age-old adage that applies as much to software development as it does to any other domain. This tutorial provides and introduction to some of the more popular and widely-used tools for mobile web app development, but bear in mind that there may very well be other tools that are the “right” ones for developing your mobile web app, depending on your requirements and available resources.

Mobile JavaScript Frameworks

As mobile web developers tend to face many of the same common challenges – such as cross-browser compatibility and inconsistent HTML and CSS in mobile browsers – frameworks have been developed (based on HTML5 and CSS3) that are specifically designed to address these issues and to work as flawlessly as possible on a wide array of smart phones and tablets. Most of these frameworks are lightweight, which helps facilitate fast mobile web browsing without compromising the look and feel of your site.
Broadening our view beyond the mobile landscape, if there is a single popular JavaScript framework worth mentioning, it is jQuery. If you’re familiar with the desktop version, I recommend trying jQuery Mobile for your mobile web app. It has a widget library that converts semantic markup into a gesture-friendly format, making operations easy on touch-screens. The latest version consists of a really lightweight code base that packs a punch with a lot of graphical elements that really can improve your UI.
Another alternative, Sencha Touch, is rapidly gaining market share as well. It offers excellent performance overall and helps produce a mobile web user interface that largely looks and feels like a native one. Its full-featured widget library is based on Sencha’s ExtJS JavaScript library.
Here are some key differences to consider when comparing jQuery Mobile and Sencha Touch:
  • Look and feel. Generally speaking, the look and feel of a Sencha Touch app is crisper and superior to that of a jQuery mobile app, but it is important to remember that such reactions do tend to be highly subjective.
  • Extensibility. jQuery Mobile offers lots of 3rd party extensions and is inherently designed to be highly extensible, whereas Sencha Touch is currently much more of a “closed” framework.
  • Device support. jQuery Mobile currently targets a larger cross-section of devices than Sencha Touch.
  • HTML “vs.” JavaScript. jQuery is largely HTML-centric (i.e., extending and manipulating existing HTML in JavaScript), whereas Sencha Touch coding is entirely JavaScript-based. (This is an example, incidentally, of the skill set of your development team being important to consider when making your technology selections.)
  • External dependencies. jQuery mobile requires jQuery and jQuery UI for DOM manipulation, whereas Sencha Touch has no external dependencies.
  • Learning curve. Most developers find the ramp-up time with jQuery to be less than that of Sencha Touch, perhaps fueled by the large percentage of web developers who are already familiar with the standard jQuery libraries.

Responsive Frameworks

An increasing number of responsive frameworks have begun cropping up in recent years, with two of the currently most popular being Bootstrap and Foundation. In short, responsive frameworks simplify and streamline web-based responsive UI design and implementation, encapsulating the most common layouts and UI paradigms into a reusable, performance-optimized framework. Mostly based on CSS and JavaScript, many of these frameworks are open-source, free to download, and easily customizable. Unless you have a highly peculiar set of requirements, it is likely that use of one of these frameworks will reduce the level-of-effort to design and implement your mobile web application.
Examining the two leading options, Bootstrap and Foundation, a few of the key differences to consider include:
  • Targeted platforms. While Bootstrap does support mobile, tablet, and desktop devices, it is primarily oriented toward desktop use. Foundation, on the other hand, is designed for essentially all screen sizes and types.
  • Browser compatibility. Bootstrap is compatible with IE7 or higher, whereas Foundation is only compatible with IE9 or higher.
  • Diversity of layouts and components. Bootstrap has a significantly larger collection of UI elements than is offered by Foundation.
  • Auto-resizing. With Foundation, the grid shrinks and stretches according to the current browser height and width, whereas Bootstrap only supports a pre-defined set of grid sizes based on a standard set of screen sizes.

Testing and debugging your mobile web app

Debugging mobile web apps can be tricky and somewhat frustrating, especially if you need to scrounge around for different devices to test on, or install SDKs for a (typically imperfect) emulation of the targeted client platforms.
In this context, one clear advantage of mobile web app development (as compared with native app development) is that you can utilize standard browser-based developer tools to debug your application. Based on my personal preference for remote debugging, the one I recommend in this app development tutorial is Chrome with its DevTools. Other standard options include Firefox with Firebug or Opera’s Dragonfly tools.
When learning how to develop web applications, look toward Chrome and its DevTools.
Some of the reasons I prefer Chrome with its DevTools include:
  • Mobile emulator in Chrome’s DevTools. This is perhaps alone sufficient reason to select Chrome for debugging of mobile web apps. Key features include emulation of touch events, user agent spoofing, network bandwidth throttling, geolocation overrides, device orientation overrides, and CSS Media Type Emulation.
  • Interactive editor. Ability to edit JavaScript or CSS on-the-fly.
  • Superior JavaScript debugger. Allows for DOM breakpoints and provides the ability to profile your JavaScript code execution time.
  • Built-in JSON and XML viewers. Avoids the need for any plugins to inspect server responses.
  • Support for the Android Debug Bridge (ADB) protocol directly over USB. Facilitates easy instantiation of a remote debugging session. (Here is a good tutorial by Google on how to start remotely debugging in Chrome.)
  • Dynamic inspection of resources. Allows you to inspect your app’s local data sources, including IndexedDB or Web SQL databases, local and session storage, cookies, and Application Cache resources. You can also quickly inspect your application’s visual resources, including images, fonts, and style sheets.
To test the layout and cross browsing compatibility of your web app, you can also use some helpful online tools, such as BrowserStack. Just enter the URL for your application, select the browser, version, and operating system, and you’ll get the emulated view (and load speed) of your site in that environment. Another useful tool for the this purposes is CrossBrowserTesting.

Wrap up

With the continued rapid expansion of the number, variety and sophistication of mobile devices on the market and in use today, the need for effective, user-friendly, high performance mobile applications is likely to increase substantially. Being able to develop these applications intelligently and efficiently will therefore continue to be of paramount importance.
Many factors must be considered when choosing between the web, native, and hybrid options for mobile applications. Each has its own advantages, but mobile web apps will often represent your most efficient development (and therefore time-to-market) option. Should you choose to go down that path, I hope this web app development tutorial helps get you more directly and successfully to your destination.
This article was written by  TOMAS AGRIMBAUa Toptal freelance developer.

Chủ Nhật, 1 tháng 5, 2016

How to set up Page-level AdSense ads in your blog

This article describes Page-level ads, a new type of AdSense advertisement which Google has recently introduced.   It includes how to set up these ads if you use Blogger, and some troubleshooting information about them.  

It also describes how to fix an error in the code which is supplied, which causes a message like "Attribute name "async" associated with an element type "script" must be followed by the ' = ' character".



What are Page Level AdSense ads

Google has recently introduced a new type of Adsense ad-units, which may be shown to people who visit a website using a mobile device (eg smartphone of tablet),

There are two types of Page-level ads:
  • Vignette ads:   When a visitor on your site clicks on a link to another page on you site, a vignette ad may be loaded as a full-page overlay which the user needs to close before they see the page which they navigated to.
  • Overlay ads:   these are smaller ads which show at the top or bottom of your screen, and which "stick" to the edge, so they seem to stay in place as the user scrolls up and down your site.   The visit may click on them in the usual way.

For Blogger users, these ads are only currently available if you have a full AdSense account: if you only have a hosted AdSense account, then you cannot get the code to install them.   But if you do have a full AdSense account (either because you have a custom domain, or because you signed up for AdSense before the "host AdSense account" option was introduced), they are attractive because they don't count towards the count of advertisement-units which you are allowed to display on each page.

They also only work if you have a mobile theme switched on for your blog, so that visitors who use a mobile device see mobile-optimised screen.


How to install AdSense Page Level ads in Blogger

Log in to your AdSense account.

Go to the My Ads tab

Turn on one or both of  Overlay or Vignette ads options.
(By default, they are both turned Off.    Click on the empty box beside the "0" to turn an option to  on:  in these controls, 0 means "off" and 1 means "on".)




Click the < > Get Code button.

Copy the code that is generated.

Switch to Blogger, and edit your theme in the usual way.

Find the text   <head>    (including the brackets).

On the very next line after <head>, paste in your code.

Optional - but highly recommended - add comments to clearly show what this code is for.   I usually use
<!-- START ADSENSE PAGE LEVEL ADS -->
and then the code goes in here ...
<!-- END ADSENSE PAGE LEVEL ADS -->
Preview the theme, and make sure it's working.
(See Troubleshooting section below if you get a message about   Attribute name "async" associated with an element type "script"    or similar.

Save the theme.



Job done!   This is all you need to do to enable page-levels ads for your blog:   you do not need to install gadgets to say where these ads go, because Google handles this for you.


How to see what page-level ads look like in your blog

Visit your blog using a smartphone or tablet.

Add the text   #googleads   at the end of the website address, so it changes from something like:
http://blogger-hints-and-tips.blogspot.com/?m=1
to something like:
http://blogger-hints-and-tips.blogspot.com/?m=1#googleads

After this, when you click on a link to move a different page in your blog,  a Vignette style ad will display - these are whole-page ads, which include a "close ad" button, like this:



Troubleshooting

Extra "src" text in the ad-code

Right now, there is a problem with the code that AdSense are providing.   I don't know if this is because Blogger doesn't understand a feature that AdSense is using, or if it's a genuine bug.    But if you see a message like this when you try to preview the theme:
Could not load theme preview: Error parsing XML, line 21, column 15: Attribute name "async" associated with an element type "script" must be followed by the ' = ' character.
then there's a very simple change that you have to make.

All you have to do is delete the "src" immediately after the word async.

So your code changes from like this:
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<script>
  (adsbygoogle = window.adsbygoogle || []).push({
    google_ad_client: "ca-pub-DONT-USE-MY-NUMBER-GET-YOUR-OWN-PUBLISHER-ID",
    enable_page_level_ads: true
  });
</script>

to like this:
<script async ="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<script>
  (adsbygoogle = window.adsbygoogle || []).push({
    google_ad_client: "ca-pub-DONT-USE-MY-NUMBER-GET-YOUR-OWN-PUBLISHER-ID",
    enable_page_level_ads: true
  });
</script>

Different Page Level settings for different websites

If you are using Adsense across several different websites, then you may want to enable one of vignette or overlay ads on some sites, and a different option on others.

Currently, there is no way to do this:  you must choose one combination of:
  • No Page Level ads
  • Overlay ads only, no Vignette ads
  • No Overlay ads, but do show Vignette ads
  • Allowing Google to choose Overlay and/or Vignette ads

Stop Vignette ads being attached to some links

By default, any link to another page in your blog may have a Vignette ad attached to it.    However there may be some links which you specifically don't want this to happen to - for example if the user really needs to remember what was on the current page once the get to the next one.

You can prevent any Vignette ads being displayed when a user clicks a link by adding a tag to the link.

The tag to add is:
data-google-vignette=”false”

and you need to switch to Edit HTML (top left of the post-editor window) to add it.

This is an example link to another page on this blog which is prevented from having a Vignette ad, and this is the HTML code I've used to achieve this.
<a data-google-vignette=”false” href="http://blogger-hints-and-tips.blogspot.com/2010/02/stop-malicious-use-of-your-adsense.html">an example link</a> 

More help

Google have provided more information about Page level ads here.



Related Articles

Setting up a mobile theme for your blog

Editing your Blogger theme

Hosted AdSesne accounts for Blogger users

Thứ Ba, 18 tháng 11, 2014

How to turn on a mobile theme / template for blogs in Blogger

This article explains why mobile mattes for some blogs (but not all), what tools Blogger has provided to help with this, and how to set up a mobile theme (aka template) for your blog.  It also links to Google's mobile testing tool, which shows you how your blog looks on a mobile device.



By default, when someone uses a smartphone, tablet or other mobile device to look at your blog, they see the "full site" just like they would if they were using a PC.   The pages aren't set up to work well on their small screen, but they have access to all the features and gadgets you've installed.

In some cases, this is fine.  For example, when I first wrote this article, I looked at the statistics for this site and hardly any of the visitors were mobile.   However now, a couple of years later things have changed and I've implemented a mobile theme for this blog.

But for other blogs, especially ones that have maps and other location-information or which people read on the go, having a mobile-friendly theme is very important:   for example, on my public-transport blog, over 25% of visitors are using mobile, and that figure is growing.  Making my site work well for these visitors is definitely important for its long-term future (and my short term advertising revenue!)


What's available

Blogger have made a set of mobile themes, to match the standard Designer Themes, and so far only one to match the Dynamic theme(s).

We cannot control the layout of gadgets on these - when the screen is only 300-ish pixels wide, there's not much room to move.

But we can add and remove gadgets, and also by choosing a custom template get colour settings that match our main blog.


How to enable a mobile theme / template for your blog

Log in to Blogger using an account with administrator rights to the blog.

Go to the Themes tab.

If your blog has a Designer or Dynamic theme, then there will be a Mobile option to the right of the "Live on Blog" area.



If the blog is not set up to use a mobile theme ,then the word Disabled will be in the middle of the picture area - although it may be hard to read if your base template (chosen in the Live on Blog area) has a picture behind it.

Click on the gear-wheel underneath the picture to see the mobile options.

Select "Yes.  Show mobile template on mobile devices."



Either leave the mobile template on Default, or select one of the other options.
  • If you choose Default, your mobile template will use the standard template matching your desktop template.
  • If you choose Custom, your mobile template will use the colour-scheme and various features from your desktop template, and you will be able to makes changes to these settings.

Use the Preview button if you want to see what your blog will look like with the selected template on a mobile device.

When you are happy with your selection, press Save.


What your readers see

Visitors to your blog who are using a desktop PC (or laptop or netbook or any other machine with a full-size screen) won't see anything different.

Readers who are using an internet-enabled cellphone (ie smartphone), tablet, iPad, etc will see a different view:
  • They won't have a sidebar
  • The gadgets will be limited (unless you add some extra ones) and in the header and footer only
  • On the home-page there will just be the title, thumbnail and snippet for each post, and a button for read-more (this is irrespective of where you've put the jump-break) - notice that the usual methods of giving your blog a home-page don't always work.
  • Custom styles that you have added to the template may not be applied (this has happened on one blog where I use styles, I'm still investigating whether it's a feature of all mobile templates, or just due to the way I added these particular styles).
  • There will be buttons at the bottom of the page for Home, <   and > .    I think that the latter two refer to older and newer posts (though possible they are the opposite way around from what I expect).
  • There will be a link to "view web version", which lets your visitor switch to to see the blog using the desktop template.

I have a  feeling that there may be some other differences too - very keen to hear about any others you've spotted.


Seeing what your mobile readers see

The absolute best way that I've found to accurately experience my blogs as mobile visitors see them is to use a mobile device myself:
  • Just like preview mode in the Post-editor, the mobile preview mode shows a "look and feel" view, which is not entirely accurate.   For example in the picture above, it shows part of the most-recent article insteaod of just the post title and mini-snippet that I see when I look at the site on my phone.
  • The screen-size testers that I've tried out (ie software tools that mimic showing your website in various different screen sizes) don't actually use the mobile template - I suspect that this is due to the way that Blogger detects mobile devices.

However you can see any blog as it would be on a mobile device by appending /?m=1 to the end of the URL.    For example, to see this blog in mobile, I would look at http://blogger-hints-and-tips.blogspot.com/?m=1      If you're going to use this approach, it's best to re-size your browser window so that it's about 300px wide - from my netbook, that's about 1/3 of the screen size, but it would be less from machiens with bigger screens.


Another approach is to use Google's Mobile Friendly Testing tool, which will
... analyze a URL and report if the page has a mobile-friendly design.
As well as showing you how your blog looks, it also reports on any issues that have been found.






Related Articles

Adding gadgets to your mobile template.

Removing the attribution from moblile blogs

Showing a Google custom map on your blog

Advertising programmes for websites

Types of Blogger template

Administrator rights to your blog

Thứ Hai, 7 tháng 7, 2014

How to copy and paste a website address on an Android smartphone

This article explains how to copy and paste a website address (URL) when you are using the Chrome browser on an Android smartphone.



Copy and paste on an Android phone

When you are using an Android cellphone, the usual way to copy-and-paste text is to "long-click" on one word, and after it is selected, drag the selector-bars at either end to select more of the text.

After this, you have options on a list at the very top of the screen to cut, copy and page.

But this doesn't work on the Chrome browser's address-bar, ie the place where you type in website addresses, or see the address which your currently viewed pages has.

Here, there is no long-click, and you have to use a slightly different approach.


How to copy a web-address on a Smartphone using Google Android and Chrome


1 Inside Chrome, go to the website and page that you want to copy the address from.


2 From the top right handcorner, choose the Overflow menu button: this is three vertical dots.


3 From the menu that opens, choose Share


4 choose Copy to clipboard from the list of sharing options.


Step 1: Choose Share

Step 2: copy-to-clipboard
Now, when you go into other applications and pages, you can long-press, and a small PASTE button will appear.   Click this - and watch your copied link get pasted.


Troubleshooting

Remember that if it's a Blogger site that the link came from, you may need to remove the " /?m=1" from the end of the URL, for the sake of non-mobile users of the place where you are pasting the link.


How exactly is this a Blogger tip?

Fair question - this a blog about using Blogger, Google's website tool for the rest of us, not about Android phones!   But as more and more people are using mobiles, and so mobile-friendly themes become ever-more important) I still think it's relevant - here's why:

Even with a new phone running a very recent version of the Android operating system, I still find it too hard to write anything exepct the simplest posts on the phone.

But I've found that I can do more and more of the promotional and social-media aspects of managing my blogs on the phone in my "spare mintues", eg while I'm on a bus, or sitting in a waiting room. Very often, this involves locating a blog-post which answers a question, and posting a short summary and link to the post there. An of course to do this, I need to copy the link to the post. So copy-and-pasting website URLs is now one of the tasks need to do fairly often.




Related Articles

Making a social media / communications plan for your blog

Turning off Blogger's mobile theme

Thứ Hai, 19 tháng 5, 2014

AdSense, mobile templates and Analytics - and how they do (or don't) work together


If you

then it's an extremely good idea to have at least one AdSense ad-unit that was made with Blogger's official AdSense widget rather than by getting the code from AdSense and installing it manually.



This is because the a majority of gadgets don't show up on the screen when a visitor using a mobile device (cellphone or tablet) looks at a blog which has a mobile template set up for it - and by default this includes AdSense gadgets.   When a mobile visitor looks at a blog, Blogger does check to see if AdSense is used on it, and if so it shows one or two ad-units to them.  But unfortunately these checks only detect AdSense gadgets, not AdSense code in HTML/Javascript gadgets or added directly to the template.   So the net effect is that unless you have one of the official AdSense gadgets, mobile visitors to your blog will not see any AdSense ads.

Some more things to note

There is a way to explicitly say that certain gadgets should be shown on your blog when it's viewed in mobile.    However I've found that due to a problem in Blogger, if you use this method, you will get an error message every time you try to manually edit your template.

Also, because of the limits to the number of AdSnese ads you can show, it seems logical that the one official AdSense gadget on your blog should be a link unit - specially since AdSense earnings through Blogger gadgets are not reported in Analytics even if it is properly set up for your blog.   However at the moment, if you try to add a link-unit to a Blogger-site, then you get an error message like this:


"Please correct the errors on this form"
The error message when you try to add an AdSense Link unit in Blogger

This only appears when a link-unit has been selected, and I have not been able to find any way to work around this problem when adding a link-unit of any size.