Who We Work For

Posted on October 10, 2012 by Matt

Every day, in our industry, things are made. Digital things. Some as small as a single pixel and others, many millions of pixels assembled into an app, site or experience.

So, it’s our responsibility to advocate for those who use the things we’re tasked with making and it’s our duty to ensure that those things are easier to use, understand, complete, create and enjoy.

Paddy Donnelly brought up a piece of advice he wished he’d been given as a young designer and it got me thinking. Web design folk are awesome at sharing and we’ve made some amazing places where we can do so, like Dribbble, Forrst, Git and Stack. We’re surrounded by great teams and inspiring visionaries who pioneer new methods that we can all try and fail at together. We collect notebooks, understand TNG references and have an incredibly intimate understanding of plaid. We work hard, but for who?

Amidst all of the liking, re-tweeting and web design gallery badges it’s easy to forget who we really work for. Some of you will say we work for our clients and that’s partially true. Some of you will say we work for our bosses – again, partially true. Most of you will say we work for ourselves, toiling over details and polishing our code until we’re proud to send it out into the world. Sometimes it even seems like we work for each other, or at least each other’s approval, but at the end of the day, we work for the user.

At Filament, we love users. I know that totally sounds like we dig junkies, but it’s true (not the junkie part). Our clients hire us because they know we’re not afraid to speak up. We ask why, we push back, and we call bullshit, but we don’t do it to stroke our own egos. We do it because we believe in making things that are useful and enjoyable. We believe in clear communication and in making people feel like they’ve won the internet every day. Happy users are loyal users (again, not the drug thing).

Aarron Walter described his version of Maslow’s Hierarchy in his excellent book “Designing For Emotion” and I love it. I even designed a poster so I could refer to it often. He compares the act of designing usable interfaces to a chef cooking edible food. If it’s the most basic thing we can possibly do, why would we focus on merely edible when we can make something incredible, memorable and enjoyable?

The pinnacle of good user experience design - making something pleasurable.

This hit home recently while designing the Android app for Green P. We already had an iOS version that people were really enjoying and we wanted to provide the same great experience to this new group of users. It would have been easy to port over the existing app and make it functional, but deep down we knew it was our responsibility to give Android users a proper experience. Having a die-hard Android user in-house didn’t hurt either. We stripped it down and re-designed it from the ground up. Sure, it took twice as long as a port would have, but the end result is a tailored experience that showed users we actually thought about them and not just about cashing the cheque. On a side note, the design and dev documentation that the Android team has put together is excellent and here’s a handy article about asset resizing by Travis Hines at Teehan & Lax.

“Design is not just making something beautiful the way you want to make it, but designing the most thoughtful, human thing you can within the constraints” – Wilson Miner.

Wilson’s quote in the latest issue of Offscreen was timely for this article. Before we try and infuse the latest trend or design technique we must ask ourselves if we’re doing it because it’s cool, or because it makes sense? Will it benefit the user? Will it work in dev? Is it the bevel and lens flare of 2012? Are we making something as human as we can, or are we more concerned with making it pretty? You’ve heard the old cliche (and the song, of course)- It’s What’s Inside That Counts. As a designer, I think the outside counts as well, but even the most gorgeous UI can’t save an app that leaves users frustrated.

Paddy’s advice is sound (his work isn’t bad either) and I think even the most grizzled veteran could use a reminder from time to time. So let’s continue to geek out, give kudos, and admire Instagrammed pics of our iSetups, but let’s not forget who we go to work for every day. We’ll be better designers, our clients will get better results and users everywhere will be a lot happier.

Posted in Design, Methodology | Leave a comment

:before and :after are your friends

Posted on October 10, 2012 by Brenna

I can’t remember exactly when I wised up to the versatility of :before and :after, but they’ve been saving my butt in tricky styling situations often enough now to justify some long form praise.

[Side note: I sent out a rhetorical tweet in praise of these guys and got back only the best answer ever from fellow code monkey and Humber alum, Zak Nitsch.]

So, what makes :before and :after so useful? Come, take a walk with me through this recent example:

I was working on making this search form come to life. I’d gotten 95% of the way there and all that remained were the keylines on either side of the text.

If this were a fixed width site, I might slice the keylines with the rest of the background image and call it a day, but this site was responsive. I’d already accommodated for a flexible width background by using a CSS gradient and a right positioned image (of just the map overlay), so baking in the keylines wasn’t really an option. That, and my purist ambitions were driving me to avoid using images at all costs. Must. Be. Code. Wizard. I thought about making a zero height wrapper element with top and bottom borders, then relatively positioning the text element within, a technique I’ve employed in the past:

This actually works pretty well, but you do need to set the background on the text element to be the same as the container background, otherwise the keylines would carry on straight through the text. With a gradient lurking in the background in this particular instance, it might be tricky to get right. Plus, the wrapper is extra non-semantic markup.

And then I stopped to think about exactly what I needed here: A little piece to the left of the text, and another little piece to the right, both to hold some embellishment. Duh doy. That’s precisely what :before and :after are for. We can still use the technique of zero height elements with top and bottom borders too. Just apply that to :before and :after instead of a wrapper.

:before and :after will create child pseudo-elements (first and last), so you’ll typically want to absolutely position them within the parent. Also remember that you need to add some content, but an empty string will work if you’re just decorating. Here’s the full solution, including some trickery to keep it flexible.

 

And here’s the finished product, in all its flexible width glory.

The real benefit is that this happens purely in your CSS, as it should for something that’s purely stylistic. Give it a try the next time you want to keep your markup minimal but add CSS flourishes.

:before and :after work in all modern browsers, plus IE8 and above. While they’re not supported in IE7 – and we still officially support that browser in these parts – it’s not a concern if you’re using them for purely cosmetic features as we’ve done here. Progressive enhancement FTW.

Hug your pseudo-elements, kids!

[Side note the second: Thanks to Dave Rupert for his invaluable inspiration and advice on sharing more with the web community: "Write about a specific problem and how you solved it." Wise words.]

Posted in Development | Leave a comment

Adventures in Stylesheeting

Posted on July 16, 2012 by Brenna

I have a bad habit of rearranging things. My old roommate would often come home to the surprise of an alternately configured living room:

“Whoa. You just moved all this furniture around by yourself at 11PM on a Wednesday?”
“Yeah….”
“Okay, cool. Looks good.”

To her, my late night furniture wrangling must have seemed like a strange impulse. In truth, careful scheming lay beneath it all.

You see, my brain is wired to analyse, whether I like it or not. Sitting in that living room enough, I began to notice its weak spots:

“Only a couple people can really see the tv comfortably.“
“You can’t reach the coffee table if you’re sitting in the armchair.“
“Wouldn’t it be better if the records were beside to the record player? “

And thus the cogs would turn.

Having been set in motion, I was now subtly bound to the task of plotting the Great Configuration. Rewatching my favourite episodes of Always Sunny?  I’m sizing up the restrictions imposed by stereo equipment wiring.  A few friends over for drinks? You might catch me gazing at the wall behind you, visualizing what the couch would be like there. Piece by piece, a plan would slowly emerge.  And once I had a solid plan (or just a half-baked plan with enough fully-cooked frustration), resistance was futile.  I’d spend an evening tearing apart and reconfiguring and, regardless of how long it took or how much I deviated from the original plan, I’d end up with a new and improved space.

But I do more than just sit on the couch…

When I began working with CSS on a regular basis, it didn’t take long for my brain to start twitching a little. My early stylesheets were typical of what most beginners would write. I’d include a reset and apply some basic global styles like font-family and margins on paragraphs, but for the most part, each piece of the page received its own set of styles.

This quickly felt rather inefficient. It also gets really boring. I’ve suffered through enough data entry at this point that I’ve developed a permanent aversion to mindless repetitive typing. And it’s not just inefficient and boring the first time you write it. Making changes to your site’s design at a later date is an unwieldy, tedious task. It’s almost enough to dissuade you from redesigning at all. It was clear I needed to refine my approach; time to rearrange my cluttered CSS.

“YOU GUYS, I’m going to embrace the cascade!”

With my next few projects, I strove for global styles. . .everywhere. In some cases, this works out really well. If you’ve got a small site and you also happen to be the designer, it’s not too hard to agree upon a standard style for “all h3s” or to consciously re-use style treatments in your design. Writing CSS in this way certainly reduces a lot of the repetitive typing overhead. Plus, there are potential performance gains to be found in the resulting smaller file.

Global styles like this are even necessary in some cases. When working with a CMS, your stylesheet needs to be prepared for unknown markup. Similarly, global styles fare much better than individual styles when it comes to scalability. New markup tends to “style itself” properly, and ad-hoc design modifications can often be implemented by changing only a couple lines of CSS. In many ways, this was a big improvement.

Nothing gold can stay: Enter the Preprocessor

As I moved on to bigger projects, I began employing several tools to help streamline my development even further. The idealist in me would love so much to create some sort of minimalist Grand Unified Stylesheet (chasing GUS) on every project, but it just ceases to be realistic on a large scale site. There will always be small exceptions to the generalizations you create. And, to style these exceptions, you’ll just end up writing lots of code that overwrites your precious cascade. It felt like I was back where I started; writing things twice (or more) and stuck with an inefficient, hard-to-maintain stylesheet.

Lucky for me, CSS Preprocessors were starting to crop up. Preprocessors essentially extend the capabilities of CSS, allowing us to use all sorts of magical things that every other developer already gets to use (i.e. variables, functions, conditionals). It sounded quite promising, so I gave LESS a go and was instantly impressed with the efficiency it brought to writing CSS.

Although there is some learning overhead, especially if you’re working with a team, the payoff is organized, maintainable code, all created with relative ease. One of the simplest use cases I suggest to anyone new to preprocessors is using variables for colours. Give your hex codes a friendly variable name (eg. @red) and BAM!  You never have to waste time looking up #cf3636 again. Naturally, this also makes your code easy to update. Changing the variable value (a single line of code) makes a global change in seconds.

The small exceptions that proved difficult to handle in fully globalized styles are also handled nicely using mixins (available in both LESS and Sass) or Sass’s @extend functionality. Mixins work like functions, grouping a block of declarations together for repeated use, optionally taking variables as arguments. @extend works by serving a common base of declarations to similar (but not identical) style blocks. And the list of features and benefits that come with preprocessors really goes on and on. Get reading if you don’t believe me.

But there’s always a catch, right?

Right.

I’m not giving up on preprocessors anytime soon, but they ought to come with a warning. Just because you’re not typing it, doesn’t mean it’s not showing up in your compiled code. It’s easy to get carried away with nesting and mixins which look all clean and efficient in your text editor, but are actually a mess of complex selectors and repeated code in production. As others have noted, make sure you know what well written CSS looks like before you start dabbling with preprocessors and audit your output once you do.

A brief love affair with Twitter Bootstrap ended in the same sordid way. I was initially thrilled with all the time I was saving by using a front-end framework: typography, buttons, grid systems, and (dreaded) forms were all made for me already! But I ended up modifying or overwriting so much of the code that I essentially negated all that efficiency during customization. Plus, there was lots I wasn’t using — lines upon lines and bytes upon bytes, silently fattening my code until a disgusting file size prompted a much needed amputation. Zurb’s Foundation, a leaner framework intended for customization, has fared a little better, but my instinct still tells me it’s overkill for most projects.

What now, then?

I don’t think I’ll be using Foundation or Bootstrap as an entire framework again, but my experimentation was not in vain.  I’ve gained useful code snippets and entirely new techniques for writing CSS.  First, I absolutely love working with a fluid grid.  Almost everything I build now is responsive, so the grid gives me an extremely solid base for that kind of structure.  (Bonus: It’s also given the designers I work with a nice starting point for designs and keeps things consistent across mockups.) The code for Foundation’s fluid grid stands perfectly well on its own and I’ve had no trouble including it in my own CSS on recent projects.

Additionally, frameworks and pre-processors introduced me to the notion of OOCSS (Object Oriented CSS), pioneered by Nicole Sullivan. There’s lots to read up on here, but in short, OOCSS breaks your styles down into reusable patterns that can be combined for ultimate scalability.  The quintessential OOCSS example is the media object. Read it. Use it.  Chris Epstein also has a fantastic presentation with practical examples on how to break up your styles into objects.  I think I had a foggy vision of this in my early attempts at abstraction, so I’m happy to have come across a practical strategy for it.

Again, this comes with a bit of a warning. Extreme abstraction might not be necessary in all cases.  If a pattern only appears once or twice, the extra time invested in creating an object is probably not going to pay off.  I also prefer to apply most of my objects using classes in the markup, rather than going overboard with Sass includes.  While “classitis” is icky, I’ll take it over a bloated stylesheet any day.  I’m still leaning heavily on Sass for variables and file organization, and mixins are still valuable for code that needs to be repeated (eg. @font-face declarations).

I’ve also gotten into the habit of creating style guides for my larger projects.  They force you to be more organized with your code and document your work (both good habits) and they’ve been a hit with the team thus far; having a visual guide makes it much easier for another developer to step into the front-end code.

A few snippets from recent style guides:

 

So that’s about where I’m at now.  My next goal is to develop my own beautiful mini-Frankenstein of a framework encompassing all this. I’m liable to get frustrated and rearrange it all at any moment now, but I wouldn’t be in this game if I didn’t like being kept on my toes.

Posted in Development, Methodology | Leave a comment

[CLOSED] Copywriter Wanted. Addicts to the front of the line.

Posted on June 4, 2012 by Stephen

Are you a Facebook addict? How about Twitter? Pinterest? All of the above?! Does your incessant liking and tweeting affect your relationships with loved ones? Have conversations with your online “friends” replaced real-life interactions completely?

Good.

If you’re a writer who lives and breathes social media then you might be just what we’re looking for. We’re looking for an enthusiastic individual; someone with a flair for wordsmithery and making up words like wordsmithery; someone who might describe themselves as “a total nerd, but not a nerd nerd. More like a cool nerd, you know what I mean?”

Your daily tasks will be to manage our clients’ social media profiles, creating interesting content and engaging followers. You’ll also be writing blog posts on a variety of subjects, as well as a whole bunch of web copy.

So what do you need to apply?

  • At least a year’s copywriting experience.
  • Knowledge of and experience with a wide variety of social networks.
  • A genuine interest in pop culture.
  • A hysterical – or at least mildly amusing – twitter feed.
  • The ability to carry on an intellectual conversation about the zombie apocalypse, or whatever happens to be in the news that week.
  • A bit of experience with HootSuite won’t hurt.

If you’d love a job with a growing digital agency located in Liberty Village – which is a really awesome place, check it out if you’ve never been – then send your portfolio and resume our way! jobs@filamentlab.com

 

Posted in News | Leave a comment

Memoirs of an Intern

Posted on May 10, 2012 by Lindsay

As soon as I came across the job posting for an intern at Filament, I didn’t hesitate to start up Word 97 on my office computer, hammer out a cover letter, attach my resume and send it off. It was the first cover letter I remember ever sending that was sincere. The tone of the posting was refreshingly welcoming, down to earth and the complete opposite of condescending. I could tell that they were looking for someone that not only had the skills and drive, but someone they would enjoy hanging out with for 8 hours a day. The posting even insisted that the applicant be a nerd! The prospect of actually being able to feel comfortable in a work environment with fellow geeks, (best of all– design and dev geeks) was beckoning me like the light at the end of the drab, grey, neverending administrative job tunnel that I had been trudging through for the past year.

This calls for a bit of backstory: I graduated from Seneca College’s graphic design program in September of 2010. After enduring a less than stellar internship as part of a credit, I naively decided to take some time off to work on my portfolio. This turned out to entail days of perusing the Internet, comparing myself to everyone better than me at everything ever, and getting increasingly discouraged in every sense. I couldn’t even bring myself to apply for anything, making the excuse that I shouldn’t be wasting my time; since I was so craptacular, no one would consider hiring me for anything ever anyway. A couple of months later I was still quite obviously going nowhere, and the prospect of gaining a little Holiday money was too enticing. I took on a full time documentation role I had previously had as a summer student (but only for now, I kept reminding myself). I got far too comfortable (read: lazy) and stayed there for over a year, all the while ungratefully complaining and making excuses while the ever evolving design world continued to pass me by. And because of my lack of motivation and self-confidence, my freelance career was floundering as well. By this January, I was fed up with myself and spent every spare moment searching design job postings. If not now, then when? became my mantra. So when I came across Filament’s, I lit up with the potential promise of gaining experience, progressing as a designer and feeding off a group of such seemingly awesome people.

I worked harder to prepare for the interview than I ever had before. I studied every bit of copy on their website, memorized their process and creeped their tweets and blog posts. I rehearsed presenting my portfolio, studied common design interview questions and encouraged myself to sound confident and overcome my chronic awkwardness. I was told to bring a tablet or laptop to the interview for a bit of an open-book quiz. Freaking out that I was going to be building a small website on the spot or designing a layout or coming up with logo concepts, I studied even harder days before the interview. But when Steve sat me down and gave me a piece of paper with 20 completely unpredictable questions listed front and back, I was initially bewildered. It ended up being more of a hilariously arbitrary assessment of one’s Google/Wikipedia skills that tested the resourcefulness and intuition of a candidate. I won’t spoil the questions for you, potential new interns, but believe me when I say– it was the most unexpected, entertaining and overall enjoyable interview I ever remember having. I, later got a response detailing that I was chosen as the new design intern and couldn’t stop beaming. I forgot that it was humanly possible to actually look forward to going to work, and couldn’t wait to start.

Right off the bat within the first week I had genuinely learned more than I had learned in an entire year on my own. I got to know organizational and productivity tools like Basecamp, Invision, Trello and wireframing tools like Omnigraffle. I was encouraged to read relevant articles and take notes on talks from conferences, ranging from Photoshop tips to breakdowns from design veterans on why being a designer is so important (and awesome). I quickly began to retain a much clearer understanding of expectations, estimation and what would be acceptable and unacceptable as quality work for clients. My first task was to design a website for a faux client with me as the client-facing designer. There were no due dates or essays, but by the end of it I had a much deeper comprehension of client facing work than any school assignment in my experience. I also came to love Filament’s creative process because I thoroughly understood why it works so well. This made-up-client-facing assignment was, so far, one of the most valuable experiences I’ve had during my design career. I learned a ton and was forced to overcome my limitations in the face of productivity, as well as living up to my own standards of quality work. Sitting down and doing the work was eye-opening in terms of my expectations of myself, and the quality of my output. As a general note, thinking that you’ve got the skills to crank out your very first entire web design concept in 8 hours is a hell of a lot different than actually sitting down and doing it —it took me a week and a half.

Within every subsequent undertaking, I would apply the process, becoming increasingly more competent as I went along. I particularly enjoyed creating moodboards, which help map out the direction a design concept will be going in. It’s sort of a scavenger hunt for inspiration that encourages you to find examples of great execution of imagery, colour, behaviour and type throughout the web. And, in another piece of advice from my teammates, the path to unbridled creativity and confidence in your abilities as a designer has got to start out with loads of practice and yes, even forms of imitation used sparingly. Additionally, not only was adhering to professional web design standards something new for me, but designing with varying screen sizes and usability issues was another eye opening lesson. Encouraged to think critically about responsive design was extremely valuable. Within one project, I spent an appalling amount of time working out wireframes for a mobile site, but it was time well spent to help me truly understand optimal functionality. Having realized the potential and capability of a designer to make things better, easier and faster for all users was a eureka moment for me.

The amount of creative freedom that was afforded me is every designer’s dream. But naturally, each design decision had to have a fully thought out rationalization. It’s fascinating to observe the kinds of creative decision making and problem solving that the team will put their heads together and come up with. Filament’s creative ideation process spawns such great concepts that, as equal parts an observer and actively engaged, my creative itch is scratched just by being in the room. Not once did I feel taken advantage of, unlike what I hear many design interns may have to endure. Never did I consider the work that was assigned to me as bitch work or slave labour. I loved coming in everyday and wanted to be of utmost use to everybody in the office. The enthusiasm that I felt coming in to work was perfectly matched by my teammates’ attentiveness and eagerness to teach. I was consistently excited to come in and work my ass off. There were periods of varying intensity and busyness but almost every day I was hard at work doing something useful. From client-facing deliverables to trying to cram as much useful design-related information into my brain as possible, every day bordered on exhausting but incredibly rewarding.

Like a good intern, I kept my eyes and ears open at all times. I watched as the creatives rationalized including or removing elements of a particular design. I would open up any .psd I could find and study the techniques used so that I would be able to break down the execution. I eavesdropped as hard as I could to every conversation related to design problem solving, from creative strategy to development issues. I wanted to be a sponge that could soak up as much as I could possibly retain. Accordingly, my mini notebooks are filled with scrawls, crammed in to any available space, of Photoshop techniques, shortcut tips, advice on best practices and song titles to download (Rdio/Spotify plus the unrivaled music taste of the Filament team had singlehandedly revamped my entire iPod library in a matter of weeks).

I had some missteps along the way for sure, but the team would never leave me hanging. My self-doubt and insecurity continued to plague me, but there’s nothing better than having such a great support system sitting directly beside and across from you. Answers to questions and advice were there at every turn. Yes, it was unpaid, but they had some pretty awesome perks. Your choice of free lunch twice a week from a myriad of excellent options in the heart of Liberty Village? Sweet. Metropasses? Yes, please. Infinite music library courtesy of Rdio and Spotify? So good. And compensation for certain client-facing deliverables? I certainly took advantage of that!

My internship at Filament has taught me an almost overwhelmingly vast amount of knowledge in such a short time. I had grown incredibly over those 12 weeks, and certainly more so here than I would have anywhere else. Because the Filament team is so small compared to most other design firms, I was truly engrained in every step of the design process for a wide array of clients. I continue to marvel at my co-workers’ expertise and passion for what they do. They remain to be among the most effective, helpful, attentive and truly caring teachers and mentors I’ve ever had. I continue to learn and grow every single day here at Filament and I am truly thankful that I was able to have an opportunity like this to learn from such experienced and supportive people. Hanging out with four (+1 from afar) truly talented, passionate, hilarious and overall awesome geniuses every day only makes you want to work as hard as you can to get to their level.

We’re going to be veering into cheesy territory for a moment here, but my 2012 resolution was to find a job in the design field in which I can honestly say that I love coming in to every morning. I feel so fortunate that I had this chance to spend such an amazing time at Filament, and I can finally say that I have actually achieved my goal. They hired me on full time as a junior designer! It’s such a rewarding feeling. (And now, I guess, to work on that other new year’s resolution– dusting off that gym membership.)

Phew, enough about me. Here are a few tips on how to be the best intern you can possibly be.

Be Humble

So you just got your dream internship and you feel like a champ! You just beat out all of the other applicants to gain a spot as a team member within one of Toronto’s best digital creative agencies. And of course you did; you were at the top of your class, always coming up with brilliant and unique design solutions, and you may have even won some student awards. But check whatever ego you have at the door, and know your role. You may have the freedom and ability to pitch what you think are solid design ideas to your coworkers. Just don’t start thinking that you’ve got the know how to tackle an entire client facing concept on your own. Don’t think that you can slap on your ‘personal signature style’ to every single project because it looks cool. Don’t give everyone outrageous time estimates that you’re likely not to follow through on. Don’t think that just because you’ve spent a hell of a lot of time buried within the Creative Suite, you’re good enough to dismiss or disregard any offerings of advice. And don’t forget that pretty much everyone around you has loads more hard earned industry experience than you. They may remember what it’s like to be you, but don’t think that you know enough to know what it’s like to be them. Be confident, but don’t get cocky!

Have a Good Attitude

Putting in hours on end and not making enough to buy yourself lunch may creep up on you now and then. Poor us, right? It’s hard for now, but don’t let it get to you. If it does get to you, don’t let it show. You’ve got to let your enthusiasm and eagerness to learn shine through. Positivity is infectious, and so is a bad attitude. Seriously, nobody likes a downer, or a jerk.

Remember that You’re With Them, Not Against Them

Since you’re working with people who are more experienced than you in so many ways, use that to your advantage. Seek out criticism from them, and keep an open mind at all times while listening to it. Feedback can often be hard to take, especially if it’s negative, but it’s so imperative for improvement of your skills and the thickness of your skin. You may have to defend your designs by coming up with solid rationalizations, but if you haven’t got one, then don’t take it personally if they recommend that you make some changes.

I would love to paste the entire 10th chapter of Mike Monteiro’s Design is a Job here if I could (read it, it’s so good), but to quote from it:

As the person being critiqued, you need to realize that the feedback is not about you, it’s about the work. And you need to be open to good ideas that come from places other than your own head. There’s a balance between defending your work and remaining open to better ideas that takes a long time to develop. It takes confidence, intelligence, and an open mind to allow others to help you make your work better. It takes a thick head not to.

Ask Questions

You’ve been assigned a to-do, and you want to prove to everyone how spectacular your initiative and can-do attitude is. You don’t need to slow everyone down with any questions that have clearly obvious answers. You kind of already assume the direction that they’re going in with this assignment, so you’re good to go. This project takes you a good 20 hours and you’ve finally got it polished and perfect. You smugly ask your coworkers to come on over and give you some quick feedback before posting it for review. Expecting a ‘Wow, you’ve got the entire project finished, you’re hired!’ instead you hear a ‘Hmm…we actually wanted the complete opposite of this, you should have come to us for some clarification’. And that’s when you feel like a complete idiot.

Yup, I’ve done it. I still have a bit of a phobia of interrupting people and or potentially wasting their time by bothering them with my stupid questions. But asking questions benefits everybody. Taking the inconvenience of an extra 30 seconds to have a question asked and answered is far more beneficial than taking an extra 30 hours to revise everything you just spent 20 hours working on, which won’t be used whatsoever. Working independently as a student, whether choosing to procrastinate and accept a late mark or taking your time for days, is far different than working as a team meeting strict deadlines. You may not be getting paid for it, but every hour counts, and if you’re not striving to be the most efficient with your time then you’re not benefitting anyone– least of all yourself.

Work and Study Your Ass Off

You’ve got to put in the work. It’s not just so that your employer can take advantage of your free labour of course. You’re learning loads along the way. And you’re probably not as great as you think you are. The harder you work, the better you’ll be. The more feedback, advice and criticism you receive, the better you’ll be. The more blood, sweat and tears you put in (and there may be plenty), the better you’ll be. The only way to get better is to sit down and do the work. Be a sponge and try to soak up everything that you possibly can. Take notes on everything, follow through on your tasks and be consistent.

And don’t think you’re out of school just yet. You may not have any electives to sit through anymore, but don’t think you should be going home and wiping your brain of everything design. Read awesome design blogs. Stir up some conversation online with fellow designers. Go over your notes that you jotted down throughout the day from work. Do some of those free Photoshop tutorials. Do self initiated projects. Then come in early to work the next day and leave late.

Posted in Bits and Bytes | Leave a comment

Evolving The Process

Posted on April 20, 2012 by Stephen

I was late to the party.  Last month, Samantha Warren, a great designer and someone that has always been open about other web designers sharing their process for the good of the industry, wrote an article discussing the use of style tiles in the web design process.

If you are unfamiliar with style tiles, there’s a handy website that will give you an idea of what they’re all about. For us, they’re proving to be useful—really useful. Which is why I was so annoyed by the commenters on the alistapart article.  Some missed the point all together and showed a tremendous lack of respect towards clients.  I posted my comments, but as it turns out, I’ve got a little more left in the tank.

You can call style tiles whatever you want, though “Style Tile” is catchy and to the point. Commenters on the ALA article, argued that the use of a board with groupings of stylistic elements isn’t a new idea. Fine, you win, I’ll concede that the idea isn’t revolutionary. However, its not always the tool that matters, it’s the application. In an age where brand and content are consumed across multiple channels, the inclusion or application of the style tile in the web design proces has never been more appropriate.

Just as it made our lives infinitely easier to separate presentation from markup with CSS and HTML, the idea of getting granular and identifying that style is just a part of the greater design problem, achieves similar benefits.  Separating stylistic preferences from design goals—while involving the client early on—frames a discussion on stakeholder personal preferences in a way that doesn’t negatively impact the final design outcome.  It starts to build consensus and trust that propels the rest of the process along a smoother tack.

Having a process is great—having one that works is better. The ones that do usually involve plenty of communication and respect. Clients want to be heard and involved. Designers want to do great work that emotes, inspires and solves problems; the two goals are not mutually exclusive.   Typically, clients will be really involved in the beginning, while we discover and research.  But, as we progress, somewhere between wireframes and visual design comps, clients feel the creative process becomes nebulous. Likely, this is a result of legacy; the way ‘we’ve always done it’ or, a lack of respect for the what a client can bring to the table to ensure success. One commenter already proved that point when he said that a client wouldn’t know design element if it jumped up hit them in the head.

Agency/Client trust is built on shared responsibility and accountability—I’ll hold up my end of the bargain, you hold up yours.  We’ll deliver on what you ask but you need to articulate your ‘ask’ in a mutually understandable vocabulary.  I’d love to meet the designer who knows exactly what a client means when they say ‘this needs to be more ‘corporate’ or ‘funky’.

But, there’s the problem, how do you come up with a mutually understandable vocabulary? Style Tiles help to bridge this gap. It also focuses the client on discussions on personal stylistic preferences which, when understood, moves us closer to quicker approvals,  a smoother process, and solid execution of the proposed solution.

You have to start somewhere and becoming a little more granular in visual design approach helps to involve the client, build trust and understanding while, at the same time (and this is the awesome part of using style tiles) reducing the likelihood of jeopardizing the final design outcome.

We, as designers, do things meticulously and try to make choices that help accomplish a goal; to solve problems.  If we isolate the discussion of style and design only when evaluating full design comps, we’ve already painted ourselves in a corner. Clients start to focus on the stylistic elements of each, rather than the solution as a whole. Non-verbally, we imply that its okay to mix and match from each comp. Most of the time, its not. Doing this takes away from the real discussion—does our design solution accomplish the goal that we set out to reach? Further, the next question on their minds is ‘Well, what about mobile?’ If we’re truly being responsive web designers/developers, do we really want to be creating multiple concepts for each channel or do we want to create a consistent framework that espouses the brand and the stakeholder style preferences, which can then be applied across channels? I’d like to think that most of us, clients included, would choose the latter.

Again, it’s not about the tool that’s used. if you want to go down that road, it’s obtuse and pedantic. Its the application of the tool that allows us to strike a dialogue where client and designer can speak the same language. Quick iteration to get at an agreed upon style and then applying that style to a proposed solution—in any channel—will save time and money for any shop.

Posted in Design, Methodology | Leave a comment

The Good, the Bad, the Ugly

Posted on January 30, 2012 by Stephen

A little while ago, I posted my thoughts about wireframes and mentioned a number of applications that we use or have used in order to make this deliverable acceptable for client eyes.  I thought it would be a good time to go into a little more detail about each app, how we used them, and why we give it the thumbs up or stopped using them all together.

We have always wanted a light-weight app to rapidly create polished wireframes and present them, as an interactive prototype, to clients, right in the browser.  We felt that a app like this would help us close the feedback gap and also educate the client without lecturing them on the point of testing a user experience against defined objectives.   A lot of the apps and tools already on the market do just that but with some drawbacks.

At times we’ve felt like a wireframing app whore–going from one to the next, never really feeling satisfied.  The ones that we got most cozy with are Balsamiq, Omnigraffle and Invision. And, to a lesser extent, MyBalsamiq and Notable.  Each has their good points and bad.  In the end –or more appropriately–as of late, we’ve fallen in love with Invision and currently enjoying a wholesome yet open relationship.

It’s important to note that initially, we were really looking for one app to do it all; hi-fidelity wireframing and prototyping, client integration and feedback right in the browser.  Like in any good relationship, compromises need to be made.  We lessened our demands and netted out pretty well by leveraging the good points of Omnigraffle on top of Invision.

One of the major gripes about most of the wireframing apps was that you were at the mercy of its stencil library.  You had to use what their app provided.  Most of the time that was ok because who doesn’t love sketchy looking interface items and a comic sans default font?

Balsamiq

Balsamiq really did a great job early on by making a stencil library with UI elements that looked like paper/pen sketches.  The philosophy behind it was that something too neat and straight looks more rigid and less approachable from a client perspective–and we wanted something that looked warm and more human. Extensive keyboard shortcuts and a fairly easy to use object inspector made creating a single wireframe screen a breeze.  It was only when we had to generate multiple screens and create interactivity did we start to notice the shortcomings.

  • Massive file size when creating big projects with  many wireframes.
  • Lack of templating for repeating elements or navigation making editing and creating interactivity a pain.
  • Presentation Mode only available on local machine, where balsamiq is installed.  This works fine if all your client presentations are done at your office, but most of the time, that doesn’t happen.
  • Exporting to an Interactive PDF requires all .bmml files to be in the right order otherwise the ‘page’ view in the resulting PDF creates an awfully disordered  linear navigation.
  • Interactive PDF export doesn’t highlight the hotspots where the PDF is clickable, which can cause frustration for us and for clients.
  • Forced to use app specific stencil library.

Notable

Notable, from Zurb, looked really great. One of the things that we liked most about it was the notion of getting feedback from the client, right on the browsers, in the exact spot where the client had issues. In that sense, Notable was brilliant–get the feedback and iterate quickly to speed up the approval process.   In the end, we found it to be less of a wireframing app and we were just re-purposing it for our needs.  Even so, when we did have a single screen available for client feedback, the frustrations mounted.

  • Comments disappearing for no reason
  • Clients frustrated by the notion of creating yet, another online account during their relationship with us (we already use Basecamp and Freshbooks)
  • Confusing interface with no way to mark comments complete
  • Lots of up-sells to white label the notable app for a branded client experience
  • Really costly ($49/mo for a reasonable plan for most studios)

Even though the team at Zurb was helpful, the app wasn’t exactly what we needed and the costs were really high.

Omnigraffle

Despite the, at times, baffling user experience,  omnigraffle is nothing short of amazing. Site maps, wireframes, mind maps – it can handle it all. With an incredibly rabid and evangelical community,  there’s no shortage of stencils or resources to extend the capabilities. With the help of the Konigi template, we were already delivering great looking Omnigraffle sitemaps, personas, mental models etc–so using Omnigraffle for client facing wireframes was a no brainer. The downfalls were easy to spot when it came time to present those wireframes.

Omnigraffle isn’t a cloud app so you need it compiled on all machines that wish to view the .graffle file type. Not ideal.  Sending an export of JPGs or PDFs of wireframes was a no go and Omnigraffle didn’t offer any interactivity–at least none that I could see.   Even though it solved part the puzzle–rapidly creating wireframes–we shelved it for a while. It came off the shelf when we found that gathering client feedback through the browser quickly and easily, was solved with Invision.

There are also some really unintuitive object inspector, formatting pallets, and keystrokes that you just have to get used to before they become part of your wireframing lexicon.  i.e. it took me a while to figure out how to get the hang of master objects, vs. master layer items vs. paste as PDF–which is to say nothing of trying to figure out how to increase the size of a canvas.  Eventually, it all makes a lot of sense but not without a fair share of head-shakes.

Invision

The Invision philosophy is simple. Do what you do best, however you do it and we’ll hold up our end of the bargain by providing you and your clients a simple way to create interactive prototypes and get feedback.   Unlike most wireframing or prototyping apps, Invision doesn’t force you to use any particular library.  If you love using illustrator for wireframes – keep on keepin’ on. If you dig on Omnigraffle, Vizio, Photoshop or Paint–awesome, Invision won’t hold you back.

Invision lets you decide on hi-fidelity mockups or low-fidelity wireframes, generated from whatever platform you want–heck you could even do pencil and paper sketchs, scan and dump em into a project.  The point is, you’re not limited to any one stencil library. Invision really becomes the apparatus for presenting prepared screens to clients or internal teams, with a unified user experience that bakes in the feedback loop.

The team has also been incredibly responsive–we’ve had skype calls with them and exchanged tweets, too. They are actively engaged with their user base through Olark and always seem to be improving the experience based on our feedback.

Feeling like we play a vital role in the success or adoption of an app, no matter how little an impact our suggestions may actually have is what made us love Freshbooks so much, back in ’07.

What’s more is that Invision just worked. Clients don’t have to create an account, just a simple link to the prototype build and off they go.  Once clicked, a lovely interstitial page that tells them their experience is loading–which is a really great way of putting clients, unfamiliar with wireframes,  into the right frame of mind.  Soon, they are able to click about and focus on the user experience, which is really the whole point.  And, the best part is that navigating the learning curve is so quick, the feedback starts rolling in before we even have a chance to let clients know how to engage ‘comment mode.’

Creating interaction between screens is where most apps start to breakdown in some way or form.  Invision does have some issues to sort out but it nails a few key elements.  File upload is a simple drag-and-drop.  Interactive availability isn’t dependant on which UI element you use, like in Balsamiq. Rather, when you enter build mode you can plot a hotspot anywhere on your file and choose a navigation path–either to another screen or previous screen.

Finally, templates will make your life really easy.   I’m sure a ton of UX people out there can sympathize with me or have cried in the corner at the thought of relinking global nav elements on a large balsamiq project.  Templates can be applied anywhere and you can have as many as you want.

Invision also has some other great aspects

  • You can replace an existing file with another of the same name without overwriting the interactive hotspots.
  • Mark comments or feedback as complete
  • Create a password protected prototype staging area
  • Filter through all uploaded screens for a given project to make replacing or finding a file that much quicker – handy when you’ve got a project with 72 wireframe screens!

There are also some drawbacks – though not many.

  • Template objects must stay in the same coordinates. Annoying when you’re footer is lower down on the screen because a particular page has more content.
  • Not being able to duplicate a hotspot (like alt+drag in most design applications)
  • View all comment conversations for a given screen in context of that screen
  • Better version control for replaced files.
  • Better way of marking a project status

If you’re anything like us, you’re always looking for ways to improve your process and be respectful of your client’s time and inclination.  If you’ve struggled with a great way to present wireframes and get feedback, take a peek at Invision app–it’s like the friend, your friend wanted you to meet because you’d get on like a house on fire.

If you’ve got some ideas as how you’ve handled this part of the agency workflow, I’d love to hear ‘em.

 

 

Posted in Methodology | 3 Comments

[CLOSED] We’re Hiring Designers

Posted on January 24, 2012 by Stephen

Filament Creative is hiring designers.  We have openings for talented, intermediate designers that not only love designing but the entire design process. We’re talking about people that can take client objectives and strategic goals and research and execute a carefully considered idea into a beautiful experience.

Qualifications

  • A great portfolio
  • A related degree or diploma from a university or college

What We‘re Looking For

  • A great eye for visual design (layout, color and typography) and the ability to create compelling visual design elements.
  • Great Common Sense
  • Understanding of Usability, User Centered Design, and UI best practices
  • Ridiculous attention to detail
  • Excellent understanding of composition, color, imagery, typography
  • Ability to explain and defend your design decisions
  • Good attitude and strong desire to learn from and share with the design team
  • Ability to work in a fast-paced (not chaotic) environment
  • The ability to communicate clearly. With words. Typed with fingers. Which is not to say that we don’t value exceptional oral communication as well.

Need To Have’s

  • Experience presenting your work to others, including clients
  • 2+ years experience in digital
  • Strong working experience with Adobe Photoshop, Illustrator
  • Experience creating and working with other creative individuals including but not limited to copywriters, designers, developers
  • Excellent understanding of user experience and how it relates to a client’s overall objective
  • Ability to self-manage projects and work within deadlines
  • An enthusiastic, eager and honest disposition with a killer work ethic. (We saved the most important for last).

Nice To Have‘s

  • Good Knowledge of HTML/CSS a plus.
  • Preference of an editor other than adobe dreamweaver also a plus
  • Some wireframe development experience
  • Good drawing/sketching skills are a plus
  • Omnigraffle experience would be nice
  • Respect for good coffee – if you take it black, that would be great.
  • Love for music – do you have a last.fm profile?
  • Dry wit

 

How to Apply

If you’re talented, smart, hard-working and dedicated–send us a resume and portfolio of your work to jobs@filamentlab.com.

  • Include a link to your digital portfolio (this is key!).
  • Have references available upon request.

Suitable candidates will be contacted promptly. No phone calls thanks.

Posted in News | Leave a comment
Blog.Feature.Rules

Understanding, Communication and The Rules of Web Design.

Posted on January 24, 2012 by Matt

I had an interesting discussion with a friend the other day about understanding. We talked about technology, processes, limitations, the jobs of others and about how our level of understanding can either help or hinder our overall objectives. He was struggling with bringing his wonderful, big-picture ideas to life because he didn’t understand what was possible, what wasn’t and where he could push the limitations of his team and of the medium – in this case, the internet. He has an impressive background in marketing and content production, but he didn’t speak the language of the web and it was stifling him.

The discussion got me thinking a lot about rules. As web designers, we labour endlessly and continuously make choices about layout, colour, typography, texture and everything else that goes into a design; our creative design. When working with a blank canvas, a design can take any shape, any form and draw from any number of influences including our own passions and desires. In most cases, the beautiful and wonderful results of this free and liberating exercise are celebrated, interpreted, discussed and consumed. The role of a web designer, however, comes with many constraints; a broad but defined set of rules to create within. Constraints do not diminish creativity–many would argue that constraint offers an unparalleled opportunity for growth and innovation.  Because of all the constraints, we’re forced to make better decisions.  However, without a solid understanding of what those constraints or rules are, success is hard to come by.

Every day we’re forced to evaluate and make sound judgements based on browser capabilities, accessibility, web-fonts, screen-size, analytics and best-practices. With each project, we garner a greater understanding of what is and isn’t possible in this ever-changing landscape, and push the envelope that much more. Successful ideas and concepts don’t only emerge from a solid understanding of the constraints. I need to understand my client, their audience, the capabilities of my team and the scope of what can and can’t be accomplished in development in a direct relationship with the allotted budget. We’ve said this before, but designing for the web is so much more than making things look pretty.

Web work involves team work (Attention: free t-shirt idea). Although parts of a project can be done independently, depending on the size of your team, we don’t work in a silo and we don’t make decisions based solely on our own experience, goals or personal preferences. The work that I do inevitably effects how efficiently and effectively my team members can do their jobs, which in turn effects the outcome of the entire project.

Content strategy, content management, business objectives, proposed measures of success and desired user experience all play an important role in how we design for web. Being a good designer is a great start, but knowledge, as in most cases, is power. Knowing what works in HTML and CSS, understanding load time, responsiveness and how to properly prepare a photoshop document for front-end development are skills that allow us to be better designers, and even more importantly, better team members.

It’s been said that an actor can’t truly act without learning his or her lines and I think that applies here. We can’t push the limits of a medium if we don’t know what they are. At the end of the day, much of what we do revolves around content–understanding what message is trying to be communicated and choosing the best content to engage an audience. Just as a guitarist learns chords in standard tuning before venturing into open tunings and effects, it’s our duty to beceome grounded in the basic principals of web design, then innovate. Whether your medium involves die-lines or div tags, it’s understanding that adds value.

The web is always changing, which means the rule book is too. It’s an exciting time for us and as our medium evolves, we’re presented with more opportunities to do some pretty amazing things. Learning, growing, failing and improving are all part of this ongoing process. Regardless of the changes, however, one thing seems to always stay the same–we need to learn the rules first. Only then can we effectively communicate with our audiences. Only then can we be great web designers.

Posted in Design, Methodology | 1 Comment

Giving the gift of charity (and delicious coffee).

Posted on December 23, 2011 by Matt

 

Ahh, the Holidays. A time to reflect and share with friends & family; a season of over-stuffing, over-stressing and inevitable awkward family moments. We love the holidays and every year we try and send something out to our clients that infuses a little bit of charity amidst all of the seasonal madness.

Each day, we’re given the freedom and opportunity to think, create, build and most importantly, play. We get to do all of this alongside our wonderful friends and clients and as a way of saying thank you this year, we put together a two-part gift that we hope will help create opportunities for those who need them the most.

Part one – Coffee. Everyone drinks it, but not everyone knows that the majority of our coffee is grown, harvested and imported under poor working conditions with unfair wages. Now, the same can certainly be said about a number of things we use daily, but here in the office, a day just isn’t a day without a good morning cup. As a way of making sure farmers get a fair deal for the work they do and that our clients can start the day with some caffeinated inspiration, we sourced some delicious organic, fair trade coffee from our good friends at White Squirrel. We even designed a custom stamp to use on our own special blend.

The second part to this years gift was a donation to an organization that celebrates youth and facilitates their ability to do something that so many children can’t do – just be kids. Right To Play’s mission is to improve the lives of children in some of the most impoverished areas of the world by using the power of sport and play for development, health and peace.  What better way to show our appreciation for our ability to explore, learn and grow than by helping children do the same.

On a more design-related note, we wanted the final package to have that old-time parcel feeling. Craft paper, jute twine and a custom tag fit the bill as did our one-sided card complete with pearlized foil printed by the awesome people at CJ Graphics.  We wanted the simplicity and honesty of the gift to be reflected in the packaging and we’re all really happy with the way things turned out.

It’s been a great year. Thanks again to all of our wonderful clients. We truly couldn’t have done it without you.

Happy Holidays and all the best for 2012.

 

Posted in Design, News | Leave a comment