How I’m Using Adobe Bridge
Is it time to ditch IE 6?
A few weeks ago, 37signals brought up a great question -- one that was echoed by a friend of mine just a couple of days ago: When can we finally ditch IE 6?
A few notable companies are taking the first steps. Facebook has been warning users about the perils of using IE for a while. And now it looks like Apple's newest web apps won't be supporting IE 6 at all. Frankly, I'm not surprised. I think they are taking a necessary step forward by forcing users to use a modern web browser. After all, it is 2008, not 1996.
Switching Mindsets: From WordPress to ExpressionEngine
I’ve been a devoted WordPress user for the past four years. I had invested quite a bit of time into learning MovableType when a developer friend suggested I try WordPress instead. The minute I saw its templating system, which is both flexible and easy for a designer like me to grasp, I was sold. It proved to be remarkably "hackable" and at Syracuse University (my previous employer), we frequently used it as a web content management system for clients with simple needs. It worked well enough, and I was content to stick with a single software package—until now.
Before coming to Viget, I never had the opportunity to build a site using ExpressionEngine. At colleges and universities, it’s common to use open-source software, partly because of budget constraints but also because the idea of collaboration and knowledge sharing is so synonymous with academia. So when I was tasked with implementing a client site in EE, the geeky side of me was thrilled while my designer side was nervously wondering if it would require more programmer smarts then I have.
After a quick overview, I dove right in, Googling anything that didn’t make sense. There is plenty of good documentation and a great support forum, so finding answers to my questions was easy. I have good news for all you designers out there: no crazy, black-belt coding skills required. It only took a few days to learn the basics and get my first EE site up and running flawlessly. There were a few things I struggled with, though—for example, mental roadblocks that probably wouldn’t have been as confusing had I not been entrenched in the WordPress ways of doing things—so for other WordPress users thinking of switching, here are a few tips:
- Get over the term "weblog." To me, a weblog meant a big—well—blog, with all sorts of page types and info and categories and whatnot attached to it. In EE, a weblog is a container used to store information and organize your data. I used a separate weblog for nearly every page in the small site, which seemed counterintuitive at first. It makes more sense when you start creating custom fields and assigning them to each weblog. Basic lesson: Don’t be afraid to make lots of weblogs for a single site. You can change your preferences to call it something else (like "section"), but the template tags will still call them weblogs, so I found it easier to just adjust my thinking. (Note: Rumor has it this term is being dropped in the upgrade to 2.0, so in a few months you won’t have to worry about this!)
- Start thinking in smaller chunks. In ExpressionEngine, it’s much easier to break your pages up into structured pieces of content (title, thumbnail image, summary, body content, etc) using custom fields. You can create custom fields in WordPress, but it ain’t easy and it often feels like you’re doing backflips to cobble together complex pages. In EE, you can make as many custom fields (bundled into "field groups") as you want. You then assign the field group to a weblog, and voila! Lovely structured data. The level of control you have is amazing, and it doesn’t require extra downloads or add-ons. Which leads me to #3...
- Say goodbye to crappy plugins. If you want to do anything fancy with WordPress, it requires a plugin. Which is no big deal; downloading and installing one takes all of a minute or two. BUT, you have to sort through a lot of garbage to find a plugin that works and is not in perpetual "beta." Because WordPress is open source, programmers everywhere are writing their own plugins for it. Some of them are awesome. Lots of them aren’t. EE has much more out-of-the-box functionality. The only plugin I installed was for a mail form, and it worked great without any tinkering. The add-ons in the ExpressionEngine library have been tested and accepted by its creators, so you can expect them to work.
- Finalize your design before moving it into the system. My original xHTML/CSS templates and the templates I ended up with in WordPress usually weren’t all that different, so modifying them outside of the editor and then copying/pasting them in wasn’t a big deal. In EE, my original templates got chopped up into small chunks right off the bat. This made big design changes overly confusing. Next time around I’ll spend more time working out design details before I move the display templates into EE.
- Expect to spend a while finding things in the control panel. It seems unnecessarily convoluted. It took me a while to find things and memorize the patterns. Create a weblog, then create a field group with custom fields, then assign that field group to a weblog, then make a post in the weblog.... yikes. It felt like a lot of steps. I know it’s partially because you have such fine grain control over things, but I’m sure the interface could be simplified so everything wasn’t five clicks away. Saving graces: you can use the back button, and you can open multiple tabs to work on things. I often keep my stylesheet template in one tab and another template (like a page template) in a separate tab so I don’t have to navigate back and forth quite so much. It appears the upcoming ExpressionEngine 2.0 upgrade will be a huge improvement, so I can muddle through until then.
- Say goodbye to PHP tag soup. My EE templates look so pretty and streamlined compared to my WordPress templates! With so many built-in functions, there’s just a lot less code to look at. All I have to say is, HOORAY. I’m obsessive compulsive by nature, so a few lines of clean code makes me much less anxious.
Shifting my thinking (and learning a CMS new system) was well worth the effort. I have found EE to be much more powerful than WordPress, and not nearly as hacky. I’m looking forward to working with it more in the future. There seems to be no end to its functionality, so it’ll keep me busy for a while.
A few sites I found especially helpful:
Simple jQuery Solution To A Simple Problem
When building out the Viget Extend blog, I really wanted to give some special attention to the real meat of the content: the code blocks.
After looking at some other dev blogs, it seemed like there were two types: Big Ol' Blocks and Little Snippets. The big ones deserved the full treatment: Scrollbars, full colorization, line-numbering, all of it. We accomplished this with SyntaxHighlighter, a cool JS file that handles all this work. The developers just need to slap a name="code" on their pre tags, and SyntaxHighlighter formats and colors everything properly. (View an example of the treatment)
The shorter code snips were a little trickier. We didn't want them to linebreak automatically (like code here at Inspire does) for accuracy reasons, but we didn't want to apply scrollbars to something as simple as a single line of code. The solution was a quick jQuery idea: Expanding the code block on hover, so they grow to the full width of the page.
$("pre").hover(function() {
$(this).animate({ width: "765px"}, 250);
}, function() {
$(this).animate({ width: "437px" }, 250);
});
This was all right for a while, but soon we began running into posts like this one, where one or more of the blocks just didn't need the expanding treatment. In these cases, the jQuery effect was just annoying.
For a while, I just let it be, but this morning the answer hit me: We could probably do something to get the width of the code block's contents, and trigger the effect based on whether not the content width exceeded the block's. The first part was just setting up a variable to get the widths of both the block and the block's contents:
Continue reading "Simple jQuery Solution To A Simple Problem"
Google Now Indexing Flash Content
I found it hard to contain my joy when Google announced on its Official Blog that it is now able to index Flash content. Hooray!
According to Google, they have perfected an algorithm, "that explores Flash files in the same way that a person would, by clicking buttons, entering input, and so on. Our algorithm remembers all of the text that it encounters along the way, and that content is then available to be indexed."
This is not in the future; Google is indexing Flash sites right now.
While this is a huge step in the direction of having Flash files as crawlable as HTML files, some major hurdles still need to be overcome. Currently, the only content being indexed is embedded directly in the swf. "This includes Flash ‘gadgets’ such as buttons or menus, self-contained Flash websites, and everything in between," as well as URLs. It doesn’t, however, index content loaded externally from HTML, XML, or other swfs. Those files will be indexed as a separate resource and not associated with the parent Flash file.
Another major limitation is the inability to see Flash files loaded using Javascript. This is unfortunate since a large number of Flash files are embedded using swfObject. Also, they do not index non-textual content like images or FLV files; essentially, Google’s only indexing text.
As a Flash developer and designer, I’ve learned that the greatest limitation to Flash is its separation from other elements on the page. With getting information in and out of Flash using External Interface in Actionsript—and now that Flash content is now beginning to be indexed—the tide is turning for Flash accessibility.
Read more about the SEO-related benefits of this new announcement from our very own faux-hawked Josh Chambers. (And yes, Josh, a post on how to design SEO-friendly Flash is forthcoming. And no, you still can’t sit at the designers’ lunch table).
Typography Tuesday: Why Type Shouldn’t Be Images
For those who have survived a traditional education in typography, the limitations of the web can be a very scary place (there was a time when I was even scared... very very scared). On more than a handful of occasions, I have been asked by people designing for the web why making text an image is a bad thing, and here are my answers:
Reasons why you should never make body-copy an image online:
- The information is not selectable for those who may want to copy and paste it.
- The text is not resize-able, making it very difficult for those who prefer larger type to scale it up to read.
- It is not accessible by a screen-reader for those who are visually impaired.
- It doesn't allow content to be; indexed by search engines.
Continue reading "Typography Tuesday: Why Type Shouldn’t Be Images"
How To: Make The Viget Inspire Author Thumbnails
Since Viget Inspire blog launched, I’ve received a lot of questions about the little user thumbnails we made for the Viget designers. Is it just a Photoshop filter we slap on carelessly? Are they painstakingly drawn by hand and watercolored over a period of several hours? The answer is (unfortunately), neither as cool as hand-drawing or as easy as a filter, but we’ve got it down to a pretty streamlined process at this point.
Like the background “how to” post from last month, this tutorial has a lot of of textures and hues, manipulated and blended in the layers palette.
Continue reading "How To: Make The Viget Inspire Author Thumbnails"
Recent Comments
JQuery is cool. I recently combo’d it with shadowbox.js to make a gallery of recent projects. The cycle.js plug-in is also worth looking at for lots of ‘Flash-like’ transitions and animations.
- Website Designer Perth on 'Fun With jQuery's Animate() Function'.
- Website Designer Perth on 'How I'm Using Adobe Bridge'.
- Mindy Wagner on 'How I'm Using Adobe Bridge'.
Subscribe to Comments RSS