Chrome added an annoying translation feature


Recently Google has added a built-in translation feature to Chrome that has some usability issues. Since these issues haven’t been fixed in the past couple of releases, they might be here to stay. So here is how it works: if you visit a page that is in a different language than your system language (or the main Chrome language), Chrome shows that little popup in the image below and asks if you would like to translate the page. Neat feature if you occasionally use it. However that is not the case when you often visit pages with another language. By the way, there’s a joke that goes like this:

What do you call a person who knows three languages? Answer: Trilingual. What do you call a person who knows two languages? Answer: Bilingual. What do you call a person who knows only one language? Answer: American.

So probably “Americans” designed Chrome but for the rest of the world, this is just a painful UX.

Why U visit pages in other languages?

Why U visit pages in other languages?

Let’s demonstrate with an example. Baidu is one of the most popular search engines in China. When you go to you just want to start typing in the search box. This is a standard behavior in Many people do it almost mechanically without even looking at the screen. However the translation popup gains the focus and doesn’t let you type. You have to click “Nope” or press “Esc” key on the keyboard so that the page regains the focus and you can type again. Note: as one reader reported, while the popup is open many other keyboard combinations on the browser level don’t work either. For example CTRL+W doesn’t close the tab.

Baidu in English Google Chrome

Baidu in English Google Chrome

Unfortunately this awesome language aid creates a bad user experience on many websites. The only options that are available for preventing this UX issue is to disable translation on the entire site or for that particular language altogether. But that’s not good if for example you are learning that language and still want to have some help when you need it. Besides there is a hidden tax: Chrome analyses every page upon load to guess its language and see if it needs translation. This costs an extra CPU usage and battery life for every single page (not a good thing on mobile devices). If you click “Nope” and visit the page again (or just refresh it), the stupid popup is going to ask you the same question again like you never rejected it a few seconds ago. Yup! Computers are stubborn, specially when programmed carelessly. It’s ironic that in an age where popup blockers are a built-in feature of the web browsers, they return even more annoying. Check out the comments on this post and Hacker News to see that people have actually left Chrome for its rivals just because of these UX issues.

Never translate this site or language

Never translate this site or language

Another examples: Try searching prices on (Sweden’t Pricerunner) and you have to pay that popup tax before you can do anything on the page. This annoyance appears in almost every interactive website that is in another language.


The UX wasn’t better before. There was a yellow bar at the top of the screen that asked if you want to have the page translated. This made the page jump a little to the bottom (to make space for that yellow bar) right after it was loaded. This visible jump was annoying. For example if you were going to click a button or link before Chrome found out that this page is in a different language, the page would jump right before you click the button. This special sequence of events may not sound very likely but has happens a lot. For example when a user is a regular visitor, his/her brain remembers where to click (for example navigation bar, menu or links) but this sudden jump makes it harder for the motoric part of the interaction and slows it down. This creates the perception that Chrome is slow even though it was just the language detection feature that took place after the page was loaded. The new interaction model with popup solves that problem. However the yellow bar still exists on the Chrome for mobile browsers (Chrome UX designers figured there was something off with it, so they changed its color to white probably to make it less distracting! Didn’t it help?).

Chrome mobile translate

Chrome mobile translate


Add an option to disable this proactive popup approach.

Let the users choose if they want automatic translation

Let the users choose if they want automatic translation

There is a similar setting under Settings > Languages (hidden under advanced settings):

Chrome Settings > Languages

Chrome Settings > Languages

This checkbox can be selected by default to comply with the current behavior of Google Chrome (occasional users of this feature will not be bothered to leave it selected). But when the user deselects this checkbox, Chrome should give up on guessing the page language every single time. Though the translation icon will be right there if it’s needed (see image below):

The translation button is still there

The translation feature is still there

If the user chooses “Nope” on a page, please remember this answer and don’t ask on every single load. The popup has a little tiny arrow at its top that makes it clear where it is coming from. User will be able to translate the page when needed. If usability tests show otherwise, add a “translate” menu item to the page menu right after “Find…”.

The translate menu in Google Chrome

The translate menu in Google Chrome

PS. one of the readers kindly suggested that such workaround already exists on Chrome. All you have to do is to disable translation altogether (using the aforementioned Settings > Advanced Settings > Languages) and whenever you want to translate a page, just right click and choose the translate menu item as shown below:

Chrome has a page-wide translation menu already

Chrome has a page-wide translation menu already

What is your experience with Google Chrome’s translate feature?

PS. If you’re from Google, take a look at the comments in Hacker News and help us reach the right people to fix this problem.

Google’s Response

This post got a lot of attention (10,000+ views) and fortunately it was noticed by Google engineers. Here is their comment:

I’m Kenji Baheux on the Chrome team and have been overseeing this feature with our UX team.

Please accept my apologies for the trouble. We’ve been listening and are making the following changes:

1. we won’t show the infobubble and rely on the omnibox icon if the focus is on an editable field. (fixed in M36)

2. the infobubble will stop stealing the focus: you will be able to type, perform shortcuts, scroll the page and so on.

3. we are experimenting with the idea of never showing the infobubble again and solely rely on the omnibox icon as soon as we observe more than X negative actions within a given timeframe T (starting with X=2; T=24h)

4. A few other adjustments around the “translated” infobubble (e.g. will not be shown for automatic translation, will not show up if the “translating” infobubble has been dismissed).

I’m eager to hear additional feedback and would appreciate if you could play with the feature in Canary as we land the different changes.

Adobe is really persistent about updating


Adobe Acrobar reader has this update dialog that shows up every now and then. The dialog has a Yes and No button but that’s just an illusion. The No button is practically not clickable and not focusable! But if you keep clicking on it eventually the dialog disappears. This has happened several times and every time I have to press the No button harder! So I decided to take a snapshot, blog about it and contact Adobe regarding this issue.

Adobe Acrobat update dialog

Adobe Acrobat update dialog

I personally don’t like it when a part of the system is aggressively asking for update. Particularly when it is Adobe. We haven’t forgotten Flashback, one of the biggest Mac security issues. I know the virus wasn’t made by Adobe, but when an application trains the user’s mind that it needs to be updated often, that very user experience will be an easy target for hackers.

Even though this dialog has a No button, Adobe is actually forcing you to press Yes. It’s not nice. It’s not intuitive. It’s not respectable. It’s annoying.


There are three solutions to this issue:

  1. First of all, improve the quality of your software to reduce the number of updates. There are many applications on a system. If each of them wants to update every now and then user experience will reduce. Remember: no one buys a computer for the purpose of updating it. People buy a computer to have some tasks done (work or game or whatever). Don’t get in their way, even for seconds.
  2. Do the updates automatically behind the scene. I really like the way Google Chrome updates itself. It’s very subtle. It’s polite. The menu icon will glow to indicate an update. The update will automatically install on your next browser lunch. It remembers the tabs and goes exactly to the state it was before the upgrade. That’s good user experience.
  3. The least you can do is to make the No button clickable. The very fact that there is a button that only works when someone is punching it angrily shows Adobe user experience designers either don’t feel responsible, or don’t care for the user’s peace of mind.


Adobe’s Flash update window shows unnecessarily too often. Maybe I’m an exception, but I haven’t bought my computer for spending time updating system software. I happen to own a copy of Cretive Cloud as well. Adobe updates happen so often that sometimes I think updates are being pushed for the sole purpose of advertisement.

Adobe Flash Update Screen

Adobe Flash Update Screen

Emacs has a confusing save dialogue box


For those of you who follow this blog, you may have noticed that I was not very active for the past couple of months. I had to relocate to a new place and there’s been a lot going on in my personal life (a lot of good things of course). Anyway, now I’m back and I’m trying to blog about the pile of images that I’ve gathered during this time (about 30+ so expect a lot of posts).

About 5 months ago, my boss who knows I write about usability, sent me a photo of save dialogue box in Emacs complaining why it is so stupid?! Without further ado here is the image:

Emacs save dialogue on Ubuntu Linux

As you can see it has 7 buttons:

  • Yes: saves the file in the suggested name (default action)
  • No: cancels the save action
  • View This Buffer: cancels the save action and makes sure that the window to view that specific file is visible
  • View Changes In This Buffer: cancels the save action and asks Emacs to show you what has changed in the file since last save.
  • Save This But No More: tells Emacs to save only this file but not the rest of the files
  • Save All Buffers: this button can be used to save several files. In this case, there’s only one file so it’s inappropriate to pollute the UI with an option that doesn’t even make sense. It is the same as “no” button for one file.
  • No For All: it is used for not saving any of the changed files. Same as “Save All Buffers” button this is unnecessary for when there is just one file.

Why is it bad? Because there are too many options, half of them are useless or do similar things as the rest! It is just a polluted user interface which confuses the user. One may argue those who use Emacs are used to this level of complexity and in fact they like the “flexibility” that it provides. But my boss is not a novice user. He has created a Linux based operating system from scratch and have been developing C applications for 25+ years and works with Linux on a daily basis (in fact his 7 year old son, terminal and bash scripts in Linux!). So if he can’t get it, who else would? And guess what? He’s not the only one. Jono from Not User’s Fault has also written about it.


This is how I would design that dialog box:

Emacs save dialogue solution

Here is the changes and the reasons:

  • Only two buttons: action is clear: save! with two answers: yes and no! If there are multiple files, this dialog can appear for each of them mentioning that individual file name (for example Dreamweaver works like that).
  • The Yes button is slightly bigger than the No button and is pre-selected (as the orange outline around it suggests). The reason the Yes button is more dominant is because probably the reason the file is changed is because user has spent some time editing it. So it’s safer to pre-select Yes instead of No. This is the only thing that I haven’t changed from the original design. However, I made the buttons bigger so that it is easier to click them. Not everyone is super quick with targeting a button with mouse. If there’s more space, give more of it to users for convenience.
  • The title of the dialog box is changed to represent what is happening. This dialog appears right before the user quits Emacs so the verb would be “Quitting” and the name of the application which is “Emacs”. The original title “Question” is not very descriptive. Of course it is a question. A modal dialog which has a question mark at the end of its message and doesn’t close until you press a button is a question for sure! Use every pixel to show something necessary to the user without polluting the interface with visual noise.
  • A save icon is added. It’s not only for aesthetics. Many people don’t read the dialog boxes but they can identify icons with a glimpse of an eye. And even though many younger users haven’t even seen diskettes, the save icon in most applications is presented like that. It has a different color here to make it stand out, but it can as well be gray or black (which in my personal opinion is boring).
  • The (X) button is removed from the title bar of the dialog box. I find that quite cryptic when I see it in a dialog box because the (X) button means “Close”. So when a dialog box appears and the user presses “Close”, what does really happen? Is it equal to pressing the No button? Does it “force quit” the application? Does it delete the file? How about being clear and providing a verbal description? Because this (X) button is indeed different from the (X) button on the main window of the application. This one merely cancels the quitting action (didn’t guess that ha?). That’s why I have the “don’t quit” on the window. It is not a very dominant action because most users answer the dialog with Yes or No instead of canceling the Quitting process. But anyway, it’s there if someone needs it. It looks like a link but it behaves same as a button. Why link? because after clicking it, the user will “go” somewhere: to the main application window.
  • A suggestion for a better UX: if there are more than 5 unsaved files, a smart design will show a checkbox that says “Do the same with the rest of the 17 files” (assuming there are 17 unsaved files). So if the user checks that checkbox and press yes, all 17 files will be saved and no dialog will be shown for each of them. If the user checks that checkbox and presses no, none of those 17 files will be saved.

And finally I’d like to close this post by words from Jono discussing why even open source project like Emacs still suffers from these usability issues instead of receiving fixes from people:

“It’s open source, so you could, theoretically, change the behavior”, while true, is not generally a constructive response to usability criticism. People with both UI design skills and coding skills are rare. Most people with usability feedback for any given project are not going to be coders. If your project’s response to usability feedback is “show me the code or get lost”, then you’re taking potentially valuable feedback and throwing it in the trash. Over time, the project teaches people not to bother trying to help unless they’re coders. And then it misses out on the best chance to improve its usability.

(the save icon is taken from IBM’s website)

Emac’s Response

This blog is not about nagging, so just like many other posts, I tried to contact the developers ( to hear their words. Unlike PuTTy, the Emac community seems to be quite open minded and active. It is now registered as bug#12635 and within a day I received 3 replies and changed the design accordingly. First let’s see the suggestions:

Eli Zaretskii ( suggested:

IMO your suggested dialog goes too far in the other direction: it removes useful options.

It is possible that the options to view the file’s buffer and to review the changes should be renamed, e.g.  “Do not save and show the changes” or some such, or maybe the layout should be changed.  But removing the options because “users can only cope with 2 at most” is not the best idea.

Likewise with “Save This But No More” and “No To All” and “Save All Buffers” (which perhaps should be relabeled “Yes To All”).  These are useful when saving several files, and should appear then.

Can you suggest a better design that leaves the options available?

Andreas Schwab ( suggested:

The latter two should probably be replaced by a check box “use this answer for subsequent questions”.

Juri Linkov ( suggested:

The most user-friendly UI would tell the user what pressing the button will do exactly.  So instead of buttons “Yes”/”No”, it would display more explicit text in buttons: “Save”/”Don’t save” or “Save”/”Discard”.

OTOH, Emacs is special in this regard that actions in the dialog box have their counterparts in the non-GUI version where “y” and “n” are keys to save or skip the buffer.  With the goal to maintain compatibility between these two versions, the GUI version could provide accelerator keys in the button text like “_Y_es” and “_N_o”.

But in case when these versions will diverge from each other, and also for the final question:  Modified buffers exist; exit anyway?

still more explicit “Yes, discard changes”/”No, cancel” or “Yes, close without saving”/”No, cancel” would be better.

“Don’t quit” to cancel the dialog is very necessary, yes, but a link in a dialog box a quite non-standard element. Much simpler would be to just add the button “Cancel”.

Removing the option “View This Buffer” could be accompanied with displaying the buffer in question unconditionally (this suggestion pertains to the non-GUI version as well).

Regarding the multi-file operation, some applications solve this problem by displaying a list of all unsaved files to help the user decide what to do with all of them.

Emacs already does the same for running processes by displaying their list and asking a simple question: Active processes exist; kill them and exit anyway? “Yes”/”No” I wonder why not to do the same for unsaved buffers?

Some of the suggestions were inspiring and some need more elaboration. In general Emacs is knows as one of the most featureful editors in the market so it’s understandable why developers are hesitant to remove features. I created various designs and went through them using heuristic evaluation to find the optimum interface.

A better solution is a hybrid solution. When less than 3 files (I’ll discuss later why 3 is the optimum number) are changed, show this dialog to for every file:

Suggested save dialog for Emacs

The cancel action now is on a button. The text on the button indicates clearly what it is going to cancel, but it is possible to say just “Cancel”. It is demonstrated in the final design at the bottom of this post. The save icon was upside down in the IBM version. I chose a better icon (from that shows the diskette the correct way. There’s also an icon on the Yes and No button with widely used colors for positive (green tick) and negative (red X). A shortcut indicator is added for every button. Also a help button is added at the top. When user clicks on the help button the mouse will have a question mark next to it. Then when user clicks on a button, a little help window shows more description about what that button does. However, everyone who has worked with computers for a while should be familiar with the concept of saving a file. So maybe the help is not really needed if it is too hard to implement.

And when the number of changed files is more than 3, show this dialog:

Suggested save dialog for Emacs when multiple files have changed

By default all the checkboxes are set. User can manually uncheck the files that should not be saved. However the background of the files turn red to indicate a warning . When all the checkboxes are selected, the checkbox next to the “Save” title is also checked. In fact user can use that checkbox to select or unselect all other checkboxes at the same time (something like select all functionality in GMail inbox). Just like the single dialog this one has help, icons and colors. It is possible to resize the headers and scroll the list to see more file names.

The advantage of this method to the current Emacs dialog is that it shows the list of files which are changed. Currently when the user clicks on “Save All Buffers” or “No For All” he may not remember the name of all of those files. Maybe there’s a couple of files that he doesn’t want to save but the rest should be saved.

Now why this dialog should be shown for when more than 3 files have changed?

  • First of all the multi-file save dialog box is less common than the single-file save dialog. So instead of exposing the user to unwanted complication, we try to show the simplest dialog possible. Users don’t mind clicking the save button or the shortcut (ALT-Y) for a few times, but more than that needs a slightly more complicated interaction design (multi-file save dialog).
  • When more than 3 files are changed, the multi-file save dialog needs less clicks and takes less reading. Let’s say 4 files are changed and half of them (2 files) should not be saved. With the first dialog, user should read 4 messages and make a decision and press two different button combination based on every decision: ALT-Y or ALT-N. With the multi-file save dialog, user un-ticks 2 of the 4 items and clicks Save button or presses ALT-S. It is 3 clicks and the interface is much easier to understand for repeated interaction model.

Since the user may see any of these two interaction models, we can make it simpler by assigning the same shortcuts for the save button. In that case the single-file save dialog looks like this:

Single-file save dialog with ALT-S shortcut

User may need to take a look at the file before saving. In that case both dialogs supports this interaction:

  • In single-file save dialog if the user is not certain about saving or ignoring the changes, he can press “Cancel” and Emacs should immediately show the file in question.
  • In multi-file save dialog if the user double clicks on a file name, the save dialog box cancels and the file that was double-clicked immediately shows up.

As a side note: this is another design idea that I came up with but it was unnecessarily complicated and crowded:

Emacs multi-file save dialog with radio buttons

I have never thought of Emacs as the most user friendly editor because of its steep learning curve, hidden shortcuts and the fact that it is initially designed for text-based interaction and then ported to the graphical environments. However, it is one of the most featureful editors with a modular design, great extensibility and when you learn the basics it is extremely efficient to work with. Some of the great code gurus that I’ve had the honor to meet used Emacs as their number one editor.

In interaction design we differentiate between power users and casual users. Power users use the software more often than casual users and have the knowledge and training necessary to work with it efficiently, but casual users occasionally use the software and usually get annoyed when they don’t get it. IMHO Emacs is more of a power-user tool and if an interaction flow is too complicated and there is no way to make it simpler, maybe it should not be changed. Meanwhile casual users can use Ecplipse, Notepad++, TextEditor or even Notepad. Nevertheless, I still think the current file save dialog of Emacs is the tip of the ice burg of how many usability “issues” there might be for casual users while power users are used to the way things are and don’t want any change. The final decision is up to the architects of Emacs based on what they think describes their users the best: power users vs. casual users.

Here is the final design:

Emacs save dialog suggestion


1 day later I received an email from Jason Rumney ( who mentioned an important point:

You have some good ideas, but they seem to be based on a misconception that each dialog in Emacs is individually designed.  That may be the case with other applications, but is not with Emacs.  Currently Emacs dialogs are quite limited in their capabilities, so the best approach is probably to split this task into two:

1. Improve the options availble in the current dialog.
2. Improve Emacs’s dialog capabilities (a much bigger task, especially if backwards compatibility is to be kept).

So maybe fixing this usability issue needs more resourced, but does it worth it? What do you think? Please share your thoughts in the comment section.

Oovoo annoys the user with unwanted noisy advertisement


Oovoo is a video call application which claims to be very popular. However, if unwanted advertisement had a score, Oovoo would be one of the top-10 with the most annoying way to advertise. It starts with a splash screen which no matter if you click “Don’t show again” or not, it will appear next time the application runs (is it an intentional bug)?

oovoo annoying ads - splash screen

Then comes the main window of the application which has two places for advertisement:

Oovoo advertisement in main window

Please pay attention, there is actually one sidebar dedicated to advertisement! Fortunately the user can close it. Roughly 30% of the screen real estate is devoted to advertisement. Oovoo claims to be a rival of Skype saying “8 out of 10 Skype users prefer Oovoo”:

Oovoo claims 8 out of 10 Skype users prefer Oovoo!

I guess I’m one of those 2 people who prefers Skype over Oovoo. You know why? Because of super-annoying advertisements which has sound and appears while in a video call. Yes, you heard it right! In the middle of a video call (or voice call), you may hear strange voices which comes from the Flash advertisements that Oovoo shows to you. The first time I encountered this issue, I was in the middle of a call. I had to turn the volume up because I could hardly hear my friend. Suddenly I heard a loud scary sound of car engine, then there was shooting and screaming. It was like the sounds from a war movie. The person who was talking to me thought that I am starting to watch a movie in the middle of the conversation. I couldn’t find the source of this annoyance. I closed my browser windows and checked the TV. None of them wasn’t showing a war movie. Then quite surprisingly I found out it is a little advertisement banner on the very same window that is used for the video call!

Annoying advertisement from Oovoo while a video call is in progress

If you have several windows with advertisement open (almost all Oovoo windows), sometimes the noise from advertisements can play at the same time and sound like a mess! For example even this chat window has advertisement:

Oovoo advertisement in chat window

And here is the video chat room window. So basically all the windows of Oovoo have some sort of advertisement:

Oovoo advertisement in video chat room

And remember all of those red rectangles in the above pictures can contain advertisement in Flash, that means annoying animation, unwanted sound and stealing your bandwidth which can reduce the user experience while in a video call: the main purpose of installing the application!


First of all: don’t be evil. Don’t force people to see what they don’t like to. If you are talking to another person, you don’t want to be distracted with annoying advertisement whether it is noise or flashy animation. I am not a Skype employee but I use it a lot. Skype has its own problems and that is why I decided to try an alternative. It would be really interesting to know where Oovoo has done its market research where 8 out of 10 people prefer it over Skype? Probably in Oovoo headquarter office in New York.

I recommend not using any sort of advertisement while user is in a call because:

  • They are already engaged in an activity and unless it is boring to death, they will not pay attention to distractions so there is no point in showing an ad that doesn’t have a good chance of being paid attention to
  • Users are ad-blind. That is: their brain automatically filters flashy animations and colors which look like an ad.

Oovoo probably earns some money with advertisement. But I would not pay Oovoo for advertisement. I don’t want my brand to be associated with annoying and interrupting advertisements in the middle of people’s conversations.

The last solution is: if Oovoo really really has to show advertisement, make sure the ads respect a few standards:

  • They don’t play any sound at all: in a video or voice call application, sound is a part of the user experience.
  • They are not flashy: no one likes to have a blinking flash light under their TV. So don’t put flashy animating ads under a video call.
  • They are not heavy in term of network usage: many users don’t have fast internet. Their bandwidth better be used for the higher quality of voice and video rather than ads.
  • They are not CPU-hungry: some of the ads are games like point and shoot or even play music. Many people use a small laptop or netbook to connect to others while on a trip. Utilize that little CPU power for calls not ads.

Oovoo’s response

I contacted Oovoo’s support team pointing out to this issue. They replied within one day as promised on the Oovoo support page. Here is what they said:

…We do serve third party advertisements but they are prohibited to run audio; it is extremely intrusive as you noted.

… We will reach out and have it removed right away

…We offer a lot of services for free and as a businessman I’m sure you understand that these services cost us money to support; we cannot offer these features without advertising.

…This summer we are making additional changes to further enhance the ooVoo experience, at no cost to our customers.

We do not run ads without conscience. Our Director of Advertising created strict criteria for the content and proactively blocks the below listed ads. And because we are worldwide, we rely on our users to tell us if they are seeing something that is out of line or running audio.

  • Adult /Provocative/ Suggestive Ads
  • Non-Premium Dating sites
  • Non-user initiated Audio Ads
  • Expandable Ads
  • Gambling
  • Shaky or Flashy Ads
  • Survey Pops
  • System Warning / Window Box ads
  • Anything deemed to be offensive to our users

Well I appreciate Oovoo’s attention to user feedback but I didn’t see any link or button under the ads that reads “Report Ad”. Moreover during the installation and after it, I wasn’t informed that I can report those kinds of ads. By the way, I have seen ads about gambling in Oovoo and I guess that should be easy for the “Director of Advertising” to spot them. My overall impression of Oovoo is: they have good support team, bad advertisement team, amateur user experience designers, good programmers and high video call quality. So who knows, maybe a Microsoft rival will buy them and refurbishes the user experience and then we can all happily use it as a serious alternative to Skype. But till that day, Oovoo has a lot of work to do in my humble opinion, specially on the user experience.

Microsoft Internet Explorer caches Ajax calls


This one came to be as such a big surprise that I had to Google it several times to make sure it is not my own mistake.

A little bit of background for those who are not web developers: traditionally the contents of the HTML pages did not change once loaded into the browser. Ajax is a technology that allows Javascript to load small pieces of data from the server and change the HTML page without re-loading it. Ajax is a very common technique that is used in most web sites from Facebook to GMail and even mobile web sites. In simple language, it is something similar to RPC (remote procedural calls in C) or RMI (remote method invocation in Java).

Today I was debugging one of my latest web applications. It has some controls that allows the user to set some parameters on the server:

GUI of my web application uses Ajax

It works in every browser except IE. Tracing the network packets, I realized that setting a parameter works. It is getting the parameter that has a problem. Every time the interface asked the server for the latest status, it returned an old value (ie. the value before the parameter was set). One of the craziest guesses I had was that this old value is coming from some sort of cache! And it turned out to be true! It means every time Javascript wants to update the page, Internet Explorer fools it by returning a cached result instead of actually sending the request to the server. As a result, the page will be “updated” with old data.

See what other developers wrote about it:

I was tearing my hair out trying to work out the cause of this problem… (Jeremy Epstein)

Strictly speacking IE caches Ajax GET requests, therefore making all your web2.0 tricks effortless! (Daniel Vecchiato)

This can be a nightmare to deal with, as you cannot ask all users of a web site to change their browser settings. (Dan Nye)

I’ve never encountered a case where I want ajax to NOT contact the server. (Dean Moses)

Since it is a really frustrating “design feature” of Microsoft IE, I decided to write about it here. This aggressive solution apparently tries to improve the speed of Internet Explorer but it doesn’t help the infamously slow browser. In fact this solution to speed up a browser is like putting two virtual reality LCDs instead of a car’s windshield and simulate a fast moving car by showing movies of driving in fast road. The car’s engine is so weak that it cannot even drive in standard roads! Microsoft should realize that in the world of free speedy real cars, users would hardly choose a virtual reality one, even if it comes pre-installed in their garage when they buy a home!


The best solution for Internet Explorer team is to follow web standards. If you cannot interpret standards, cheat! Just check how open source browsers like Firefox implement it and follow their lead. It’s the only case where cheating hurts less than not cheating!

Various web developers have suggested workarounds for the issue. Check out the links of the quotes above. There are mainly 3 solutions:

  • add a timestamp as an extra parameter to every request so that IE thinks it is a different request and doesn’t load it from cache. Of course the server ignores this parameter.
  • use “POST” requests instead of “GET”. Apparently IE just caches GET requests.
  • the server response can add a header to the response that explicitly asks the browser not to cache it.
  • for debugging purpose it is possible to ask IE to behave “normally”:

Telling IE to behave like other browsers and not to cache Ajax

Spotify loves to use your Facebook wall as an advertisement board


Spotify is an online music streaming software. I like Spotify but there’s nothing worse than a software that cheats you. I’m writing this after seeing people discuss about how Spotify misuses their trust and advertises on their wall. Even though music may not be directly related to social media, Spotify figured out a way: share your latest music discoveries with your friends in order to make your friends curious about what you are listening. There is only one problem: how to get the users trust a music application with their social network? The answer is: advertisement! Spotify shows a big Facebook button on the main user interface all the time with a message that makes the user curious.

When you click that button, a standard Facebook authentication window opens and asks if you want to give access to Spotify Facebook application and that’s how the story begins. Spotify starts reporting the songs you listen on your wall so that your friends can see:

When others click on a song, they will be asked to install Spotify. Smart way to advertise! Sounds like a win-win situation: you show off your taste of music and Spotify finds a chance to attract your friends. Well, not exactly. If you care about your privacy, it can be a big problem. Imagine you are heartbroken and listen to Bonnie Tyler’s It’s a heartache and some similar songs. It’s almost as telling everyone in your friend list what mood you have. Now it might not be bad to share your mood with your friends, but many have people in their friends who they are not comfortable with them to share emotions. Music and emotional mode are connected. Spotify shares not only your songs, but also your mood.

Moreover it allows others to see what music you are listening in real time:

You don’t want to be judged by others because of certain types of music you listen, do you? Specially if you are a fan of not-so-popular song or artist, there is a big chance that others may prejudge you. You may not care what people say which is a good thing, but still Spotify shares too much information which makes such unnecessary prejudices more likely.

So, maybe after trying Spotify Social you decide it’s not your cup of tea and want to uninstall it. This is what happens if you remove the Facebook app:

Spotify constantly shows that annoying red error message bar at the top of the main user interface like it doesn’t understand how to deal with this very unlikely error! Also those “Loading…” messages constantly keep animating on your screen till you try to fix it, even if it means installing Spotify again!

A good error message is descriptive, and shows a solution. “Failed to enable Spotify social” doesn’t have these characteristics. It doesn’t even use the word “Facebook” so it takes a while to figure out what is wrong. It doesn’t offer any solution either. Should the user go to Facebook and do something? Should the user click on the message bar and do something? (nothing happens)

In order to solve that problem you have to go to options, click on “Connect to Facebook…” and then disconnect it from here again. Then go to Facebook and remove the Spotify application again. Quite weird, right? Well, I personally don’t believe it’s very hard to fix for a company like Spotify. Here in Stockholm, Spotify promotes itself as Google of Sweden! So they sure have enough programmers and designers to fix such obvious flaws, if they want to.


First of all, don’t publish messages on behalf of the users that they are not OK with it. When installing the Spotify app, it simply informs the user that it will be posting messages on user’s wall. But it never gives the option to the user to turn that off. It shouldn’t be hard to add these options under the settings of the application.

Moreover it should be possible to turn off sharing the music you are listening in real time. If users feel their privacy is respected, they trust the application. Otherwise they will uninstall it as soon as they can. This is probably not what Spotify wants.

Don’t force users to do something they don’t want to. Many users learn by trying. If someone clicks “Connect to Facebook”, let them disconnect from Facebook that easy too. Now it may be argued that the user should have discovered that since he has connected to Spotify via the desktop application, he or she should have figured out that it should be disconnected from the same place. Right! But still many of us get rid of annoying Facebook applications on Facebook! Spotify may show those annoying messages for technical reasons. Maybe it cannot detect between an uninstalled application and a broken connection to Facebook! But whatever the reason, it should handle it gracefully and ask the user if they want to disconnect from Facebook. If the user uninstalls the Spotify Facebook application it should ask if they want to disconnect from Facebook? Or they want to try connecting again.