How not to write good product descriptions

As Christmas approaches, many ecommerce sites look to optimise their sites so they can be found in search engines, increase conversions and ultimately boost sales.  One of the most obvious ways to do this is update (or write) product descriptions across the site.  Usually if you're an ecommerce site, you sell products online, and the item or product page is where most customer decide to add that product to their cart.

Here are some ways not to write product descriptions.

1) Focus on features - Many retailers focus on the features of a particular product. This doesn't sell your product, you should instead focus on benefits.  Why do I need this 48" LCD TV?  You might be tempted to write on your product page, 'Amazing 48" LCD TV, Flatscreen, 4 HDMI ports, USB and flashing lights..".  Yes this is useful, but is it making me want to buy it? may be... but what if you focused on the benefits? 'Stunning 48" HD Flatscreen LCD Television, perfect for watching the FA Cup or catching up with your favourite soap'.  Straight away I can see the benefits of having this TV.  I can watch the football or Corrie in crystal clear Hi Def.

2) Use Manufacturers Text - Many people copy the manufacturers product descriptions directly from their site or brochure to populate their own item descriptions.  Great!  Now you have the same text every other person selling that product has.  Not too good, I would imagine for SEO if you and 26 other retailers all have the same text word for word.  Taking the time to reword standard copy lets your customers know you care about the product to make sure you know what you are selling.

3) Write for search engines - It's great to write friendly content for search engines, make sure you have keywords and important information in the descriptions, but don't over do it.  Many descriptions are written with search engines in mind and although SEF or SEO'd it just doesn't read well to customers.  Search engines don't buy your products, customers do, and if they can't read your description for all the bold HDMI, LCD and Samsung keywords that's not going to do anyone any good.

4) Go heavy on text - It's great writing descriptions and product information, but don't write War and Peace.  Customers don't like to read!  They want short, sharp sentences or even better bullet points.  Sell the benefits of your product as quickly as you can to your visitors. Don't waste their time or yours with long-winded and pointless reams of text.

5) Ignore grammar and punctuation - This just doesn't look good at all.  If I'm paying good money for a product online, I want to at least know the seller has taken the time to proof read what the material they are using to sell to me.  If I see a product description littered with punctuation, spelling or grammar errors I lose confidence quite quickly in the whole operation.


I hope these are of some use,

Thanks,

3 Layers of Static Code Analysis in PHP

Every developer should be running some form of static code analysis on their code regularly. A recent article I read about how this is done at Etsy makes for what I believe should be a minimum standard of code analysis for any team of developers work on a shared codebase. We shall assume you are committing your codebase to some form of version control on a regular basis.

The 3 layers can be summarised as:

1. Sanity Checks
2. Formal Checks
3. Security Checks

Sanity and Syntax Checks

In Stage 1 we perform basically a sanity check of the code. Are there any errors, missing semi-colon's or just plain stupid things being committed to our repository and code base. This is essentially a case of running php -l against all our files being checked in or changed to make sure we catch these before they are committed and let you fix them before they are picked up by the wider team.

Formal Checks

This stage involves a more global analysis of the source code files, checking for thing such as:

• Too many or too few arguments in a function/method call
• Undeclared global or local variables
• Use of return value of a function that actually returns nothing
• Functions that have a required argument after an optional one
• Unknown functions, methods, or base classes
• Constants declared twice

This can be accomplished by using tools such as PHPCodeSniffer. This allows us to ensure the above are picked up, and also that our code is in compliance with our agreed coding standard. Any issues, the commit is bounced back with the opportunity to resolve before being integrated into the repository.

Security Checks

The final layer of analysis, the security checks can be more thorough and use tools to scan our code for OWASP vulnerabilities, or as Etsy do - scan the repository with Antivirus and assess for dirty URLs.

Etsy claim they use ClamAV to check for any files or bad code which might make it's way into the repo, such as MSWord or PDF files that are suspicious.  ClamAV also scans URL's and checks these against Google's Safe Browsing List to pick up on suspected Phishing or malware sites.

It is also possible to check here to ensure things like passwords aren't committed to repositories or specific naughty functions or processes are used.  This can then trigger alerts for code reviews or ping back to the developer advising to fix ASAP.

PHP Traits

PHP 5.4 introduced the concept of traits. Until Traits PHP used a classical inheritance model in which one class could inherit only one class. In simple terms; before PHP 5.4 PHP used the single inheritance model which made it difficult to reuse the code.

Traits allow developers to reuse sets of methods freely in several independent classes living in different class hierarchies.

Traits are a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies. The semantics of the combination of Traits and classes is defined in a way which reduces complexity, and avoids the typical problems associated with multiple inheritance and Mixins.

A Trait is similar to a class, but only intended to group functionality in a fine-grained and consistent way. It is not possible to instantiate a Trait on its own. It is an addition to traditional inheritance and enables horizontal composition of behavior; that is, the application of class members without requiring inheritance.


Check out PHP.net for more info.

Keeping Account Management REAL

Account Management should be methodical. A process to work through to ensure nothing is missed.  The best way to do this is to remember 4 key stages.

The four key stages in account management are:

Recognise – The needs of the business, the customers' requirements and the role of the account manager
Evaluate – Our current customer base, prospect list, category and planning process
Act – On our plans, the sales process and required resources
Learn – From what we've done, sharpen the axe and move forward

How to Lose Your Clients

If you are wondering how account management could cause you to lose a client, please pay close attention. In my experience, account management is almost as important as results. Clients typically terminate accounts when they are confused or just plain frustrated with you. What are the common account management mistakes you should avoid? What are the best tips for success?

Account Management Mistakes You Should Avoid

1. Not writing a fresh email

One of the biggest mistakes I see people making is sending an email to their client with all of their internal correspondences included.

In other words, they went back and forth a few times with colleagues, and instead of writing a fresh new email, they just replied to the client from the last email they received from their colleagues.

This allows the client to see what you are saying back and forth to one another. Depending on what was said, you could really end up with your foot in your mouth.

2. Not being prepared

It's so easy to just copy and paste what someone else said to answer a client's question. The problem is, most of the time we don't really read what they wrote or get involved in the conversation.

Next thing you know, the client is calling you to talk to you and you have no idea what is going on. They might have follow up questions with regards to the multivariate test you are running.

Do you even know what they are testing or what the timeline is? You can really make a fool of yourself, and the company, if you aren't careful here.

3. Not clearly defining roles

As their account manager, the client expects to work with you and only you. It is almost pointless for you to act as account manager if you are putting them in contact with your SEO, your PPC person, your usability expert, and your analytics analyst. Now the client has to try and keep five people straight.

This will really stress the client out, and things won't get done. If there is one person they work through, they'll be more responsive and they'll be less stressed.

4. Not staying in contact

As the account manager, the client is relying on you, and only you, to stay in contact with them. You should be prepared to keep them up to date with progress reports.

Some projects won't require as much input from the client, but by providing them with regular updates they'll know that you are working hard for them.

How to Succeed as an Account Manager

The best tip? Make sure you don't make the mistakes listed above. Clients are looking for three things from you:

1. Results
2. Communication (with them)
3. Internal communication

If you can provide them with insurance on those three things, you'll be off to a great start. My only other tip would be to never lie to a client. You'll only dig yourself in a deep hole and put yourself, your colleagues, and your company at risk. While you may not like the mistake you made, you should always fess up.

There are many ways to recover from a mistake. Lying isn't one of them.

Stop saying 'Just'

Dear Reader,

Client:

• "I just need a blog."
• "It's just a website."
• "I just need a shopping cart."

In our industry “just” is a red flag, especially when it is coming from a non-technical person like a client or manager.

When you hear “I just…” in a discovery meeting, immediately stop and dive deeper. Unpack their entire idea until you are clear what they are asking for and you can described it back to them. Ask for clarification. Keep digging until you have explored exactly what they are “just” asking for.

Software development is a process of details. “Just” helps someone gloss over details and only look at the big picture. Like the iceberg that sunk the Titanic, most of the details of any software project is beneath the surface.

The next time you are tempted to say “I just need…”, just stop.

Why Estimates never work

Somewhere, right now, a project manager is compiling estimates on a software project and coming up with a completion date based on “velocity” and “scope”. When they’re done, they’ll take their completed work and show it to their boss, who will look it over, and set a “hard date” for delivering the project. There will be a team meeting, the developers will be gathered, the plan will be presented to great fanfare, and everyone will go off to work, expecting that they’ll actually meet the hard deadline in three months.

Three months will go by. The deadline will come and go. And in most cases, the deadline will be sorely missed.

You can probably guess what happens next. Executives will be furious. Project managers will blame the “lazy” developers. Developers will blame the over-zealous estimates of the project managers. There may even be a death march. At the end of it all, much if not most of the developer team will quit, the executives will vow “never again”, and the resulting project will be terrible, filled with bugs, and full of technical debt.

How do I know all this? Because I’ve seen it happen. Over and over again.

The truth is that estimates are a terrible way to determine when a project will be completed. There are four reasons why estimates fail.

Estimates are based on a best-case scenario.

When a project manager asks a developer for an estimate, they’re asking them to guess at how long something will take. The developer will use their judgement, experience, and familiarity with the project to make an estimate. But in almost all cases, these estimates are “best case scenarios”. The project manager then takes those estimates, adds them all together, and determines how long a project will take.

But what happens when the worst case comes true? I’ve worked with project managers that assume developers can do 40 hours a week of work. A sick day, a vacation, a power outage at the office or a snow storm can wreak havoc with their schedule.

Other times the developer only estimates the time needed to write the code – not to think about it. I may take 40 minutes writing a feature but spend 4 hours thinking about how it’s going to work and what it’s going to look like. If I estimate only 2/3rds of an hour, my estimate is off by 700%. Thinking time matters too.

Finally, most people are optimists. They estimate based on optimism about how long something will take. If we take that estimate as gospel, we run the risk of making a terrible mistake in our planning.

The scope estimated isn’t the scope built.

If I give you an estimate on a particular feature or task, my estimate is only good for that particular feature or task. Any changes will change the estimate. This logical, reasonable concept makes sense to most people on its face. And yet, so often it’s forgotten when we get into the nitty gritty of software work.

If a developer estimates two days for a particular task and the project manager then adds a bunch of new stuff, nobody can hold the developer to the “original estimate”. Adding stuff on will make the job take longer. Period.

“Scope creep” happens all the time. It’s common, so common that I’ve never worked on a project that didn’t have it. Yet so often the developer’s original estimate for a far smaller body of work is still used to plan the project. Is it any wonder that the final date is wrong?

Features don’t exist in a vacuum.

Features don’t exist by themselves. You don’t write a feature and have it never interact with other features. But so many estimates forget this fact. A developer will forget that a feature affecting user accounts affects every part of the application and only quote the time needed to write the new code. They forget to fix the other code that is now broken becuase of the changes.

The more massive the feature, the more impact it has on the entire system. And if an application is already built, the work is even harder. Foundational application elements are like the joists or the foundation in your house – replacing, fixing or changing the structure in a way that requires modifying these components will inevitably result in more work in unexpected areas than you otherwise anticipated.

Application development is more art than science.

To cook a steak that is one inch thick will take between 10 and 12 minutes. I know this, because I have copious amounts of experience with cooking steaks. There’s a scientific certainty that if you apply the right amount of heat for the right amount of time that you’ll get consistent results. There are many parts of cooking that are pure artistry, but there are many more that are simply chemistry.

Not so in programming. In the programming world, it’s nearly all artistry. Computer Science may be a STEM discipline in the schools, but software development is not a scientific or engineering pursuit at all.

How do we know this? Ask 100 developers to implement a function and you’ll get 100 different, unique approaches. And by “unique” I mean “completely different and novel from one another.” When it comes to many other professions, there just aren’t that many ways to do things. This is a uniqueness in the development world that’s special, but often ignored.

If you asked a famous artist, “when will that painting be done?”, you’d be told, “when it’s ready.” If you insisted on an estimate, you’d walk away with paint all over your face. And if you got an estimate and then demanded to know why the project is late, you’d be lucky to leave at all. Art doesn’t follow a schedule. Cooking a steak follows a schedule. But art does not.

But wait! What about agile/scrum/<insert development methodology here>?

There are a number of development methodologies that purport to fix the problem in a variety of ways. But they really don’t end up fixing the problem, they mask the problem by reducing the calendar time eaten by bad estimates.

Imagine that I estimate something will take 2 days. It takes twice as long, so it takes four days. If my sprint is 2 weeks long, I’ve only lost 2 days out of it. If I am consistently estimating at 1/2 the time it actually takes, I’m still delivering work on a fairly regular basis, but I’m still not estimating well.

Development methodologies were designed to reduce risk, but they don’t actually help deliver software faster. In fact, many of them come with additional overhead in providing frequent estimates, breaking up the day with stand-ups (I hate stand-ups), endless meetings and constant pressure to be right about the estimate (leading to other bad things like overtime and burn out).

So, what do we do if estimation sucks?

The answer is don’t estimate in the first place. Period. Just don’t do it.

Estimates suck. They’re rarely if ever accurate. Creating them is busy work better spent writing software instead.

So, if you don’t have estimates, how do you ship software? The answer lies in building an application that always remains stable and production-ready as new features are added, combined with the creation and implementation of small features.

The concept here shouldn’t be hard to grasp. Look at GitHub: they deploy several times a day, pushing out new features all the time. They have a solid continuous deployment process, a solid rollback process, and developers create features and ship them in a short time. Certain features are designed to be feature-flagged as off (so they don’t show up if they aren’t ready), or A/B tested.

Of course, if your app is just starting out, this can be really hard. That’s why the concept of the MVP (minimum viable product) is so important. I don’t like the MVP from a “product validation” standpoint, but I love it from a “let’s ship something quickly and iterate” standpoint.

If you’re shipping software constantly, you don’t need estimates. If a feature is taking a long time you know it, and you can work to address it by breaking it up or determining how you can declare victory sooner. Plus, your work gets shipped faster, bugs are fixed sooner, and developers are better able to move the project forward.



Estimates suck. But you don’t have to fall into the estimate trap. Instead, start shipping, start delivering, and stop driving yourself crazy with estimates that won’t be right anyway.



http://amzn.to/1JzNKyj
Steve McConnell is recognized as one of the premier authors and voices in the development community. He is Chief Software Engineer of Construx Software and was the lead developer of Construx Estimate and of SPC Estimate Professional, winner of Software Development magazine's Productivity Award. He is the author of several books, including Code Complete and Rapid Development, both honored with Software Development magazine's Jolt Award.
Check out his book

Social commerce trends in 2015

5 general trends should be paid attention to in 2015.

The world will be a Mobile-First World

In the big smartphone times, more and more people are put more time on mobile. In the U.S., carriers' shelf-space for devices with 4.7-inch or larger screen displays increased from 4 percent to about a third in 2014 alone, matching a sales growth - larger-screen phones now account for more than one-quarter of all sales, according to NPD Group. Facebook's recent earnings report showed that while overall daily active users grew 8 percent in 2014, mobile daily active users grew 15 percent and mobile-only daily active users grew 34 percent.

A Pay-to-Play Social World is coming

Forrester recently reported that brand interaction on organic Facebook posts is now squeezed to 0.073 percent. Social advertising spend continues to rise, though as a whole it still doesn't match time spent overall on social. Only on Facebook has spending outstripped time spent - 6 percent of U.S. adults' digital media time is spent on Facebook, but 10 percent of U.S. digital ad spending is now assigned to Facebook. But that's because for most brands, Facebook means social. And Facebook's ad products continue to improve in sophistication. As other platforms get their ad products launched, spending there will increase, too. Again, where Facebook leads, others will follow.

Social Content Continues is still rapidly developing

It's not like using content to market came out of nowhere. It's always been there. But the topic of content marketing seemed to attract an inordinate amount of attention in 2014, not only with regard to efficacy, but also about how hard it is to produce quality content in quantity. Marketers have been challenged to produce content for more channels, and have been challenged to make that content meaningful and informative. Content will continue to be a central directive for brand marketers on social.

The Development Multi Video Platform Interacting is boosted

Posting advertisements on YouTube is not sufficient to make a success now. There is increasing interaction with video in places outside YouTube, particularly with short form video on Twitter's Vine channel, as well as even shorter form GIFs on Tumblr. Surprisingly, Facebook announced that they had more video views than YouTube of this year, with many people scoffing that it was because of auto-play, not because of a video watching revolution.

The Social Diversity Will Continue

Facebook is still the biggest, most dominant social network and the "lowest common denominator" of social marketing. However, social audiences will continue splintering. This social diversity represents a serious challenge for brand marketers - particularly for brands seeking the youth market - who are looking to find the right voice for their audiences in the right location. In 2015 the social imperative will remain to hit the right voice on the right social platform, which may not be Facebook at all.

Technical Debt

In the debate between developers and their employers, fixing technical debt is often seen as a cost centre, a time suck that takes away from feature work. After all, when there are features to ship and clients to satisfy, taking the team off such projects so that they can rewrite what already works is seen as silly, costly or foolish.

But smart employers recognise that technical debt is more than an annoyance or a cost centre. They recognise that technical debt has a chance of costing them good developers.

Developers hate technical debt. It's annoying, it's frustrating, and the struggle to find time to fix it is constant. Developers hate technical debt because it makes their jobs harder. It makes solving other problems harder. Technical debt, from a developer perspective, really sucks.

The problem here is that frustrated developers are unhappy developers. Unhappy developers have a tendency to quit. And given the fact that hiring developers is tough under the best of circumstances, this means that technical debt is actually costing your team skilled developers. And this costs money.

The loss of a single developer can cost a company £20,000 - £35,000, depending on the costs of replacing that developer. And the skills and knowledge they take with them can never really be replaced.

When considering whether or not to fix technical debt, it's worthwhile to consider the frustration level of your development team, and the cost of replacing just one of those developers if they should choose to quit. Is the cost of fixing the debt less than the cost of replacing a developer? If so, the tech debt should be paid down, until the developers are happier and satisfied.

Refactoring: rename class/method/variable

This refactoring is such a simple idea and you'll find yourself continually doing this as you work and build extra functionality into your web applications. There is also continual need to do this whole debugging and/or refactoring existing code.

Take for example the below class:

class person {

  public $w;

  function clchrlypr() {

    // calculate hourly pay rate of employee

    ...

    return $var;

  }

}

Now let's look at the below example:

class employee {

  private $wage;

  public function calculateHourlyPayRate() {

    // do some magic

  }

}

Which was easier to read and follow?  I would hope the second snippet was clearer, however the first is an all to common sight in some projects and seeing this code makes you really have to think hard, and quite frankly wastes time  if we had written the second block of code in. The first place things would have been so much easier for our colleague.

Legacy Code Change Algorithm

When working with legacy code, it is very easy to get carried away and make a big bang refactoring (actually, 'code cleanup and pray' is a better term since we do not have any tests). In this case, we can try to eliminate the static cling by making the static method non static, and extracting the non-static method into an interface. Make the clients (all the call sites) use the interface. This would mean that we deal with potentially a few changes to the client code to a few hundreds in some worst case scenarios, all at one time. The result could be 'Object Reference not set to an instance of an object'. We want to be able to make this change in a phased manner in small manageable increments.

Approach

1. Pick one call site.
2. Change in one call site.
3. Bring it under the safety net of unit tests.
4. Make sure the change works.
5. Meanwhile, the other call sites continue using the original unchanged code and continue to work fine.
6. Go back to step 1 till all the call sites are refactored, and remove the static method finally.

Let us see how these steps map to one of the techniques in eliminating static cling, 'Introduce instance delegator - p369, Working Effectively with Legacy Code'.

Introduce Instance Delegator

1. If the class which contains the static method is static, make it non static.
2. Introduce an instance method with the same signature which delegates to the static method.
3. Use ExtractInterface and extract the instance method created.
4. At the call site for the static method, change to use the instance method (called through the extracted interface) instead of the static method.
5. The instance can be provided at the call site
• as a parameter
• via setter injection
• via constructor injection

Most importantly, the other call sites continue using the static method till we get them under the safety net of unit tests.

Increase conversion rates - the easy way

When your business is online, conversion rates are hot on the list of KPI's to watch month on  month, year on year.  But what are conversion rates, and how do we increase them?

In terms of an ecommerce site, be this physical goods or e-goods, for example ebooks or services, the conversion rate on your site is essentially the percentage of your visitors who you manage to convert into paying customers.  People who visit your site and decide, you know what, I've just gotta have this!  And if you can make them impulse buy - even better.

Here are some quick tips to increase your conversion rates:

1.  Explain the benefits - 3 C's

• Clear
• Concise
• Consistent

Summarise the benefits and sell your product or services as clearly and concisely as possible.  Let your customers know what they are paying their hard earned cash for, and let them know quick.  Why waffle on for pages and pages?  When you meet someone in person, they make their mind up about you in the first 30 seconds of the conversation.  Giving someone the key benefits upfront can boost your conversion rates by as much as 150%.  If you do feel the need for a more detailed description, be consistent with the key benefits you first mention so no one misses out.

2. Collect Customer Feedback

Customer feedback is key to improving your site and giving customers what they want.  Services that prompt for feedback on Products and Services such as Feefo and Trustpilot are great, but what about general site experience?  Services such as Qualaroo and WuFoo are great for general usability questionnaires.  Ask questions such as

• What information is missing from this page?
• What can we do to improve our site?
• Would your recommend our site to a friend?

3. Make your site easy to use

Another great tool for gathering feedback is iPerceptions.  iPerceptions offer a free short survey to your web customers.

• How would you rate your site experience?
• What describes the primary purpose of visit?
• Were you able to complete the purpose of your visit today?

Using feedback you can prioritise content on your site. You may receive feedback from customers looking for particular brands or wanting to compare 2 or more products. This information may be available on your site, but nested deep in the site, or require many clicks. Why not create a landing page with the most popular selling brands or products on the site, or comparing the 3 most popular electronic gadgets that visitors want.

4. Contact visitors that abandon

Email marketing shouldn't be underestimated in upping conversion rates, visitors who abandon during checkout, almost bought from you. Studies suggest you have a window of 90-120mins to finalise the deal or they'll go elsewhere and forget about you. A personalised email to visitors, reminding them of their shopping cart, complete with easy to follow links so they can continue where they left off should help. Let them know it's the last one in stock, or if they buy now they qualify for reduced delivery or a free pen! Everyone likes a freebie.

In review.

Increasing the conversion rate on your ecommerce site needn't be all scientific with graphs and numbers. Listening to your customers and providing a personal touch will let them know you care.

Refactoring: Push down method

Previously we mentioned the pull up method we can use during refactoring our code. The push down method is the exact opposite. Let's start with some code:

abstract class animal {

  function bark(){
    // bark here
  }

}

class dog extends animal{}

class cat extends animal{}

$dog = new dog();
$dog->bark();

Maybe one day our cat had a bark about it, or maybe we've coded an if statement to do something different like return false if it's a cat. 

abstract class animal {}
class dog extends animal {
  function bark(){
    // bark here
  }
}
class cat extends animal {}

$dog = new dog();
$dog->bark();

PHP Refactoring: Pull Up Method

As projects grow organically it is important to continually be refactoring your code base.  One simple refactoring technique which is often overlooked is called "pull up method". This is exactly what it says on the tin - pulling a method up in the hierarchy of its chain so it can easily be reused. Let's take an example:

class vehicle { }

class car extends vehicle {

  function accelerate() {

    // code here

  }

}

class motorbike extends vehicle {

  function accelerate () {

    // code here

  }

}

We can clearly see the duplication above of the 2 accelerate methods. What if e pull these up into the vehicle parent class?  Lets see how:

class vehicle{

  function accelerate (){

    // code here 

  }

class car extends vehicle {}

class motorbike extends vehicle {}

Refactoring: Replacing inheritance with delegation

All too often inheritance is used in the wrong scenarios. Inheritance should really be used when it makes logical sense, however we often see it used for convenience. Take this example:

class sanitation {

  public function washHands(){ 

    return "cleaned";

  }
}

class child extends sanitation { }

$child = new child();

$child->washHands();

In this instance child is not a "sanitation" So inheritance doesn't actually make sense here. We can refactor this to delegate handwashing by passing an instance of sanitation into the child constructor and calling it that way.   Now let's look at this example refactored child class:

class child {

  public function __construct($sanitation){

    $this->sanitation = $sanitation;

  }

  public function washHands(){

    $this->sanitation->washHands();

  }

}

$child = new child(new sanitation);

$child->washHands();