Archive for the 'Google' Category
เปิดตัวแล้ว “G1″ สมาร์ทโฟนตัวแรกแพลตฟอร์มแอนดรอยด์ (Android) ถูกวิจารณ์ว่ารูปลักษณ์คล้ายไอโฟน (iPhone) เพราะมีหน้าจอทัชสกรีนขนาดใหญ่ แตกต่างที่คีย์บอร์ดสไลด์ข้าง มี trackball ปุ่มกลมที่ผู้ใช้สามารถดันขึ้นลงซ้ายขวาเพื่อควบคุมเมาส์ได้ และสามารถเปิดใช้บริการอีเมลและแผนที่ของGoogleได้แสนสะดวก
และเกินคาด T-Mobile ตั้งราคาขาย G1 ไว้ที่ 179 เหรียญสหรัฐ (ประมาณ 5,900 บาท) พร้อมสัญญา 2 ปี ดัมป์ราคาเฉือนไอโฟนถูกลงอีก 20 เหรียญ พร้อมจำหน่ายในสหรัฐฯวันที่ 22 ตุลาคม ก่อนจะจุดพลุในอังกฤษเดือนพฤศจิกายน และกลุ่มประเทศแถบยุโรปปีหน้า
สำหรับ สหรัฐฯ G1 จะวางจำหน่ายในร้านค้าของ T-Mobile เฉพาะใน 21 เมืองที่ T-Mobile ให้บริการเครือข่าย 3G เท่านั้น เช่น นิวยอร์ก ลอสเองเจลิส ฮุสตัน และไมอามี โดยผู้ใช้ในพื้นที่อื่นๆ สามารถสั่งซื้อ G1 ได้จากเว็บไซต์ของ T-Mobile
อัตราค่าบริการข้อมูลที่ T-Mobile วางไว้นั้นเริ่มที่ 25 เหรียญต่อเดือน (ราว 825 บาท) โดยคิดเพิ่มจากค่าบริการโทรศัพท์ เทียบเท่ากับอัตราแพคเก็จบริการข้อมูลขั้นต่ำซึ่งบริษัทโทรคมนาคมไร้สายให้ บริการในสหรัฐฯขณะนี้
แพลตฟอร์มแอนดรอยด์นั้นไม่ได้ถูกวางตัวเป็นซอฟต์แวร์ทำเงินของGoogle แต่Googleเชื่อว่า การเปิดทางให้ผู้ใช้โทรศัพท์มือถือเข้าสู่บริการออนไลน์ได้ง่ายขึ้น จะทำให้คนใช้งานบริการออนไลน์ไม่ได้กระจุกตัวอยู่ที่กลุ่มผู้ใช้คอมพิวเตอร์ เท่านั้น เมื่อนั้นช่องทางทำเงินในธุรกิจโฆษณาออนไลน์ของGoogleก็จะถูกขยายให้แข็ง แกร่งยิ่งขึ้นไปในตัว จุดนี้Googleเคยออกมาประกาศว่า ท้ายที่สุดแล้วGoogleจะสามารถทำเงินจากอุปกรณ์พกพามากกว่าพีซีด้วยซ้ำ ซึ่งเฉพาะคอมพิวเตอร์พีซี ก็เป็นช่องทางที่สามารถทำเงินให้Googleกว่า 20,000 ล้านเหรียญสหรัฐต่อปีแล้ว
แน่นอนว่าเรื่องนี้ ยาฮู (Yahoo) และไมโครซอฟท์ (Microsoft) สองยักษ์ใหญ่ธุรกิจโฆษณาออนไลน์เห็นด้วยกับGoogle และลงมือกรุยทางโตบนอุปกรณ์พกพาแล้วเช่นเดียวกัน
G1 ถูกวิจารณ์ว่าเหมือนไอโฟนตรงที่มีหน้าจอทัชสกรีนความละเอียดสูง และทำให้การใช้งานเว็บไซต์ที่ไม่ได้สร้างมาเพื่อเปิดบนโทรศัพท์มือถือทำได้ สะดวกขึ้น แต่สิ่งที่ G1 ต่างจากทั้งไอโฟนและแบล็กเบอรี่ (BlackBerry) ซึ่งเป็นสมาร์ทโฟนที่มีการใช้งานมากที่สุดในสหรัฐฯ คือ G1 นั้นมีข้อจำกัดในการเข้าถึงระบบอีเมลในองค์กรธุรกิจ สิ่งที่เกิดขึ้นแปลว่า G1 ถูกออกแบบมาเพื่อผู้บริโภคอย่างแท้จริง
เท่ากับ G1 ไม่ได้มีจุดยืนเป็นโทรศัพท์ไฮเอนด์ที่มีความสามารถพิเศษเลิศเลอ แต่อย่างไรก็ตาม เมื่อGoogleเปิดกว้างให้ชุมชนนักพัฒนาโปรแกรมพัฒนาซอฟต์แวร์แพลตฟอร์มแอ นดรอยด์อย่างเสรี ก็เป็นไปได้มากว่า G1 จะมีฟังก์ชันมากมายให้ผู้บริโภคเลือกใช้ได้หลากหลายมากกว่าโทรศัพท์รุ่นอื่น ในอนาคต เพียงแต่ว่า แอปพลิเคชันเหล่านี้ยังไม่เกิดขึ้นและโชว์ตัวให้เห็นเป็นรูปธรรมในขณะนี้
แอปเปิลนั้นวางแนวคิดนี้ไว้ให้ไอโฟนเช่นกัน แอปเปิลเปิดร้าน App Store เพื่อให้นักพัฒนาวางขายหรือแจกโปรแกรมแล้วระยะหนึ่ง แอปเปิลระบุว่าประสบความสำเร็จมากมาย มีผู้ดาวน์โหลดโปรแกรมไปแล้วมากกว่า 1 ล้านครั้งในช่วงหลังการเปิดตัวร้านไม่ถึง 1 เดือน อย่างไรก็ตาม รูปการณ์กลายเป็นว่าแอปเปิลเข้ามาควบคุมการให้บริการแอปพลิเคชันเหล่านี้ อย่างเต็มที่ และบล็อกแอปพลิเคชันที่ดูเหมือนว่าจะมาแข่งขันกับแอปพลิเคชันของแอปเปิลเอง ด้วย ซึ่งเป็นที่ไม่พอใจและมีการถกเถียงว่าแอปเปิลยึดหลักเกณฑ์ใดในการพิจารณา บล็อกหรือไม่บล็อกโปรแกรมใด
G1 นั้นไม่ใช้บริการเพลง iTunes ของแอปเปิล แต่ใช้แอปพลิเคชันที่เชื่อมกับร้านขายเพลงของ Amazon.com ผู้ใช้สามารถดาวน์โหลดเพลงลง G1 ได้โดยตรง และเพลงที่เปิดให้ดาวน์โหลดไม่มีโปรแกรมป้องกันการละเมิดลิขสิทธิ์ใดๆ
ผู้ก่อตั้งGoogleอย่างเซอร์เกย์ บริน ก็บอกว่าได้ลงมือพัฒนาแอปพลิเคชันสำหรับ G1 เช่นกัน เป็นโปรแกรมที่ใช้เซ็นเซอร์ตรวจจับความเคลื่อนไหวที่ฝังมาในโทรศัพท์มือถือ เป็นตัววัดว่าโทรศัพท์จะใช้เวลาเท่าใดในการโยนขึ้นกลางอากาศและตกลงมา
“เราไม่ได้ติดตั้งโปรแกรมนี้เป็น default ครับ” บรินกล่าวติดตลก เชื่อว่าใครที่คิดจะใช้แอปพลิเคชันนี้คงต้องใจกล้าน่าดู
และ จากการสอบถามประชาสัมพันธ์ของเอชทีซีไทยแลนด์ คาดว่า G1 อาจจะไม่ได้เข้ามาทำตลาดในเมืองไทยเนื่องจาก T-Mobile คือผู้ทำตลาดด้วยตัวเองและไม่ได้ใช้ชื่อภายใต้แบรนด์ HTC โดยมีข่าวลือว่า โทรศัพท์มือถือแอนดรอยด์แบรนด์เอชทีซีอาจจะสามารถแจ้งเกิดในปีหน้าจำนวน 3 รุ่น ซึ่งมีโอกาสถูกส่งมาให้ชาวไทยเชยชมมากกว่า G1
As anticipated last month, Google’s experiment that lets you reorder and annotate search results is now live. Google SearchWiki should be available automatically if you are logged in to a Google account and it can be recognized by the visual clutter added to the search results.
Next to each result, you should see three new options: a way to promote a web page at the top of the results, an option to remove results from the page (they’re still visible at the bottom of the page) and a feature that lets you share public comments about a result. After promoting a result, Google shows some unnecessary information about the other people who promoted the result.

It’s important to remember that all the changes are saved to your Google account and they won’t affect the search results for everyone, at least not directly. If you want to see an aggregation of all promotions, demotions and comments, go to the bottom of the page and click on “See all notes for this SearchWiki”. This is the real wiki built by Google and it’s easy to access by adding &swm=2 to the URL of a search results page: http://www.google.com/search?hl=en&q=google&swm=2.

Comments are not very useful, although you could find insights for some obscure queries. The absolute number of people who promoted a search result is not very useful either, especially when you’ll see big numbers like 314,159,265.
SearchWiki’s main idea is to give users the opportunity to manually customize the search results and make them more predictable. Since many people repeat common searches like [mail], [weather], [news] and Google’s results are constantly changing, it’s nice to pick your favorite results and display them at the top. If you can’t find a site you like, click on “Add a result” and manually add a page in the list of top results.

Good things about SearchWiki:
- you can now adjust Google’s results for your typical queries and save time when repeating the searches
- use Google instead of bookmarking web pages
- for unfamiliar queries, check the wiki to find a different ranking and potentially useful comments. Try to avoid the wiki for queries that are likely to be spammed.
Bad things about SearchWiki:
- visual clutter. The only way to remove the additional icons displayed next to each search result is to log out.
- your changes are available only when you repeat the query and, in some cases, for similar queries (e.g.: [google.com] in addition to [google]). That means you can’t remove a web page or a domain from all search results
- comments are public and there’s no option to write private notes (Google removed the option to annotate results in Google Notebook)
- an obvious feature would be to get a permalink for your edited results, but Google doesn’t offer this yet
- there’s no option to toggle between your edited results and the standard results (you’ll have to log out)
- it’s difficult to reorder results, since the only action allowed is to place a web page at the top, after all the other promoted pages. If you promote the page again, it will become the first result.
Google has always used people’s clicks to improve the quality of search results, so the new options could influence the ranking algorithms in different ways. “At this time we aren’t using SearchWiki to influence ranking but it is easy to see how that could happen in the future,” said Marissa Mayer. “Search is adapting to the Internet as it becomes a more participatory medium. Now you have people telling us specific things about how they’d like to see their search results. You could imagine if we do see a particular site (about which) people have a unanimous opinion, that might trigger external things. Like maybe we should check out our spam control,” suggested Cedric Dupont, product manager for SearchWiki and Google Knol.
Webmasters often ask us at conferences or in the Webmaster Help Group, “What are some simple ways that I can improve my website’s performance in Google?” There are lots of possible answers to this question, and a wealth of search engine optimization information on the web, so much that it can be intimidating for newer webmasters or those unfamiliar with the topic. We thought it’d be useful to create a compact guide that lists some best practices that teams within Google and external webmasters alike can follow that could improve their sites’ crawlability and indexing.
Our Search Engine Optimization Starter Guide covers around a dozen common areas that webmasters might consider optimizing. We felt that these areas (like improving title and description meta tags, URL structure, site navigation, content creation, anchor text, and more) would apply to webmasters of all experience levels and sites of all sizes and types. Throughout the guide, we also worked in many illustrations, pitfalls to avoid, and links to other resources that help expand our explanation of the topics. We plan on updating the guide at regular intervals with new optimization suggestions and to keep the technical advice current.
So, the next time we get the question, “I’m new to SEO, how do I improve my site?”, we can say, “Well, here’s a list of best practices that we use inside Google that you might want to check out.”
Webmasters often ask us at conferences or in the Webmaster Help Group, “What are some simple ways that I can improve my website’s performance in Google?” There are lots of possible answers to this question, and a wealth of search engine optimization information on the web, so much that it can be intimidating for newer webmasters or those unfamiliar with the topic. We thought it’d be useful to create a compact guide that lists some best practices that teams within Google and external webmasters alike can follow that could improve their sites’ crawlability and indexing.
Our Search Engine Optimization Starter Guide covers around a dozen common areas that webmasters might consider optimizing. We felt that these areas (like improving title and description meta tags, URL structure, site navigation, content creation, anchor text, and more) would apply to webmasters of all experience levels and sites of all sizes and types. Throughout the guide, we also worked in many illustrations, pitfalls to avoid, and links to other resources that help expand our explanation of the topics. We plan on updating the guide at regular intervals with new optimization suggestions and to keep the technical advice current.
So, the next time we get the question, “I’m new to SEO, how do I improve my site?”, we can say, “Well, here’s a list of best practices that we use inside Google that you might want to check out.”
Today morning when I sign in my gmail account, I saw a message top on my gmail.
Its a new service of google to their mail. I am happy that I themed my gmail. I chose my theme. I feel better to see my gmail new look.
Google has refined the appearance of its search page when visiting from an iPhone or iPod touch, an announcement reveals. Results are now formatted in a similar manner to other Google services, with a blue navigation bar, and vertically-aligned text or imagery that eliminates the need to scroll horizontally. Where appropriate, results will automatically bring up maps, as well as larger and more obvious direction and phone call buttons. In the case of multiple listings a Show Map link brings up the new view.

If needed, it is also possible to revert to the desktop version of Google via the Classic link. Access to the iPhone/iPod formatting is currently restricted, however; it is only viewable in English from the US, and requires an Apple handheld with v2.x firmware. Google says it eventually intends to bring the formatting to other phones, countries and languages.
Since launching our first batch of 13 Gmail Labs features, we’ve received a lot of suggestions for more experimental features you’d like to see — plus, we’ve had some of our own ideas. Today, there’s a new batch of labs features to play with. If you like using Labels, we hope you like these.
Custom label colors, by Mark K

If the 24 standard color choices aren’t your thing, enable this feature to create your own custom color combinations. Instead of choosing one of the standard colors from the label drop-down menu, click “Add custom colors,” pick your palette, hit “Apply,” and enjoy.
Go to label keyboard shortcut, by Bruce D
Never have to click on a label again. Instead, enable keyboard shortcuts and press “g” then “l” to display the “Go to label” pop-up. Start typing, and your labels will be filtered as you go. You can use the arrow keys to select a label and hit “Enter” to select one.

Powertip: The pop-up searches each word in your labels for a match, so if you have multiple labels with the same prefix, simply add a space, dash or slash after the prefix and search for the second word. For example, typing “labs” will display labels named “gmail labs,” “gmail-labs,” or “gmail/labs” but won’t display “gmaillabs.”
Navbar drag and drop, by Anatol P
If Labels are more important to you than your Contacts, you can switch them around with this Labs feature, which allows you to reorder the items in Gmail’s lefthand navigation bar using drag and drop.
To turn on these Labs features and more, just go to the Labs tab under Settings. Keep posting feedback on the forums because we’re reading what you have to say!
Source: http://gmailblog.blogspot.com/2008/09/new-in-labs-3-experiments-with-labels.html
Gmail Labs has been a really fun way to easily try out new ideas and get some of our pet feature requests implemented quickly. We wanted to take this to the next level and let you start adding your own stuff to Gmail. Today we’re launching a few Labs experiments that let you add gadgets to the left-nav, next to Chat and Labels.
To get you started, we’ve worked with the engineers from the Calendar and Docs teams on two highly requested features: a simple way to see your Google Calendar agenda and get an alert when you have a meeting, and a gadget that shows a list of your recently accessed Google Docs and lets you search across all of your documents right from within Gmail.
There’s a third Lab that allows you to add any gadget by pasting in the URL of its XML spec file (e.g. http://www.google.com/ig/modules/youtube_videos.xml). We realize this isn’t very user friendly right now; it’s a sandbox mainly aimed at developers who want to play around with gadgets in Gmail. We’re not tied to the left-nav as a primary way to extend Gmail — in fact we think it is relatively limited and doesn’t offer scalable real estate. There are also some downsides to the iframe-style Gadgets we’re using today — they can sometimes slow down the page. We’re fanatical about speed, so we’ll be keeping a close eye on performance.
This is also a chance for us to test the developer infrastructure involved. We’re using common gadget infrastructure, such as the Apache Shindig project, and working with other gadget containers to make gadgets more portable.
We’re looking forward to your comments in the Labs forum, so send us your ideas, let us know how you like the Calendar and Docs gadgets, and if you’ve written a gadget that you think works well in Gmail, post it and let us and other users try it out.
A couple of notes:
(1) Try out Anatol’s Navbar drag and drop Labs feature so you can easily re-order all the boxes on Gmail’s left hand side.
(2) Not all gadgets are fully compatible with https, so if you’re connecting to Gmail via https, you may see mixed content warnings caused by parts of the gadgets being served over http. We’re working on fixing this where we can.
Source: http://gmailblog.blogspot.com/2008/10/new-in-labs-calendar-and-docs-gadgets.html
Chatting with webmasters often reveals widespread beliefs that might have been accurate in the past, but are not necessarily up-to-date any more. This was the case when we recently talked to a couple of friends about the structure of a URL. One friend was concerned about using dynamic URLs, since (as she told us) “search engines can’t cope with these.” Another friend thought that dynamic URLs weren’t a problem at all for search engines and that these issues were a thing of the past. One even admitted that he never understood the fuss about dynamic URLs in comparison to static URLs. For us, that was the moment we decided to read up on the topic of dynamic and static URLs. First, let’s clarify what we’re talking about:
What is a static URL?
A static URL is one that does not change, so it typically does not contain any url parameters. It can look like this: http://www.example.com/archive/january.htm. You can search for static URLs on Google by typing filetype:htm in the search field. Updating these kinds of pages can be time consuming, especially if the amount of information grows quickly, since every single page has to be hard-coded. This is why webmasters who deal with large, frequently updated sites like online shops, forum communities, blogs or content management systems may use dynamic URLs.
What is a dynamic URL?
If the content of a site is stored in a database and pulled for display on pages on demand, dynamic URLs maybe used. In that case the site serves basically as a template for the content. Usually, a dynamic URL would look something like this: http://code.google.com/p/google-chec…s/detail?id=31. You can spot dynamic URLs by looking for characters like: ? = &. Dynamic URLs have the disadvantage that different URLs can have the same content. So different users might link to URLs with different parameters which have the same content. That’s one reason why webmasters sometimes want to rewrite their URLs to static ones.
Should I try to make my dynamic URLs look static?
Following are some key points you should keep in mind while dealing with dynamic URLs:
- It’s quite hard to correctly create and maintain rewrites that change dynamic URLs to static-looking URLs.
- It’s much safer to serve us the original dynamic URL and let us handle the problem of detecting and avoiding problematic parameters.
- If you want to rewrite your URL, please remove unnecessary parameters while maintaining a dynamic-looking URL.
- If you want to serve a static URL instead of a dynamic URL you should create a static equivalent of your content.
Which can Googlebot read better, static or dynamic URLs?
We’ve come across many webmasters who, like our friend, believed that static or static-looking URLs were an advantage for indexing and ranking their sites. This is based on the presumption that search engines have issues with crawling and analyzing URLs that include session IDs or source trackers. However, as a matter of fact, we at Google have made some progress in both areas. While static URLs might have a slight advantage in terms of clickthrough rates because users can easily read the urls, the decision to use database-driven websites does not imply a significant disadvantage in terms of indexing and ranking. Providing search engines with dynamic URLs should be favored over hiding parameters to make them look static.
Let’s now look at some of the widespread beliefs concerning dynamic URLs and correct some of the assumptions which spook webmasters. 
Myth: “Dynamic URLs cannot be crawled.”
Fact: We can crawl dynamic URLs and interpret the different parameters. We might have problems crawling and ranking your dynamic URLs if you try to make your urls look static and in the process hide parameters which offer the Googlebot valuable information. One recommendation is to avoid reformatting a dynamic URL to make it look static. It’s always advisable to use static content with static URLs as much as possible, but in cases where you decide to use dynamic content, you should give us the possibility to analyze your URL structure and not remove information by hiding parameters and making them look static.
Myth: “Dynamic URLs are okay if you use fewer than three parameters.”
Fact: There is no limit on the number of parameters, but a good rule of thumb would be to keep your URLs short (this applies to all URLs, whether static or dynamic). You may be able to remove some parameters which aren’t essential for Googlebot and offer your users a nice looking dynamic URL. If you are not able to figure out which parameters to remove, we’d advise you to serve us all the parameters in your dynamic URL and our system will figure out which ones do not matter. Hiding your parameters keeps us from analyzing your URLs properly and we won’t be able to recognize the parameters as such, which could cause a loss of valuable information.
Following are some questions we thought you might have at this point.
Does that mean I should avoid rewriting dynamic URLs at all?
That’s our recommendation, unless your rewrites are limited to removing unnecessary parameters, or you are very diligent in removing all parameters that could cause problems. If you transform your dynamic URL to make it look static you should be aware that we might not be able to interpret the information correctly in all cases. If you want to serve a static equivalent of your site, you might want to consider transforming the underlying content by serving a replacement which is truly static. One example would be to generate files for all the paths and make them accessible somewhere on your site. However, if you’re using URL rewriting (rather than making a copy of the content) to produce static-looking URLs from a dynamic site, you could be doing harm rather than good. Feel free to serve us your standard dynamic URL and we will automatically find the parameters which are unnecessary.
Can you give me an example?
If you have a dynamic URL which is in the standard format like foo?key1=value&key2=value2 we recommend that you leave the url unchanged, and Google will determine which parameters can be removed; or you could remove uncessary parameters for your users. Be careful that you only remove parameters which do not matter. Here’s an example of a URL with a couple of parameters:
http://www.example.com/article/bin/a…8906&query=URLlanguage=en – indicates the language of the article
answer=3 – the article has the number 3
sid=8971298178906 – the session ID number is 8971298178906
query=URL – the query with which the article was found is [url]
Not all of these parameters offer additional information. So rewriting the URL to www.example.com/article/bin/answer.foo?language=en&answer=3 probably would not cause any problems as all irrelevant parameters are removed.
The following are some examples of static-looking URLs which may cause more crawling problems than serving the dynamic URL without rewriting:
www.example.com/article/bin/answer.foo/en/3/98971298178906/URL
www.example.com/article/bin/answer.foo/language=en/answer=3/
sid=98971298178906/query=URL
www.example.com/article/bin/answer.foo/language/en/answer/3/
sid/98971298178906/query/URL
www.example.com/article/bin/answer.foo/en,3,98971298178906,URL
Rewriting your dynamic URL to one of these examples could cause us to crawl the same piece of content needlessly via many different URLs with varying values for session IDs (sid) and query. These forms make it difficult for us to understand that URL and 98971298178906 have nothing to do with the actual content which is returned via this URL. However, here’s an example of a rewrite where all irrelevant parameters have been removed:
www.example.com/article/bin/answer.foo/en/3
Although we are able to process this URL correctly, we would still discourage you from using this rewrite as it is hard to maintain and needs to be updated as soon as a new parameter is added to the original dynamic URL. Failure to do this would again result in a static looking URL which is hiding parameters. So the best solution is often to keep your dynamic URLs as they are. Or, if you remove irrelevant parameters, bear in mind to leave the URL dynamic as the above example of a rewritten URL shows:
www.example.com/article/bin/answer.foo?language=en&answer=3
We hope this article is helpful to you and our friends to shed some light on the various assumptions around dynamic URLs. Please feel free to join our discussion group if you have any further questions.
Source: Dynamic URLs vs. static URLs
Written by Juliane Stiller and Kaspar Szymanski,
Google Search Quality Team
Monday, September 22, 2008













