Posts tagged: rebuild

  • Thursday
  • April 19
  • 2012

First take at responsive web design

It is been a year since LSNC got stalled on redesigning its advocate-oriented websites, the last reporting here being about a rebuild of the Race Equity Project site. The process of rebuilding our sites got seriously sidetracked while working on the LSNC Google API Project.

So much time has since passed that we have decided to reboot the whole site rebuilding thing and work purposefully toward a new, better designed set of WordPress templates based on current responsive web design. So, out of the box, here is our initial take: LSNC’s RCFE Field Guide:

RCFE screenshot

The guide is a modest but useful online checklist, with citations, for ombudsman investigators in California who need quick reference to the regulatory requirements affecting the rights of residents of long-term care facilities for the elderly.

This site design is our first attempt to come up with a re-usable flexible grid design that scales and repositions page elements smoothly to accomodate varied viewports, from the desktop down to a 7″ form factor and down further to a typical smartphone display. The design relies on core code from the very clean, minimalist Origin WordPress theme. Lovin’ it.

  • Monday
  • April 11
  • 2011

The Race Equity Project rebuild debuts

Photo of Martin Luther King, Jr.

This last weekend we rolled out the second LSNC subsite rebuild: The Race Equity Project. The redesign elements will look familiar to those who have followed the LSNC rebuild series here that provides the core code base for the custom variations we eventually will deploy at all the LSNC.net domain sites.

The Race Equity Project rebuild directly reflects several touches first built out and tested here, namely, better use of the Google custom search API; more practical findability of archive posts by providing a browsing metaphor for visually scanning a list of posts in inverse chronological order; handy-dandy sharing improvements with use of the WordPress ShareDaddy plugin to add Twitter, Facebook, Email and Print doodads below each post and most pages; and, of course, our roll out of WPtouch Pro to provide visitors with a clean, intuitive mobile version of the site.

Widely recognized and respected for its leadership role within the national legal services community on race equity issues affecting low-income communities, the Race Equity Project has honored and supported its mission with 320+ posts since November 2006. This is the REP statement of it’s origin and purpose:

In 2003, through an empirically-based self-assessment, Legal Services of Northern California (LSNC) found marked racial disparities in the allocation of resources in our service area. Through further investigation and staff education, LSNC gained program-wide awareness that although the form of race discrimination has changed over past decades from predominantly overt and intentional to the implicit and institutional, discrimination continues to burden grossly LSNC’s clients and communities of color. This led LSNC to establish the Race Equity Project (REP) in 2004. The Race Equity Project seeks to address issues of race within our service area by (1) identifying race disparities in the institutions and systems used by LSNC’s clients; (2) educating clients and community agencies and organizations about these disparities and how to address them; and (3) enforcing laws and policies to eliminate or mitigate these disparities.

The REP is not a specialty unit within LSNC, but rather a program-wide broad approach to legal aid advocacy guided by the REP coordinators. LSNC implements the REP by using the following tools: (1) understanding social cognition and understanding and adopting strategies to counteract implicit bias and structural/institutional racism; (2) communications framing; (3) mapping and data presentation; and (4) community lawyering.

It will likely be sometime in May before we get the top-level LSNC Advocate feed done, but it’s coming.

  • Monday
  • April 4
  • 2011

LSNC Regulation Summaries: Variations on a Theme

We have implemented the first real iteration of the new LSNC site redesign: LSNC Regulation Summaries (née Regs @ LSNC.net), a subsite of Legal Services of Northern California’s home site. Of the LSNC sites we are in the process of rebuilding, this is the easiest to do, since it is just a collection of hundreds of straight-up post items, plus only two simple custom pages — an about page and a search result page, the latter being the content-target page for the Google custom search API. (For the record, LSNC has posted 954 regulation summaries since 2004.)

Those following the recent rebuild series of articles here will recognize the source of many of the design elements. I won’t go into those again.

That said, I do want to mention the virtuous cycle that comes with rebuilding all our sites on the WordPress 3.x multisite platform, while reaping the benefits of core web standards now more widely implemented by all major web browsers.

First, with WordPress we have been able to build a core set of new “LSNC” theme files that, for the first time, will be uniform and standardized across all of our sites, with the added advantage of a unified network administrative panel and single login for editors to all the sites to which they add content. Adding plugins and updating the core WordPress application is also now way easier since it can be done once for all our sites.

Second, because everything is being rebuilt on the WordPress platform, we are able to use the wondrous WPtouch Pro plugin, which makes deployment of a mobile-ready site quite effortless. You can view two slightly different implementations we’ve done of WPtouch by viewing Webdogs 3.0 and Regulation Summaries on your smartphone. This is a plugin that we can turn on and configure in about 30 seconds for all other LSNC sites, as we roll the new design out.

Third, I cannot overstate how much the adoption of web standards has simplified the development and made vastly more predictable the results of our CSS code. Setting aside for the moment the proprietary CSS property values one still has to use to implement CSS3 box-shadow and border-radius (rounded corner) effects, I was somewhat stunned to discover that the only other design element in the entire site that required any browser-specific change at all was the search-text input field, which is dynamically generated by the Google search API code. And even that quirk was minimal. I had to make changes to the CSS padding property of that element to make the presentation reasonably uniform among Firefox, Webkit (Chrome and Safari), Opera and IE. Yep, a tweak for one CSS property associated with one CSS selector. That’s it.

WordPress. HTML5. CSS3. Web Standards. Lovin’ it.

  • Wednesday
  • March 9
  • 2011

Rebuild 10: Deconstruction of the Reconstruction

In the broad sense, the rebuild of Webdogs 3.0 has now been completed. We do have plans for reorganizing some of the content, so you will see minor changes to the navigation scheme, via the horizontal menu at the top, as we add paths to particular types of site content. We will also be cleaning out some posts and pages that are well past their shelf-life and not archive-worthy.

That said, here’s a recap of how the rebuild was approached and what software and tools were used to make it happen, along with related observations and lessons learned:

WordPress 3.0, the foundation

All of the public websites created by Legal Services of Northern California (LSNC), including this one, have long relied on the WordPress publishing platform. That’s not news. What is news is our migration over to the new WordPress 3.0, which merges the site-stand-alone version of WordPress with WordPress MU, “allowing the management of multiple sites (called Multisite) from one WordPress installation.” This has dramatically simplified the management of our multiple public websites, including the ease of updating the sites with the latest versions of WordPress and WordPress plugins, and giving our multiple editors one login and one dashboard for accessing all the sites.

Building out to HTML5

Once we had the new WordPress backbone in place, the first stage of site reconstruction involved dipping our toes into HTML5 by building a test home page, using several of the new semantic HTML5 markup elements (e.g., article, aside, footer, header, etc.), and then reassuring ourselves that it all would validate, which it did.

Structuring the page-specific markup

Confident that HTML5 “works” on the real web, we started our markup rebuild using Chris Coyier’s BLANK WordPress Theme, which includes among other things a well edited, trimmer functions.php file. (He and Jeff Starr offer a half-dozen other free, very well-coded WordPress themes at their DiW Theme Clubhouse.) The BLANK theme comes coded to XHTML 1.0 Strict. Since we were jumping on the HTML5 bandwagon, we dropped that and went for the HTML5 “upgrade” by declaring the much simpler HTML5 doctype.

That done, we just followed the yellow brick road and built out all new structural markup to support the new Webdogs 3.0 content design. The construction of the header.php file was largely prosaic, but a prudent addition if moving to HTML5 is the addition of an HTML5 IE enabling script that makes older versions of Internet Explorer backward compatible with the newly introduced HTML5 elements.

Adding the WordPress plugins

There were several functional changes we wanted to add to the site, along with some site management tools, that we knew we could accomplish with WordPress plugins. So, we added these plugins:

  • Google XML Sitemaps – the current production version is not compatible with the new multisite version of WordPress 3.0, but there is a beta version that does work. Try it. You’ll like it.
  • SimplePie Plugin and SimplePie Core – a perennial favorite for presentation of multiple feeds within WordPress, used here for the new side bar. It is no longer updated by the author but it seems to work fine with the latest version of WordPress.
  • WP Simple Sitemap – not to be confused with either of the above two plugins, this is what we used to create the browse page, which lists post archives in inverse chronological order, so that visitors can more easily — and visually — scan older posts.
  • WP Page Numbers – want a “pager” function for your archive listings? This works. (By the same author as the preceding plugin.)
  • WPtouch Pro – how to create a very professional looking cross-device mobile version of your WordPress site within seconds. So far, the vibe is pretty good and worth the charge. But that’s us. How about you? View Webdogs 3.0 on your smartphone and tell us if it works for you.

Sprinkling with CSS3 transitions and box-shadows

Hey, were entitled to have some fun, right? We have gone light on adding CSS3, but we added a few page element transitions, some of which are also layered with box-shadows. A modest coding effort that makes us smile whenever we go into a hover state.

Adding Typekit fonts

Another toe-dip for us was the use of Typekit fonts for post headlines and a few other page elements, such as the heading over the comment form. This is an effortless and free way to add some typographic distinction, with styling control of the font retained in your CSS file.

Exploiting the Google Custom Search API

Truth be told, taking advantage of the Google Custom Search API has been the hardest part of the rebuild. There are easier implementations, especially if one creates a Google custom search engine, relies on a CSE “Get Code” cut-n-paste, and then plops it down into a standard page. But to get firmer control of how the code functions and how results present themselves, well, that takes a lot more work. We’re pleased with our current search function, but admittedly there is more we want to do with it.

The only part of the new site that we had serious trouble styling was the Google-API, dynamically generated search-query text-input field. It didn’t want to do what we wanted and we had to wrestle it to the ground. (And the match is not over!) And there was one other significant CSS styling issue that came up: CSS3 “rounded corners” using the border-radius property. All the major browsers now support border-radius in one form or another, but there is a problem with jagged edges in all of them except Firefox, if the element with the rounded border is set against a dark background and the border itself is noticeably lighter. If you view the Webdogs search input field first in Firefox and then in a different browser, you’ll see the difference. The difference would be even more pronounced had we not implemented this partial solution.

Hope you all enjoy the new site design. Now, on to the rebuild of all the other LSNC sites…

  • Friday
  • February 11
  • 2011

Rebuild 09: Google custom search + mobile + related posts

Webdogs 3.0 mobile

The site search functions here have been pretty funky during the rebuild — sometimes working, sometimes not working, and more often than not displaying oddly as we tried out a variety of things. That should begin to settle down. We have now integrated the Google Custom Search API with a basic, clean, quite traditional implementation. (For example, search for HTML5.) There’s still some funk in play with auto-suggestions and auto-completion, and something is causing some jitters in Google Chrome but not other Webkit browsers. We’re hammering it out.

Two other site elements have also been added recently using WordPress plugins: related posts are now linked below each original posts as “other posts of possible interest.” We are also testing WPtouch Pro as a very easily implemented mobile solution.

The next step is to do a comprehensive code sweep of the rebuilt site to tidy things up, before we use the coding experience to update all of LSNC’s public websites. Having hammered things out here, we should be able to do the site updates to our other public sites efficiently. (That’s the theory, anyway.) There is a “Rebuild 10″ post coming up, where I will recap the code building blocks used to do the Webdogs 3.0 makeover. Stay tuned.

  • Wednesday
  • December 15
  • 2010

Rebuild 08: Project content and CSS3 transition examples

The basic layout and presentation for the projects page is done. Setting up that page prompted me to implement a few CSS3 transitions at three locations: the horizontal navigation links, the sidebar items, and the project titles in the left column of the projects page.

You’ll need Chrome, Safari, Opera or the Firefox 4 beta to see the effects. As you hover over any of those three page elements, you will see a smooth transition effect. This is very easy to implement. All I had to do was add this CSS3 code to the CSS selector for the particular element to which I wanted the effect applied:

-moz-transition: all 0.60s ease-in-out;
-o-transition: all 0.60s ease-in-out;
-webkit-transition: all 0.60s ease-in-out;
transition: all 0.60s ease-in-out;

There is a lot more one can do using CSS3. To see a real-world site with a lot of this sort of thing implemented, open up Chrome or Safari and take a look at CSS-Tricks and hover your mouse around all the parts of the page. Of course, this level of implementation can really get annoying, sorta like an overuse of visual gimmicks in PowerPoint slides. But, hey, if your site is called “CSS-Tricks,” I think you get a pass.

  • Wednesday
  • December 8
  • 2010

Rebuild 07: Headlines using Typekit fonts

Among the oldest complaints about web design have been the practical constraints on typography, with alternative solutions not so easy for all too many. The situation has changed dramatically in recent years with options like the Google Font API and better understanding of how to implement the @font-face CSS at-rule. Using those techniques offer varying success, since not all web-font sans-serif alternatives and serif alternatives are created equal.

In any event, as part of the current rebuild I have opted to go with Typekit and have implemented the Museo Sans font for all headlines and in a few other places. Offering a touch of typographic distinction, Museo Sans is widely used as a high quality alternative to the ubiquitous Arial font. Typekit makes implementation a piece of cake. And this particular font is available as part of Typekit’s free account. Hope it works for you.

The one tip I would offer is to consider applying CSS letter-spacing and word-spacing property values, even if only “0″, when using this particular font. I discovered that at a smaller size the Museo Sans character spacing was somewhat uneven. Once I applied a zero value for letter-spacing and word-spacing, the display problems resolved themselves.

Want to learn more about web-based typography? Take a look at the online classic, The Elements of Typographic Style Applied to the Web.

  • Tuesday
  • November 30
  • 2010

Rebuild 06: Nips, tucks and a new page footer

A new, serviceable site-wide page footer is in place. The design would be fairly characterized as prosaic, much like innumerable other sites, since it uses a fat page-footer area to position basic site information, i.e., what the site is about, contact information, feeds and permissions. Works for me.

I’ve been doing a lot of site nips and tucks, changing various pixel-level settings at different page locations to make things look, well, just so. There is still a lot left to do. All the initial rebuilding is being done against Firefox; I have yet to tweak things specifically for the other common browsers. A lot of the existing site content is still living below the redesign radar, because the re-organizing and navigation relinking of that content are still on the to-do list. And an even more major task is ahead: Rebuilding the site search functions with the Google Search API.

Stay tuned.

  • Sunday
  • November 21
  • 2010

Rebuild 05: Page layout tweaks, comments and a new sidebar

I have been toying with the layout of the main content areas for the site’s new page design, and have now opted for “posts” with a three-line date format, for weight and balance, to the left as a visual guide to the beginning of each post. Posts themselves, with their left margin pushed to the right about 140 pixels, are set to a 600px width for readability. The default non-post “page” design has wider content margins. These layout changes have been applied sitewide.

Comments are now working, although there is a little bit of funk going on in what displays where, so I will be tweaking that code over the next several days.

The new sidebar goes retro with a feed pull displaying the four most recent items from a new Webdogs 3.0 Delicious feed. This will not be yet another collection of voluminous link dumps. Rather, the intent is to draw attention to the type of web content I actually read, which often comes in longer form articles. The external feed pull was created using the SimplePie WordPress plugin (which also requires you install SimplePie Core to work.)

  • Saturday
  • November 13
  • 2010

Rebuild 04: The basic “look” of the new home page

Having Veterans Day off, I got motivated and worked up the basic layout and presentation for the new home page. There are several things on the page that are temporary placeholders, not linked through or entirely non-functional at the moment. Most notably, the search text and submit inputs are nothing more than placeholders, so I could work out the presentation for those elements in the header. And the sidebar and footer areas are as yet just undefined placeholders, as well. That said, the basic header, horizontal navigation, and main content areas are pretty close to where they will end up when the redesign is finished.

The one custom page template I have built is for the site archives, viewable via the Webdogs 3.0 browse menu option. I got the idea for a browsable list of archived posts, by title in inverse chronological order, from Chris Coyier’s CSS Tricks archive. Implementing something comparable was fairly easy, using the WP Simple Sitemap plugin with a bit of tweaking of the plugin to display the date corresponding to each post. The pager element at the bottom of the list was created using the WP Page Numbers plugin, by the same author.

  • Monday
  • November 8
  • 2010

Rebuild 02: Mock the Dog with HTML5 markup

Before getting to the presentation layer, which is to say the CSS code that will dictate the layout and look of the Webdogs design, I have first built a rudimentary, mock-markup home page, relying on a mininmal set of HTML5 elements. (There are eight lines of embedded CSS to provide just a touch of presentation that retains the HTML document flow.) The new markup elements introduced here include the HTML5 header, footer, aside and section tags, as well as the descriptive role attribute. You can view the source code for the mock home page, or simply view this text version.

Two notes about the HTML5: First, The head tag includes an IE conditional statement with the HTML5 IE enabling script, a bit of Google Code javascript that makes older versions of Internet Explorer backward compatabile with the newly introduced HTML5 elements. Second, the HTML5 role definitions are part of the emerging WAI-ARIA standards, and offer promise of significant semantic gains in accessibility for users who rely on screen readers. The use of HTML5 role attributes at this site will advance that promise.

The purpose of the home test page is as basic as it gets. I want to make sure that the new design will display successfully when relying on a core set of HTML5 structural elements supported by current browsers. Confident of that, I can use the test page to then rebuild the actual “design” with CSS. I can then transpose that structural markup and CSS code to this site’s WordPress installation.

There are loads of HTML5 resources out there explaining how to do what is illustrated by the mock home page. I can make two recommendations: I am a huge fan of the Jeremy Keith’s HTML5 for Web Designers. Yes, it is a touch expensive for a book that is only 85 pages or so, but it is worth it. It is a clearly written, insightful while amusing summary of what HTML5 is and why you will want to adapt to it. The other recommendation is free: Mark Pilgrim’s Dive into HTML5.

  • Sunday
  • October 31
  • 2010

Rebuild 01: Webdogs unplugged

The transition begins. For starters: A plain-vanilla, stripped-down, back-to-basics WordPress template to set a new design baseline. Source: The “Blank” theme, courtesy of Chris Coyier and Jeff Starr’s DiW Theme Clubhouse.

Think of it as “The Rally to Restore Webdogs.” Or maybe not. Whatever you call it, the look, feel and function of the site will be changing episodically over the next several months. At appropriate junctures, I will post deconstructions of the changes.