Showing posts with label CSS. Show all posts
Showing posts with label CSS. Show all posts

Monday, January 11, 2010

Zend Framework Route Context Plugin

See Zend Framework Route Context Plugin at its new home on bradley-holt.com.

I want to share a simple, yet very useful, custom Zend Framework plugin that we use on almost all of our projects. The plugin (and associated code in the layout file) provides the Zend Framework route context as CSS classes on the body element. This allows us to change the design (using CSS) and/or behavior (using unobtrusive JavaScript) on the page based on the Zend Framework route. For example if the module name was default, the controller name was news, and the action was get then the opening of the body element would like this:

<body class="default news get">

There are some limitations. For example, you need to be careful not to overlap module, controller, or action names. If this is a problem for you then you could preface the class names (e.g. module-default, controller-news, action-get).

The RouteContext plugin hooks into the preDispatch event and creates an array of route context strings. This example simply uses the module, controller, and action names as the route context. Often I'll add other contextual strings to this array as needed. This array is then assigned to the view. The layout view script then simply implodes this array into the value of the class attribute using a space character as the glue.

Saturday, January 2, 2010

Web Design and Web Development

See Web Design and Web Development at its new home on bradley-holt.com.

Back in October, Jeffrey Zeldman tweeted something that I strongly agree with:

Real web designers write code. Always have, always will. #aea

This sparked many conversations including these two tweets from Chris Shiflett:

According to @zeldman, real web designers write code. (I think he means HTML and CSS, not PHP, Perl, and Python.) What do you think?

I’ve now asked, separately, whether developers and designers should know HTML and CSS. In both cases, most think they should. Interesting.

To which I responded (brackets added):

@shiflett IMHO, the demarcation between web developers and web designers should be POSH [Plain Old Semantic HTML]. That's what both need to know.

I have a pretty strong opinion about this. You could say that I have the luxury of working with an excellent designer who implements all of his own CSS—even tackling much of the JavaScript coding on websites we build. To be clear: he is a designer, not a developer—working in both print (which is more technical than you might think) and web.

The typical process is summarized well in Marco Tabini's PHP Advent 2009 post on CSS and Other People:

From a developer’s perspective, “design work” means having to deal with the often hated, sometimes impossible, and always challenging task of translating a designer’s comp into a combination of HTML and CSS that will render properly on browsers that are often at complete odds with one another.

In my opinion, that process is broken. Why is it assumed that because HTML and CSS are "code" it should be a developer's job to implement these? Any decent designer is already familiar with the concept of separating presentation and content with style sheets (which are supported in Adobe InDesign, QuarkXPress, and even PageMaker and Microsoft Word). Is learning HTML and CSS, both declarative languages, considered too hard for designers?

Let's take a look at comps and the dreaded "s" word—slicing. As Marco pointed out, trying to "slice" a comp into HTML and CSS is "sometimes impossible" and "always challenging." If a designer is only providing a comp, and not the HTML and CSS, it is very likely that the designer does not have a solid understanding of things like progressive enhancement, browser compatibility, and even what is possible on the web.

The use of a comp generally assumes that design is purely visual and that all representations of the web page should look exactly like the comp. How should the content be presented to screen readers, to mobile devices, and in print? Sure, you could provide comps for each of these scenarios but this is not scalable and you quickly risk violating the "One Web" concept. Thinking of a web page through the lens of only one specific visual representation of that page is very limiting.

Do you agree that the typical process is broken? If so, what are the barriers to fixing this process? Do we need better trained web designers? Do organizations need to be educated on how to better structure their web teams? This problem will eventually self-correct. My prediction is that teams with web designers that know HTML and CSS will create better websites and web applications and be more successful than teams using the old process.

Monday, June 1, 2009

Tagnabit Launched!

See Tagnabit Launched! at its new home on bradley-holt.com.

Last night we announced the launch of tagnabit, a social media aggregator. It's "a service that aggregates tags from popular social media websites. It is useful for conferences or other events. Participants can use a shared tag across Twitter, Flickr, Technorati, YouTube and Delicious. Tagnabit then aggregates this content in one place." The idea originally started with Town Meeting Day Vermont and then was used for the Alliance for Community Media Northeast regional conference. People found it useful, so we decided to make a "generic" version that basically has the same functionality as these sites, but for any arbitrary tag. Bill Simmon has a few ideas on how tagnabit can be used.

The functionality behind tagnabit was built using Zend Framework (MVC components, Zend_Feed, Zend_Service_Flickr, and Zend_Cache). The client side is all semantic XHTML (with a few Microformats), CSS, and a few JavaScript enhancements (using jQuery). We've got plans for some new features - but we're curious to see how people use the site first. If you've got feedback, please send it our way via Twitter, Flickr, Technorati, YouTube or Delicious by tagging your content with tagnabit (#tagnabit on Twitter).

Tuesday, April 7, 2009

Open (local) Government

See Open (local) Government at its new home on bradley-holt.com.

Last night I went to the Burlington, Vermont City Council meeting to listen to our newly re-elected mayor, Bob Kiss, give his State of the City speech and watch the City Council attempt to elect a new council president. I said "attempt" because, after 14 rounds of voting, they were still deadlocked 7-7 for opposing candidates. However, that's not what I want to talk about. In Mayor Bob Kiss' speech he made the following statement:

My administration worked closely with the Open Government Committee formed by resolution of the City Council. In response to committee recommendations, we’ve included more information about public meetings on the City web-site and the Planning Department added a new section about proposed and pending zoning amendments. During the campaign it was clear that people want to know more about the activities of each city department. Over the next year we’ll look closely at how to finance and build a more uniform, responsive and user-friendly City website that will keep you better informed about public meetings and how you can participate in the process of government.

I'm all for open government and the City of Burlington, Vermont could certainly use a better website. I'd like to give the city some advice on its priorities in building a better website. This blog post is my first round of advice, but I'd like to hear reactions from other web people in and around Burlington — or anyone else who has an interest in our city having a better website! This advice is based on the goals outlined by Mayor Bob Kiss: that the website is inline with the spirit of Open Government, is responsive, and is user-friendly.

First, the website must be accessible and use open standards. I put these two together because by using open standards the website can be accessible. Specifically, the website should use strictly semantic XHTML. This allows for its use in the widest range of user agents (browsers) by the widest range of user abilities (as opposed to disabilities). Its presentation should be progressively enriched through CSS and its behavior should be progressively enhanced through unobtrusive JavaScript. Progressive enhancement means that the website is useful, at its core, without any CSS or JavaScript. It becomes more useful through the use of CSS and then, perhaps, even more useful through the use of JavaScript. However, neither CSS nor JavaScript should be required to access the website's content.

Second, the website should be built using free (as in freedom, not cost) and open source software. It is our government's responsibility to use non-proprietary software wherever possible. When it comes to building websites and web applications, there are no excuses for not using free and open source software. The capabilities of the open web platforms available equal, or exceed, the capabilities of proprietary web platforms. Any custom software developed for the city's website must be licensed to the city under a free and open source license (this does not mean that the city shouldn't pay for this software to be developed).

Third, the city should embrace the concept of open linked data. This means that the city should publish data, not just content. This data should be both human and machine readable. This allows third parties to access raw data and repurpose this data in new and interesting ways. To this end, data and content should be either put in the public domain (which is probably the case already) or use a Creative Commons license. Where possible, the city's website should consume open data published by others rather than duplicating effort. There are several technical approaches to publishing and consuming open linked data including Microformats and the Semantic Web.

I hope these recommendations are useful. Once I've heard some feedback from other web people, I'll forward these recommendations to my city councilors and the mayor. Hopefully they'll find it helpful in improving the city's website!

Monday, March 16, 2009

The Web Is Not A Visual Medium

See The Web Is Not A Visual Medium at its new home on bradley-holt.com.

A claim you may have heard me make before is that the web is not a visual medium. Some of you know exactly what I mean and some of you probably think I'm nuts. For those of you who think I'm crazy, let me elaborate. You, like most people, probably experience the web visually. However, this visual aspect is only one facet of the web. Underneath the visual aspect you will find that the web is a structured, or semantic, medium. This means that people (or even machines) of varying capabilities (as opposed to disabilities), using all sorts of user agents (a fancy way of saying web browsers) can experience this same web non-visually. If built correctly, the same web page should be accessible to you visually as well as to visually impaired people, search engine robots, people that want to use text only web browsers, people using older versions of web browsers (backward compatibility), people using mobile devices, and user agents that weren't even invented yet when the web page was first built (forward compatibility).

There's one catch. There are many web sites and web applications built on the incorrect assumption that the web is a visual medium. The web designers and web developers who build these web sites and web applications break the web. In order to not break the web, web designers and web developers need to use open standards starting with plain old semantic (X)HTML. This semantic (X)HTML can then be progressively enriched/enhanced using CSS (for presentation) and JavaScript (for behavior). This approach works well with the concept of One Web which "means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using."

Craig Cook has a good article about How to Grok Web Standards in which he addresses many of these ideas and more. If you still think I'm crazy, hopefully it's not because you think I'm wrong about the web not being a visual medium. If you don't think I'm crazy then maybe in another blog post I'll talk about why I think that content management systems (CMSs) in general, and WYSIWYG editors specifically, break the web.

Saturday, January 17, 2009

CSS for Web Developers

See CSS for Web Developers at its new home on bradley-holt.com.

The Burlington, VT PHP Users Group will be meeting Thursday January 22nd from from 6:00 pm to 8:00 pm. Since we (Found Line) recently had some demolition - I mean renovations - done we've got a bit more space so thought we'd finally host the meeting. Here's a description of the presentation, "CSS for Web Developers", that Jason will be giving:

Most web developers don't consider themselves designers—and shouldn't. The reality of working on a website or web app, however, is that developers must either wear the designer hat or must interface with a designer/design team. Having a solid understanding of design best practices makes for a more efficient process and a higher quality product. Come hear more about web design and CSS from a designer's perspective. We'll cover semantic markup and its influence on CSS implementation, reset and debug stylesheets, tools for creating and debugging CSS, coding standards, and maybe even microformats if time allows. The goal isn't to convert developers into design experts, but rather to give an overview of an effective design process that works for designers and developers alike.

Jason Pelletier is Creative Director and Web Designer for Found Line. The Burlington-based creative firm develops standards-based websites, product packaging and marketing strategies for growing businesses. Clients include Seventh Generation, Vermont Public Radio, EatingWell and True Body Products. Prior to co-founding Found Line, he managed creative resources for Seventh Generation, and was a designer for Stonyfield Farm.
More details here. Please pass this on to others you think might be interested. Pizza will be provided and we will be giving away a "please don't hurt the web - use open standards" t-shirt as well as a copy of Jeffrey Zeldman's book "Designing With Web Standards". Hope to see you there!

Tuesday, November 4, 2008

VPR Reports Campaign 2008

See VPR Reports Campaign 2008 at its new home on bradley-holt.com.

For coverage of local Vermont and national election news, check out the VPR Reports Campaign 2008 page that we (well, Jason really) put together. The 2008 Election Map is a Flash widget provided by NPR but other than that the page is all XHTML, CSS, and JavaScript (via jQuery and jQuery UI). Check back throughout the evening for updated information and listen to live coverage on VPR starting at 7pm tonight!

Monday, October 20, 2008

VSA Arts of Vermont Website

See VSA Arts of Vermont Website at its new home on bradley-holt.com.

We recently launched the updated VSA Arts of Vermont website. Since VSA Arts of Vermont's mission is to make "the world of the arts accessible to Vermonters of all abilities" it was critical that their new website be accessible. This was a challenge we readily accepted as web accessibility is something we take very seriously.

Web accessibility is fairly straightforward if you take a content-first approach and focus on web standards. The real challenge is doing this and making a great looking website that doesn't have to compromise on functionality. We accomplished this by using semantic XHTML that contains enough structure to stand on its own without any visual representation. Then, this content was stylized using CSS. Finally, some behavior was added using unobtrusive JavaScript (using jQuery). This concept is called progressive enhancement. The final result is a great looking and very functional website that is accessible to all users.

Saturday, August 23, 2008

Northeast Pools & Spas Website Launch

See Northeast Pools & Spas Website Launch at its new home on bradley-holt.com.

We just launched the new Northeast Pools & Spas website. I think Dave and Jason did a great job on the visual design and Liz did a fabulous job on organizing and helping to write the content! I worked primarily on the functionality for the construction and portfolio pages. The site is implemented using semantic XHTML, CSS, jQuery, and Zend Framework.

The cool thing about the construction and portfolio pages is that they use progressive enhancement. What this means is that users without JavaScript (i.e. search engine robots & screen readers) can navigate the content by fully reloading the page on each click. You can try this out yourself by disabling JavaScript in your browser. For users with JavaScript, each click on "next" or "previous" (on the construction page) or each portfolio feature (on the portfolio page) will cause their browsers to load the appropriate content dynamically into the right spot on the page without needing a full page reload.

One of the common problems with this type of JavaScript navigation is that you often break the browser's back and forward navigation capabilities. Another common problem is that you can't bookmark the page or send the link to a friend and have the same content loaded. Because these pages update the browser's "hash" we get the browser's back and forward capabilities as well as bookmarkability. The "hash" is the part of the URL that starts with the "#" character. For example, assuming you have JavaScript enabled you should be able to navigate right to the waterfall photo using the following link:

http://www.northeastpools.net/portfolio/#feature/waterfall/

Critiques are welcome!

Sunday, April 27, 2008

New Found Line Website Launched

See New Found Line Website Launched at its new home on bradley-holt.com.

I am happy to report that the new Found Line website has launched! This new version includes some much needed content and visual updates and is now running in Zend Framework (although there is very little functionality beyond static content). All of the visual effects use jQuery, there is no Flash to be found on the site, and all behavior should degrade gracefully if JavaScript is not enabled. The site is almost entirely valid XHTML and CSS - the only exceptions are a couple of visual effects that required a bit of hacking (but we're hoping to find a valid XHTML alternative). The site has been checked for cross-browser compatibility in 25+ browser/OS combinations. It has also been tested in a text only browser and should be accessible to screen readers. Please take a look and let me know your thoughts - good, bad, or indifferent!

Wednesday, April 2, 2008

POSH In Action

See POSH In Action at its new home on bradley-holt.com.

In a previous post I talked about Plain Old Semantic HTML (POSH). The POSH concept saved us a lot of time and frustration on a recent project. Our task was to create a cold water wash calculator for Seventh Generation's Get Out of Hot Water for Earth Day promotion. The calculator takes four inputs: water temperature, type of hot water heater, type of clothes washer, and loads per week. It then tells you the savings if you switch to (or are already using) cold water, an Energy Star washer, and/or 2X Concentrate Natural Laundry Detergent.

They wanted a smooth user experience. This sort of thing would normally be created in Flash but we decided to use XHTML + CSS + jQuery instead. The first step was to create functional and technical specifications. The specifications (and looking through all of the calculations to make sure we understand everything correctly) were actually a big part of the project. After that we moved into production.

We had two people working on this project - I implemented the functionality in jQuery and Jason implemented the design in CSS. We spent the first two hours working together on getting the semantic XHTML correct. Once we had the semantic XHTML we essentially had an API that we both could use to do our work. It was worth the time upfront getting this part right.

Next we went to our respective corners. I created the jQuery functionality selecting and manipulating the DOM using CSS selectors. Jason used the XHTML structure we had come up with to add CSS and make it all look pretty. The great part was that, since we had come up with the the XHTML structure as the one touch point, we were each able to do our jobs without hardly bothering the other person to ask questions or make changes.

Of course, there were a few changes needed to the XHTML once we started working on our individual pieces - we're not perfect after all. This is were Subversion came in handy. I could change my local copy and when I was sure I wanted to I could commit that change and Jason could update his local copy merging any of his own changes (or vice-versa). The whole process went quite smoothly and we're very happy with the results (the "Switch to Cold Water and Save" calculator on the right).

Thursday, March 27, 2008

Standards

See Standards at its new home on bradley-holt.com.

I'm sure everyone has heard the phrase, "The great thing about standards is that there are so many to choose from." I think we finally have a coding standard for everything we do at Found Line - from PHP to CSS to web file names. We've gone through a couple of iterations and various options but here's what we've come up with.

For application code we've decided to simply follow the Zend Framework PHP Coding Standard. It gives us guidance on PHP file formatting, naming conventions, coding style, and inline documentation. If it works for a project like Zend Framework with a large number of developers it should work for us. Plus, I wouldn't be surprise if many applications start standardizing on Zend Framework conventions so following their standards should put us in a good position when doing integration work.

For id and class names in XHTML and CSS we've decided to adopt the microformats naming principle of dash-separated-lowercase-words. This is the only CSS naming convention I've seen that has a real purpose behind it. We will try to use names from existing microformat standards before coming up with our own. However, when we have to come up with our own names at least they will be consistent with the microformat names.

For files that will be web-accessible we've decided to use the dash-separated-lowercase-words standard as well. This is for a couple of reasons. First, it's consistent with what Zend Framework expects. Second, Matt Cutts recommends dashes instead of underscores as word separators.

Monday, March 24, 2008

Plain Old Semantic HTML (POSH)

See Plain Old Semantic HTML (POSH) at its new home on bradley-holt.com.

I didn't realize someone had coined a clever phrase for this concept. The basic concept of POSH is creating (X)HTML that is semantic, or structural, rather than presentational. Most people experience the web as a visual medium and thus assume that it is a visual medium. Many web development tools (such as Dreamweaver's WYSIWYG editor) reinforce this misconception. The web is in fact a structured medium and one facade to that structure is its visual side that most of us experience every day. People without the gift of sight, search engine robots, and other web crawlers don't experience the web visually. In order to make the web available to the widest audience possible we need to build websites with proper structure first. Then we can add presentation via CSS and behavior through a JavaScript library such as jQuery.

Here are the basic steps to make your next website POSH:
  • validate your (X)HTML - invalid markup is not very POSH at all;
  • use tables only for tabular data, never for layout;
  • use existing elements and attributes if they fit the semantics of what you're creating (e.g. ul, li, dl, dt, dd) instead of generic div or span elements;
  • use class and id names that are semantic, not presentational (e.g. MainNav is semantic but LeftNav implies presentation and is not so POSH);
  • use as little (X)HTML as possible to markup your content.
For those who claim that this is too limiting when it comes to design I suggest you check out css Zen Garden. Very POSH, very cool. Every single design you can pick from uses the same structured XHTML page - the only thing that changes is the CSS style sheet.

Earlier I mentioned something about adding behavior with JavaScript. My favorite JavaScript library is jQuery. jQuery lets you unobtrusively add JavaScript behavior to your (X)HTML pages using simple CSS selectors. This means no inline JavaScript code in your (X)HTML - no onclick or onmouseover event handlers cluttering things up.

POSH + CSS + jQuery (or another unobtrusive JavaScript library) is very cool indeed. But it's more than just cool. It makes your websites easier to maintain and it opens the door to concepts such as microformats - data that is both human and machine-readable. Are you ready to get POSH?