Webmasters Gallery

 

Google is getting into the operating system business (again) with Google Chrome OS. Palm put WebKit at the heart of a device with webOS, the Crunchpad talked about it for the netbook, and there have long been desktop-boot-to-browser devices out there.

Google Chrome OS goes deeper:

Google Chrome OS is an open source, lightweight operating system that will initially be targeted at netbooks. Later this year we will open-source its code, and netbooks running Google Chrome OS will be available for consumers in the second half of 2010. Because we’re already talking to partners about the project, and we’ll soon be working with the open source community, we wanted to share our vision now so everyone understands what we are trying to achieve.

Speed, simplicity and security are the key aspects of Google Chrome OS. We’re designing the OS to be fast and lightweight, to start up and get you onto the web in a few seconds. The user interface is minimal to stay out of your way, and most of the user experience takes place on the web. And as we did for the Google Chrome browser, we are going back to the basics and completely redesigning the underlying security architecture of the OS so that users don’t have to deal with viruses, malware and security updates. It should just work.

Google Chrome OS will run on both x86 as well as ARM chips and we are working with multiple OEMs to bring a number of netbooks to market next year. The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies. And of course, these apps will run not only on Google Chrome OS, but on any standards-based browser on Windows, Mac and Linux thereby giving developers the largest user base of any platform.

It is interesting that Google pre-announced this so far in advance. Google is very different from other companies, that normally hold back for a release. They instead come out and tell you what they are doing (sometimes) and promise to open source it 🙂

This is great news for Web developers of course. The Web as a platform continues to push outwards, and we can use our skills to reach more and more folks out there.

There is a reason that we won’t see the fruit of this labour for awhile though, and that is because there is a ton of work to be done. I am excited to see us all come together to push the Open Web platform further and get to a point where it can do everything we need to create compelling user experiences!

Some will say that Android and Chrome OS are totally different beasts, but Jim Pick does have a point:

Google now has two competing open source in-house Linux-based operating systems with Webkit browsers. This won’t end well.

Competition baybee.

“Why doesn’t Google use GWT more?”

That is a question that I was asked maaaany a time. There are sites like Base and the old mashup editor and others…. but “why not something big like Gmail?”

It was always so tough because it wasn’t a totally fair question.

1. Google has some of the best Ajax hackers out there. Teams with that talent may not be the right people to use GWT!
2. A lot of sites were written before GWT was created, and migrating something is a different proposition

Google Wave on the other hand, had the chance to really evaluate GWT and they went with it. There was a talk at Google I/O about why, and some of the cool new features they use such as runAsync that does some incredibly smart things to lazily load code when needed (and gives you a much smaller initial download).

I don’t have much to add to the massive coverage that Wave has gotten today. I see two pieces. The one that most people focus on is how it looks and what the site does. It is very rich, and cool, and some people will try it and some will not like how it feels.

That isn’t the piece I am most excited about. Although it is great to reboot what a communication tool could be in 2009, but I am much more excited about the APIs. A lot of servers and frameworks and languages are vying for the “real time Web server” trophy. What Wave gives you is a federated implementation AND a spec to build your own stuff. At its core I see it as a great way API to let people collaborate on a shared object. That is a fantastic building block.

When I heard about it, I immediately thought about my own world of Bespin of course. From the initial prototype we had the notion of creating a collaborative social experience with code. One feature that has long been on the drawing board can be seen here:

 

We want to tie chat/status/microblogging content to files and even code snippets in a project. Imagine being able to highlight some code and see not only who created it and when, but also what was discussed. The social bar on the right has some of that concept. Then down below you see the timeline view that lets you go back in time and see the code change before your eyes. Maybe you want to replay the coding that a coworker did while you were out instead of staring at the diffs? This is the kind of thing that I hope we can experiment with Wave to do. We will see!

Robert Kroeger has released a nice library for local database access. The Web Storage Portability Layer nicely abstracts on top of HTML5 and Gears for database access.

    The WSPL consists of a collection of classes that provide asynchronous transactional access to both Gears and HTML5 databases and can be found on Project Hosting on Google Code.

    There are five basic classes:

    google.wspl.Statement – A parametrizable SQL statement class

    google.wspl.Transaction – Used to execute one or more Statements with ACID properties

    google.wspl.ResultSet – Arrays of JavaScript hash objects, where the hash key is the table column name

    google.wspl.Database – A connection to the backing database, also provides transaction support

    google.wspl.DatabaseFactory – Creates the appropriate HTML5 or Gears database implementation

    Also included in the distribution is a simple note-taking application with a persistent database cache built using the WSPL library. This application (along with Gmail mobile for iPhone and Android-powered devices) is an example of the cache pattern for building offline web applications. In the cache pattern, we insert a browser-local cache into the web application to break the synchronous link between user actions in the browser and server-generated responses. Instead, as shown below, we have two data flows. First, entirely local to the device, contents flow from the cache to the UI while changes made by the user update the cache. In the second flow, the cache asynchronously forwards user changes to the web server and receives updates in response.

    By using this architectural pattern, a web application can made tolerant of a flaky (or even absent) network connection!

You can of course take a peak at the code to see how it works, for example:

JAVASCRIPT:

1	google.wspl.DatabaseFactory.createDatabase = function(dbName, dbworkerUrl) {
2	var dbms;
3	if (window.openDatabase) {
4	// We have HTML5 functionality.
5	dbms = new google.wspl.html5.Database(dbName);
6	} else {
7	// Try to use Google Gears.
8	var gearsDb = goog.gears.getFactory().create(‘beta.database’);
9	var wp = goog.gears.getFactory().create(‘beta.workerpool’);
10	// Note that Gears will not allow file based URLs when creating a worker.
11	dbms = new wireless.db.gears.Database();
12	dbms.openDatabase(”, dbName, gearsDb);
13	wp.onmessage = google.bind(dbms.onMessage_, dbms);
14
15	// Comment this line out to use the synchronous database.
16	dbms.startWorker(wp, dbworkerUrl, 0);
17	}
18	return dbms;
19	};
20

Nicely done. It would be great to see a version that acts as a shim and when in Gears mode manually implements the HTML5 standard API so you can write your user code to that and not a new google package.

About a month ago, we covered an announcement about Mozilla’s plans to basically put OpenGL ES in the browser and call it Canvas 3D and to do so working with a new working group over at the OpenGL standards body, Khronos.

This week, we covered Google’s own 3D announcement, a plug-in offering a high-level scene graph API and embedded V8 run-time.

And of course, don’t forget about Opera’s 3D work, which we covered back in November 2007.

So now there are three approaches to 3D:

• Mozilla: Low-level, OpenGL wrapper
• Opera: Mid-level proprietary scene-graph-ish API
• Google: The full COLLADA monty

Where should the web go? Mozilla’s Chris Blizzard compares the debate to Canvas vs. SVG:

Canvas is a very simple API, much like what we’ve proposed to Khronos for 3D support. It’s well-scoped, well understood and integrates very well with other web technologies. And it’s been getting a huge amount of traction on the web. People are writing all kinds of really neat technology on top of it, including useful re-usable libraries for visualization. Have a look through Google’s own promotional site for Chrome – a huge number of them use canvas. It has traction. And we’ve gone through a couple of iterations – we’ve added support for text and a couple of other odds and ends once we understood what people were trying to do with it.

Now compare this to SVG and SMIL. Each of those specs are multi-hundred page documents with very large APIs and descriptions of how to translate their retained-mode graphics into something that’s usable on the web. (SVG 1.1 is a 719 page PDF. SVG 1.2 Tiny is 449 pages. The spec for SMIL is a 2.7MB HTML file.) We’ve seen some implementation of SVG and SMIL in browsers, but it’s been slow in coming and hasn’t seen full interoperability testing nor any real pick up on the web. The model for these specs was wrong, and I think it shows.

Chris doesn’t directly say that Google’s approach is “wrong”, but he wonders if the Google proposal of a bigger and more ambitious API would represent too great a compatibility burden for browser vendors and developers.

In the comments of his post, Henry Bridge of the Google O3D team replied; here’s a lightly edited excerpt:

We agree that to keep a standards process focused, APIs should be as minimal as possible while remaining useful, and so we would likely keep things like that out of any first attempt at a standard and, as you say, let it evolve over time. But the usefulness question brings up an important, and we think, unresolved point. We’d love to build the animation and skinning system in JS, but we just couldn’t get a JS-based animation system fast enough — even on our retained-mode API. Javascript is getting faster all the time and we love that, but until someone builds some apps it’ll be hard to know what’s fast enough.

Standardizing [an Open GL-like] immediate mode API for JS makes total sense. It’s a well defined problem, lots of people know GL, and we think it will be useful. But some of the demos we wrote _already_ don’t run well without a modern JS implementation, and moving to [Open GL] won’t help that (but we’d love to be proven wrong). That’s why we think it makes sense to explore both an immediate and a retained mode 3D, and make sure they work well together.

Google Ventures seeks to discover and grow great companies, they believe in the power of entrepreneurs to do amazing things. Google Ventures is broadly interested in startups in industries including consumer Internet, software, hardware, clean-tech, bio-tech, health care and others.

They invest anywhere from seed funding to tens of millions of dollars and embrace the challenge of helping young companies grow from the garage to global relevance. They’re looking for entrepreneurs who are tackling problems in creative and innovative ways. Are you one of them?

Just when you thought you were done with IE 6 and its hacks and exceptions, now you’ve got a new browser to consider: Google’s Chrome.

The good news is that Chrome is a lot more compatible with web standards than IE 5 and 6. However, Chrome has its own idiosyncrasies and bugs.

No one knows if Chrome is here to stay, but it has already captured a surprisingly decent share of the web browser market in a short period of time.

Here are some tips to get your web pages working in Chrome and hopefully looking the way they were designed to look.

Mac Users

As of February 2009, Chrome is still a browser for Microsoft Windows PCs. If you use a Mac, you will need to run Microsoft Windows through Bootcamp, or one of the virtualization products for the Mac (Sun’s VirtualBox, Parallels, VMWare Fusion). If you are really daring, you can try and get Chrome to run using Darwine. Google promises to have a native Mac version of Chrome available in the coming months.

Vanishing Pop-Ups

Pop-Up blocking is great unless your website really needs pop-up functionality. If you have a web page that must use pop-ups, you won’t see them in Chrome. By design, Chrome only displays the title of a pop-up and minimizes it to the bottom right corner of the browser window. Users will need to click and drag the pop-up’s title in order to view its content.

SSL is Broken?

By design, Chrome will only certify a valid SSL (secure sockets layer) page with the padlock icon if all the elements on the page are served via SSL. In other words, if your page is served via SSL but it calls elements via non-secured HTTP, Chrome will give your page an exclamation point icon indicating that it considers your page to be an inconsistent SSL transmission. To get around this, make sure that all the resources loaded by your web page, including all images, are prefaced with HTTPS.

Declare Encoding First

If your web page text is garbled or otherwise just plain wrong in Chrome, you may need to insert encoding information into the <head> section of each web page. If you already have encoding information, it must come first, before any CSS or Javascript. Otherwise, Chrome will just ignore it. A working example:

<html>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=windows-1251?>
<script type=”text/javascript”>
… your JavaScript code …
</script>
… your CSS code …
Also, Chrome will ignore encoding specified by Javascript. Period. For example, the following would be ignored:

document.write(”<meta http-equiv=”Content-Type” content=”text/html; charset=windows-1251?>”);
Instead of using JavaScript, you must insert your encoding into the beginning of the <head> section of each web page as shown above.

Bookmark Favorites

When users choose to bookmark your web site, you can control the default bookmark name, description, link, and bookmark icon. Just make sure to place your code in the <head> section of your web pages. Here is a working example:

<head>
<meta name=”application-name” content=”Greatest Website”/>
<meta name=”description” content=”The very best on the web”/>
<meta name=”application-url” content=”http://www.superfantasticgreatestweb.com”/>
<link rel=”icon” href=”great-icon_32×32.png” sizes=”32×32?/>
<link rel=”icon” href=”great-icon_48×48.png” sizes=”48×48?/>
</head>

Fixing JavaScript

If your JavaScript is not working properly in Chrome, check Chrome’s JavaScript console, accessible from the Page menu icon -> Developer -> JavaScript console. That should give you some direction as to what you can change.

For the more advanced JavaScript developers, you can also use the JavaScript Debugger, accessible from the Page menu icon -> Developer -> Debug JavaScript. That will allow you to watch variables and set breakpoints.

CSS Image Problems

If you are using images or backgrounds implemented through CSS and they are not rendering properly in Chrome, you might want to convert images between GIF, JPG, and PNG to see if a different image format solves your problems. Although this makes no sense, it sometimes works, especially with random spacing and image formatting problems.

CSS “First” Selector Hack

Chrome can be finicky and unforgiving about CSS and may ignore styles applied to certain page elements. You might try using the “first-of-type” keyword which will be ignored by all other browsers (except for Apple’s Safari). For example, if you cannot get a particular style applied to the <body> section of your web page to work in Chrome, add in something like the following:

body:first-of-type p {color:#ff0000;}

“First-of-type” will simply be ignored by the browsers that are already displaying your page the way you intended.

GiantIsland CSS Hack

Chrome interprets cascading style sheets (CSS) differently than other browsers. Then again, IE 5, 6, and 7 do not even interpret CSS the same! The GiantIsland CSS Hack is a relatively simple CSS markup hack that makes use of square brackets [ ] to target CSS on specific browsers like Chrome. As a bonus, it can also help you conform your CSS to IE 5, 6, 7, Safari, and Firefox, all at the same time. For more details, check it out at http://www.giantisland.com/Resources/LitePacificHackforSafariAndIE7.aspx.

Stay Away from HTML5

Chrome does not try to conform to HTML5 API standards yet, even though Webkit, its rendering engine, does support HTML5. If you use HTML5 features or syntax, you will likely run into problems. Stick with HTML4 standards and you should have an easier time. Chrome will likely support HTML5 in the near future.

Validate Your Pages

Before swearing at Chrome and throwing in the towel, validate your pages to make sure you have not inadvertently used a non-standard HTML call. You can validate any web page at http://validator.w3.org/. Some web browsers allow you to take some shortcuts with web standards, but Chrome is not very lenient.

Try it with Safari

If you can’t get your web pages to look right under Chrome no matter what you try, try your web pages in Safari before giving up. Safari is Apple’s web browser and is available for both Mac and Windows PCs. If you use Windows, you can freely download Safari from Apple at http://www.apple.com/safari/download/. Both Chrome and Safari are built using the open source “Webkit” browser rendering engine. If you can see a rendering error in both Chrome and Safari, there is a good chance that Webkit is the culprit. You can post a bug for the Webkit developers at http://webkit.org/quality/reporting.html.

Aw Snap!

The Chrome developers have provided some funny error messages (if an error can be considered funny). If Chrome gives you the dark grey “Aw Snap!” page which also says “Something went wrong while displaying this webpage,” it might not be your web page at all. Chrome has a tendency to crash on some PCs depending on system settings and other installed applications. Try a few other well-known web pages, and see if they crash. Also try closing Chrome, re-launching it, and then test your web pages again. Some people have found Chrome to be unstable on some PCs. Google intends for Chrome to become more sturdy with each new version.

Bug Reporting

If you find a bug with Chrome’s rendering, report it! You will be making the world a better place. Google maintains a public bug list for Chrome at http://code.google.com/p/chromium/issues/list.

Written exclusively for WDD by Derek Underwood, a professional web designer and software developer. You can read more about Derek and contact him at his website:

Alexa.com is a well known web traffic statistics website. It tracks websites visited by persons who have opted to install an Alexa toolbar in Microsoft’s Internet Explorer or Sparky plugin in Mozilla’s Firefox. Alexa’s ranking has been criticized over the years for being unreliable but many website owners and advertisers still use it as a measuring stick to rank the popularity of a website.

For many years Yahoo.com was the most trafficked website in the world according to Alexa but recently Yahoo.com has been overtaken my Google.com as the most trafficked website in the world at least for web users with the Alexa toolbar or sparky plugin installed.

 

 

Top 10 Sites according to Alexa

Google.com

Yahoo.com

Youtube.com

Live.com

Facebook.com

MSN.com

Wikipedia.org

Myspace.com

Yahoo.co.jp