Keyboard Shortcuts in Google Chrome

This is a collection of useful keyboard shortcuts for the Google Chrome Web Browser, that will speed up your browsing, and improve your experience.


(“Click”, with no other specification, means a Left Mouse Button Click.)

  • CTRL + Click: Open link in a new tab.
  • SHIFT + Click: Open link in a new window.
  • Middle Click: (On a link) Open link in a new tab (in the background.)
  • Middle Click: (On a tab) Closes the currently clicked tab.
  • Shift + Middle Click: Open in new tab, and shift focus to this newly opened tab.
  • ALT + Click: Save link target as...


  • CTRL + T: Open a new tab.
  • CTRL + N: Open a new window.
  • CTRL + SHIFT + N: Open a new incognito (private browsing) window.
  • CTRL + SHIFT + T: Re-opens the last closed tab. (Repeat to keep re-opening previous tabs.)
  • ALT + Left or Right Arrow Key: Go forward or backwards in your browsing history.
  • CTRL + TAB Key: Change focus moving through the next tabs.
  • CTRL + SHIFT + TAB Key: Change focus moving through the previous tabs.
  • CTRL + PageUp: Go to the next tab.
  • CTRL + PageDown: Go to the previous tab.
  • CTRL + (1 through 9): Go to a tab in the chosen position.
  • CTRL + W: Close the current tab (if it were the only open tab, it would close your browser.)
  • ALT + F4: Close your browser window, no matter how many tabs were open.
  • CTRL + R: Reloads the current tab.
  • F5: Refreshes the current web address.
  • CTRL + P: Print the current webpage.
  • CTRL + F5: Refresh the current page, bypassing any cached version.
  • ALT + Home Key: Navigate to your homepage.

- Actions

  • CTRL + F: Search occurrences of the given text in the curent webpage.
  • F3: Go to the next search result with the current search query, in the current webpage.
  • CTRL + U: View source code of the current page.
  • CTRL + D: Add the current page to your bookmarks.
  • CTRL + H: Open your browsing history.
  • CTRL + B: Toggles the visibility of your bookmarks bar.
  • SHIFT + ESC: Opens up the task manager of Google Chrome.
  • ALT + F: Opens the tools menu.
  • CTRL + SHIFT + J: Opens the developer tools menu.
  • CTRL + O: Opens the selected file using Chrome.

- Address bar / URL

  • CTRL + L: Moves the cursor focus to the address bar, allowing you to write a new website address.
  • CTRL + K: (Also CTRL + E) Focuses on the address bar, including the ? symbol before your cursor, to perform a Google search.

After writing something in the address bar:

  • CTRL + ENTER: Adds “www.” and “.com” to the text we've written, and navigates to that URL.
  • ALT + ENTER: Open the chosen URL in a new tab
  • CTRL + ALT + ENTER: Adds “www.” and “.com” to the text we've written, and loads that address in a new tab.

What ind of Headphones / Ear Buds should you buy?

Let's simplify all the information related to Ohm (Ohms), dB (Decibels) and Hz (Hertzs). There is a lot of technical information around the Internet trying to explain what they are, but they don't answer the quick, frequent question of what should I take into account when purchasing a new set of headphones?

TrebleClick aims to make your life easier, so we're going to simplify all that, and explain it in an easy-to-understand way:

Ohm, dB and Hz: what they are, what's their purpose, and why are they important?

  • Ohm: Ohms are the Impedance of your headphones, or, in plain English: the resistance that your headphones oppose to the flow of an electric current. This determines the amount of power that reaches your headphones, in relation to the amount of power sent. More Ohms will require a higher power input value to work properly. If the resistance value is very high, your system will need an amplifier. You will find the nominal value of resistance in the technical specifications of your headphones. 16, 24 or 32 are usual Ohm values, and they should work for regular purposes.
  • dB: The Decibels represent the Sound Pressure Level (SPL), or the audio volume power. Higher dB values will make the sound in your headphones be louder. But higher dB values will also lead to earlier distortion in such sound. The higher this volume value is, the closer to the distortion threshold you'll be.
  • Hz: Hertzs are the Audio Frequency, and they actually are the most important parameter to take into account when considering the sound quality of some new headphones. The Hertzs represent the frequency range that your headphones will play back, from the lowest bass to the highest treble. This usually comes specified in minimum and maximum values, so the best headphone sets will have broader ranges, with a lower minimum, and a higher maximum. Human ear can hear sound frequencies ranging between 20 and 20.000 Hz.

Conclusion: what do I need in my headphones?

If you are a professional sound technician, or an expert, and you already have a pretty decent sound system, you won't probably even need to read this, and you may even disagree about some details. But if you are just an average computer user, avid gamer or designer, and the only thing you want is some headphones to use with your computer or laptop, the only things you need to take into account when choosing them are as follows:

  • A higher dB value implies higher sound volume. The usual values are set around 112 dB/mW.
  • Higher Ohm mean higher resistance values, and this means that you'll need higher input power values - otherwise, you'll experience a lower sound volume. Nominal Ohm values of 16, 24 or 32 are the most frequent ones.
  • A higher Hz range will play more sound frequencies, providing higher quality sound playback. This is the other key parameter. 20-20.000 Hz is okay. From that point on, a broader frequency range (like 12-28.000 Hz) should have better sound quality, while a narrower frequency bandwidth (for example, 21-18.000 Hz) would provide lower sound quality.

Playing music in Cakewalk Music Creator 6 with a computer keyboard

Have you ever wanted to play music with your computer keyboard when you don't have a regular MIDI keyboard at hand? This time-saving feature is usually available at most music creation software, but unfortunately, it isn't built as part of Cakewalk Music Creator 6 Touch.

That's why I found out a way to use your regular computer keyboard as a MIDI keyboard that would be recognized by Music Creator 6, so you can compose some quick musical experiments even when you are on the go! The following sections will detail the steps to get this nice feature working on your music creation software.

Using a computer keyboard as music keyboard

How to make Cakewalk Music Creator 6 Touch to recognize your computer keyboard as MIDI input

The procedure to have your keyboard recognized as a MIDI keyboard in any music creation software would follow these steps:

  • A virtual MIDI keyboard should capture the keystrokes from your computer keyboard and turn then into MIDI.
  • This MIDI information should be rerouted from the output of the virtual keyboard to the MIDI input of your music creation software.
Use your computer keyboard as MIDI input

Getting your keyboard to work with Music Creator is easier than it seems, once you have the following two software programs:

  • VMPK. It is a useful open source project that stands for Virtual MIDI Piano Keyboard. VMPK will recognize the keystrokes in your computer keyboard as MIDI input. It can be downloaded from here, where other detailed usage instructions are available.
  • loopMIDI. This program, created by Tobias Erichsen, provides a reliable and extremely simple way to reroute your virtual MIDI cables. It works from Windows XP to Windows 8 systems, supporting both, 32 and 64 bit systems. It can be downloaded from the author's website here.

Detailed steps to use your computer keyboard as a MIDI input in Music Creator 6 Touch

Once you have Cakewalk Music Creator 6 Touch installed in your computer, as well as the other two previously mentioned programs, you just need to follow these steps to start playing and recording music from your computer keyboard.

First, run loopMIDI by executing loopMIDI.exe. Click the plus (+) symbol to add a new loopback MIDI port. In the example, we created a new MIDI port with its default name, loopMIDI Port. Don't close loopMIDI, since you'll need this program to be running as a background process in order for the MIDI reroute to take effect.

Then, run VMPK.exe to execute the Virtual MIDI Piano Keyboard software. It will start capturing the keystrokes from your computer keyboard as MIDI input, as long as its window is selected and has focus as an active window. Select Edit > MIDI Connections to configure the MIDI output of this program.

edit virtual keyboard MIDI connections

We want the output of this virtual keyboard to go towards our recently created virtual loop MIDI port. That's why inside the VMPK MIDI setup menu we should be selecting the name of the new loopMIDI port as an Output MIDI Connection – in this example, we select our previously created port named “loopMIDI Port” and hit OK.

output MIDI connection

Here's where Cakewalk Music Creator 6 Touch comes into play. We are already recognizing the keystrokes from our computer keyboard, and sending them to a new MIDI port that would reroute them as a MIDI input. So the next step is to configure Music Creator 6 to use this virtual port as its MIDI input. Inside Music Creator, open the preferences menu by selecting Edit > Preferences.

edit Music Creator preferences

Inside the Music Creator preferences window, select Devices under the MIDI section. The top list will display all available MIDI inputs under the Inputs label. Look for the name of the virtual MIDI loop port you just created – loopMIDI Port in our example – select it by checking the box at the left of its name, and click okay.

Cakewalk Music Creator MIDI input devices

And that's all! Cakewalk Music Creator will now recognize your keystrokes as MIDI input (as long as your VMPK window is the selected, active window, and as long as the loopmidi software is running,) allowing you to record (and even step-record) the notes of your songs directly from your computer keyboard.

Even when nothing can replace a full music keyboard, this is a quite time-saving solution if you don't have a MIDI keyboard at hand or if you are composing music on the go.

Geeky 3D Music Video.

From one of our writers and designers, Rael del Fraile, comes this 3D video of the little big-headed robot from Star Wars, dancing like the King of Pop:

Well, now you can tell your friends that you have seen R2D2 dancing like Michael Jackson.

How To Optimize Mobile-Only Websites

A few years ago, mobile devices were just used for phone calls. But nowadays, the traffic that our websites receive from smartphones just keeps increasing to a level that their importance cannot be denied anymore. And with new technologies and opportunities come new challenges and questions.

To make things easier, we are sharing here a list of questions and answers about how to optimize mobile-only versions of your websites, taking into account technical, user experience and SEO considerations.

Why would redirecting to a mobile version make sense?

Responsive web design presents several advantages when compared to creating a detached, alternative version just for your mobile users:

  • Maintenance can be simplified. Even when responsive websites can increase the level of complexity, only one website would have to be modified. Content-wise, all your contents would remain on just one place, making it easier to expand and update your site for both, regular users and mobile users.
  • SEO can be simplified. Presenting a single version of your website for all your users with (mostly) the same content avoids the hassle of notifying search engines about both versions, making clear which one is the main version and which one is the mobile-optimized version.
responsive design

However, even when responsive web design is probably the only trend that will survive in the not-so-distant future, creating a responsive web design instead of a mobile version may not be the best option under certain circumstances:

  • Budget constraints. Responsive designs require additional planning in advance and testing in a broad array of devices and screen resolutions, for all the kinds of content.
  • Outdated phones. If most of your users still rely on feature phones or old smartphones, but still do want to navigate a mobile version of your site, then you better make that version very lightweight and fast, specifically designed with simplicity and speed in mind.
  • Legacy code. If you already do have a mobile version in your website, or a website that would be very hard to turn into a responsive website, then working with your existing versions would make sense.
  • Context restrictions. The goals of your users while on the go may differ from the goals of other users accessing your website from a desktop computer. There are some additional interface and context restrictions as well: typing on a small touchscreen while walking down the street may render your web forms useless; reading on a tiny mobile screen may render your detailed, long pages overwhelming.

If you are under one of these previous scenarios, you will definitely want to keep using your separate mobile website version, and optimize it as much as possible so:

  • You will be serving easy-to-navigate content to your users.
  • It will be easy to discover for search engines.
  • Your mobile version won't compete with your original version, cannibalizing your search engine results.

Here is a list of frequently asked questions about how to optimize the performance of a standalone mobile version.

Should you display different content for mobile browsers in the same URL, or redirect them to a different, mobile-only URL?

There are two approaches to serve mobile optimized content to your site users: keeping them in the original URL but sending them different, mobile optimized content, or redirecting them to a different URL where they would find mobile optimized contents.

mobile URL redirection

The first approach has a SEO-related advantage: all links pointing to one of your mobile URLs will also pass their ranking to the main URLs, since both are the same.

However, this approach also has bigger risks as well. Issues with this configuration, like failing to tell apart your mobile users appropriately, may lead to search engines think that you are sending shallow content to all users, or creating a URL masking scheme.

There could be issues with your mobile users as well. Without the URL providing additional feedback about the version they are browsing, your users might be confused about thinking this is the only version of your website (if your "go to original version" link weren't very visible.)

That's why redirecting to a mobile-only URL still makes sense, as it can be technically easier to work with, pretty clear to understand, and very well organized. But you need to make sure such an URL is marked as just for mobile browsers, as an alternative version, so it won't compete with your regular URLs in search engine rankings.

Should you create different versions for feature phones and smartphones?

While smartphones boast not-so-tiny touchscreens and powerful processors, those old mobile phones out there, the so called feature phones, will lack enough screen real estate or processing power to deliver a good browsing experience in most websites.

The answer to this question depends on your business. Your browsing stats will be priceless for this purpose. Most stats tracking software will give you a detailed breakdown about the hardware that your visitors are using to navigate your site. If that list contains a decent percentage of old mobile phone users, then creating a version optimized for featured phones would make sense.

However, mobile phones are quickly evolving. It depends on your target market and on the country where your business is located, but chances are that feature phones will quickly disappear in favor of more powerful smartphones. And taking into account that the processing power of smartphones is coming closer to being little desktop computers, chances are that your future website design plans should consider only smartphone-optimized versions.

Feature phones vs. smartphones

At the end, this is what the other big web design trend of responsive design is already hinting: in a not-so-distant future, desktop versions and mobile phone versions would only be distinguished by the layout used to present information. In the meantime, a single alternative fast-loading and concise mobile version should suit the needs of all your mobile users.

How is a mobile URL marked as a mobile, alternative version?

Tagging mobile pages

Google recommends tagging pages with alternative versions following this approach:

  • The regular, original page should signal that there is a mobile-friendly version serving similar content.
  • The mobile-optimized versions should point at their related regular pages, marking them as the main, canonical pages.

Screen size is used to discriminate mobile phones, while the media type handheld is used to target feature phones. In the most common scenario where there's just a mobile-friendly version, these are the alternate link tags that you would include in your main, regular version:

 <link rel="alternate" media="only screen and (max-width: 640px)" href="http://www.mobileURLHere" />

<link rel="alternate" media="handheld" href="http://www.mobileURLHere" />

And this is the canonical link that you would include in the mobile version:

<link rel="canonical" href="http://www.mainURLHere" />

You can also tag mobile versions in your sitemap.xml as alternative versions. Each alternative mobile version should be associated to its related regular version, so the sitemap of your website would look like this:

<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns=""






    media="only screen and (max-width: 640px)"

    href="http://www.mobileURLHere" />



It is important to make sure you are redirecting exactly to the URL specified in these alternate tags, or you could be sending confusing information to the search engines, and you could even risk getting your website flagged as spam.

If there is no corresponding original page, where should a canonical tag inside the mobile version point to?

If your mobile site doesn't mirror your original site in full (that is, having a mobile-optimized page per each original page) then the quickest approach would also be the safest: small mobile websites can redirect all their pages to your main url in your original version, ensuring all of them pass pagerank to your main webpage.

canonical links

Take into account that, in an ideal case scenario, every single page of your main website should be having a mobile-optimized page. Other scenarios can lead to bookmarks that don't work as expected across different devices, or, as Google calls them, irrelevant redirects – unless your mobile version is specifically crafted to serve an optimum version considering your mobile users' context and market niche.

Update: in this official blog post titled Changes in rankings of smartphone search results Google updated what they consider an irrelevant redirection. According to this report, mobile-accessed pages without a mobile version available shouldn't redirect to your main mobile page, as that would be considered an irrelevant redirection. The recommended approach for pages without mobile versions is to lead the user to the original, non-mobile-optimized page.

Other than that, the recommended suboptimal approach according to Google is having a mobile-optimized page for every single of your regular pages (thus removing the risk of irrelevant redirections.) And the optimum recommended scenario would follow a fully responsive website approach, with a single version that would work nicely on all devices.

How can you detect mobile browsers to serve them different contents?

Mobile browsers identify themselves through their own user agents. By identifying their user agent you can send them different contents or redirect them to a new page.

You don't need to create a whole list of user agents by yourself. There are some scripts out there that would take care of that for you. is an open-source mobile browser detection library that will do the trick, offering scripts in several different programming languages (Apache server scripts, Javascript, ASP, PHP, etc.)

detect mobile devices

Be careful with this tactic, though, since new mobile devices, not considered in this list, might eventually appear. There's a slim chance of your mobile detection script running outdated and classifying new devices into the wrong category. So make sure you keep updated detection rules as well.

Should Google's mobile crawler be considered in mobile browser redirection scripts?

Google has a Googlebot-mobile webcrawler, specifically dedicated to crawling mobile versions, which is completely independent from their regular Googlebot. So it would make sense that this crawler reached the mobile version of your website.

mobile website crawler

However, Googlebot-mobile presents itself using the user agent of regular, well-known smartphones. You don't need to discriminate Googlebot-mobile in your browser-detection scripts. Google warns that doing so can be flagged as URL cloaking, which would bring you a penalty from Google.

Server-side redirection or Javascript redirection?

There are a couple of different approaches when redirecting your mobile users to a different mobile version. You can perform the appropriate user agent checks on your visitor's web browser by using a Javascript redirection. Or you can go ahead with a server-side redirection, so your web server performs the browser agent checks (either directly on the server engine by using .htaccess rules, or in a server-side programming language, such as .NET, PHP, Ruby and so on.)

The problem with a Javascript redirection is that part of your original page needs to load before your mobile user is redirected to the appropriate version. On the other hand, a server-side redirection would leave the user agent checks and processing to the server itself, preventing your user from loading unnecessary content.

Javascript redirect
Server-side redirect

Taking into account that mobile users have limited bandwidth and processing power, server-side redirects are the preferred approach since they will be faster.

Permanent 301 redirect or temporary 302 redirect?

There are two main different types of server-side redirects that are triggered by specific HTTP response headers directly sent from the server:

  • A 301 redirection is a permanent redirection, indicating that the original URL doesn't matter anymore, so all queries should be redirected to the new URL.
  • A 302 redirection is a temporary redirection, just signalling that visits to the original URL are redirected to a new URL at the present time, but that this is a temporary situation expected to be reverted.

If you use response codes to redirect your mobile users to the appropriate, mobile version, in Google's own words:

For this purpose, it does not matter if the server redirects with an HTTP 301 or a 302 status code.

So it really doesn't matter what kind of redirection you are using to send your users to your mobile version.

Temporary 302 redirect

However, let's consider a worst case scenario: if some misconfiguration or glitch in the process is preventing both versions of your site from being understood the right way from a search engine's perspective, using a permanent 301 redirect from your regular version to your mobile version would send most or all your pagerank, traffic or users to your alternative, simpler, mobile-optimized version. Such a scenario would be a disaster for your SEO strategy.

That's why using a 302 temporary redirect pointing towards your mobile version is a better strategy in terms of risk prevention.

Should you include a vary HTTP header in mobile URLs?

Google mentions in its guidelines that, in case you use any kind of redirect, any redirecting webpage should also be outputting a Vary HTTP header to notify potential search engine crawlers that mobile crawling is also in order, since the page can lead to different results depending on the user agent used to browse it. This way, every mobile page would be crawled, and the structure of your site would be better understood.

Vary response header

This also holds true for websites using the same URL to serve optimized content for both, mobile users and regular users (dynamic serving.) In this case it can become even more important, as there wouldn't be any other way to tell the search engine spiders that a mobile version exists for the present page. You would also make sure that the mobile optimized version wouldn't be considered as masked content or as the main version related to this URL, since you would be announcing its existence through this header.

The Vary header should be sent indicating that the contents in that page can vary depending on the user-agent, so it should look this way:

Vary: User-Agent

Should you include a link to the original, regular version in your mobile-optimized version?

Definitely. Some users will still want to access the full contents of their main version if they feel that they are missing part of the content, or if they just have a smartphone powerful enough for regular browsing.

If your mobile-optimized version is simple and short enough (as it should be,) the link to the original article / normal version could be safely included at the bottom of the page: there wouldn't be any need to go to the regular version if the mobile version provided enough information by itself. Going to a normal version is rarely a decision taken in the first second.

link to normal version

Make sure to display this link to your main version in a very visible way, though. You really do want to make your users know there's still a different, potentially more complete and eye-catching version that they could visit if they wanted to. This becomes specially important if you are serving your mobile contents from the same URL, as the URL wouldn't offer any additional clue about the existence of a regular version.

Where should a link from the mobile version to the regular version exactly point?

In the ideal case of having a mobile website composed of a mobile page per each regular page, the links pointing to the regular versions from the mobile pages should precisely target their corresponding regular page, talking about the same subject and offering similar content.

However, things can be a little bit more complicated if your mobile website comprises just a subset of your whole regular site, which can still make sense to offer a simplified, more straightforward version of your contents to the specific market niche composed of your mobile visitors.

If there were no matching page, offering a link to the homepage of your website from its mobile version could seem like a good idea, since the homepage presents the most easy-to-access gateways to all your content.

link to mobile version

But that's not enough. Consider the following scenario: a user performs a specific search from his web phone, clicks a specific search result, and is then redirected to the homepage of your mobile version instead. This can be okay as long as your user appreciates the ease of navigation of your mobile version, and as long as he finds relevant information. But, what if he just wants the answer to his original, specific query, and thinks that his smartphone should be able to handle browsing the full, regular webpage? Giving him a link to your main homepage will feel like a burden.

That is why you should also offer a link to the page your mobile users were trying to reach before being redirected to the mobile version of your website. You can annotate the page where a redirection was started (for example, in a parameter, cookie or session variable.) Mobile users pleased by the ease of use of your mobile version would remain there with no problem. And mobile users wanting to reach the original contents that triggered their click in the search engine results would still have the option to view the original contents they were originally thinking about.

How to allow mobile users browse your regular version?

Mobile users should be redirected towards your mobile-optimized version. So when one of your mobile users prefers trying to navigate your full website using a powerful smartphone, and clicks a link to your regular version, how to prevent him being redirected back to the mobile version, and stuck in an endless loop?

One of the most straightforward approaches to solve this issue is to add an additional parameter to override this redirection for users who explicitly request to see full versions from their mobile phones. Just a query parameter appended to the target URL can be enough. The target, regular webpage would check for the existence of this parameter. If found, any redirection would be skipped this time, allowing your mobile user to navigate the regular version of your website.

Nevertheless, that might not be just enough. That same user could still want to keep navigating other regular sections of your website. If such parameter weren't kept, your user could be redirected back to a mobile version when clicking a new link.

So once a regular version is requested by including a parameter to override mobile browsing, this preference should be stored in a cookie for your user, or even just in a session variable. So your user won't have to worry about being redirected to your mobile version again.

If a cookie or session variable were set for that user, no regular page would redirect such specific mobile user.

storing mobile preferences

On the other hand, this user can still go back anytime to your mobile version, not by an automated redirect, but by pressing his “back” button on the web browser of his mobile phone. This is a rare scenario that might only happen if your user decides that the regular version is too much for his phone after explicitly requesting it, but being covered about this case is still worth for optimum user experience purposes.

What about redirecting desktop / regular users accessing your mobile version to your regular version?

This is what Google calls bidirectional redirects. It prevents your desktop users from landing on a mobile-optimized version, which in their large screens would look rather limited or empty, and thus, wouldn't create the appropriate first impression.

If you have an updated mobile agent detection, then bidirectional redirects can make sense. It is very strange that a desktop user would rather see the incomplete or limited mobile version instead of the full, original version of your website.

redirecting desktop users

Independently from that redirection for desktop users, some mobile phone users would still like to access your regular pages. Having a link offering to visit the normal version instead would come here into play.

The only catch about bidirectional redirects is that you need to make sure your code is working perfectly. If not, you could leave your users stuck in the wrong site version or in a redirection loop.

Are tablet browsers mobile browsers too?

Tablets have some points in common with mobile browsers: they provide their users with some mobility, not-so-big touchscreens, and less processing power than desktop computers.

However, most modern tablets already allow regular navigation in regular webpages with ease. Their processing power is enough to move normal webpages, and their screens (even the 7-inch ones) are big enough to provide good website readability.

That's why I suggest not treating tablets as mobile devices, and to exclude them from your user-agent detection scripts.

tablet users

Besides, it is still possible to redirect tablet users to your mobile version as well. This can make sense if your regular version is not so tablet-friendly (if it takes too long to load, if it features Flash content that won't work in iPads, or if it just targets a niche where you wouldn't include your tablet users.)

If you are using the user-agent-detection script previously mentioned,, you would just need to add the following code to the first regular expression to treat iPads, Kindle Fire, Playbooks and Android tablets as mobile devices as well:


WhatsApp is now available only for iPhone.

The messaging app "Whatsapp", is no more available for the iPod and iPad because of a decision taken by Apple, and it has now removed from the App Store for those devices. Now the WhatsApp App is only available for iPhone.

While WhatsApp for Android is free, WhatsApp has a price in the App Store, and Apple is not refunding the amount of any previous purchase.

WhatsApp keeps working on those iPad and iPod devices in which it is still installed. But you won't be able to update or purchase WhatsApp for iPad or iPod anymore.

Those iPod and iPad users who had already purchased it and who want to keep using it in the near future will be able to do so as long as they don't erase the installed app, and as long as the installed version remains compatible enough, because there's no (legal) way to get a WhatsApp app for your iPad or iPod.

You can create a backup of the app syncing the device with iTunes in your own computer, and then copying the file "WhatsApp.ipa" located inside the folder: "C:\Documents and Settings\Windows username\My documents\My music\iTunes\iTunes Media\Mobile Applications" (in Windows XP; other newer Windows operating systems store the app data in a similar route).

Note: that files has a unique ID, and works only in the device in which the original purchase of the app took place, as it is synchronized with the user's iTunes account. Copying and pasting that WhatsApp data file in a different iPad or iPod will make the app to stop working.

How to take a screenshot in Android Samsung Galaxy S smartphone

Saving a screenshot in the Samsung Galaxy S Android-based smartphone is very easy: it's just a simple combination of keys.

You need to keep pressed the tactile key Back and, without releasing this key, we press the central Home button (the one that returns to your main screen) and then we would release the "Home" button (without releasing the Back key.)

The best way this screenshot trick works is just keeping pressed "Back" during a second and then pressing "Home". If we do this fast it might not work. And if we wait too long, maybe the screenshot would be taken too late, because the "Back" key might act, going to the previous level in the current app or page.

Essentially, this trick is all about pressing and releasing "Home" while "Back" is still pressed.

If our screenshot was successful, we would hear a sound similar of a photographic camera shutter, and in the bottom of our screen a message would be displayed: "Screenshot taken. Saving as image file", and the image would be stored in the "ScreenCapture" folder of the Samsung Galaxy S device.

In spite of the outdated information spread all over Internet about this feature, with statements about the impossibility of saving a screenshot in the Samsung Galaxy S smartphones, suggesting other complex operations, connecting the device to the computer, etc., truth is that these specific Android-based phones, since the Android firmware version 2.2, are able to save screenshots in this simple way.