Much more is coming. These first several steps simply set the stage for getting into deployment of the Google Search Appliance (GSA), what we think are the more interesting and challenging parts. Among other things, upcoming are documentation of how to install and configure the connector to the GSA, and walkthroughs explaining how we have configured our GSA to accomplish the goals of the project.

(Kudos to Ed Lachgar, IT extraordinaire at Legal Services of Northern California for writing up these first 16 sections.)

As a coda to last week’s post about turning on Gmail 2.0 for Google Apps, it is worth noting that doing so will effectively kill some Firefox add-ons that you may be accustomed to using to spiff up the appearance of your Gmail interface, including some commonly used Greasemonkey Gmail scripts and popular Userstyles.org Gmail scripts that rely on Stylish. You should update those, as needed.

For LSNC perhaps the biggest deal is having a solution for mailto links, so that the Gmail 2.0 “Compose Mail” page opens whenever the user clicks on a mailto link.

One of the easiest solutions to this dilemma is to have users install the Better Gmail 2.0 Firefox add-on.

To get the “Compose mailto Links in Gmail” feature to work with your Google Apps domain, click on the “Advanced” button in the Better Gmail 2.0 console and then simply add your domain. Problem solved. Well, for the most part. Once set, if the user has Firefox open and is already logged into Gmail, whenever the user clicks on a mailto link it will open to the Gmail Compose Mail page. If not logged into Gmail, clicking the link will trigger Gmail opening to its default Inbox page. Hey, but no harm, no foul.

With the Better Gmail 2.0 add-on you also get several other useful options, including a very helpful “Attachment Icons” display that substitutes file-type specific icons for the Gmail default paper clip icon. Useful stuff.

And before we launch directly into rebuilding the styles for Pika 3.06, I thought to offer an overview of a few web development tools that are extremely helpful and fairly easy to use for figuring out what is going on with a given web page’s structural markup and the CSS code controlling its styles. To that purpose, I discuss here four particularly useful tools for HTML and CSS diagnostics available for use within the Firefox browser:

• Firebug
• MRI bookmarklet
• XRAY bookmarklet
• Web Developer Toolbar

Firebug

There is no question that the Firebug browser extension for Firefox is the web developer tool I will rely on most for Stage One of Project Grace. The name Firebug is true to its purpose: It is a remarkable and easy-to-use web page debugging tool you can invoke with a few mouse clicks directly from within your Firefox browser window to easily and visually deconstruct any web page. At the same time you get immediate access to the underlying HTML, CSS and JavaScript code so you can better understand how the page is built and what the underlying HTML, CSS and JavaScript code are doing (or not doing) when the page loads. It is not the first web page debugging tool to hit the web developer world. But is by far the first to make debugging HTML, CSS and JavaScript code in a given web page this easy to do, and in a way that makes the tool authentically easy to use even for non-professional web designers. You know. Like most of us.

My intention here is not to reinvent the tutorial wheel. If you are new to Firebug, it is easy enough to find a basic introduction to Firebug; any number of longer-form Firebug tutorials; even a long-form “Welcome to Firebug 1.0″ video by its creator Joe Hewitt. Get your Firebug orientation, as you need.

Rather, my goal here is more modest, just to get you up and running and in the swim with Firebug to assure you can follow along as its use is illustrated in the Project Grace articles to come. So, for Firebug newbies, here is one way to get your Firebug on:

First, be sure to install Firebug in your Firefox browser. After installing it, completely close out and then restart your Firefox browser (as you would with any newly added Firefox extension). You need to “enable” Firebug when you first use it. To do so, click on the green circular icon with the white check mark located in the lower right-hand corner of your browser, on the far right of the status bar, as illustrated. This triggers a dialog window inviting you to enable Firebug. Do so.

You’re good to go. You should now see the Firebug “inspection” window. Click on the “Inspect” tab and watch the magic, as you hover your mouse over parts of the web page displayed in the window above the Firebug inspection window. As you hover over any element on the web page, Firebug highlights the element with a blue border in the web page above, while highlighting the corresponding HTML structural markup in the Firebug window below. On the right side of the Firebug inspection window, you will also see a separate window detailing the CSS “Style” code and the spatial “Layout” affecting the display of that same element. Here’s an example using Webdogs 2.0 of what is displayed if you hover your mouse over the Webdogs 2.0 logo at the top of the page:

Give it try here at Webdogs 2.0. Open the Firebug inspection window and hover over the Webdogs 2.0 logo image, as illustrated above. Click on the logo image. Here’s what you’ll see on the left side of the Firebug inspection window, with the markup for the Webdogs 2.0 logo image element conveniently highlighted in blue:

You can immediately see in the left pane of the Firebug inspection window where that page element is located in the flow of page HTML markup, plus its corresponding attributes.

On the right side of the Firebug inspection window, you can also see all the CSS code affecting the presentation or display of the Webdogs 2.0 logo:

The CSS information provided by Firebug is nutrient dense, to the max: You can see immediately all the CSS selectors (e.g., #banner img); the corresponding properties for each selector (e.g., float:left; and so on) affecting the dispay of the page element; and the location of that particular bit of CSS code (e.g., style.css at line 101). But wait … there’s more! Scroll down and you will see examples of other bits of CSS code that are inherited from other parts of the cascade (e.g., the styles affecting the display of the anchor tags that makes the image a clickable link), as well as other inherited style elements that have been trumped by other, more specific parts of the CSS code (e.g., the color values affecting anchor tags elsewhere in the page design). If that were all Firebug did, that would be plenty. But it does tons more things you’ll discover as you play with it.

MRI and XRAY bookmarklets

Sometimes using Firebug is akin to using a shotgun when a fly swatter would do the job just fine, thank you very much. In that spirit, allow me to suggest you try the XRAY, a handy bookmarklet that enables you to quickly see how the box model is affecting the display of any page element. Again, to illustrate using Webdogs 2.0, click on the XRAY bookmarklet, which triggers a smoke-colored “Welcome to XRAY” window. Click on the Webdogs 2.0 logo image and you get a chock-fulla display of information about the spatial layout of that particular page element:

Not only is this a great way with a single click to get a lock on the basic dimensions (height, width, margins and padding) of a page element and its positional characteristics (e.g., the element is a “float”), it is the quickest way I know to determine whether an id or class attribute has been added to the element, and what is the inheritance heirarchy affecting the element — all useful information for locating or establishing related CSS coding in the style sheet.

The MRI bookmarklet does something similar but different: Click on the MRI bookmarklet and then enter a selector into the dialog box and it will find any page element that uses that same selector. It also works in reverse: You can see the page element on the page but want to know what selectors it uses. No problema. Click on the MRI bookmarklet and then click on the page element and the dialog box displays a list of suggested selectors affecting the display plus the structural markup heiracrchy. Other tools are better at this sort of thing or do it differently, e.g., Firebug (described above) and View Source Chart extensions. But the MRI bookmarklet is a nice quickie way to get this basic information, in a pinch.

Web Developer Toolbar

The Web Developer Toolbar is famously described as the Swiss Army Knife of web development tools. It has some 150+ functions and so it can seem overwhelming. If you are new to it you may find it helpful to read the Web Developer Toolbar Overview.

Over the last year or so Firebug has largely supplanted the Web Developer Toolbar as the “diagnostic” tool of choice for many because the former makes it easier to get to the source of and diagnose HTML, CSS and JavaScript code on a given page. But beyond the formidible, more user friendly “debugging” advantages of Firebug, the Web Developer Toolbar does a whole lot more things.

For Project Grace, here is a little used and little understood tool in the Web Developer Toolbar I use all the time: “Display Topographic Information.” You can find it about half way down the list of options under “Information.” I use the “Topographic Information” display primarily to get a “pseudo-grid” display of all the elements displayed on the page. Some designers use a background grid to evaluate the relative positioning of elements. I prefer to just use the topographic information display. With it, I can more readily see how page elements are positioned relative to each other, whether the elements display evenly (or not), and way more easily so than looking at the regular page itself, especially in a design like Webdogs 2.0 that relies on a lot of open, unbordered page elements and does not rely on rules or lines to orient the eye to the spatial relationship of those elements.

To illustrate my point, take another look at the home page of Webdogs 2.0. Regardless of how you feel about the overall design, the page elements look basically well-ordered, evenly spaced, no? Well, maybe. Maybe not. Using the Web Developer Toolbar, select “Display Topographic Information” and view the same page:

Ah! Get it? This “topogrpahic” layout of all the page elements actually makes it easier to see if the positioning of elements is consistent with the overall intended layout design. I get the advantage of a grid-like view of the page but with added topographic detail. And it helps me see whether a page element is too big or “pushing” or “obstructing” other elements, something that can be very hard to do, or simply impossible, by just deconstructing the CSS code in the abstract context of a style sheet.

OK people, now let’s get some real work done. Onward and upward to Project Grace 02: Basic HTML and CSS deconstruction!

The Whole Enchilada: Project Grace: Pika Reloaded