Category Archives: Web Design

From WordPress.org to WordPress.com

I used to consider taking the leap into WordPress.org. This article effectively sums up why I didn’t. Sometimes the simplest solution is best.

Live to Write - Write to Live

wordpress-logo-stacked-rgbI recently moved my personal blog from a WordPress.org site to a WordPress.com site and thought I’d share the experience in case anyone else was considering a similar move.

WordPress is a blogging software that comes in two flavors. WordPress.org offers free software that you download and install on a server (most people rent server space from a hosting company). WordPress.com offers a hosted version of the software, a basic wordpress.com site is also free, but there are premium options that provide personalization (like using your own domain name) and customization (number of columns, header size, colors etc). A wordpress.org site is a good idea for someone who wants complete control of every aspect of their website or blog. A wordpress.com provides allows more of a point and click interface. The trade off is that you have limited options on wordpress.com, still for most end users wordpress.com will meet their needs.

View original post 745 more words

Leave a comment

Filed under Web Design

Improving the Add to Cart Button

Last October I posted an infographic detailing the importance of a webstore’s add to cart button. David Max from Perception System recently expanding on the infographic with additional formatting details and statistics for 2014 . Sometimes the smallest details lead to the biggest sales.

Check out the infographic below (Source: Perception System Blog):

Add-To-Cart ButtonCourtesy of Perception System

Leave a comment

Filed under Web Design

Add to Cart Infographic

Overlooking the simplest details often leads to the biggest problems in website design. Take for instance, the “Add to Cart” button on a webstore. This simple yet essential button contains a myriad of design possibilities that no two webstores approach in the same manner. Size, color, even the words that appear on the button hold influence over visitors. Just like other visual decisions, some looks are more pleasing and user-friendly than others.

So how do most webstores approach the look of their most important button? E-Commerce website builder Volusion recently offered detailed research data highlighting the subtle intricacies of the Add to Cart button, which you can see through the infographic below:

Infographic 10 17 2013222 Infographic: Constructing a Higher Converting Add to Cart Button

Leave a comment

Filed under Web Design

Templates – The Fickle Shortcut

In the world of information design, templates exist for everything under the sun. Blogs, resumes, websites, everything under the sun has a shortcut that will, in theory, do the design work for you. All you have to do is plug in your information, and viola, all done. Templates are vital shortcuts.

Templates are also dangerous. Very very dangerous.

We use templates because we want to increase efficiency and maintain consistency. Fantastic! I agree, templates are great for that. The danger of templates comes in the form of preexisting templates. I’ll clarify with this bold statement: the best template, nay, the only template you should ever use, is the one you design yourself. For all the thousands of preexisting templates for whatever project you have, they will ultimately hamper your work for two reasons:

1) Preexisting Templates are Unoriginal

If you use the first template on the list of templates, your work will look the same as everyone else who chose the same template. You don’t have to create a resume or website so radical the likes of which no ones ever seen, but you will be far from unique. Originality stands out in today’s society.

2) Unsatisfactory Design Flaw

Everyone differs on the idea of a perfect template. Mainly because everyone’s individual needs differ. Your individual design ideas do not have the 100% eHarmony compatibility match somewhere on the internet. Although several templates may come close, one or more lingering small details will always haunt you during the entirety of your project’s lifespan. Your project will not be perfect if you are not satisfied.

Fortunately, an easy solution exists.

Note in my bold statement that I said “design” and not “create.” Templates, much like programming and website coding, don’t need to be made from scratch. The simplest way to create a template is to borrow ideas from pre-existing templates. By taking individual features you enjoy from multiple templates, you create a design that not only works 100% for your needs, but also looks a bit less cookie cutter. Just because you are selecting a template does not mean you cannot change it. The template police will not hunt you down.*

Being willing to get technical helps a lot. A willingness to edit a few simple fields (color, font, size) goes a long way towards change you enjoy. Resumes are easily tweaked in word/OpenOffice, for the blog/web page designer, a little CSS editing is all you need. A simple Google search points the way.

Templates are important, and taking some time to make one you are happy with will pay off in the long run. A happy template equals happy projects. 🙂

*Though you should not use copyrighted/protected work without permission, of course.

Leave a comment

Filed under Information Design, Technical Writing, Web Design

Usability Testing – Avoid Front Page Overload

I learned many web design tricks in graduate school. Many of them seem rather obvious in hindsight, like putting the most important information at the top of the web page. After all, the more scrolling viewers go through, the less likely they will see all of the information on the page.

Web Design Rule #1: Web page visitors are very impatient. Don’t make them think.

The obvious solution to preventing scrolling is to eliminate scrolling entirely. Well, some scrolling is inevitable (I certainly cannot write blog posts that short!) but the key idea remains the same: put your key information front and center. Yet this is a double edged sword. While users should see the most valuable information first, cramming too much information in that limited initial space is very dangerous.

Since I happen to work in medical equipment sales, I’ll use two medical equipment manufactures to demonstrate this point. Take a look at Sklar Surgical Instruments. See anything interesting? That’s the problem, there’s too much interesting to see. This little three column layout is not only crammed with so much information, the information is badly prioritized. While the “what’s new” header in the left has some interesting new information, technically the middle and right columns also present new information.

In the end, the average visitor will have difficulty focusing on one section of the site. I admit the layout holds some merit for frequent visitors who want to quickly see what is new and exciting with Sklar. Yet this overload of “new” is quite unfair to first-time visitors interested in what products Sklar sells. That little yellow products link is not easy to spot.

Quick Aside: I’m not a big fan of three column layouts, though I admit it holds value for e-commerce stores. The company I work for, Medical Device Depot, happens to use one rather effectively. Then again I might be biased. 🙂

On the opposite end of the spectrum, Clinton Industries utilizes a very effective front page. New information cycles through the middle, while easy navigation to their products other details are easy to spot. You simply cannot get lost when looking for products when it leaves a trail of breadcrumbs for you to retrace your steps.

One more fun fact: serious usability testing utilizes eye tracking. Technology actually exists which allows testers to track where a person first focuses their eyes on a web page.

This is why a high Google pagerank is important.

Leave a comment

Filed under Technical Writing, Web Design

Defining the “How” in “How can I help you?”

I discovered an interesting post from one of the technical writing blogs I follow during my Sunday morning blog catch-up. Technical communicator  Shweta Hardikar recently wrote a blog post pondering “embedded help” or, helping users solve problems without calling it help.

Although programs are constantly evolving and taking advantage of multimodal interaction, one important question remains: “how do I use this program?” Users want immediate results, they don’t like to read through 50-page user manuals and guides. Looking up answers takes the user outside of the program experience, ruining the immersion. And honestly, how many people actually bother to read or even keep the user manuals that come with programs? Although companies are getting smarter (and eco-friendly) with user manuals by storing them in the program or on a  CD, the fundamental problem of having to go outside the program remains.

That is where embedded help comes in. Embedded help integrates the help directly into the application instead of through an outside source. This often takes the form of text that appears directly on the application, or via an easily accessed button. Not sure what a particular option does? Instead of making the user look up that bulky/poorly accessible user manual, offer a button labeled “help” or “?” if you don’t like the idea of using the word help.

Not every section of a program requires embedded help. Indeed, the golden rule of maintaining simplicity should remain in effect. The key behind using embedded help lies in anticipating where the user might have a question. A handy accessibility rule for programs and vital for web navigation, especially if you are running a business.

When I create product pages for Medical Device Depot my supervisor constantly stresses the importance of clarity. I always have to anticipate where the customer might experience trouble when ordering a product, and provide necessary clarification through embedded help. If I don’t include this explanation then the best case scenario is that the customer calls and asks, an unlikely possibility. At worst, the customer won’t buy the product, or accidentally order an incorrect product. Suffice to say, none of these scenarios are particularly desirable.

Here’s one example: when purchasing an emergency drug kit the customer must input additional information. I use popup help buttons to help clarify necessary details just in case the customer is uncertain. This not only saves time and trouble, it may prevent the loss of a sale due to lack of understanding.

Examples of how embedded help directly assists a customer. (Click image to see it in full size)

Leave a comment

Filed under Technical Writing, Web Design

WYSIWYG Web Design

wysiwyg / Adjective: Denoting the representation of text on screen in a form exactly corresponding to its appearance on a printout.

Although I’ve been experimenting with HTML & CSS since High School, it was not until my later undergraduate years that I really started to dive into the building blocks of website creation. After all, as an English/Communications major I needed to supplement my abstract writing skills with something practical that I could put on a resume. Taking the time to learn website coding payed off well for me; it helped land me a job as a webmaster for Medical Device Depot, a medical equipment store where I alternate between updating the company website and tinkering with Mac 1200 EKG Machines. Did I mention I also assist with their advertising? 🙂

Anyway, when I started working on their website and fixing product pages, I grew very familiar with wysiwyg web building. Wysiwyg is an awkwardly short way of saying “what you see is what you get.” In other words, you use a robust HTML editor to sort of paint a picture of what you want on your webpage. When you’re done, the HTML editor generates a lot of (horribly written) code and you end up with a nice literal representation of what you designed. Incidentally a lot of blogging sites, including WordPress, utilizes a wysiwyg-style editor for users to design blog posts. If you’ve ever started (and subsequently abandoned after one week) a blog, you may have used a wysiwyg editor without realizing it.

Note that I said the code was horribly written. Unfortunately even the most robust HTML editor cannot keep up with the constantly changing human brain, and the right combination of erasing and re-inserting data can result in an awkward mess that can be difficult to fix in the limited editor program. Wysiwyg editor’s do not always like the idea of the undo button. They may get violent with you if you try to undo a mistake, resulting in an even bigger mess than what you began with.

Take a chart or table for example – you want to create a very even 4 column x 3 row table to display data, say different dimensions and sizes on a piece of furniture. You might tell the wysiwyg editor to create this table, and viola the table appears. However, if you make one simple misstep or need to change the table dimensions halfway through entering data, then your local wysiwyg editor may decide to turn your table into a piece of abstract art that you cannot fix unless you obliterate the entire table and try again. This is why some web designers shun wysiwyg and stick to doing all of their coding by hand with good ol’ notepad (or notepad++).

I respect the viewpoint of those web design purists, and I agree that wysiwyg has it’s faults. Yet those user-error faults won’t stop me from using it. This is partly because I’ve worked with my local wysiwyg editor for almost two and a half years and I know every pitfall to avoid. But mainly it is due to the fact that, because I am pretty good at coding HTML by hand, I can dive into the HTML code and fine-tune those silly coding errors as they appear. If that table example I described above occurs to me (and it occurs often), I can just look at the code, add or remove a <td> or <tr> tag, delete that moronic fixed-width cell padding the editor likes to toss in and viola – awesome looking table. Well, nowadays I just insert my homemade table code when I need a table, but that’s the general idea.

Sure the wysiwyg editor may create some unnecessary header tags or throw in a silly amount of <br> (blank line) tags that may cause a purist coder to faint, but that’s ok. I don’t need super awesome neat looking code. Website visitors don’t see that stuff. No, I need code that works. And if you take the time to develop your skills with HTML produced via wysiwyg and handmade code you’ll get code that works with minimum frustration.

In related news, this blog post is a fancy way of telling the world that I’ve started experimenting with Adobe Dreamweaver. I look forward to using Dreamweaver, which incidentally allows for an amazing blend of wysiwyg and hand-coding, to make websites in the future.

It also helps that I can put it on my resume.

Leave a comment

Filed under Web Design