Two web artists. One amazing company.

Stahp "the Internet" from sabotaging your work time

from Sarah Prasuhn on December 7, 2015 05:05am


Reddit. Facebook. Twitter.
Git. Trello. Email.

Yesterday's tabs and windows stare back at you offering two paths to start your day: productive work time OR casual meandering through all things internet (evil whispering) that no one has to know about.

Choose carefully, because once you start down the (now literal) click hole can be hard find your way back. We all do it from time to time, but I've created a way to break the cycle of getting lost at the start of my work time and you can to.

Read more

To hourly or not? How Block Billing is Changing EVERYTHING

from Sarah Prasuhn on August 4, 2015 11:55am


Everyone bills hourly, and as it turns out just about everyone hates it. This process makes clients feel cheated, and agencies exasperated.

At the end of the day there's usually at least a hint of disappointment in both how long it takes to get paid, and/or how much it all came to.

You come to expect that you are going to be disappointed 99% of the time. So most of us just cross our fingers and hope the project doesn't become hell for everyone at the end of the month.

But this makes zero sense. There is so much more we can do to change the way that we run our consultancies, and so this summer I began experimenting. (Note: Blocks for September are starting to book, so if you think this is for you at all, get in touch.)

I've considered block billing for years, but thought transitioning would be some dramatic ordeal. You know tell ALL the clients, change ALL the forms, and it was some work...but the start...the start was so so simple...

A little column in a table of rate options. I'd heard that competing against yourself was a good thing. So, I decided to list three price options for some new potential clients. Block billing just happened to be one of them. I even did this for a well established client, and guess what it worked there too!

The client ALWAYS chooses block billing. It's been kind of awesome. Because it turns out client's like to have a general idea of what they're getting too.

Would this work if I only offered block billing? Probably, but even then I would give options, control is such a fleeting thing on a web-project for clients give it anywhere you can.

Would this scale? If you scale the size of the block, say a week, this works well for even larger agencies. In fact I learned it from watching @brenandunn who's advice is aimed at consultants, but scales quite nicely to agencies as well.

The goal of block billing is to make the focus on the features of the project not on the time spent. This way the website, the users, you, AND the client all win. If the focus is only on the time spent, it's very easy to lose perspective quickly.

So here's how it works, and the awesome results.

Read more

Styling Bootstrap 3 Buttons in Drupal 7

from Sarah Prasuhn on June 2, 2015 03:20pm


One of the greatest differences between Bootstrap 2 and Bootstrap 3 is the out of the box look and feel. Bootstrap 2 had a lot more pre-built colors and states, whereas Bootstrap 3 is a little more barebones.

So we're going to cover adding the class to integrate the basic default buttons, and then in Part 2 cover how to implement some more pre-built styles the colors, and sizing etc.

Like most frameworks you just add the class of course...but where?

Read more

Running Your Agency/Tech Company like a Factory is Destroying Humanity: Part 2

from Sarah Prasuhn on May 11, 2015 12:45pm


In case you missed it Part 1

Very carefully I cut the letters out of the magazines that are strewn across my table. My fingers covered in glue, I lay them out one at a time on a piece of heavy duty paper, a message for the CEO of my friend's company. A message to save humanity:

"Your company is following the startup lemmings off the cliff, do you care?"

-- Anonymous

Every year your agency or startup is throwing away thousands of dollars, because you follow some very bad habits that reward mediocrity and egos. I know because as a CEO of even a tiny company, I've watched you bleed and wanted to hand you the bandage.

At Shomeya I am the CEO and the Project manager, when I fuck up and put my programmer in a bad position I see how it effects his work AND his home life. I feel every late night, and regret every poor choice when I said yes to the client, because I deal with the results.

So I learned to adjust Shomeya to make better choices. And the good news is these choices can scale because they are based on something we all deal with no matter what the size of our payroll; human brains.

Read more

Running Your Agency/Tech Company like a Factory is Destroying Humanity: Part 1

from Sarah Prasuhn on April 22, 2015 03:10pm


I'm running endlessly through the woods, as far away from Silicon Forest/Valley as I can. Facebook has collapsed, so has Google, so has everything. A post-social media, free internet, apocalyptic world has ensued and all of the developers have gone into the woods to escape the aftermath clutching their now worthless laptops. In my dream all the CEOs of the software companies are in a room patting themselves on the back for giving it a good go, while the world falls apart in the aftermath of their self-focused existence.

This may have just been a crazy post White God viewing dream I had, but it touches on something real. Something that as a consultant for multiple companies I see all the the time.

And it's killing me. It's killing your company, and you're too busy getting beers with your funders to notice. Meanwhile your developers, project managers, and everyone else that is the core of your business is slowly burning out until they rage quit and go somewhere else to start it all over again.

Read more

Web-Consulting's Dirty Little Secret

from Sarah Prasuhn on April 9, 2015 01:05pm


It's the day after a launch and your client calls you in a sheer panic. Traffic is not as high as they'd like! Why aren't their new social media features paying off? Don't you know what you're doing? And to top it all off the site is slow! You need to fix this now.

As you listen to your client yell, you drift back in time to that first meeting where you both are posturing and laying down the ground rules for each other. Business as usual planning out the new details with excitement and anticipation.

And then the moment comes back to you. The moment when you said nonchalantly, "We can do that feature, but it may cause the site to slow down. Why is this feature so important?" And the client, also nonchalantly said, "We just need it, our competitors all have it." And you both went back to going over the other features on the list, not realizing that you had just wasted thousands of your client's dollars and hours of your life on something that most users don't give a flying flip about bringing almost zero value to the world, all because everybody's doing it. This is how the business just works, and hardly anyone ever questions it.

Read more

Knowing when to use content types and when to use custom entities

from Michael Prasuhn on April 3, 2015 07:15am


Ever catch yourself staring at your editor? Then switching over and staring at the content types overview of your new Drupal site? Then back to the client requirements? And then doing it all over again and again while you face a decision? Drupal content types and fields vs. custom entities. That's the tough decision. The choices you make here will affect almost part of site building to come, but it's so hard to know which to choose.

On one hand, Drupal fields are getting better, faster and more flexible all the time with better integration with contributed modules like views. But at the same time the new entity API with Drupal 7 is more flexible than ever, allowing you to add fields to even your own custom entities. So which route should you go? How can you make a decision like this without second guessing yourself all the time?

Why getting it right is important

While lots of projects can go either way the downsides can make the difference between a successful web project and a maintenance or performance nightmare. Using content types and fields with a complex data model that requires lots of complex queries can hurt performance, but using custom entities when you don't need them can add a maintenance burden when it comes time to upgrade your site or make changes. So how do you make that decision?

Read more

A cheat sheet for hook_entity_api()

from Michael Prasuhn on March 26, 2015 11:10am


The worst time to read software documentation is when you're trying to fix something that is broken and you have no idea why. I'd say it's like shopping when you're hungry, but it's actually the opposite. When stuff breaks for no apparent reason and you're on edge it's easy to notice every little issue with the docs, and you instantly form a very strong opinion on documentation.

The good news is that as a Drupal developer, you have tons of awesome documentation just a click away on or and contributed module documentation is better than ever. Even though almost everything you could ever want to know about Drupal internals is available on (even the source code!) sometimes you need to combine that with contributed docs, or dig in a little deeper.

That's exactly what I had to do while working on the first few chapters of Model Your Data with Drupal. Hooks like hook_entity_info() are well documented on, but the Entity API module adds it's own options to the mix. Entity API has great docs on it's options as well, but there isn't a lot out there that thoroughly documents them together, or the interaction of their options.

Read more

All about that trace, 'bout that trace

from Michael Prasuhn on March 19, 2015 09:25am


No one likes debugging code when it breaks and you can't figure out why it's broken. That piece of code might have been hard enough to write in the first place, or maybe it's a snippet that "should work" from a coworker, or maybe the documentation is missing, or maybe.... But what if you've checked, double and triple checked, and it's still not your code, it's something else in the system – code you're calling out to, or something that is calling your code – what do you do then?

Enter the backtrace, (also known as stack trace, or just trace). A powerful weapon in any software developers toolkit, it is more and more useful as the software you develop grows in complexity (Drupal 8 anyone?)

Read more

Subscribe via RSS