Design:Divide

Design | Innovation | New Media

Archive for June, 2008

Voicing Your Opinion To A Client

While working with a group of designers and programmers today, we had a little powwow about a new site design which led to some interesting conversation about managing clients and when it is appropriate to voice your opinion about staying with the design and strategy choices of a project to clients. This made me start thinking about how client relationships differ from shop to shop while reflecting back on shops that I’ve worked at.

One ad agency that I’ve worked at had a rather interesting approach that seemed to work for them when voicing their opinions and ideas about projects to clients… and honestly, I kind of applaud them. Their take on taking bad client suggestions/requests and turning them down stemmed from the phrase, “we were hired as an advertising agency because of our years of experience and sound, proven tactics.” In a nutshell, when a client whom thought they knew a thing or two about advertising decided to suggest a change to a project’s collateral whether it was a brochure, TV spot, or Website was based on irrelevant information, or purely personal preference, they were quick to point out that they were hired as their advertising and marketing agency, and that they advised strongly against such changes because of the goal of the project and the research method of attaining that goal. Surprisingly, that worked about 90% of the time. There was still 10% that said, “my way or else,” and they were just as fine to step aside in their argument and do as the client requested.

A common problem among many agencies across the world is when to say no to a client. My take on it, is very similar to that advertising agency I once worked for. I’ve been doing what I was hired to do for quite some time, and have experience, knowledge and sound, proven logic behind the decisions I make for my clients to help them meet their goal and overcome any hurdles between getting their products or services to their customers. However, there are times when dual input actually enhances a project and its effectiveness in meeting the goals and overcoming those obstacles. I have on several occasions suggested moving a project down one path, had a client respond with a request to move down another path, and after a meeting where both sides gave case-in-point examples, we were able to form a new path together with ideas from both sides coming together to form a plan that actually turned out to produce more results than either previous plan of achievement would have produced.

It is when we take all things into consideration and look at the marketing challenge with open eyes that we are able to take an idea, no matter how bad or good it may seem and look at it objectively and be able to see it for what it is and make rational, strategic decicions based on the objective and the plan of action to meet that objective. When you’re able to separate personal bias and “he’s paying, so he gets his way” thinking, you’re able to come to a well positioned strategy to meet the needs of the business.

Magento : Lets take this out back!

I have a client who recently switched his hosting provider to a more flexible one, and as we transferred to the new provider, we made a few improvements to his site’s back end and found a new product to meet his e-commerce needs as well… or so I thought.

Magento Opensource eCommerce

Enter Magento. So, at first glance, Magento looks like a sweet Web app. It has really cool features and tools that will help my client manage his online sales and order process, notify him when his stock is getting low, when someone has placed an order, and eventually integrate with QuickBooks so that there’s less data entry and more selling. Besides all that, it’s opensource, scalable, and is actually a pretty nice e-commerce solution. For the person who has to develop it (me) it’s a nightmare for now.

When I got this client I started to educate him on best web practices, why they matter, and what is going to improve his website. Eventually I was able to ween my client off of a GoDaddy website and GoDaddy shopping cart set up because it posed limitations, slow response times, and lack of features. But, what do you expect for a “cheap” solution set up by the client himself who isn’t a web developer, much less a designer? So, after a bit of research and keeping an open ear out in the development community, I suggested we try Magento as it looked to be the ideal solution and would allow customization and custom skinning. Little did I know that as soon as I switched over, what should have been a 6-8 hours for set up, product transfer, and skinning turned into a “To be continued…”.

The first thing that threw me off once I started to change the way Magento looked and worked was when I opened Magento’s root folder and got lost trying to find where the files were that I needed to make changes to which would update the design and content accordingly. Everything is done as a PHP include and it’s buried deep within folders, within folders, within folders which aren’t always logically labeled. Besides that there were may files with the same exact name in different folders, so that if you were in the wrong folder and didn’t know it, you might be changing the wrong file. Another issue I encountered had me 4 hours into a debugging with setting security on the site, with an initial attempt at searching on my host server for the security configuration file via Apple’s Terminal and then finally arrived at the problem. The problem turned out to be a corrupted file several folders deep into the site’s files that was corrupted on install. Once I figured that out, I was able to fix my problem in about 10 minutes including uploading the new file and also fixed another administrator side error that was being caused in the admin area.

Other beef I had with it, was that on default set up, it runs sluggish due to the amount of JavaScript that is uses which is placed in the header tag in the HTML. It also takes 5.44 seconds to load a blank page… blank in the sense that there are no products being loaded or displayed, just the design shell. I also fought and continue to fight with the coding to get a simple page to call functions correctly and pull data from my database to basically recreate one page’s content for another page. This ongoing battle is also part of the “To Be Continued…” part that is frustrating. Another learning curve I had to adjust to was based on the fact that their files are built as PHTML and if you’re not familiar with what that is, it’s PHP and HTML combined as a custom PHP extension which is definable in your server’s httpd.config file.

To add the icing to the cake, if you go to the Magento forums, there are many, many, many developer and implementation questions and a few administrator responses. There was a couple of questions that ranged in age of 2 weeks old to 2 or so months old which still had not been answered. Forums for developers are a great way to help out others and yourself overcome issues, bugs, difficulties and learn how to do new things. On the forums currently for Magento , everyone seems to be asking questions with very few answers. Seems like the community as a whole are having problems too. I work with a developer who also has been implementing Magento into a client’s site… and his basic response to Magento was very similar to mine.

Magento was definitely written by back-end developers as you can tell. I think in a version or two, Magento will probably be a pretty solid, front-end developer friendly product with easy skinning and a ton more standard, built-in modules. Until then, plan on long nights and ample frustration… Or maybe you could try all those different desktop stress balls and such that are out there.

How To Create A Custom E-blast Part 2

In this article I will cover some of the basic specs of building a custom e-blast for direct mail marketing and personal use. If you missed the first post, you can read How To Create A Custom E-blast here in my blog.

Custom E-Blast

Assuming you are already familiar with web design and know that web graphics are built at a resolution of 72 ppi and in RGB color mode, we’ll begin with the preferred size of an e-blast. Best practice of building an e-blast is at a size of 600 px wide and as long as your content needs it to be. If you stay around that size, or even a little bit smaller, you’ll find that your e-blast is compatible with many e-mail clients both desktop versions and web client based (ie. Yahoo!, MSN/Hotmail, Excite, Gmail, etc.) and you’ll even find that it works nicely with newer devices, such as Apple’s iPhone.

You’re probably asking yourself why you would want to design one so “small” when websites are built larger than that, and your monitor is capable of viewing larger resolutions. Well, the answer is simply so that you ensure that your intended recipient is able to see your e-blast as intended on what ever viewing platform they use. Let’s say for a moment that you know that your entire list contains only people with Yahoo! email addresses. Just because they may have a Yahoo! email address doesn’t mean that they necessarily check their email by logging into Yahoo! mail to read it. It could be automatically forwarded to another email address, it could be downloaded to their mail app such as Microsoft Outlook, or Microsoft Entourage, or Apple’s Mail, Apple’s iPhone, Blackberry, or any other device and email reader program that exists. So, being compatible with your audience’s preferred email reading ways is important for usability reasons and to help remove any barriers that may exists to get them to read your message.

Once you’ve gotten the size out of the way, your next question will probably be, what format should this be in and how should I code it. For e-blasts, you will find that you can and should be using JPG images, GIF images (animated or static) or both, along with good old HTML. Most mail readers are able to handle embedded and inline CSS for the styling of text, but not for positioning. You’re best off to use tables, which may contain DIVs, and CSS. The types of things that you can define in CSS that will work well in e-blasts include: both background and font color, widths, heights of tables, table cells and DIVs, borders, font attributes to include sizes, weights, font families (ie. Arial, Verdana, Georgia), text alignment, and padding.

Best practices for mixing images and browser text stems from knowing the limitations and possible outcomes of using them with different email readers. It is best to use both graphics and browser text for many reasons. Some email readers do not display images until you’ve granted them permission to download the graphics. If your e-blast was all graphics, the viewer might never see any text associated with the mail, not click on the download images button, or worse yet they, or their email reader might think that your e-blast is spam. Spammers for a long time, and continually use emails with all images so that they can still displaying words that usually trigger spam software to mark them as spam or delete them because spam software can’t determine if there is “text” represented in the image and it makes it harder for the spam software to catch it as spam. These days, spam software usually automatically marks messages with all images as spam because of this practice. Additionally, some e-blast sending programs allow you to input a text only version for people who either block images, or people with screen readers so that they can still receive the message.

Another best practice for mixing images and browser text is that if you have a background image/texture behind browser text in your e-blast, consider defining a background color too through CSS so that when your e-blast gets to a program such as Microsoft Outlook with versions that do not display background images, your recipient will still be able to read your message. As an example, if you didn’t plan ahead for this and let’s say that you put white text on a dark background image, and when the user reads it in their email reader which doesn’t display background images, they might not see it if the “page” background is white too. White text on a white background has no contrast and therefore can’t be easily read or seen.

Having a healthy mix of images and text is good not only to help avoid spam blockers, but also because it helps make your e-blast lighter in terms of size which will help with loading times. As with any website or e-blast, if it causes your user problems or takes too long to load, your user may become irritated and delete the email or navigate away from your site. So keep in mind that web optimization is a good solution.

The next best thing to do when creating a custom e-blast is to test, test, test it until it’s working correctly and displaying the way you want to on as many email readers as you can and that you have access to. If you don’t already have multiple email addresses, you should at least set one up under different email reader such as Yahoo!, Hotmail, GMail, set up desktop email reading programs such as Apple Mail, Microsoft Entourage, Microsoft Outlook, etc. to also retrieve these accounts and when you send out your test, be sure to include all of your test accounts in those. Only send out your final e-blast to your mailing list only after all testing has been completed and finished. Nothing will look worse than you sending out your e-blast numerous time to your recipient without a valid reason (ie. a significantly incorrect piece of information, such as an event day, time address, etc., price or otherwise important information). A good testing solution for you may be the one offered by Campaign Monitor which allows you to test many mail reading applications all at once.

When you’re ready to send it you have a few options. You can either have a custom e-blast generating program built for you by a company which can be as simple or complex as you wish, or you can use an online service such as Constant Contact or Campaign Monitor that I highly recommend or any other number of providers out there. Each of the online e-blast service providers out there charge for sending e-blasts on their own pricing structure. Find out which one is right for you and offers the features that you want.

To sum up creating a custom e-blast…

Build your e-blast at 600 px wide or less, use JPG images, GIF images (animated or static) or both, and use both images and properly formatted text. Use HTML which may include DIVs. Lastly don’t forget to do cross email reader platform testing to only yourself first before sending out your e-blast to your mailing list.

If you need further consultation, guidance, or even someone to build your own custom e-blast or e-blast sending web based software for your company, consider DesignCarter Interactive Agency to help you with those needs.