pablo estrada

A simple AM/FM radio

pablo — Mon, 05 Mar 2012 05:02:29 +0000

I’ve been working on building a simple AM/FM radio, operated through just a few buttons and knobs, and with decent audio quality. It has a simple display and fits in a fairly compact package, more or less the size of hardcover book.

Not long ago, I would have built a traditional receiver design using discrete components, probably a superheterodyne (used in the vast majority of inexpensive alarm clocks and portable AM/FM radios lying around in homes) or perhaps a regenerative receiver for novelty. Today, the popularity of small, digital, low-cost devices with integrated AM/FM radios has driven more parts of the radio into integrated circuits (though often keeping the superheterodyne design).

Radio hardware

I was excited to find the Silicon Labs Si473x family of radio ICs. The Si4735 includes AM/FM/SW/LW reception in a single IC that requires just a few external components and two external antennas. Essentially, the chip replaces what traditionally requires a few dozen discrete components and it eliminates manual adjustment of tuning sub-circuits.

The reduced bill of materials doesn’t simplify everything. Instead of sourcing, assembling, and tuning discrete RF/IF components, the radio IC must be interfaced over a serial, 2-wire, or 3-wire connection. Silicon Labs provides guidance through its datasheet and a few application notes, but I found some steps, such as the power-on sequence, could have been more clearly documented.

Sparkfun sells the Si4735 AM/FM IC and an Arduino shield that includes the IC, a crystal, and a few components that support the AM and FM antennas. Using the shield absolves one of any SMD soldering or source the diodes, crystals, and inductors that support the chip.

Sparkfun wrote some code to help users get started with the shield, and a few others have extended it and added some very cool features, such as querying the IC to get its current frequency and adding RDBS processing to get FM station and programming information off the air. Wagner Sartori Junior (Trunet) and Jon Carrier added quite a bit of this functionality, so it’s thanks to them and Sparkfun that getting the Si4735 up and running with these cool features is so easy.

Other hardware

I needed some other hardware besides the Si4735 shield and Arduino board. For the display I used a serial enabled white-on-black 16×2 character LCD display. A rotary encoder is used as the tuning knob and band-switching push button, and a simple 10 kΩ potentiometer controls the volume. The Si4735 support volume adjustments via software, but I chose an analog potentiometer for simplicity.

The Si4735 shield outputs a very small audio signal (I haven’t tried to measure it yet), so an off-shield audio amplifier is mandatory. I opted for a mono amplifier based on a single NE5534 op amp. It has good performance, is reasonably priced, and doesn’t require too many supporting components. I considered adding stereo support but the radio didn’t require very high quality FM output, and there is a stereo headphone jack in case it’s really desired. The circuit I used is from http://www.electronics-diy.com/

Arduino, shield, and LCD

Software

Jon Carrier’s code is hosted on Github and includes example sketches. I played with them quite a bit before using bits and pieces in my own sketch. Jon put a lot of effort into making RDBS work, and while it’s quite cool to see the station and song information scroll across the screen, I don’t use it. I do like to see the station’s callsign, so I kept this part and display the callsign on the second line of the LCD display. Many stations don’t transmit RDBS data, so in case the station callsign is unknown, my LCD doesn’t display any information on the second line. I also removed the volume and seek states, since I’m handling the volume level through an analog potentiometer and I don’t care for a separate seek mode at this time (perhaps I will later).

I experienced a few of the issues that have been brought up in the comments on Jon’s page. In particular, I frequently saw the system start or very quickly jump to its initial frequency + 0.1 MHz, and I also found the LCD screen locking up when I turned the rotary encoder very quickly. I used a serial connection of 9600 baud (the default value for the serial enabled LCD) and I wasn’t able to really troubleshoot this behavior. I’ve read in a few places that these LCDs can lock up when they receive data too quickly, so my wild guess is that this was somehow happening, perhaps from other things coming unintentionally on the serial line. A few times I also reproduced the 655.3 MHz and 0.0 MHz frequency change that Jon mentioned, even though the code is supposed to restrict the frequency to the broadcast band range when using the rotary encoder for tuning. It seems some of these issues may come from the rotary encoder, debouncing (or lack thereof), and/or the rotary callback function.

There are many sample rotary encoder implementations, some using interrupts, some using the digitalRead function in the main loop, and so on. Since the tuning knob and responsiveness is so central to the radio’s operation, I wanted to make sure the rotary encoder’s data was reliably read and displayed on the LCD, even for very fast rotation rates. I made a separate sketch to prototype this part of the system and ended up using Arduino’s built-in interrupts based on the code found here. Once this was working on its own, I integrated it as the interrupt and callback in the radio sketch.

An important note about using the shield

The Si4735 and the shield communicate through 3.3V, not the 5V that boards like the Arduino Uno, Duemilanove, and Diecimilia expect. This is documented in the comments of the Sparkfun product page and on a few forums/blogs. The two generally accepted workarounds are to:

Insert a silicon diode between pin D12 and the GPO1 line on the shield. Trunet also documents how to do this on his wiki.
Use a level-shifter to convert between 3.3V and 5V signals.

Both are hacks for using the shield with 5V Arduino boards and require a bit of surgery in severing a trace on the shield. Using the level-shifter is the more “robust” approach and I chose this because it gives the flexibility to send and receive SPI commands to the Si4735. Inserting the silicon diode allows reading SPI data, but not writing it. However, it takes up space on the shield and limits the possibility of adding other components on top of it. Another issue with the shield is that it connects the GND and AREF pins – meaning AREF is permanently tied to ground, unless you break that connection. This is important if you need to use the Arduino’s analog pins.

Next steps

The radio works as designed, the audio amplifier is built out on a protoboard (and is certainly loud enough), and the display and tuning are smooth, so all that’s left is to connect the power supply, mount the components inside the enclosure, which is made from Ampersand Hardbord. The tuning knobs are simple diamond knurled cylindrical knobs from Digikey.

Conferencing

pablo — Fri, 17 Dec 2010 02:13:46 +0000

My participation in conferences is almost always limited to the speaker’s side, behind a podium, or simply at a booth or on the show floor. I rarely participate as an attendee, but recently I had the chance to attend a conference simply to, well, do the things one does at conferences: attend talks and sessions, meet/greet others, and go to the demo booths! Sitting in the audience I realized some speakers kept me quite engaged and others let my attention lapse a bit during their talk. Some conclusions from notes I took during talks I attended:

Don’t labour on the obvious
If you represent a large, well-known company, say Intel* for example, but you are talking about a narrower topic, don’t spend five minutes repeating what your company is already known for (in Intel’s case, that would be semiconductors and processors). It’s ok to discuss the larger area to give context and perspective, but please don’t spend more than absolutely necessary (yes, Intel is in the semiconductor and processor businesses, I GET IT).
Unreadable slides are pointless
If I can’t read the material on the slide it’s almost pointless to present it, especially if it has all text and no visual cues. And then to go on and read the unreadable-to-me text is simply punishment.

Easily digested slides build rapport
As a counter to the previous point: easily read and digested slides are the opposite of pointless. Rather than alienate the audience, they help build rapport with the speaker as the audience internalizes the content and forms an opinion about it. And an easily digested slide ensures the audience won’t drown in details or attempt to listen to the speaker and read the slide at the same time, which may reduce comprehension.
Simple is beautiful
Be clear, confident, and concise. Make a point and back it up. Don’t try to make ten points in the space of five, and don’t make references to related points unless they are in proper context. Stay on-topic and don’t ramble.

Make it worthwhile
Make it valuable to the audience. If the objective is to introduce your product or service, make sure the audience leaves with a clear understanding of it. If the objective is to demonstrate complex and difficult achievements, let the audience leave with a sense of wonder. Don’t regurgitate a press release or blog. In most cases, people are in the audience attending your talk and skipped others that may be of interest because they felt yours would be more worthwhile.

By no means is this list even remotely comprehensive or unbiased, rather, it has just a few things I’ll keep in mind the next time I’m behind the podium.

pure

pablo — Wed, 08 Dec 2010 04:41:22 +0000

I do hope HTML5 and CSS3 are not the next

of the web.

I kid. Mostly.

VII Network photographer Donald Weber: Interrogations

pablo — Wed, 01 Dec 2010 04:58:09 +0000

VII Network photographer Donald Weber’s series Interrogations, a work-in-progress, is captivating and provocative:

http://www.viiphoto.com/showstory.php?nID=1180

If you’re not familiar with his photography, I encourage you to see some of his other projects, such as:
Bastard Eden, Our Chernobyl or Zek: In the Prison of the East.

Web2py: an application framework

pablo — Sat, 14 Aug 2010 22:46:19 +0000

Recently I’ve been using web2py as an application framework and front-end structure for a web page I’m extending. This is rooted in previous pages, tweeting the world cup, which then led to dropping tweets into a SimpleGeo layer. Web2py is described as a

Free and open source full-stack enterprise framework for agile development of fast, scalable, secure and portable database-driven web-based applications.

It is written in Python and was created by Massimo Di Pierro. He is amazingly omnipresent in support and development of web2py.

When considering how to extend the tweet-dropping capability, I looked at a few options. The program to record the tweets into a SimpleGeo layer was already written in Python so I looked at web applications and frameworks built around Python or at least with Python support. Looking back a bit, it seems a lot hinged on one program which ended up being but one very small element in a larger structure. But I was enjoying fiddling with Python and there are plenty of frameworks to choose from. I didn’t have much time to evaluate and test different frameworks so I wanted to make a decision quickly.

A framework that naturally comes to mind is Django. It’s popular, widely used in production, well documented, and actively supported through the community. Others like CherryPy and webpy are also available. After the head-slap that was realizing web2py is not related to webpy, I took a closer look and decided to go with web2py. My need was mostly to quickly make a prototype, and while the others would have been fine for this also, it seemed web2py would allow me to get up and running as with minimal learning of new template languages and other overhead. It also seemed to be easy to deploy to Google App Engine. Having limited information I knew there was some risk I would run into a roadblock while carrying a lot of sunk time into the development, but I estimated it was reasonable.

Now with an application framework comes MVC, hand-in-glove. I’d never used an MVC framework so I was completely green. MVC is a pretty broad model but it’s often seen in web frameworks such as Django and yes, web2py. web2py follows the MVC model but as I would soon learn, it is quite flexible. My use case really didn’t require many views at all, and probably only a couple of controllers at most. The flexibility of web2py allowed me to rapidly prototype what I wanted while still retaining the robust structure that MVC brings, and yet at the same time mostly abstract this from the user and even myself to some extent. It really seems to be the best combination in that sense.

As I investigated and experimented with the most suitable implementation of web2py for my need, I found an explanation on the difference between push and pull frameworks by Massimo:

There are two types of frameworks push and pull. In a push framework (like web2py, Django, Rails) the URL is mapped into a function, which returns data (in the form of a dictionary) and the data is rendered by one view. In a pull framework (like Struts and JBoss) the URL is mapped into a view which calls one or more controller functions. From your question I assume you have a pull framework in mind. You can mimic a pull framework in web2py in multiple ways. One way is via ajax requests…

This was exactly the flexibility I was looking for and just didn’t know it. I needed one or two views initially, and several groups of controller functions exposed within the same view. Reading this message gave me confidence I wasn’t going down a deep framework crevasse with no rope to haul myself back out if needed.

The learning curve for web2py is quite reasonable. It doesn’t have a separate template language per se, but it does have a structure and reusable components that, along with built-in helper functions, make prototyping speedy. And it allows Python code to be typed directly into .html files, by enclosing the Python code within {{ }}.

Extensive documentation for web2py is easily found and you can start by going through the tutorial on the web2py website. It’ll take you from rendering a simple web page to creating a wiki in one chapter! Other examples demonstrate some of the easier-to-implement functions and they really show-off how easy it is to get something functional up and running.

A single serving site

pablo — Fri, 30 Jul 2010 05:05:53 +0000

Just because: http://isdoloresparkclosed.com/

(http://en.wikipedia.org/wiki/User:Tlogmer/Single_serving_sites)

Dropping Tweets into a SimpleGeo Layer

pablo — Wed, 14 Jul 2010 01:23:23 +0000

The mandated decay imposed on my previous experiment due to restricting Twitter searches to no more than a week (or so) in the past had me thinking of a more permanent method to archive tweets and their geo-location information. On the same day I wrapped up SF Tweets the World Cup 2010, Andrew at SimpleGeo wrote about how to map Foursquare checkins to a SimpleGeo layer. This way the checkins are all visible on one layer and the user can perform spatial queries on them.

Andrew’s example Python script looked simple enough that I took it as a base to do the same as I’d essentially done with the World Cup tweets, but instead of plotting tweets on a Google map they would be inserted into a SimpleGeo layer. This time, rather than searching on a keyword and collecting any returned results, the purpose was to collect tweets from a Twitter user, in this case, my own.

I could have accessed the Twitter API directly as I did for the World Cup tweets, but the availability of some simple and excellent Twitter clients/libraries for Python made it too easy to avoid. I quickly found a few and settled on Tweepy, by joshthecoder. It’s described as a Python library with “complete coverage” of the Twitter API. And just as cool, it has reasonably detailed documentation. Sold!

The first step was to get Tweepy returning tweets. For a single user’s timeline Tweepy provides the method tweepy.api.user_timeline, one of several timeline methods. By default this returns the last 20 tweets as objects available for manipulation, including the fields of interest here such as coordinates, if available, the tweet ID, date and time, and so on. It’s quite easy to get Tweepy talking with Twitter and in minutes I had my latest 20 tweets on the screen. Since I’m no Python guru, it took me a bit longer to get familiar with the objects returned to me and their available attributes and methods. Someone even slightly Python-adept could have breezed through this in just a few clock cycles, but it’s part of the learning process for me.

Assigning latitude and longitude is pretty easy as long as the tweet has the associated tweet.geo data. As I noted in the World Cup blog post, this is often not the case. This was an important reason to plot my own tweets: I have control over the geotagging of each tweet, and don’t have to depend on others to do it. If I were to grab tweets from the search API or the public timeline, it’s likely a small percentage would have latitude and longitude information.

But wait, what about Twitter places? Yes, users can attach place-based geographic information to their tweets. This allows the user to reveal the general location from which the tweet is sent without revealing the exact coordinates. Naturally, a bounding box described this area on a map, and Twitter has associated a unique URL for each place. In my case, many of my tweets are sent from the Richmond in San Francisco. The XML attached to my tweets sent from the Richmond and identified as such is this:

 

64be9bb264eb76c1 Central Richmond  Central Richmond, San Francisco   neighborhood   http://api.twitter.com/1/geo/id/64be9bb264eb76c1.json    37.77212997 -122.49240012 37.77212997 -122.47178184 37.78442901 -122.47178184 37.78442901 -122.49240012  The United States of America

A bounding box like this is not difficult to deal with, but there should be some consideration on how the information is presented when it is in the same context as markers on a map with lat and lon coordinates. But that’s a digression…

Once the proper modules are imported, the two key components to call are the SimpleGeo Client(MY_OAUTH_KEY, MY_OAUTH_SECRET) and the Tweepy tweepy.api.user_timeline(MY_TWITTER_USERNAME). All that basically remains is to throw objects from one universe into the other. Tweepy returns status objects and the SimpleGeo client adds records to a database.

My own tweets don’t always have associated coordinates, so even though I can choose to tag or not tag a tweet with coordinates, it’s smart to check and ensure a tweet has the necessary properties before trying to add it to a layer. If a tweet has coordinates, its status object will have an array in tweet.geo['coordinates'] of the form [lat,lon]. That’s simple to verify and require before calling the function to insert the object into the layer. Some other properties are useful: the tweet’s URL, the place (this could be useful later even if the lat,lon coordinates are included), the text of the tweet itself, and the time-stamp.

I ran into one hiccup with the time-stamp with regard to time zones and offsets. Each Tweepy status returns a time-stamp in GMT form. When I first added these to the SimpleGeo layer they had an offset of +7 hours (the magnitude of the difference between PDT and GMT zones). To account for this I manually subtracted the time zone offset from the tweet’s time-stamp, and that fixed it. I peeked at the Tweepy code to see if I could do it more elegantly, but I’m not sure I understand how it handles locale as there is some comment about backward-compatibility with Python 2.4.

It’s also quite simple to delete records and I did this a few times as an experiment and to check I was manipulating the layer’s objects correctly. A simple call to SimpleGeo’s client.delete_record will delete the object by passing the layer and object ID.

I didn’t change anything from Andrew’s Foursquare example to add the objects into the record and it worked! Next steps might be to add duplicate record checking, pagination, and spatial queries into the SimpleGeo layer. Thanks to Andrew for his help on getting my example to work – he gave me some pointers and was readily available to help me out.

The .py file is available here: http://gist.github.com/474741

Tweeting the World Cup

pablo — Sat, 10 Jul 2010 02:03:56 +0000

A few weekends ago I went down to the Haight to watch the USA vs England World Cup match. I’ve watched other World Cup matches at Mad Dog in the Fog but I seriously underestimated the crowd that would ride the wave of USA World Cup mania and try to cram into one of the more popular viewing-pubs. Fifteen minutes before kickoff a long line had already formed, complete with metal barriers and an anxious crowd. Instead of waiting impatiently for the odd fan to leave Mad Dog and let the standby-line inside one-by-one, I went two blocks west to Danny Coyles. It was also full, but only to the edge, so I managed to grab a spot just outside the open window with a clear view of one of the screens. As I snuggled into the optimal viewing position, I wondered how many people had tweeted from inside Mad Dog, perhaps noting how crowded it was inside, or even if others had tweeted about the long lines well before the match started. Naturally, this can be searched, but I also wondered where people might be tweeting as the game started. Where people heading over to other pubs, just like I went to Danny Coyles? It would be really sweet if I could pull up a map around my current location and find tweets relevant to my interest (in this case, the USA vs England match), and read them on a location-by-location basis. Surely, this has been considered before, right? Hmmm…

If you’re interested, the site is here: http://www.pabloestrada.us/worldcup/

I wondered how difficult it might be to plot out local tweets on a Google map and see their geographic distribution, so I checked out the Google Maps API on a recommendation from a friend that the API is well documented, easy to understand and straightforward to implement. Indeed, throwing a map onto a web page is almost trivial and all that’s needed are some very basic parameters including latitude and longitude coordinates that define the map’s center. Easy enough, I thought. The next step was slurping some tweets from the Twitter API.

Pulling data from the Twitter search API is pretty straightforward and has been implemented elsewhere. Choosing to use jQuery not only simplified data retrieval, but also put the broad set of jQuery functions and plugins within reach. jQuery’s widespread use and well-docmuented API shortens the time to implementation for me. Naturally, I depended on Google search. However, many implementations use the JSON format instead of JSONP. I understand this is done for security reasons, and this necessitates the use of a server-side proxy. I chose JSONP simply because it doesn’t need the proxy.

Twitter’s advanced search page allowed me to construct the query and cross-checked with what I’d written based on their API documentation for the Search API. The documentation covers all the optional parameters and provides simple examples of their use, however, I would only later realize at least two parameters are missing range (allowed values): the since and until parameters; they allow the search to be restricted to a date range. I wished to restrict the search over given match dates to only return results that were tweeted during (or near) the game. The finest resolution for this restriction is entire days, so it’s not possible to restrict the search to within certain hours of a date.

At first I tried to use $.ajax to make the query as it provides a bit more flexibility than the $.getJSON function. At this point I was using mostly Google Chrome for testing and kept getting null as the returned value. In tracing this down, I found there was an unexpected character in line 1 of the HTML file, causing an Uncaught SyntaxError (Unexpected token) as a result. That seemed odd, because I certainly wasn’t changing the first (or first few) lines of the HTML file. After some searching I found this may be related to an old defect in Chrome. It seems a BOM character is inserted at the front of the JSON response, according to this: http://code.google.com/p/chromium/issues/detail?id=176. To avoid it I instead used $.getJSON. It has a bit less flexibility than $.ajax, but I worked around that by simply defining the callback function in $.getJSON to call another function, which I constructed separately. This also kept the code a bit more modular and easier to read. Once I had a proper query constructed and had a proper grip on the returned data, I saved the JSON response to a test.js file so I could keep developing without having to poll the API each and every time I, say, changed the color of some text on the page. It also froze the search results so I could test cases of tweets with different location results.

As I looked over the search results, I realized a very low percentage of tweets are tagged with geo-location data. Those that are make it very easy to jump from tweet to Google map, since the geo-tags include latitude and longitude – perfect for placing on a map! Unfortunately, most tweets don’t have this data. The Twitter search API makes it easy to restrict a search to a geographic area; my search was restricted to a 12 mile radius around San Francisco. I quickly realized the variety of location information among the tweets. Some users populate their profile with a location description: this could be San Francisco, or SF, or San Francisco, CA. Others populate a location that includes latitude and longitude, but is prefixed by a string such as “iPhone: ” or “ÜT: “. This really reduces the value of placing the tweets on a map of local (city) scale. When comparing tweets between different cities, this is perfectly valid and useful, and is probably sufficient resolution to make a geographic comparison. For example, one could plot out tweets from San Francisco and Los Angeles on one map. In that case, it may not be necessary to know exactly where in San Francisco a tweet originated. But in my case, I wanted to distinguish tweets sent from Mad Dog vs Danny Coyles, and this level of resolution just isn’t enough.

I decided not to plot tweets with unspecific location information on the map. This would not be intuitive because a user naturally associates a pinpoint on a map with that specific geographic location. Where should tweets tagged with the location, “SF,” be placed on the map? I considered placing them all in the middle, or very close to the middle, of the city (this is somewhere in or near The Castro). But then how could they be differentiated from a tweet that really did originate in The Castro and was tagged with latitude and longitude coordinates? I decided to list the tweets below the map but only plot tweets with coordinates onto the map. I used some simple regular expressions to match a few variations in location, for example, the iPhone or ÜT prefixes to coordinates.

The next step was to automatically trigger a search based on a World Cup match. The user shouldn’t have to type in “#GER” to search for Germany on the date of the Germany vs Spain semifinal. I placed all 64 matches on the right side of the page with the score for each team. Using small flag icons next to each team name, I had javascript extract the team name from the img src attribute of the flag to automatically trigger a search for the corresponding hashtag for that team. I also encoded each a href attribute with the match number so that the search could key off an array of 64 date values and restrict the search to the match date. This was pretty easy using regular expressions, but I later realized that using regex was completely overkill since the length and format of each img src string does not change for all the teams and all the matches. Only later when I tested in Internet Explorer did I realize this. Thanks, IE, for reminding me of the stings developers endured in years past when trying to write cross-browser compatible code for Netscape and IE 4, and who knows what other nightmares. Internet Explorer treats calls to String.split() with regular expressions differently than other browsers. But of course! I found a brief explanation on a page titled Inelegant JavaScript. Woohoo! In the end, it was pretty easy to slice() the string I needed and that took care of it. But hey, I learned some simple regular expressions and browser inconsistencies, right?

The next step was to take the process location information from the relevant tweets and place each one on the map. I used each team’s flag in place of the default Google map marker. If more than one team’s tweets were to be plotted on the map, this would produce a visual display of the distribution and relative magnitude between groups of tweeters mentioning each team. At some point this could even go further and plot some type of mood indicator for fans of each team, but that would require more processing and estimation of the tweet text and some guessing based on that. My map only plots one team at a time, but that’s not hard to change. In fact, I had some trouble not to do that, as I wanted to clear the map of all flags when a new search was triggered. The previous version (V2) of the Google API had a method to clear markers, but the current version requires each marker to be tracked so it can be individually erased when the clear marker function is called. Luckily, Stack Overflow came to the rescue with a solution for V3.

I made a function to take the JSON data and clicked-on team name. The function dynamically appended the contents of a

with the user profile image (avatar) of the Twitter user, the location information sent with the tweet, and the contents of the tweet. For tweets containing coordinate information, a function is triggered to plot the tweet on the Google map with the corresponding team flag. That function also creates an InfoWindow (tooltip) containing the user profile image and tweet contents, making each flag clickable, just like default Google markers. That adds a bit of personalization to each tweet on the map, and it’s cool to see the user’s profile next to their tweet and team flag.

After everything was working as expected, I used another function to build the search string URL based on the team name, match date, and some Twitter search parameters. Once everything was working I disconnected the test.js file and connected the code to the Twitter search API using this function to provide the input to $.getJSON.

There are still possible improvements, for example, I’ve done nothing to consider the speed of searches or anything to make the content update look a bit more smooth. There are also no graceful failures, for example, if a search yields no results or fails for another reason, or if a user clicks on a match in the future (because this triggers a search on a future date). Currently, nothing happens and no error is presented. Finally, this whole experiment will expire in its current form a few days or weeks after the end of the World Cup when the match dates become too old for the Twitter search API. Just like the tournament, it’s been fun while it lasted.

Gearing Up for ARG vs GER

pablo — Sat, 03 Jul 2010 02:33:34 +0000

And to warm up, a New York Times article on Maradona.

An Apology to Maradona, a Rollicking Genius, By ROB HUGHES

Should this match live up to expectations, it will be historic.

Class Abuse

pablo — Sat, 26 Jun 2010 03:08:17 +0000

The introductory video on the Compass site really intrigued me – http://compass-style.org/docs/.

Compass is described on its site as:

“a stylesheet authoring tool that uses the Sass stylesheet language to make your stylesheets smaller and your web site easier to maintain. Compass provides ports of the best of breed css frameworks that you can use without forcing you to use their presentational class names. It’s a new way of thinking about stylesheets that must be seen in action!”

As I watched, I thought: Yes! It’s true! CSS can really suck sometimes! I loved the comment, “ferociously abusing your classes.” As CSS has evolved, it seems abuse has become more and more common, and maybe necessary, and people hammer away and pound it into submission. Grids! And with CSS3 grinding its cleats into the grass, I’ve seen sites emerge with complex and delicate layouts that show off the power and magic, and not least of all the promise of –the future–.

But just because you can doesn’t mean you should. I’d like to use CSS(3) as a way to move away from the extremely carefully positioned and crafted layouts that, even though technically impressive, are visually confusing and crowded. Somewhere, there must be a former HTML 4 hack who labored so hard, for so long, to implement something similar using nothing but and cells who surely feels like the ability to do this with (relative) ease is better than nirvana. Liquid, fluid, blah blah blah. I don’t mean to say I don’t admire and desire a carefully, precisely positioned and crafted layout. I do. I just don’t think everything should be placed on n-th pixel resolution just because we can.

Two examples:
1) UX Magazine

Is it cleanly organized and orderly? Certainly it is. Is the text highly readable? Mostly yes, except for some of the categories that are the top heading in each box. Is it cluttered? I think it is. My eyes go nowhere and everywhere at the same time. It’s easy to understand the navigation and news sidebar, however, the center content seems all to have equal relative weight. Maybe that’s the intent, as the footer notes the content is based on articles published one-at-a-time. The quote from Bertrand Russell looks as if he tweeted it – I like that.

2) Jeff Croft

This looks just as organized and orderly, and in my view, much easier to understand visually. It lets the reader feel in control of the visual content and not barraged with everything at once. I don’t like everything there, but it’s the style of site I’d like to make.

Searching around for CSS frameworks I found this excellent article from Eric Meyer about the lessons of CSS frameworks. Great tips to keep in mind, especially before diving into frameworks.

This site is based on a WordPress theme, which itself is based on a 900 grid system. As I hacked at it, I mostly stripped away from it, partially because it had more functions than I wanted or needed, and partially to just simplify it (instead of just ignoring unused parts). My frustrations took root in the naming conventions and myriad div and span elements.

, anyone? How about A collection of 224 Grid and CSS Layouts? No, thanks.

Anyway, this isn’t about being anti-grid. Compass looked cool, at least from its introduction. Naturally this led me to Saas. The ability to assign and use variables, perform simple math, and even simply nesting are appealing enough to give it a try. Functions and mixins? Woah. Now, I’m not sure if this will move away from such lovely-named classes, as was claimed (but not actually done) in the introductory video. But leaving that aside, I’m still tickled enough to give it a try. Their tutorial gives a quick overview.