Blind Ape Seo

As a recent thread on Wickedfire has had me searching for some introductory texts, I stumbled across this neat little introduction to web design by Robbie Manson.

I know that readers of this blog have likely surpassed this level, but I still wanted to share.

Enjoy,

::emp::

One acronym that will get spoon.fed to you anytime you look at marketing methods is AIDA.

AIDA stands for

• Attention
• Interest
• Desire
• Action

And provides a solid (and easy to remember) foundation for marketing efforts.

However, it took me quite some time until it finally clicked in my head about how to use this in landing page design. The key to me was that a user reads a page from top to bottom.

Keeping that in mind, you can easily apply AIDA to a landing page.

So, before I keep boring you any further, I will just link directly to an example page, that should provide a pretty self -explanatory AIDA page design.

It is built using the blueprint framework, and you can get the .zip file directly from the page.

Enjoy.

::emp::

Fugue icons

pinvoke has some neat icon packs to use in your web projects, called Fugue and Diagona. All they are asking for is a link back, or a modest price. The fugue icon pack, pictured above, has over 2000 icons in it, the diagona icon pack 400 of them.

All icons are easy to read and look nice, while the diagona icons are a bit more simplistic than the fugue icons.

Go check them out.

Have a look at this list of tools for hacking stuff together on the fly.

A lot of the times, these tools either suffice or they serve to proove a concept. Yahoo pipes, for example is an easy way to throw together a scraper that can then be made more sophisticated when coding it for real.

I especially enjoyed the article on using Google spreadsheet to scrape wikipedia.

Enjoy.

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

oops, I completely forgot I still had to wrap this up. I even began work on a new article series already. (Closer to affiliate marketing bread and butter)

To wrap this up, I would like to reiterate the key points I was trying to make, review the concept of metawork and point you to some good literature on the subject of managing projects.
1. Outsourcing is broken
Well, not really broken, but it has difficulties. One side wants quality work for less, the other side needs money.  “Modern” bidding wars only aggrevate the problem.

2. Telepathy does not work
Make sure your requirements are up to the task.  They are the only way to communicate what you want. They are also your sole witness in a dispute.

3. Numbers are your friends
Numbering tasks, bugs, features makes it easy to track work.

4. The grimoire
Keep track of good and bad experiences to avoid getting burnt twice.

5. Be nice
Bonuses are one thing. Being nice to developers, graphics artists, writers, etc.. is even better.

Meta work

I use the term “meta work” to talk about things you have to do that are above the level of an individual project. The fact is that this work will take up a good chunk of your time once you start managing projects and people. And it should!

Meta work is thinking about the way you are working. Take a bit of time out of your busy day and reflect.

• Are you communicating clearly?
• What problems have occured and how could they have been avoided?
  (This is meta work, as there is no thing you can do NOW to avoid the problem, as it has already happened.)
• Have I been friendly to people? Why not?
• What do I need to know about? Is there anything I need to research?
• …

I am a firm believer in the value of meta work. Any manager not doing this is a waste. In fact, even as a delivering worker, all your projects will profit from this practice.

Here are some good books now:

The Art of Project Management (Theory in Practice (O’Reilly))
This textbook is a good introduction into project management. Highly recommended and not as dry as most books on the subject.

Code Complete: A Practical Handbook of Software Construction
Code Complete is a very technical book. You will benefit the most of this if you are a developer or if you are managing highly technical projects. Probably too dry for  a lot of people. Good nonetheless.

This about wraps it up, young grasshopper.

Good luck with your projects and… Have Fun!

::emp::

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

If you fear that your old simian has abandoned this article series, don’t.
It just took me fotever to write this entry,mainly because

You should know this since Kindergarten!

Sadly a lot of people still don’t seem to get it.

What is getting to me are the hostile to upright racist and insulting remarks often targeted at foreign developers.

To make one thing clear, I am far from the touchy-feely, the world is one big bundle of joy, all people are wonderful type of guy.

The reality is: you will meet assholes everywhere, all around the globe, of all nationaliries and heritages.

But I have worked with people from all over the globe. Indians, Russians, French, Germans, Swiss, Italians, Spaniards, Americans, Italians, English. and honestly, most of them were good people, taking pride in their work and doing their best.

My advice to freelancers:

Keep a black book on employers just like the one I described in my last post.

Assholes are not worth the money you could earn.

My advice to entrepreneurs outsourcing work:

Don’t be an asshole.

Simple as that.

::emp::

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

Part 4 - The little black book that could

So here comes another insight into building projects with outsourced labor found online.

You are going to get burned.

Yes, no beating around the bush. You are going to have bad experiences, you are going to get burned.
Granted, the cost of those burns is going to be manageable - we are looking at cheap, outsourced labor, after all. Still, it is going to sting.

So we are going to try and keep that sting to a minimum.

So what am I proposing to avoid those half-built websites, shoddily thrown together backends, badly designed layouts?

Of course, making one of those trusty excel sheets to keep track. (you knew that was coming, didn’t you?)

Fool me once - shame on you. Fool me twice - shame on me.

It will still happen. You write great specs (of course), you communicate clearly and concisely (naturally), you offer a fair payment for the work (par for the course) and still - shit happens. Or in the age of the net - excuses happen.

Deadlines seem to have a bad effect on pets and relatives of all kind.

Time to go meta

After cutting your losses, renegotiating or transfering your work to another worker, comes the time for your meta-work.
(I define this as work above the level of the project or any ongoing work, defining strategies and processes.)

In this case, this means keeping track of people you gave work to and how they performed.
Besides keeping track of nicknames / avenues of contact, keep track of the deadlines, slippages in deadlines, failures and reasons for failure.
(This is the time for some humble reflection on your own work, such as specifiactions as well.)

Then you have to deliver the

Consequences

1. Someone who does not deliver on the first or second project - never going to work with them again.
2. Deliver two projects without fail - ask for a direct mail adress and keep on file.
3. Three projects without fail - ask for direct contact and the possibility of giving projects privately and on short notice, also bumping up the rate a bit without them having to ask.

After three projects, a dev will still be blacklisted from my list if he fails to deliver for shitty reasons and being rude about it.

But a good dev is cut some (some!) slack.

Why? Because shit happens. Pets do get sick, grandmothers die and sometimes the sky falls on your head.

Here it is important to keep track of how many times this happens and if the person is forward and honest about it. If you are going to disappear for weeks at a time and then come back with a lame excuse - well, you are not on the list of good people to work with anymore. And although I do not think that “outing” people on forums, etc is a good idea .. do not hesitate to contact friends and tell them to avoid that person.

To end this on a more positive note:
People who perform well or even above the specifications should get a slight bump (or bonus) in their pay and should be recommended.
Just fair play.

With a few bad experiences, you will build up a nice little black book of good and exceptional performers who you can contact for your projects.

The little black book that could.

::emp::

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

Part 3 - Tracking Features and Bugs
Now that we know how to write better requirements, here is another secret project management kung fu technique:

Numbering

Oh wow! Yay! Man! WTF?

I am being serious.
Number and name your requested features.
Each and every one of them.

This could look like this (taking up from the last part)

23 Affiliate offer site

23.1 Affiliate button
At the end of the text container, put a green button. The button should be labeled “Claim your prize NOW!”. The color code for the button is #00FF00. See attached screenshot of layout (layout_mockup_01.jpg).

23.1.2  Button function
When the user clicks the button, he is directed to redirect.php in the same directory. The link opens in the same window.

This way, you get a handy method for tracking the work and bugs.

For this, make yourself an excel sheet with the numbers, the name, status and note.

Then, whenever the project comes back into your hands, you can test each number and note the status and eventual bug note.

23 Affiliate offer site Buggy  23.1.2 Does not work as it should, leads direct to affiliate link.

Why numbers?
Numbers are easy to communicate. There is no ambiguity with numbers. Instead of saying “Ya know, that green button at the bottom of the offer page does not work.” I can point the coder to “Feature 23 is buggy, please see the report.”

That way, a lot of misunderstandings are ruled out and development and bug fixing are faster.

Yes, this is a lot of work, but it will save you time and money in the long run.

How so?

First off, you will come to grips with what you are actually asking for. Making a list like this, it becomes easily apparent when something is missing.

You will also come to grips with the size of the project - timewise and moneywise.
If you need an estimate, ask for an estimate by numbers. You don’t need to ask for each and every task, but you can ask by chunks, in the above example this would be #23 - Affiliate offer site.

Hint:
Try to keep the work packages at approximately 1 day or less for small projects, 1 week or less for big (multi-month) projects.

If you are trying to improve your project management skills, keep tabs on how your estimates compared to the times it really took to complete a task. Learn and adjust.

This will also help your estimation skills as a developer, so you don’t end up taking more than you can handle.

::emp::

I just thought I would share this collection, as it seems to cover all daily needs beautifully.

51 Freeware apps for a free PC

Of course, if you are running windows, your PC will never be free completely.

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

Part 2 - Requirements and you
When you give away a project to be done by someone else, the first thing that you will have to do is to come up with the requirements.
This seems to be easy, and everyone wonders how their projects become so garbled in the process.
Now, here is a little secret:
Writing requirements is hard.

Writing good requirements takes practice, patience and a little secret.

The secret to a good requirements document:
Treat the requirements document as if it would be the only thing that stands between you and checking off the task on a list.
Because that is what it is.

Someone who would not know your project or anything else about what you are trying to do has to be able to look at the list and see if an item has been done. Because this is what is going to happen the moment you enter a dispute over a project outcome and - ultimately - your money.

As this all seems cut and dry, here is a real-life example.

I was working for one of the top international banks as a project manager at the time when this happened.
One part of the project I was involved in (thank you, I was not involved in the part that went south) had the following requirement written down and sent to India.

Requirement 3465x/b: Implement a print button as seen on graphical mockup 577254b.

What happened?

Well, the print button was implemented as per reuirement and mockup from the graphics department. One tiny thing: It would not do anything when clicked on. Yes, you heard that right: Nothing would happen.

Whose fault?

Although it would be easy to blame the programmer (and it was tried) He did NOTHING wrong.
He implemented the feature exactly as requested and specified.

Yes, you could say “But he should have known that it should print the page when clicking on the button.” But I disagree.

Why? Because there are easily a few dozen questions like this:

• How should the printout look?
• Which print function should I implement? Is there a print function available for this program already?
• Should or could we use a third party library?
• Should it print physically or convert the page into a PDF?
• Which part of the pages am I supposed to print?
• Should a legal notice be attached to the printout?
• Which font should I use for printing?
• Should the logo header be included? Where is the high resolution logo?
• …

This is what happens when you write shitty requirement documents.
Another drawback is insecure and less productive coders, as they are having to guess your intentions along the way.
Time and cost estimates done on bad requirements are also way off.

How to write a good requirements document

• Treat the document as what it is: The only evidence of what you want to have done. Telepathy does not enter the picture at any point.
• Divide the document into sections according to screens / pages
• Divide the sections into features / work packages to be done.Each feature should be described in a way that makes it easy to identify it as “done”. For a bonus, it should be possible to identify a good implementation from a bad one.

In the above, badly done requirement, implementing the button was “done” flawlessly.

Also:
Update the requirements document with every change and communicate this clearly to your programmers.

Another example:
I want a button on my landing page that leads to my affilate offer versus a redirect page.

Bad:
Make a green button, leading to redirect.

Better:
Put a green button on the lower page, leading to redirect.php

Better still:
Put a green button on the lower page, just before the footer.
Clicking the button will lead to redirect.php.

Best:
- At the end of the text container, put a green button. The button should be labeled “Claim your prize NOW!”. The color code for the button is #00FF00. See attached screenshot of layout (layout_mockup_01.jpg).
- When the user clicks the button, he is directed to redirect.php in the same directory. The link opens in the same window.
- Please contact me with any questions.

Drawbacks to this method
I am tempted to say “NONE” but of course there are.
You will be spending more time on your requirements and you will still mess it up sometimes. Live and learn.

Advantages of this method
Your coders will know exactly what is required of them, leading to them being more productive and feeling more secure in what they are doing.
You will get better results and the chance to dispute badly done work.

Join me for more fun in part 3 -Tracking features and bugs

::emp::