Mindy Wagner, ON THE TOPIC OF General and Tips and Tricks

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:

1. 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!)


2. 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...


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.


4. 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.


5. 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.


6. 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:

• Veerle’s EE Posts
• How to make a "cheat sheet" listing your various element names
• The official Expression Engine wiki
• Boyink!’s "Building an ExpressionEngine Site" series
• Doug’s posts on Building Viget.com in EE - Part 1 and Part 2

Leave a comment ( 34 )

Doug Avery, ON THE TOPIC OF Javascript

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"

Leave a comment ( 6 )

Erik Olson, ON THE TOPIC OF General

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). 

Leave a comment ( 5 )

Samantha Warren, ON THE TOPIC OF Tips and Tricks

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"

Leave a comment ( 7 )

Doug Avery, ON THE TOPIC OF Tips and Tricks

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"

Leave a comment ( 10 )

Doug Avery, ON THE TOPIC OF Development

In my last EE post, I covered some ExpressionEngine tricks we used for managing multiple sites, removing the /comments URL segment, and setting up a simple “Preview” function.

This time, we’re going to use URL segments to create some dynamic user profiles, sort a portfolio page, and make a flexible upcoming event list.

Continue reading "Building Viget.com In EE (Part 2)"

Leave a comment ( 7 )

Tom Osborne, ON THE TOPIC OF Favorites and Tips and Tricks

Sometimes you need to get a bunch of ideas in a short amount of time. Its not always easy for one person alone (though easier for some than others). Collaboration is key whether it be collectively or individually within a working group of people. Team design is one of the benefits of working in an agency or inhouse studio.

In borrowing from an idea that originally began in partnership with some of my former colleagues, the design team at Viget recently embarked on our first Design Flash Mob (DFM). You may have heard the term 'flash mob' to describe wacky collaborative events such as massive pillow fights where a large group of people gather in a single place, fight each other with pillows and leave with a pile of feathers on the ground as a residual reference to the event. The basic steps of these events are as follows:

1. Plan and promote in advance of the event. What do you hope to accomplish? When and where should this take place?
2. Gather at the designated time and place.
3. Act upon on what you set out to do.
4. Disperse and reflect on the madness.

In the spirit of design synergy we can take these steps and use them to collaborate quickly on things like logo designs, t-shirt ideas or rethinking user experience problems. Plan to do something about a week out. Think ahead about what you might want to create. When the time comes you'll be ready to jump in and start designing in a rapid but refined way. Take a morning or afternoon to hold the event. At the end, take time to talk about it and share different perspectives on working under pressure.

Another important aspect of a design flash mob is that it should not be treated as a competition. Even if one design is to be chosen it should be a democratic effort including those who played a part in the event. Benefiting the greater good should be the goal. In effect, the whole is greater than the sum of the parts.

One great place to start with a DFM is to have several people participate in designing desktop wallpapers. They're simple to design in a short period of time and have no production costs associated with them. This is where we started on our first Viget DFM. The assignment was simple. Take an afternoon (roughly 4 hours) to assemble one or more desktop wallpapers within the given time and include the Viget brand no matter how big or how small. Everything else was left up to the designer's discretion. Planning ahead was ok but no one was allowed to begin until the start of the event. Additionally, you didn't have to be a designer to participate. Our design team consists of UX designers, visual designers and production specialists with a wide range of talents and skills. How you work within the guidelines is all that matters.

Continue reading "How to Create Design Concepts in Rapid Fashion"

Leave a comment ( 10 )