Be a User Advocate and Save the World

Be a User Advocate and Save the World

Client relationships are tough. We have our expertise and they have theirs. We have a business to run and so do they. It’s easy to get caught up in the “us” verses “them” mindset. When a client asks for something, we do it. Simple, right? Well, not quite. As experts, we need to understand what core goals the client has for any given change to the site, and offer suggestions and guidance when we can. Furthermore, clients don’t know what they don’t know, so it’s up to us to be an active partner in the relationship and suggest improvements.

The reason I wanted to work in the ecommerce business was because I wanted to see a direct correlation between the work I did every day and its affect on the public. I know that changes I make to the codebase directly influence the conversion rate and the bottom line for the sites I work on. Before, when I was working on brochure websites, it was hard to tell the utility of what I did outside of Google rankings and subjective aesthetic value. By moving to ecommerce, I stopped working so much for designers and site crawlers, and started working for the user.

Being a User Advocate

Wait a minute… I though we were talking about clients… now we’re talking about users? What gives? Well, they go hand in hand. You need to be a user advocate to your client. Passive client relationships are poisonous. Who wants to spend their career updating social media icons to the latest “cool” design, anyway? Instead, you should be an active participant in your client relationship.

I’m always keeping an eye out on Twitter and Feedly for anything relevant to making the client’s site better for users. Carousel on the homepage? Show them the research and articles by Erik Runyon and Brad Frost about how users rarely click on anything past the first slide. Show render time differences with WebpageTest.org by removing the extra 4 images in the slider. Follow that up by showing them the research gathered by Luke W about how each second the user waits for the page to load decreases conversion rates by 7%.

Create an argument arsenal that is bulletproof and make the changes to the site that you want to make. You will gain the client’s trust by showing them you have a vested interest in the conversion rate and bottom line of their site. I’ve seen it firsthand. By sending WebpageTest.org reports and articles from industry leaders, clients no longer see you as a means to an end, but as an ally. Soon, you’re being asked to be in phone calls and offer feedback on new initiatives and projects.

With the help of WebpageTest.org, I’ve been able to generate new business for my team, in addition to improving the user experience. When users are happy, they spend money. When users spend money, our clients are happy. When the clients are happy, they want to spend more money with us. With all of this happiness and of all this money being spent, you’ve basically reinvigorated the economy and solved world peace … so what are you waiting for?

The post Be a User Advocate and Save the World appeared first on Pete Schuster.


from Be a User Advocate and Save the World

reading my uncommented code from last year

dev-practices:

(via @greg24x)

client does not request support for IE8

dev-practices:

(via @greg24x)

Reading the full story about lavabit

devopsreactions:

image

http://lavabit.com/

screw it. !important

dev-practices:

(via @alex_morrison)

Sass Variable Architecture

Sass Variable Architecture

Sass Variable Architecture

Using Sass is helpful when authoring and maintaining CSS. One of its many advantages is being able to define variables that can be reused again and again. Creating a scalable and easy to use variable structure has been something I’ve been working on and researching for quite some time now. Below are a few of my findings.

1. Use Auto-Complete Friendly Terms

Many IDE including Sublime Text offer an autocomplete when you start typing a word or function. Autocomplete allows you to work more efficiently, by not having to remember each of your variable variations. When you’re working in the CSS, you probably know from working within the PSD that the item you’re trying to style is supposed to be blue. In the first example, this works great with autocomplete. You start typing “$blu” and you’ll get all the results from the first list. This isn’t the case for the second least and can become confusing if you use the same name convention for the other colors in your scheme ($lightYellow, $lightRed).

Do – Start with the Color

$blue: ###;
$blueLight: ###;
$blueDark: ###;

Don’t – Start with the Variant

$blue: ###;
$lightBlue: ###;
$darkBlue: ###;

2. Utilize User Friendly Terms

As the author of the CSS, you might have been provided a style guide with brand colors for the project. It’s important to name these colors as they relate to the interface rather than an arbitrary hierarchy. I’ve found that there are typically 3 main colors in designs. A primary color for primary actions like an “add to cart” or some other main call to action, a secondary color for secondary action, and an alt color for unique cases where the other two don’t apply. Then there tends to be variants on those three colors. By creating this relationship and standardizing a naming convention, you create a direct relationship with the interface and your variables. This will also help future developers to be able to easily understand and relate which color goes with which variable.

Do – Abstract Color Names

$primary: $blue;
$primaryLight: $blueLight;
$primaryDark: $blueDark;
$secondary: $yellowDark;
$secondaryLight: $yellowDark;
$secondaryDark: $yellowDark;

Don’t – Abstract Ambiguous Color Names

$brand-1: $blue;
$brand-2: $yellow;
$brand-3: $blueLight;
$brand-4: $blueDark;
$brand-5: $yellowLight;

3. Use a Calc Function and a Font Size Mixin

The REM unit is still not well supported and there may be other situations where you want to change the root body element font size. If you’re using EM based CSS, changing that value can have a big impact on your layout and design. By setting a $base-font-size variable and using it as the basis for all your root EM base calculations, you can make sure your CSS remains fluid. The $base-font-size variable also comes in handy to reset the font-size on inline-block elements whose parents’ font-size is set to 0 in order to overcome the inline-block white-space shortcoming.

Do – Use Calc and Font Size Mixins

.selector {
    margin-bottom: calc-target(10,14);
    line-height: calc-target(20,14);
    @include font-size(14);
}
$base-font-size: 16 !default;

// ==========================================================================
// calc target
// ==========================================================================

@function calc-target($target, $context: $base-font-size, $unit: 1em) {
    @return $target / $context * $unit;
}

// ==========================================================================
// @mixin font-size
// ==========================================================================

@mixin font-size($targetSize, $base: $base-font-size) {
    font-size: $targetSize / $base * 1em;
}

4. Create a Default Architecture with Overrides

From project to project, some things change, but many stay the same. Whether it’s the path to your image directory, the color of error text, or the different samples of grey you use, keep these things constant for every project and refine them over time with your base CSS architecture. Keep these defaults in one file, and in a separate file, create project specific overrides. Now in your compilable Sass file, call the default variable file first, and the project overrides afterward. Much like using plugins in JS, this keeps your project separate from the core architecture and is easier to update/upgrade to newer versions.

Do – Use !default Values

//system
$imagePath: '/resources/images' !default;
$fontPath: '/resources/fonts' !default;

//greys
$greyWhite:         #fff !default;
$greyLightest:      #fafafa !default;
$greyLighter:       #f2f2f2 !default;
$greyLight:         #ddd !default;
$grey:              #ccc !default;
$greyDark:          #666 !default;
$greyDarker:        #444 !default;
$greyBlack:         #222 !default;

// system colors
$ui-yellow:         #c09853 !default;
$ui-yellowLight:    #fcf8e3 !default;
$ui-red:            #b94a48 !default;
$ui-redLight:       #f2dede !default;
$ui-green:          #468847 !default;
$ui-greenLight:     #dff0d8 !default;
$ui-blue:           #0484cb !default;
$ui-blueLight:      #d9edf7 !default;

The post Sass Variable Architecture appeared first on Pete Schuster.


from Sass Variable Architecture

virginiagentlenerd:

Still goddamn hilarious

(Source: nedstarksillegitimateson)

architectureofdoom:

A climbing plant peels off a brick building, in an effect reminiscent of a snake shedding a layer of skin

architectureofdoom:

A climbing plant peels off a brick building, in an effect reminiscent of a snake shedding a layer of skin

(Source: malformalady)

when the client wants major changes near the deadline

thecodinglove:

image

/* by olorapino */

Email Q&A: Becoming a Front End Developer

Email Q&A: Becoming a Front End Developer

This past week I received an email from a designer looking for some advice on breaking into front end development professionally:

Hi Pete, hope you’re doing well. I was hoping you could help me out with some questions I’ve been having lately. Recently I’ve been toying with the idea of a career change into full time front end development. I’ve been working in the graphic design field for the last 8 years. The last 2, I’ve really been drawn to front end development. One thing I love about it, is constantly learning new things and taking advantage of modern workflows. i.e. sass, gruntjs, git / bitbucket, and the general open source community.

The design world can be “unforgiving”.. we’ll say. You could spend 20 hours designing something you think is perfect and the client can shut it down in all of 5 minutes, then it’s back to another round of 20 hours of work. It’s also very subjective. What looks good to one person will look bad to another. Unless you work for yourself, you most likely won’t be designing things you want to in an agency/firm setting. So far my experience with programming has been very black and white, which i consider a good thing. Theres only one way to write.

I’ve only done front end development in a freelance setting, never at a firm or agency. They’ve all been generally pretty simple sites. I’ve never had to use angular or a js framework with my sites. Probably a good thing because I don’t know them yet!

So, finally my questions.
1. Can the programming world be unforgiving? For example do you find yourself re-programming the same thing 10-20 times a day and working late because of it? Are you asked to program an entire site in 1 day?

2. From what I can tell, the pay is generally higher for web programmers vs designers. Do you have any thoughts on that?

3. If there was one spot I’m still lacking in, it’s javascript and js frameworks like angular or backbone. Honestly, I’m still learning vanilla javascript. Do you use these? Are they important to the daily life of a front end dev?

4. Are you always rushed, constantly stressed out?

5. If you could pick the hardest or most stressful thing about working full time as a programmer, what would it be?

6. Everyone has their own opinions of front end vs back end. Are you required to manage servers, change dns settings, purchase the domain names, transfer databases, move wordpress sites to a new host, that kind of thing?

7. What are your thoughts on the current job market for front end devs?

Well if you’re reading this far, thank you so much. I know I wrote a lot, but I would really appreciate and value your thoughts and opinions on these questions. And if theres anything else you’d like to mention about your experience thus far, please do.

thanks!

Here is my response to his questions:

1. Can the programming world be unforgiving? For example do you find yourself re-programming the same thing 10-20 times a day and working late because of it? Are you asked to program an entire site in 1 day?

The programming world is very forgiving. There are a lot of ways to accomplish the same thing in the programming world, and the resources online are plentiful to help you out if you need it. When it comes down to it, the best way to program something is to make it maintainable, easy for another person to understand, and that it runs quickly in the browser.

2. From what I can tell, the pay is generally higher for web programmers vs designers. Do you have any thoughts on that?

I would say pay is higher for programmers. The design world is kind of in flux right now. Designers are starting to learn HTML/CSS and design in the browser now rather than use static PSDs. Because of this, the line between front end and design is growing thin. Some people are still holding onto the past, mainly because their background is in print design, but that will soon be a thing of the past. I think with your design skills AND your programming skills, you are a really great candidate for a high paying position.

3. If there was one spot I’m still lacking in, it’s javascript and js frameworks like angular or backbone. Honestly, I’m still learning vanilla javascript. Do you use these? Are they important to the daily life of a front end dev?

JS is definitely part of my daily workload, but its rarely anything more than simple DOM manipulation with jQuery. Tech like backbone and angular have their place, but unless you’re building a custom app from the ground up, they are rarely used in practice. Vanilla JS is a great thing to learn, but jQuery has also become the industry standard. I wouldn’t worry so much about JS unless you find its something you really want to do. It can be a rabbit hole of the latest and greatest frameworks from week to week. If you don’t want to pursue more JS, I’d suggest leaning more toward User Experience.

4. Are you always rushed, constantly stressed out?

At my current job, no. In the past, I worked at smaller agencies that created brochure sites with picky clients with little experience on the web. Now, at my current job, WebLinc, I work in a small team at a larger company. In that small team, we work on a set of client sites, working with their e-commerce directors and marketing teams to tweak and promote their site to users. It’s like a different world when you’re working to refine a product vs rushing to spit out a site to meet a deadline.

5. If you could pick the hardest or most stressful thing about working full time as a programmer, what would it be?

I don’t really have many stresses at work. If I had to pick something, I would probably say pushing code live and worrying that it might break while I’m asleep or something and the client could be losing money. With all the QA and code review we do, plus all the monitoring we have in place, it doesn’t affect me that much.

6. Everyone has their own opinions of front end vs back end. Are you required to manage servers, change dns settings, purchase the domain names, transfer databases, move wordpress sites to a new host, that kind of thing?

No, we have a whole department that takes care of that stuff. I work only within the front end HTML/CSS code. Although I like to understand what the other branches of the company are doing, I would never do it on my own.

7. What are your thoughts on the current job market for front end devs?

The current job market for front end is amazing. Every meetup I go to, people are always making announcements that they are hiring for front end. Personally, I’m constantly being bombarded with recruiters trying to entice me away from my job. And here at WebLinc, we are always hiring front end developers as well.

The post Email Q&A: Becoming a Front End Developer appeared first on Pete Schuster.


from Email Q&A: Becoming a Front End Developer