Try to create a Google account with, for example, a user name "alicesmith" and also a second Google account with a user name "alice.smith".
After you create the "alicesmith" account, if you try to create an "alice.smith" account Google displays a message: "alice.smith is not available."
The Google error message is a trivial bug because it can lead you to incorrectly conclude a third-party already has created the "alice.smith" account.
In fact, the "alicesmith" account owns the "alice.smith" account. Google ignores nonconsecutive dots in a user name, and should probably specify that detail on its "Create An Account" form.
Sunday, October 16, 2011
Thursday, September 1, 2011
Google's Recipes Feature: Some Trivial Bugs
Google has a "recipes" search feature described here:
"Search for a recipe or ingredient (ex: chili, banana bread, lentils). After searching for a recipe or ingredient on Google, select Recipes in the left-hand panel on the search results page. You can filter your results by ingredients, cook time, or calories."
The Google "recipes" feature has several trivial bugs:
Bug #1:
Ordinary searches are better than searches using the "recipes" feature because they A) return a greater number of recipe results, and B) allow you to add contextual keywords to make your searches more precise.
Finding recipes using a standard Google query might require an additional mouse click or two to drill down to the recipes, but the tradeoff of gaining more relevant recipes makes it worth while.
Example #1:
Using the recipes feature
[apple pie]
About 4,630,000 results
Regular Google search
[recipes apple pie]
About 9,760,000 results
Example #2:
Using the recipes feature
[pizza]
About 35,900,000 results
Regular Google search
[recipes pizza]
About 106,000,000 results
Example #3:
Using the recipes feature
[tapas madrid hot spicy inexpensive]
About 1 result
Regular Google search
[recipes tapas madrid hot spicy inexpensive]
About 259,000 results
Example #4:
Using the recipes feature
[smirnoff cranberry twist]
About 1 result
Regular Google search
[recipes smirnoff cranberry twist]
About 147,000 results
Example #5:
Using the recipes feature
[tomato sauce mozzarella olive oil garlic basil oregano fennel pepper]
About 2 results
Regular Google search
[recipes tomato sauce mozzarella olive oil garlic basil oregano fennel pepper]
About 394,000 results
Example #6:
Using the recipes feature
[spanish olive crusted salmon]
About 4 results
Regular Google search
[recipes spanish olive crusted salmon]
About 219,000 results
Bug #2:
When you use the "recipes" feature, a list of ingredients displays with yes/no option buttons. The first part of the bug is that it is not clear what result you get if you do not select either yes or no for an ingredient. Maybe the ingredient will be included in the recipe and perhaps it won't?
However, the main part of bug #2 is that the set of ingredients you can include/exclude is limited and in many instances arbitrary.
When you use the "recipes" feature, a list of ingredients displays with yes/no option buttons. The first part of the bug is that it is not clear what result you get if you do not select either yes or no for an ingredient. Maybe the ingredient will be included in the recipe and perhaps it won't?
However, the main part of bug #2 is that the set of ingredients you can include/exclude is limited and in many instances arbitrary.
When using the "recipes" feature, if you want a list of salad recipes to contain cucumbers, broccoli, and gorgonzola cheese and exclude jalapeno peppers you are out of luck. However, you could run a query for those recipes using a traditional Google search.
Here are the severely limited forced choice inventories of ingredients you can include/exclude from a recipes feature search for [salad] and for [omelette] :
Example #1:
Using the recipes feature search for [salad]:
Ingredients:
spinach yes/no
chicken yes/no
poppy seeds yes/no
dill yes/no
cranberries yes/no
sesame seeds yes/no
mustard yes/no
Example #2:
Using the recipes feature search for [omelette].
Ingredients:
haddock yes/no
watercress yes/no
crème fraîche yes/no
tarragon yes/no
feta yes/no
peppercorns yes/no
cheddar cheese yes/no
chives yes/no
See my earlier post about recipes: http://googcomments.blogspot.com/2008/02/smirnoff-cranberry-twist.html
Sunday, August 21, 2011
A Small Google Search Bug
When you use the + prefix with Google search keywords, Google matches exact literal strings and does not return synonyms. If you search for spaghetti you can get a result for pasta, but if you search for +spaghetti you will only get spaghetti.
Should a Google search using the + prefix return more, fewer, or the same number of results as a search without the + prefix?
Here are a couple of possibilities:
1. The + prefix should return fewer results than the same query without the + operator: The + operator does not return synonyms, so if you search for keywords and their synonyms you should find a greater number of results pages.
2. The + prefix should return more results than the same query without the + operator: If searching for keywords and their synonyms requires more computational power than matching exact literal strings and if Google searches have time-out durations the +prefix keyword searches will return more results for any given amount of computational time.
The small bug is the discrepancy between these results:
1. Single keyword queries: + prefix returns fewer results.
2. Two keyword queries: + prefix returns more results.
Either the number of results feature is incompletely documented, making the metrics somewhat useless, or there's an algorithmic bug.
The examples below use arbitrary search keywords. In almost all cases, the + prefix returns fewer results for single keyword searches, but more results for two keyword searches.
Example #1:
pizza
About 556,000,000 results
+pizza
About 534,000,000 results
bicycle
About 212,000,000 results
+bicycle
About 204,000,000 results
pizza bicycle
About 17,200,000 results
+pizza +bicycle
About 53,100,000 results
pizza OR bicycle
About 727,000,000 results
+pizza OR +bicycle
About 1,440,000,000 results
Example #2:
coffee
About 939,000,000 results
+coffee
About 903,000,000 results
tea
About 756,000,000 results
+tea
About 729,000,000 results
coffee tea
About 75,900,000 results
+coffee +tea
About 120,000,000 results
coffee OR tea
About 1,630,000,000 results
+coffee OR +tea
About 3,160,000,000 results
Example #3:
ant
About 276,000,000 results
+ant
About 269,000,000 results
caterpillar
About 102,000,000 results
+caterpillar
About 99,300,000 results
ant caterpillar
About 6,350,000 results
+ant +caterpillar
About 16,700,000 results
ant OR caterpillar
About 365,000,000 results
+ant OR +caterpillar
About 731,000,000 results
Example #4:
baseball
About 621,000,000 results
+baseball
About 575,000,000 results
football
About 1,400,000,000 results
+football
About 1,290,000,000 results
baseball football
About 321,000,000 results
+baseball +football
About 325,000,000 results
baseball OR football
About 1,860,000,000 results
+baseball OR +football
About 3,610,000,000 results
Example #5:
crayon
About 38,000,000 results
+crayon
About 37,200,000 results
pencil
About 167,000,000 results
+pencil
bout 163,000,000 results
crayon pencil
About 8,260,000 results
+crayon +pencil
About 8,480,000 results
crayon OR pencil
About 399,000,000 results
+crayon OR +pencil
About 398,000,000 results
Should a Google search using the + prefix return more, fewer, or the same number of results as a search without the + prefix?
Here are a couple of possibilities:
1. The + prefix should return fewer results than the same query without the + operator: The + operator does not return synonyms, so if you search for keywords and their synonyms you should find a greater number of results pages.
2. The + prefix should return more results than the same query without the + operator: If searching for keywords and their synonyms requires more computational power than matching exact literal strings and if Google searches have time-out durations the +prefix keyword searches will return more results for any given amount of computational time.
The small bug is the discrepancy between these results:
1. Single keyword queries: + prefix returns fewer results.
2. Two keyword queries: + prefix returns more results.
Either the number of results feature is incompletely documented, making the metrics somewhat useless, or there's an algorithmic bug.
The examples below use arbitrary search keywords. In almost all cases, the + prefix returns fewer results for single keyword searches, but more results for two keyword searches.
Example #1:
pizza
About 556,000,000 results
+pizza
About 534,000,000 results
bicycle
About 212,000,000 results
+bicycle
About 204,000,000 results
pizza bicycle
About 17,200,000 results
+pizza +bicycle
About 53,100,000 results
pizza OR bicycle
About 727,000,000 results
+pizza OR +bicycle
About 1,440,000,000 results
Example #2:
coffee
About 939,000,000 results
+coffee
About 903,000,000 results
tea
About 756,000,000 results
+tea
About 729,000,000 results
coffee tea
About 75,900,000 results
+coffee +tea
About 120,000,000 results
coffee OR tea
About 1,630,000,000 results
+coffee OR +tea
About 3,160,000,000 results
Example #3:
ant
About 276,000,000 results
+ant
About 269,000,000 results
caterpillar
About 102,000,000 results
+caterpillar
About 99,300,000 results
ant caterpillar
About 6,350,000 results
+ant +caterpillar
About 16,700,000 results
ant OR caterpillar
About 365,000,000 results
+ant OR +caterpillar
About 731,000,000 results
Example #4:
baseball
About 621,000,000 results
+baseball
About 575,000,000 results
football
About 1,400,000,000 results
+football
About 1,290,000,000 results
baseball football
About 321,000,000 results
+baseball +football
About 325,000,000 results
baseball OR football
About 1,860,000,000 results
+baseball OR +football
About 3,610,000,000 results
Example #5:
crayon
About 38,000,000 results
+crayon
About 37,200,000 results
pencil
About 167,000,000 results
+pencil
bout 163,000,000 results
crayon pencil
About 8,260,000 results
+crayon +pencil
About 8,480,000 results
crayon OR pencil
About 399,000,000 results
+crayon OR +pencil
About 398,000,000 results
Sunday, July 31, 2011
A Trivial GMail Bug
The bug is that GMail partially uses your customized incoming text filters when you send GMail.
Try this experiment: Create a GMail filter that deletes all incoming emails that contain the word "cat". Now send an email that contains the word "cat".
GMail sends your email, but it also moves a copy of it to your trash folder instead of to your sent email folder.
Try this experiment: Create a GMail filter that deletes all incoming emails that contain the word "cat". Now send an email that contains the word "cat".
GMail sends your email, but it also moves a copy of it to your trash folder instead of to your sent email folder.
Friday, October 1, 2010
Improving Google's Two-Factor Authentication
Google is rolling out two-factor authentication for Google Apps. See these posts:
Here's the Google authentication flow:
1. User: Enters a valid user name and password (something known by the user).
2. Google: Sends an SMS verification code to the user's mobile phone (something the user has).
3. User: Enters the SMS verification code (something the user has) and logs into the Google App.
In my opinion, the Google flow can be improved. I would remove step #2 because it causes a potential latency issue. The Google-to-user phone link is a third-party application that may be unreliable. Latency presents a serious problem if a user needs to access time-dependent information such as a set of medical records.
The Google authentication flow requires three steps. Each step, in my opinion, should correspond to a single authentication factor. Currently, the "what the user has" factor requires steps #2 and #3.
The solution I suggest is to send the next SMS immediately after the user logs out of the application. Under this scenario, the user actually has the SMS instead of waiting until Google sends it in real time during a login attempt.
As a backup, and in case the user misenters the verification code, the verification code screen should also contain a "Send new verification code" button that displays if the user enters a correct user name and password.
Here's the Google authentication flow:
1. User: Enters a valid user name and password (something known by the user).
2. Google: Sends an SMS verification code to the user's mobile phone (something the user has).
3. User: Enters the SMS verification code (something the user has) and logs into the Google App.
In my opinion, the Google flow can be improved. I would remove step #2 because it causes a potential latency issue. The Google-to-user phone link is a third-party application that may be unreliable. Latency presents a serious problem if a user needs to access time-dependent information such as a set of medical records.
The Google authentication flow requires three steps. Each step, in my opinion, should correspond to a single authentication factor. Currently, the "what the user has" factor requires steps #2 and #3.
The solution I suggest is to send the next SMS immediately after the user logs out of the application. Under this scenario, the user actually has the SMS instead of waiting until Google sends it in real time during a login attempt.
As a backup, and in case the user misenters the verification code, the verification code screen should also contain a "Send new verification code" button that displays if the user enters a correct user name and password.
Thursday, September 9, 2010
Improving The Google Instant Feature
Google Instant is a new search feature that automatically returns pages of search results as a user types partial (e.g. "c") and complete (e.g. "cat") search keywords. See the Google blog post, Search: now faster than the speed of type.
Currently, Google Instant displays search results only for the topmost entry on the Google Suggest drop-down list. If you search for "cat" or "car" or "computer" and type "c", Google displays a results page consisting only of "craigslist" entries.
"Craigslist" is the Google search prediction for users who begin Web searches with the letter "c".
In my opinion, Google Instant could be improved by displaying the search results page in sections.
If the search results page displays 12 entries, the first 3 search results could be for "craigslist", the next 3 for "CNN", the next 3 for "chase", and the last 3 for "costco". These sections correspond to the first 4 Google Suggest entries, instead of only to the highest Google Suggest entry.
When a user wants to view search results only for the topmost Google Suggest entry, the user can click Search or hit Enter.
Currently, Google Instant displays search results only for the topmost entry on the Google Suggest drop-down list. If you search for "cat" or "car" or "computer" and type "c", Google displays a results page consisting only of "craigslist" entries.
"Craigslist" is the Google search prediction for users who begin Web searches with the letter "c".
In my opinion, Google Instant could be improved by displaying the search results page in sections.
If the search results page displays 12 entries, the first 3 search results could be for "craigslist", the next 3 for "CNN", the next 3 for "chase", and the last 3 for "costco". These sections correspond to the first 4 Google Suggest entries, instead of only to the highest Google Suggest entry.
When a user wants to view search results only for the topmost Google Suggest entry, the user can click Search or hit Enter.
Wednesday, September 1, 2010
Several Trivial GMail Bugs
You can see these trivial bugs here: GMail Inbox -> Show search options -> Date within field. As an arbitrary example, in the "Date within" field specify "Date within 3 days" of "9/1/10". Click "Search Mail".
Note: The current date is 9/1/2010.
Google runs the query and displays this spurious message: "after:2010/8/29 before:2010/9/5".
Here are the bugs:
Bug #1: "before:2010/9/5" is a bug because Google's Gmail cannot run a search into the future side of the stated time range.
Bug #2: "after:2010/8/29" is also bug because "Date within 3 days" of "9/1/10" should include the current day and the 3 preceding days. After 2010/8/29 suggests 1) 2010/8/30 and 2) 2010/8/31 which is a 2-day, not a 3-day range.
Bug #3: Although the query message says "after:2010/8/29", the results actually include emails received on 2010/8/29. The fix would be to change the word "after" to "from". The "before" part of the message should be deleted when it involves future days.
Bug #4: The Gmail query message label: "after:2010/8/29 before:2010/9/5" uses a yyyy/m/dd date format. Though not incorrect, mm/dd/yyyy or dd/mm/yyyy formats are more typically used.
Note: The current date is 9/1/2010.
Google runs the query and displays this spurious message: "after:2010/8/29 before:2010/9/5".
Here are the bugs:
Bug #1: "before:2010/9/5" is a bug because Google's Gmail cannot run a search into the future side of the stated time range.
Bug #2: "after:2010/8/29" is also bug because "Date within 3 days" of "9/1/10" should include the current day and the 3 preceding days. After 2010/8/29 suggests 1) 2010/8/30 and 2) 2010/8/31 which is a 2-day, not a 3-day range.
Bug #3: Although the query message says "after:2010/8/29", the results actually include emails received on 2010/8/29. The fix would be to change the word "after" to "from". The "before" part of the message should be deleted when it involves future days.
Bug #4: The Gmail query message label: "after:2010/8/29 before:2010/9/5" uses a yyyy/m/dd date format. Though not incorrect, mm/dd/yyyy or dd/mm/yyyy formats are more typically used.
Saturday, August 14, 2010
Some Chrome Browser Bugs
These bugs are caused by Chrome setting up a dependency on Microsoft third-party software. Chrome shares the IE browser's "Internet Properties" dialog box.
In Chrome, click the wrench icon then Options -> Under the hood -> Change Proxy Settings. The IE Internet Options dialog box displays. [Hard to believe.]
Note: The Mozilla FireFox browser avoids this dependency.
Environment:
In Chrome, click the wrench icon then Options -> Under the hood -> Change Proxy Settings. The IE Internet Options dialog box displays. [Hard to believe.]
Note: The Mozilla FireFox browser avoids this dependency.
Environment:
- Up to date Chrome 5.0.375.126
- Up to date IE: 8.0.7600
- Up to date FireFox: 3.6.8
- Up to date Windows Pro 7
Bug #1 (security):
A malicious exploit specifically targeted at IE browsers that changes internet option parameters will also adversely affect Chrome's shared internet option parameters. For example: 1) Reducing browsing security levels, 2) Allowing active content to run, 3) Changing how the browser connects to the internet.
Countering these exploits against IE and Chrome may require an IE patch or update.
Bug #2 (security):
Bug #2 (security):
IE users in multiuser computer situations (cafes, classrooms, libraries) can reduce the browsing security level of Chrome users and vice-versa.
Bug #3 (security): Chrome browsers running on Windows computers do not support SSL3.0/TLS1.x encryption.
Bug #4 (security and usability): A Chrome user can try to change features that Chrome does not support in the internet parameters dialog box. For example: IE InPrivate browsing, SSL3.0, TLS1.x.
A user connecting with Chrome to a site requiring SSL3.0 will get an error message even though SSL3.0 is selected in Chrome.
Bug #5 (security and usability): Under the internet properties "Advanced" tab there are several features marked with asterisks (*). A label notes that "* Takes effect after you restart Internet Explorer".
Question: Does a Chrome user who changes one or more * features need to open and close an IE browser session to activate the options in Chrome? From the Chrome GUI the required user behavior is completely unclear.
Bug #6 (security and usability): Chrome displays some duplicate parameters that are separately and inconsistently configurable. These duplicate parameters include configuring: 1) a start page, 2) auto-complete forms and passwords features, 3) a default browser.
Bug #3 (security): Chrome browsers running on Windows computers do not support SSL3.0/TLS1.x encryption.
Bug #4 (security and usability): A Chrome user can try to change features that Chrome does not support in the internet parameters dialog box. For example: IE InPrivate browsing, SSL3.0, TLS1.x.
A user connecting with Chrome to a site requiring SSL3.0 will get an error message even though SSL3.0 is selected in Chrome.
Bug #5 (security and usability): Under the internet properties "Advanced" tab there are several features marked with asterisks (*). A label notes that "* Takes effect after you restart Internet Explorer".
Question: Does a Chrome user who changes one or more * features need to open and close an IE browser session to activate the options in Chrome? From the Chrome GUI the required user behavior is completely unclear.
Bug #6 (security and usability): Chrome displays some duplicate parameters that are separately and inconsistently configurable. These duplicate parameters include configuring: 1) a start page, 2) auto-complete forms and passwords features, 3) a default browser.
- Start page: You can set duplicate home page parameters that are different. Set the first value in Internet Properties -> General Tab -> Home page. Then set a different home page here: Options -> Basics -> Home page. Chrome will use the value you set here: Options -> Basics -> Home page, ignoring the home page value you set under internet properties. However, the value you set from Chrome under internet properties -> Home page will change the startup page for any IE users on that computer.
- Auto-complete forms and passwords: You can set this feature inconsistently in two places. Set the first value under Internet Properties -> Content -> AutoComplete -> Forms and User Names and Passwords on Forms. Then set inconsistent values in the duplicate fields here: Options -> Personal Stuff -> Passwords and Form Autofill. Chrome will use the values you set here: Options -> Personal Stuff -> Passwords and Form Autofill, ignoring the values you set under internet properties. However, the values you set from Chrome under internet properties -> Content -> AutoComplete will take effect for IE users on the same computer.
- Default browser: I have FireFox as my default browser. In Chrome, if I go to Basics -> Default browser it says: "Google Chrome is not currently your default browser. Make Google Chrome my default browser." In Chrome, if I go to Options -> Under the hood -> Change Proxy Settings -> Internet Properties -> Programs -> Default web browser it says: "Internet Explorer is not currently the default browser. Make default."
In my opinion, the above set of problems should be assigned the following bug severity levels:
- Security: between medium and high
- Usability: critical
Sunday, August 8, 2010
One Trivial, One Small, And One Large Chrome Browser Bug
A couple of days ago, I downloaded Chrome.
Bug #1 (trivial bug):
I downloaded Chrome from a Google US download page, and ran the setup file expecting the Chrome GUI to be in English. Instead, the Chrome GUI was localized by my IP address so the GUI language was non-English.
This wouldn't be a bug if changing the Chrome locale settings was user friendly. It took me a few minutes, in a foreign language, to find the language settings under this non-intuitive path: Options -> Under the Hood -> Web Content -> Change font and language settings.
The three Chrome option tab labels 1) "Basics", 2) "Personal Stuff", and 3) "Under the Hood" are not self-descriptive. Having tab labels that are not self-descriptive is a bug. In my opinion, locale settings could arguably be placed under any of those tabs.
I would make these changes:
By default, Chrome checks spelling in user name fields. In my opinion, most user names will not exist in a spell-checker dictionary - so the spell checker will keep making errors.
For Google account users, Google could add a list of those user names to the Chrome spell-check dictionary which it hasn't.
In my opinion, Chrome should not spell-check user name fields at all. Consider this scenario: A user goes to a login screen (e.g. Google accounts), enters a user name and password, and clicks "Sign in".
Would any product developer consider displaying user name suggestions as an error message on a failed login screen? I doubt it, but that's what Chrome does now when a user enters a value in a user name field that is not in the Chrome spell-check dictionary.
Bug #3 (large bug):
If you click Options -> Under the Hood -> Change Proxy Settings a dialog box called "Internet Properties" is displayed. This dialog box contains dozens of important parameters other than for changing proxy settings which are located under the "Connections" tab.
The large bug is that as far as I can tell there is no way to display the "Internet Properties" dialog box to expose all of its important parameters other than to click: Under the Hood -> Change Proxy Settings.
Bug #1 (trivial bug):
I downloaded Chrome from a Google US download page, and ran the setup file expecting the Chrome GUI to be in English. Instead, the Chrome GUI was localized by my IP address so the GUI language was non-English.
This wouldn't be a bug if changing the Chrome locale settings was user friendly. It took me a few minutes, in a foreign language, to find the language settings under this non-intuitive path: Options -> Under the Hood -> Web Content -> Change font and language settings.
The three Chrome option tab labels 1) "Basics", 2) "Personal Stuff", and 3) "Under the Hood" are not self-descriptive. Having tab labels that are not self-descriptive is a bug. In my opinion, locale settings could arguably be placed under any of those tabs.
I would make these changes:
- Add a locale picker to the Chrome download page, or to a screen that displays the first time the Chrome browser is launched.
- Move the "Translate" and "Language" settings from the "Under the Hood" tab to a tab called "On the Road" to make it easier for users to find those settings and to expand the car metaphor.
By default, Chrome checks spelling in user name fields. In my opinion, most user names will not exist in a spell-checker dictionary - so the spell checker will keep making errors.
For Google account users, Google could add a list of those user names to the Chrome spell-check dictionary which it hasn't.
In my opinion, Chrome should not spell-check user name fields at all. Consider this scenario: A user goes to a login screen (e.g. Google accounts), enters a user name and password, and clicks "Sign in".
Would any product developer consider displaying user name suggestions as an error message on a failed login screen? I doubt it, but that's what Chrome does now when a user enters a value in a user name field that is not in the Chrome spell-check dictionary.
Bug #3 (large bug):
If you click Options -> Under the Hood -> Change Proxy Settings a dialog box called "Internet Properties" is displayed. This dialog box contains dozens of important parameters other than for changing proxy settings which are located under the "Connections" tab.
The large bug is that as far as I can tell there is no way to display the "Internet Properties" dialog box to expose all of its important parameters other than to click: Under the Hood -> Change Proxy Settings.
Wednesday, August 4, 2010
More Google Image Search bugs
Bug #1 (trivial bug):
The bug is that for image searches the "Number of results to display per page" parameter has no effect.
Try this...
From a Google Image Search page (new or basic view), click Search Settings, change the number of results to display per page (10 to 100), then save your preferences. Regardless of the value you select, when you run a new search (e.g. snow) Google Image search displays the same number of results.
Note: Google Web and Google News search do not have this bug.
Bug #2 (medium bug):
The bug is that using the new Image Search view, a user cannot print all of the image results.
Try this...
From a Google Image Search page (new view), run an image search, then use the page down button to display all of the 20+ subpages. When you are sure all images display, go to File -> Print Preview. Try various print drivers, different scale values, and both portrait and landscape orientations.
Even when I go to landscape with 10% scale, only a fraction of the image results can be printed.
Note: Google Web, Google News, and Google Images search (basic view) do not have this bug.
The bug is that for image searches the "Number of results to display per page" parameter has no effect.
Try this...
From a Google Image Search page (new or basic view), click Search Settings, change the number of results to display per page (10 to 100), then save your preferences. Regardless of the value you select, when you run a new search (e.g. snow) Google Image search displays the same number of results.
Note: Google Web and Google News search do not have this bug.
Bug #2 (medium bug):
The bug is that using the new Image Search view, a user cannot print all of the image results.
Try this...
From a Google Image Search page (new view), run an image search, then use the page down button to display all of the 20+ subpages. When you are sure all images display, go to File -> Print Preview. Try various print drivers, different scale values, and both portrait and landscape orientations.
Even when I go to landscape with 10% scale, only a fraction of the image results can be printed.
Note: Google Web, Google News, and Google Images search (basic view) do not have this bug.
Sunday, July 25, 2010
Another Large Google Image Search Bug
The bug is that Google Image search results are roughly the same irrespective of the user's locale. You can try these searches...
Search for faces
I haven't yet been to Nigeria, but it's likely folks look different in Nigeria than in the US.
Search for hamburger
Search for hamburger
I haven't yet been to India, but it's likely that because cows are sacred the search results for hamburger should be different. Perhaps, the images should be of veggie-burgers.
Search for House
Search for House
I haven't yet been to South Africa, but it's likely that because of economics and climate differences houses in South Africa look different from typical houses in the US.
Google Web search is localized by language, and Google News search provides a large selection of localized Google News pages.
Not localizing Google image searches is a large bug.
Friday, July 16, 2010
A GMail Bug
A few days ago, I sent an email but it wasn't deliverable. Usually, when this happens a Postmaster failure to deliver email is returned to the GMail inbox. The bug is this time the failure to deliver email went directly into the GMail spam folder.
In GMail, spam is a couple of clicks away from the inbox. Unlike some other email clients, GMail does not have a "You have spam!" alert. Probably, GMail hides access to spam because it presumes it can effectively detect spam from nonspam.
It would be useful if GMail could put Postmaster failure to deliver emails into the GMail inbox where users can see them.
In GMail, spam is a couple of clicks away from the inbox. Unlike some other email clients, GMail does not have a "You have spam!" alert. Probably, GMail hides access to spam because it presumes it can effectively detect spam from nonspam.
It would be useful if GMail could put Postmaster failure to deliver emails into the GMail inbox where users can see them.
Saturday, June 12, 2010
A Large Google Image Search Bug
Here's a large Google Image Search bug. These searches contain two keywords: 1) an instance, and 2) the exclusion of a broad including category.
Search for roses excluding flowers:
rose -flower
16 out of 20 of the images displayed are roses.
Search for ants excluding insects:
ant -insect
20 out of 20 of the images displayed are ants.
Search for circles excluding shapes:
circle -shape
18 out of 20 of the images displayed are circles.
The bug is the following: Google Image search does not understand simple semantic relationships.
The image search algorithm does not know a rose is a flower, an ant is an insect, and a circle is a shape.
Search for roses excluding flowers:
rose -flower
16 out of 20 of the images displayed are roses.
Search for ants excluding insects:
ant -insect
20 out of 20 of the images displayed are ants.
Search for circles excluding shapes:
circle -shape
18 out of 20 of the images displayed are circles.
The bug is the following: Google Image search does not understand simple semantic relationships.
The image search algorithm does not know a rose is a flower, an ant is an insect, and a circle is a shape.
Sunday, May 30, 2010
Some Large Google Image Search bugs
Here are some large Google Image Search bugs.
Bug #1: Page Rank for images
In Google Image Search, run this search: ice cream. The first results page displays 9 out of 20 images containing ice cream cones.
In my opinion, other types of ice cream probably should have equal or higher page rank:
Bug #2: Incorrect image exclusion operator
Exclude vanilla from your ice cream search results by entering these keywords: ice cream -vanilla.
Here are the results:
The first row incorrectly contains mainly vanilla. The exclusion operator should exclude, not include, vanilla.
A similar bug appears if you try to exclude chocolate.
Try this search: ice cream -chocolate. Here are the results which is a bug:
The results incorrectly display chocolate.
Try this search to exclude cones: ice cream -cone. Here are the results for the first two rows of images..
The bug is that 7 out of 8 of the highest ranking images contain cones. Cones are supposed to be excluded.
The image search exclusion operator bug not only fails to exclude, but it may tend to have the opposite effect by emphasizing what it is designed to exclude - at least for the images with the highest page rank.
Bug #1: Page Rank for images
In Google Image Search, run this search: ice cream. The first results page displays 9 out of 20 images containing ice cream cones.
In my opinion, other types of ice cream probably should have equal or higher page rank:
- ice cream cakes
- ice cream bars
- ice cream sundaes
- ice cream sandwiches
- ice cream shakes
- ice cream scoops
Bug #2: Incorrect image exclusion operator
Exclude vanilla from your ice cream search results by entering these keywords: ice cream -vanilla.
Here are the results:
The first row incorrectly contains mainly vanilla. The exclusion operator should exclude, not include, vanilla.
A similar bug appears if you try to exclude chocolate.
Try this search: ice cream -chocolate. Here are the results which is a bug:
The results incorrectly display chocolate.
Try this search to exclude cones: ice cream -cone. Here are the results for the first two rows of images..
The bug is that 7 out of 8 of the highest ranking images contain cones. Cones are supposed to be excluded.
The image search exclusion operator bug not only fails to exclude, but it may tend to have the opposite effect by emphasizing what it is designed to exclude - at least for the images with the highest page rank.
Friday, May 21, 2010
SSL Encryption Is Now Available For Google Search Keywords
Previously, I wrote a post describing the security and privacy issues that may arise when using clear text Google queries: Cyber oppression and the problem of clear text search engine keyword requests.
A Google R&D post has now announced that Google searches can be encrypted using SSL: Extending SSL to Google search. Google's new SSL-enabled Beta site is here: https://www.google.com.
My suggestion: Currently, when a user clicks a cached snapshot link in Google's search engine results list, a URL displays that contains in clear text both the 1) website URL, and the 2) user's search keywords.
Example:
Search keywords: [ski equipment]
An example clear text URL of an arbitrary website clicked from Google's new SSL-enabled search results: http://www.skis.com
An example clear text URL of the related cached web site clicked from the same SSL-enabled Google's search engine results: http://webcache.googleusercontent.com/search?q=cache:t3SmcuNSLKIJ:www.skis.com/+ski+equipment&cd=2&hl=en&ct=clnk
Google's cached website versions often are not up to date, and they usually do not display an entire web site. However, some users may prefer viewing them to reduce the chance of governments, ISPs, and other potential eavesdropping entities from tracking their website visits.
It would enhance the security and privacy of these users if Google encrypted the URLs it displays for its cached web sites.
Here is my SETI research: http://setilinguistics.blogspot.com
A Google R&D post has now announced that Google searches can be encrypted using SSL: Extending SSL to Google search. Google's new SSL-enabled Beta site is here: https://www.google.com.
My suggestion: Currently, when a user clicks a cached snapshot link in Google's search engine results list, a URL displays that contains in clear text both the 1) website URL, and the 2) user's search keywords.
Example:
Search keywords: [ski equipment]
An example clear text URL of an arbitrary website clicked from Google's new SSL-enabled search results: http://www.skis.com
An example clear text URL of the related cached web site clicked from the same SSL-enabled Google's search engine results: http://webcache.googleusercontent.com/search?q=cache:t3SmcuNSLKIJ:www.skis.com/+ski+equipment&cd=2&hl=en&ct=clnk
Google's cached website versions often are not up to date, and they usually do not display an entire web site. However, some users may prefer viewing them to reduce the chance of governments, ISPs, and other potential eavesdropping entities from tracking their website visits.
It would enhance the security and privacy of these users if Google encrypted the URLs it displays for its cached web sites.
Here is my SETI research: http://setilinguistics.blogspot.com
Tuesday, May 11, 2010
A Small Google Web Search Options Message Bug
Here's a small Google search options bug:
Run any Google search - say, for volcano. Click Related Searches -> Nearby -> Custom Location. An empty edit field displays and under it the following message appears:
"Sorry, we couldn't understand . Please try another location."
Here are reasons this is a bug:
1. The message should display after, not before, the user enters a value, clicks Search, and Google doesn't understand it.
2. The anthropomorphic "Sorry, we" may be considered a small bug: 1) Google doesn't have to express regrets, 2) why is Google referred to as a plural "we"?
Would Microsoft Windows display a message such as: "Excuse us, but we could not open your dialog box"?
3. There's an incorrect space between the word "understand" and the period.
My suggestion is to improve the message by changing it to something like this:
"Good afternoon. This problem can only be attributable to human error. Please try another location."
Here is my SETI research: http://setilinguistics.blogspot.com
Run any Google search - say, for volcano. Click Related Searches -> Nearby -> Custom Location. An empty edit field displays and under it the following message appears:
"Sorry, we couldn't understand . Please try another location."
Here are reasons this is a bug:
1. The message should display after, not before, the user enters a value, clicks Search, and Google doesn't understand it.
2. The anthropomorphic "Sorry, we" may be considered a small bug: 1) Google doesn't have to express regrets, 2) why is Google referred to as a plural "we"?
Would Microsoft Windows display a message such as: "Excuse us, but we could not open your dialog box"?
3. There's an incorrect space between the word "understand" and the period.
My suggestion is to improve the message by changing it to something like this:
"Good afternoon. This problem can only be attributable to human error. Please try another location."
Here is my SETI research: http://setilinguistics.blogspot.com
Thursday, May 6, 2010
A Small Google Advanced News Bug
The Google Advanced News web page Author field provides this example: e.g. John Smith or "John Smith". The trivial bug is that the two suggested searches are not equivalent.
The first query runs this search author:John author:Smith and finds news articles that have John Smith, John, or Smith as authors. The second query runs this different search author:"John Smith" and finds news articles that have John Smith as an author.
The first query runs this search author:John author:Smith and finds news articles that have John Smith, John, or Smith as authors. The second query runs this different search author:"John Smith" and finds news articles that have John Smith as an author.
Saturday, May 1, 2010
Small Google Calculator bugs
Here are some small Google Calculator bugs.
Bug #1:
The Google Calculator results of these arbitrary calculations include a space instead of nothing or a comma:
32*128
32 * 128 = 4 096
Bug #1:
The Google Calculator results of these arbitrary calculations include a space instead of nothing or a comma:
32*128
32 * 128 = 4 096
33*27*8
33 * 27 * 8 = 7 128
44+7^4
44 + (7^4) = 2 445
The reason it's a trivial bug is that a user may copy and paste one of these results into another equation and get an error because Google Calculator inserted an erroneous space.
44+7^4
44 + (7^4) = 2 445
The reason it's a trivial bug is that a user may copy and paste one of these results into another equation and get an error because Google Calculator inserted an erroneous space.
Bug #2:
If you perform a Google Calculator operation, under the computational result Google displays a link asking you whether you want to search for documents containing the terms you entered in the search box.
Example:
(823^2)*5/9082
((823^2) * 5) / 9 082 = 372.896388
Search for documents containing the terms (823^2)*5/9082.
You might expect the suggested search to return documents containing the calculation:
(823^2)*5/9082
However, if you click the link Google Search runs this erroneous query:
823 2 * "5 9082"
Google threw away the "^" and "/" operators, probably changed the "*" multiplication operator to a string wildcard operator, and for unknown, spurious, reasons it changed 5/9082 to an exact phrase by surrounding it with quotes.
Sunday, April 18, 2010
Google Rich Snippets: Google Page Rank algorithms vs. user votes
A Google post describes Rich Snippets: "Brief annotations you see beneath search results that summarize what's on a web page."
If a Rich Snippet, say, for a recipe contains a rating property with a high value (e.g. a 5-star review) to what extent does it influence Google's page rank? At its inception, Google could have created a purely democratic "voting" format for web page relevance - however, it didn't. Instead, Google opted for using complex page rank algorithms to determine page rank.
A purely democratic search engine would work as follows: The more people who vote for a web page, the higher it is listed in search query results. All other page rank algorithms can be ignored.
If a Rich Snippet, say, for a recipe contains a rating property with a high value (e.g. a 5-star review) to what extent does it influence Google's page rank? At its inception, Google could have created a purely democratic "voting" format for web page relevance - however, it didn't. Instead, Google opted for using complex page rank algorithms to determine page rank.
A purely democratic search engine would work as follows: The more people who vote for a web page, the higher it is listed in search query results. All other page rank algorithms can be ignored.
Sunday, March 28, 2010
Improved Google Suggest Interface
A Google post, This week in search 3/26/10, describes a new Google Suggest feature. Now "Google Search" and "I'm Feeling Lucky" buttons display when the Google Suggest box is open.
My suggestion: Make the "I'm Feeling Lucky" button accessible from the keyboard. As far as I can tell, a user can't access it from the keyboard.
My suggestion: Make the "I'm Feeling Lucky" button accessible from the keyboard. As far as I can tell, a user can't access it from the keyboard.
Subscribe to:
Posts (Atom)
