I believe the distinction here is between "contractor" or "staff augmentation" and "consultant." A contractor gets hired to practice his craft, while a consultant (theoretically) leaves a company better than when they first arrived.
This involves things like leading meetings to get buy in across groups, developing plans for what needs to be built, etc. It's very far from sitting behind your screen in Photoshop all day.
One of the best books I've read to understand what a consultant truly does is [Getting Naked](http://j.mp/1mAnhnn).
I understand that it's a different role, hence my interest.
I'm not sure I agree that a contractor is there to merely practice his craft, compared to the consultant who is there to make sure a company in a better position than before. It should be a contractor's job to do that as well.
This is why I'm seeing quite a grey area between what constitutes a consultant, and a contractor, or freelancer.
Good point, and that might be something to point out. What types of issues have you experienced in the past that you couldn't have blanket predicted beforehand?
The main one is how customers are going to react to your product. Spending a few hours on XML sitemaps and a build process for minification might seem like a good idea if you are a perfectionist, but if you end up spending time on these things it means less time for other features.
It's not so much about solving issues to make the perfect product up front, but more about making progress quickly. Number of iterations is one of the best predictors of product quality, and by spending time on things other than getting out the next iteration, you're slowing down your rate of iteration. It might be tempting to think of a website as "done", but a launch is just the beginning.
For example, the biggest issue with our product at launch (http://sonalight.com, a mobile app that allows you to text through voice) was the pricing structure. We realized it was better to give the product away for free instead of limiting usage. We would never have realized this if we hadn't launched and heard complaints from our customer base.
Thanks for the input! I've been debating the merits of minifying HTML, CSS, and JS. I learned about all three of those extensively by exploring others' code. Minifying breaks that. How do you address that issue?
Breaking the readability is the trade-off you have to make, though I think it's worth it for production code, it really brings the file sizes down and if you concatenate all your javascripts in to a single file you can really cut down on requests too.
If you use Google chrome you can click the '{}' icon inside the developer tools to 'pretty print' the javascript which helps a little!
You only minify the deployed CSS and JS, so in development, it's still perfectly readable. You shouldn't really need to read production js, usually, and when you do (for debugging issues that only happen in prod), the little brackets in Chrome that my sibling pointed out will be enough.
It's not about being upset, it's about the view that they are losing their edge in building new, interesting stuff. They are not solving user problems, they're just copycat products.
To become a long-lasting company, you have to be able to build the "next big thing".
Completely agree, and I think that's most people's sentiment. Dropbox has solved my problem enough that 5% improvement isn't worth the time of checking it out.
I'm not an IA or designer by trade at all (Degree in Finance, work in Marketing), and I found that Keynote Kung Fu was incredibly accessible by almost anyone (myself included). I had poked around in OmniGraffle before, but KNKF was just so much easier to use, especially for whipping up quick visual examples of things I want to show.
True that the final product is more styled, but that's when you have to work closely with the designer to make sure they understand you're not implying that's what the final visual style needs to look like.
I've also used KNKF for doing mockups for usability testing, which works very well.
This involves things like leading meetings to get buy in across groups, developing plans for what needs to be built, etc. It's very far from sitting behind your screen in Photoshop all day.
One of the best books I've read to understand what a consultant truly does is [Getting Naked](http://j.mp/1mAnhnn).