The ewakened blog

we enlighten code
Ewakened

We create web sites and web applications.

Contributors
FreshBooks
Tags
Get Updates
 

7 tips for finding a good web developer

Today we spoke with a woman who runs a very successfully business, but is less than happy with her current web developer.  Listening to her describe her problems, it was clear that she made some bad decisions when picking a web developer.

To help you avoid making the same mistakes, here are seven tips for finding a good web developer.

1.  Look for someone who is proactive.

If you are building a website for yourself or your business you need to realize this is not a weekend project.  Your developer should be enthusiastic about what they do and should want to help you make it the best it can be, this means being proactive.  For example, maybe your content is really well suited for a mobile site.  Will you know this?  Will you design this yourself.  Likely no.  However, if your developer loves what they do, they will probably test your site on the iPhone, the iPad, the N30 and yes the PlayBook.  If they think this is going to be a big project then they can send you an estimate, if it's quick.  They might just do it for you :)

2.  Don't judge solely based on portfolio

Too often companies discount you due to a lack of a good portfolio.  Many companies cannot publish a lot of their work and others are just getting started.  Clearly, you need some baseline measure of their work but don't let it make or break the decision.  Use the portfolio as a conversation starter, find out why they made the decisions they did.  See if their thinking and values mesh with yours.  Values and compatibility trump a portfolio every time.

3.  Look for ambition

A lot of times you won't have the budget to get "one of the big boys", so look for a company that has ambition.  Ask them the question.

Where do see your company is 5 years.

Their answer will tell you a lot about how serious they are.

4.  Look for flexibility.

The web changes so fast.  Web developers need to embrace this fact and ride the wave.  Some developers are very set in their ways and set with their tools.  If you love using a hammer everything looks like a nail.  Remember all of the people that thought Flash would take over the web... well it did... for about 2 years and now it's switching again.  You want to find a company that embraces change and isn't afraid of it.

5.  Be willing to pay a retainer.

Building a website involves some upfront costs.  Things like servers, designers, designs, tools etc.  Web developers often pay out of pocket for this kind of stuff. Companies that charge a retainer up front mean business.  This should give you confidence.  If they don't, they are either very successful, or haven't learned the "right way" yet.

6.  You get what you pay for.

Web development is not cheap.  Regardless of all the ads you might see online for $12 websites, this is not what you want.  Granted, sometimes a $100 throw away site serves your need, but this is rarely the case.  Don't expect to pay anything less than $2500 for even a simple website.  Also, be wary of things like Search Engine Optimization and other "extras", all the good guys do this anyway. 

7.  Look for good listeners.

If your developer chats your ear off about why Ruby on Rails is better than Django, or why php is dead or why .Net is for corporate snobs... politely finish the call and scratch them off the list.  Websites are all different, unique and special.  Things like tools don't matter too much.  Some developers love hearing themselves talk.  This is a sign of bad communicator.  Your developers need to be excellent listeners or you will spend a lot of time and money going back and forth when your ideas and their ideas don't meet halfway.

So... that's it!  Clearly there are many more we could discuss, but this is a good start.  Go with your gut in the end and pick someone that makes you feel confident and happy.  Your website is very important and it should be to the people who make it too.

Thanks for reading.

Filed under  //  advice   developers  
Comments (0)
Posted by Kent Fenwick 
 

Please stop using IE6

If you are using IE6 you have to stop.

Ewakened recommends Firefox, Chrome or IE9 but we realize this is not an option for everyone.

Please go to Microsoft Update or Windows Update and install ALL of the updates. Microsoft is far from perfect but they try and make up for it with constant updates and hot fixes. However, due to their lawsuits in Europe, they cant force you to install them. I know it's an inconvenience but it is necessary.

Besides when you use IE6 you are missing out on years of great browser improvements. Internet explorer 8 isn't bad and Internet Explorer 9 is awesome, Firefox and Chrome, even better. So run the updates, make yourself a cup of tea and start browsing the web the way it should be browsed.

This has been a public service announcement from Ewakened.

Comments (0)
Posted by Kent Fenwick 
 

Ewakened loves Fresh Books

FreshBooks

If you are like me, you are an entrepreneur and you have changed accounting system more times than you can count.

On second thought, hopefully you found Fresh Books at the beginning and didn't need to look any further.  Its amazing that something so simple can make me so happy but it does.  I have been using Fresh Books for a week and don't know how I lived without it.

Fresh Books isn't a full blown accounting system.  It doesn't do bank reconcilations or anything like that.  It's really designed for invoicing, expensing and billing.  Since I have an account that files my Tax for my business, this is really all I need my software to do.  If you need more accounting like features,  it has a whole whack of plugins and plays nice with a bunch of different systems such as Xero.

So how did we get here?

In the past, I used two very good applications to manage my finances: Billings and Less Accounting.

Billings is beautiful.  It's built for the Mac and it shows.  The animations, graphics and user interface are stunning.  It also has a really great iPhone application that does everything you want it to do.  However, I found it really hard to sync across multiple machines.  I used MobileMe and Dropbox with some success but found the syncing clumsy.  Also, it was designed more for invoicing and billing rather than true accounting and expense tracking.  This lead me to Less Accounting.

Less Accounting is also great.  It's built using Rails which gave it huge points in my book and is really one of the main reasons why I checked it out.  It is exactly what it claims to be, it's a simple accounting system.  However, something about it didn't click with me.  I wasn't a huge fan of the user interface and found the constant popups a little annoying.  Less Time Spent, the time tracking component was awesome and I miss it at times, however, Fresh Books has that covered too.  Also, the Auto-Syncing of Credit Cards and Bank Accounts was really bad.  Very buggy.  This could be because I am Canadian, but regardless I wasn't a fan.  I really used it as an expense tracking application and sent a few invoices with it.

Then I rediscovered Fresh Books.  When I started using it again it was magical.  The interface is beautiful, it's fast, it has the most practical time tracking section of any billing software I've used and it has really flexible billing options.  It also motivates you to get more business, it shows you week by week how much you are billing, and if want, shows you how you stack up to other clients in your business category.  I enjoy logging in and tracking time.  I enjoy making expenses.  This is a good sign.  

Fresh Books also has a great iPhone app called MiniBooks, with solid syncing and does everything you need a mobile app to do.

So if you need to bill, tack time, send invoices and keep track of expenses and you want to smile while doing it, start using Fresh Books.

Did we mention we love it.

Filed under  //  accounting   apps   tools  
Comments (0)
Posted by Kent Fenwick 
 

What HCI can teach us about API design

The May 2009, edition of the ACM Communications magazine had a great article about API design.  The author described in great and insightful detail some of pitfalls, and common mistakes that API designers make.  The entire article is worth reading, but if you want the elevator pitch, here it is.

Many API’s are poorly designed since the designer is the implementer and is too close to the code, therefore assumptions are made too often and are too often wrong.  The implementer also assumes that the consumers of their API will be similar to them, when in reality there is no reason the consumer will be anything like the provider.

What struck me about this article is that you could replace API design with Design.

Think about it, everything that I just said about API design is true for design in general.  More often than not, the design of the software, (especially web applications or internal applications) is done by the people writing the code and stepping into the shoes of the person using the software is not a skill that most developers posses out of the box.

Treating API design as a subset of design; maybe we can apply some of designs best ideas and best practices to API design.  Two of those best ideas I will argue is User Centered Design and Participatory Design, both of which could be and should be applied when designing an API.

User Centered Design (UCD) is focused on the user.  The idea is to design a solution around a given population of users that are already solving the problem you are trying to solve, but perhaps in a sub-optimal way.  UCD is therefore a joint effort between stakeholders and software designers since many aspects that might be cool and compelling to software types, have little to no value in the real world.  UCD involves heavy user feedback at all stages of development.  Ideally, iterative design is used so that small incremental changes can be tested with users, feedback can be acquired and then incorporated into the next iteration.  This process is what formed the basis of iteration cycles in Agile Development, Extreme Programming and Scrum, while it has become very popular recently, it has been used in Academia for over 20 years, namely from Ron Baecker, Bill Buxton, Ideo and many more…

Participator Design (PD) takes UCD to a new level by concurrently involving stakeholders throughout the design and development process.  The idea is to remove the separation between producer and consumer, thus making the users active members of the development team.  The key to PD is not to simply pay the users or domain experts lip service, but to give them real, authoritative roles in the design of the product.  Users actively write, discuss, vote and even veto features.  This keeps the developers humble and ensures that only usable and practical features are included.  At the same time, developers can chime in with innovative ideas that users might have never thought of given their backgrounds and engineering expertise.  (There is a great podcast from the guys at the Java Posse talking about Design and Engineering, check it out if you are interested) If done correctly, PD can be one of the most powerful design tools.  So why doesn’t everyone use PD?  Well, it can be more expensive up front since you need to find a domain expert or two or three, have frequent design meetings and training sessions bringing different groups up to speed etc… therefore the process tends to take more time.  However, there are often fewer problems and more users once it has been released, so the trade off is a worthy one.

So bringing this back to API design.  I believe that UCD and PD can drastically help API design and should be employed by companies who are API heavy or even for everyday Joes looking to make a new API for a given service.

I have had the pleasure and pain of writing and using a variety of different API’s.  Some of the best, are from Apple and Google.  Apple’s iPhone SDK, while massive and complicated, becomes intuitive after the initial barrier of Objective-C gets out of the way.  Google tends to like REST, and simple URL based APIs.  My guess is that since Google needs to use their own APIs and SDK’s much like Apple, they are very well designed.  Microsoft has some good ones too.  Their Windows Mobile API and SDK are top notch!  In fact, I have lots of fun writing Windows Mobile Applications, that being said they are not nearly as well thought out as Apple’s iPhone SDK.  Even though they have more documentation, Apple tends to self document, whereas Microsoft often has two methods for doing the same thing, or slight variations that make it hard to know what the side effects will be.  Again, this is personal preference, obviously some people HATE the iPhone SDK due to its poor documentation and MVC architecture, however, once you start using it, you see it’s real power: self documentation and reuse of common design patterns for solving different problems (think Delegation).

Looking back, it would have been cool for either of those companies to ask users what the API should like it.  Go out into the wild and give users a bunch of different options for calling the same core method or preforming the same task and see which one the users prefer.  Even better, setup a website similar to UserVoice where users can vote on the API they want.  The new Google Analytics API looks like it was designed for users, since it’s so clean and simple.  It reminds me of Ruby and one of the things I love about it.  When I am teaching ruby to someone and write the following…



irb> (1..4).each { |number| puts number }

I really don’t have to explain what it does.  It self documents.  I heard that Matz, the creator of Ruby, would constantly show the language to colleagues and have them play around with it.  They would give him the feedback and he would iterate.  I am saying that there should be more of this.  We need more User Centered API Design and Participatory API Design.  I know that it seems like common sense and unfortunately many design principles, when written down or discussed seem like common sense, but the fact is they aren’t being applied.  If they were, there would be less crappy APIs.

I promise the next time I am designing an API I will employ these methods and report back on how it goes.  I really think this could work, and could go a long way to making sure that another article doesn’t have be written 25 years from now in Communications complaining how we have solved teleportation, our energy problems and have made headway on the meaning of life, but still have terrible APIs.

Thanks very much, let me know what you think,

Kent

Comments (0)
Posted by Kent Fenwick 
 

Super Simple Rails Tabbed Navigation Helper

The Opportunity:

You have just built a fantastic website for a client using Rails (of course).  Everything is to spec, your tests are all passing, your delivering early and are waiting for your cheque to be cut.  Then, all of sudden, your client rushes into the room and says,

Hey… so can you like make it so that whatever section of the site I am on gets highlighted in a different color on the navigation?  You know, just give  them some feedback. That’s really easy right… shouldn’t take more than a few minutes?

Any good web developer will tell you that at least one of the things the client said is right,  it shouldn’t take more than a few minutes to add navigation feedback, however if my code reviews, water cooler conversations and open source browsing has taught me anything its that this problem is not always easy to solve.

Actually, let me rephrase that… there is no design pattern for solving it.  There is not a set way of doing this.  It’s not hard by any means, but each developer has their own way of doing it.  Some people like using regular expressions, others like to use… shutter… global variables.  Then some people even create entire plugins and libraries to help them do this tabbed navigation.

The guys over at The Rails Way did a great post about Tab Nav helpers where they outlined some of their favorite methods.  To be honest, I didn’t like any of the ones they put out.  I looked through the comments and found one that resonated with me.  It was Andrew Hobson’s layout_link_to helper method:

There are lots of things I like about this solution but a few places where I thought it could be improve.  Firstly, I want to be able to pass some more options to the link in case I have a custom CSS class or if I want to pass the :target attribute.  Also, this helper only works when you are on the exact path specified.  This works well, but what if you have a Projects Controller and you want the tabbed nav called projects to be highlighted when on the new, show and edit pages.  It’s a pain right now since it only checks for equality of path, all you have to do is add a little string.include? instead of string ==.  Here is my re-write that incorporates both of these fixes.

The Solution:

So, there you have it… a simple and powerful tab nav solution for your next Rails application.  Thanks to the Rails Way, Andrew Hobosn and yours truly.

Thank you so much,

Be well,

Kent

Comments (0)
Posted by Kent Fenwick 
 

Trying and failing is better than not trying

So last night I had some delusions of grandeur and my buddy Nick wasn’t around to talk some sense into me.

Here’s the story.

Recently, I have been experimenting and using Compass, a really great CSS framework that comes with a base of excellent default styles and custom styles along with blueprint-css, yui and other CSS framework support.  Anyway, it’s amazing and has great Rails project support.  I decided to try YUI, Yahoo’s CSS framework since Chris Eppstein told me that it had great Flex / Fluid grid support.  This kind of behavior was important since I had tried using Blueprint on a previous project, and even though it does so many things right, it isn’t really that agile since if you change the layout, mainly the width of the web site, you have to go around and change all the class names to reflect the new layout.

What I wanted was a way for me to express blueprint-css span’s in % or em rather than px.  You can sort of do this using Compass and Sass, however, it doesn’t really work since the container div always needs a fixed width.  I wanted to be able to nest grids within grids using % units so that the site would fill the screen.  YUI lets you do this using however I ran into problems when nesting.  Also, YUI uses an obscure class naming system that I really didn’t like.  After trying to make it work for a few hours I began thinking that I could do this much easier and better than Yahoo did.  As it turns out, the guys at Yahoo are very smart since there are so many edge cases that you need to cover.  I scaled down my project and began writing very common CSS layout patterns such as a 50% / 50% grid, 30% / 70%, 70% / 30% etc.  After about 5 hours, I had managed to write it.  It worked, it was awesome and it was almost exactly the same as the YUI classes minus edge case coverage.

So, am I upset that I wasted my time?  No, not all.  I am happy that I tried to do it, even though I came to an existing conclusion.  The act of doing it helped me understand div based grid systems in CSS better and also gave me an appreciation for the edge cases and how common they actually are.  At the same time, I still think I have the seed of an idea, and with a more liberal time frame in mind, I have started working on a fluid CSS framework similar to blueprint-css using Sass.  I will post it, when I have something more substantial than a YUI clone :)

Moral of this story.  Just do it!  Don’t like a tool you are using? Try and rewrite it.  Don’t like your editor? Go and write your own.  Don’t like Mac or Windows, try hacking on Linux.  Chances are you will not get as far as you thought, but that’s okay in fact that’s what learning is all about.  Give it a shot, the best thing that could happen is that you will have something really amazing to share, the worst thing is that you will gain an appreciation for the problem you are solving and for the tools and people who help you solve them.  Also, keep in mind that everyone undersells themselves and thinks that the person on the other side of the screen is smarter.  You are smarter than you think you are, so go prove it.  When you do prove it, let me know!

Thank you and take care,

Kent

Comments (0)
Posted by Kent Fenwick 
 

Re-Factoring

As most of you know, while I am not doing research, I work on Prospectlinker, the best place on the web to have professional conversations with smart people outside of your network.  Prospectlinker has gone through many different iterations, some on paper and some in code, but we are currently working on a big rewrite.


I often wonder if I am the kind of person who just likes refactoring code, or if its really necessary.  There is a risk when you refactor since you might be adding additional complexity that isn’t necessary, you might be using the refactoring as a highly productive means of procrastinating (my fav).  You really do need to think about certain things before doing a re-write.  I won’t pretend by any means to have the answers or even the questions that you should ask since I don’t think there is too much logic that can make the right decision.  I think you need to be able to have a look at all the evidence, go for a walk, or a run, or watch some tv, read a book, anything to distract you from the project and then let your brain do a big integration and see if the decision is a good one.  If you try this I think you will find your answer.
 
I am speaking from experience here since this isn’t the first time that we have considered a re-write.  When Prospectlinker made the change from nkdGuru, I fought very hard to re-write the code, I fought myself, and my team.  In the end, after some anti-thinking (feeling more than thinking) I realized that we had enough of a good base that could be adopted to convert nkdGuru to Prospectlinker.  At the time, it was the best move and I would make it again given the same circumstances, however, I now know that it was the wrong decision.
 
There is more to re-writing code then simply writing code.  There is a mental aspect that trumps the physical.  Re-writing is more of a mind set then it is a concept in programming.  Sometimes things need to be re-written, they need to be forgotten, appreciated nonetheless but ultimately forgotten.  Making something, like old code fit a new problem is limiting… re-writing is liberating.
 
I am 2 weeks into our Big Rewrite and feel so much better about Prospectlinker than ever.  It’s time to make what is working better and to purge anything that is holding us back.
 
At the end of all of this I think Chad Fowler was right when he quoted the unrelated but ultimately insightful Martin Fowler,
 
The question to ask isn’t if you should refactor or rewrite your code, it’s when you should refactor or rewrite it.
 
So take the plunge and refactor something right now.  Maybe a program, maybe an interface, maybe a plugin, maybe a gem, maybe a script, maybe even a relationship or work flow, anything at all that you feel is limiting you or limiting others.  If you don’t do it now, the time will never come.
 
Good luck and as always, share your experiences with me so that I can learn and re-share them with others :)
 
Take care and have a great night,
 
Kent

Comments (0)
Posted by Kent Fenwick 
 

What submarines can teach us about productivity

Imagine if we were able to dive like a submarine and surface only when we need to.  I think we can do this.  I think we can make this fun.  I think we can make this productive.  Let me explain.
 
We often find ourselves so distracted with Twitter, News, Social Networking,not to mention email; that we have trouble focusing and keeping things on task.  This is a huge drag on productivity.  Some extremists tell you to stop doing these things entirely, or severely limit your time on them each day, but this didn’t work for me.  I often find myself hypnotized by twitter.  I can watch the updates come rolling in, aimlessly clicking links, reading things that don’t have much impact on me either way. I can do this for an hour easily! Not all at once, but off and on.  How is this possible!  Is this the new form of procrastination? I think we can still have twitter, email, Facebook and any other site that makes us happy but this week let’s try it like this:  BE DELIBERATE and have fun while doing it.
 
I vote for a submarine work flow.  Deep dives that last as long as you need them to be to feel productive, followed by equally productive periods of surfacing.  This up and down, ebb and flow will bring a subtle sense of accomplishment and reward to each hour, each day of your life.
 
The more I think about this idea, the more common sense it brings to mind since so many things are cyclical.  In fact, it’s hard to find a natural process that doesn’t, at some level of reality have a cyclical nature.  Why should we be any different.  There will always be ups and downs, the goal is to make the most of the ups, and enjoy the downs for letting us know what it means to be up.
 
I challenge you to try this and measure the outcomes.  I love this notion of measuring simple behaviors and changes to those behaviors, it can be a very enlightening experience since there are so many untested assumptions that we carry with us.  For most of us, the assumption is that we have to multi-task, be superman /superwoman, respond to emails right away, update twitter at a given interval because that’s what we need to do… these are all assumptions that might work for some people, but that doesn’t mean by default it will work for you.  So challenge it.  Test it.  The worst that can happen is that you will realize it was a good idea and does work for you!  At least you know.  Most likely, you will find that some if not all of your assumptions, especially about work, are flat out wrong!
 
So when you work, work!  Don’t think about later, don’t look at twitter or email, just work and enjoy what you are doing.  When you are done your dive, surface for some air.  Go for a walk, have a healthy snack, check your email, tweet something, go read a blog (maybe this one)… then hold your breath… its time for another dive.
 
Take care everyone,
 
Kent

Comments (0)
Posted by Kent Fenwick