joellensmith:

thrift store picture turned monster attack

joellensmith:

thrift store picture turned monster attack

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 */