If you are trying out Google Chrome, type about:stats into the address bar and hit enter. You get:

In a previous post I wrote how adding features to a product to assist in debugging issues pays dividends; its great to see others also using this technique. This page/feature is obviously for determining and optimizing memory issues and performance stats. I wonder how many other "address-lets" like this there are built in?

Troy.

Google announced and released their Chrome browser today.

This post is from Chrome, and it does seem to work on most sites i've looked at - however, there are many rendering issues that aren't issues in Firefox or IE. Some examples can be seen on my LINQ Wiki site (Hooked on LINQ) where the spacing between adjacent span's seems squashed, and the order of table cells seems to be incorrect (OK, different) than the current popular browsers. It is a beta after all, but google have said the rendering engine is closest to Apple's API, and I must admit, my sites are less tested on Safari (in fact, not really at all).

This brings up an interesting Product Management challenge. If peoples first impression is that sites they frequent are "broken" in Chrome - will users persist with that product. Gmail is still in "Beta" which is a bit farsicle given its time in the market, so understanding what Google actually means by "Beta" is difficult to judge - But - Chrome is definately BETA!

What works

- I like the "common pages" layout of a New Tab. Rather than just a blank tab, you get previews of common sites you frequent

- I like the developer javascript and page analysis built-in features (think Developer Toolbar)

What Doesn't Work

- Rendering issues on many sites that I find work in Firefox and IE

- I'm sure this wasn't a high-priority item for Google, but I struggled to get a Silverlight app to run. I went to Hardrock Cafe, and it almost ran (showed images, but couldn't zoom, pan, etc). I think Silverlight was installed OK (no mention of anything being downloaded), but in general - no luck here.

I'm most interested to see how Google will leverage this browser as a runtime for applications. They spend some time saying how they want applications running in Chrome to be more "Desktop Like" - my point would be, why not make them Desktop Apps! Solve the deployment problem, and write well coded Smart Client interfaces.

Troy. 

Some business rules are complex to capture, and codify into an application. Some examples are when there is company policy that is interpreted (hopefully minimally) slightly differently by different parties, or requires complex analysis when the new system "gets it wrong!".

One example I came across was the logic surrounding whether or not a banking loan application falls within an automated decision process or whether it has to be manually assessed. We took three releases to satisfy all the different business stakeholders. Our issue wasn't so much the actual rule coding, but the actual individual circumstance that swayed the rules engine one way or the other given individual interpretation. Our output of true or false didn't give us any understanding (or the end-user) as to why a certain decision was made.

In the second release, I added a right-click menu item to the "Calculate…" button. This menu allows the user (normally under the direction of the help-desk) to perform the calculation AND populate the Windows Clipboard with a small text based diagnostic report detailing the following aspects –

1.   The data it is ACTUALLY using for the decision – in many cases we were incorrectly gathering this data, making our result difficult to predict
2.   A step-by-step progress – Step 1 (Parties over 18 years old) : PASSED, Step 2 … etc…
3.   The date, time and user logged-in
4.   The version numbers of all assemblies and rules loaded

The end-user would then email this to our team as part of an "In My Opinion – You Got it Wrong" bug report. These reports allowed our Business Analysts to quickly isolate an issue, or more commonly a mis-understanding by the end-user as to actual bank policy! We quickly took a major unstable area and by the next version reports were almost zero (at least a 95% decrease in one release).

The key takeaways for me were –

1.   When a feature has many stakeholders, or the feature might be complex to remotely diagnose – consider adding some features to support the help-desk gathering the information you need to improve that feature over time
2.   Building diagnostic reports into the Clipboard was a very low impact way of getting data from end-users, and was easy for the helpdesk to explain
3.   Make the features obscure (although easy for the help-desk staff to tutor end-users). You don't want these features negatively impacting the user experience for normal cases
4.   Consider privacy issues. Only expose underlying data that you actually need. No personally identifiable medical results :-)

Troy.