Hints and tips for the styling and layout of your text content

With the vast amount of text being posted online and via social media these days I thought it would be beneficial to share this very brief tutorial for how (and how not) to style all that great stuff you’re sharing online. These tips apply anywhere you might post text—whether it be in one of our content management systems, WordPress, Facebook, Blogger or even old fashioned MS Word, these simple design principles will help insure your message gets the credibility that it deserves.

1. Learn to use <shift><enter> (Windows) or <shift><return> (Mac) to insert line breaks with no vertical spacing. This practice helps insure you maintain close proximity of related content and greatly aides in readability.
   People often just hit <enter> between lines of text which adds awkward and undesirable vertical space.

   Example using <shift><enter>	Example using <enter> only
   My mailing address: RisingLine 111 S. Broadway St STE 101 Boise, ID 83702	My mailing address: RisingLine 111 S. Broadway St STE 101 Boise, ID 83702

2. Don’t change typefaces (fonts). In fact you cannot change fonts/typefaces in our CMS text editor but many other text editors allow you to do so. The typefaces for your Website are specified in a single Style Sheet that was developed specifically for your site and insures consistency across all pages of your Website. Consistency in the presentation of your content is a cornerstone of good design.
3. Don’t change typeface colors. For a professional consistent presentation of your content the colors are controlled through the Style Sheet. Emphasis colors (such as the color of your hyperlinks) have been selected by your professional designer specifically to harmonize with the color palette of your Website.
4. Use the "font size" selector very very sparingly. Avoid at all costs using the "font size" selector to increase text size. This practice will invariably create inconsistent and amateur rendering of your content which cannot be controlled from the central style sheet. The only reason we retain the font size selector is for those rare occasions where a line of text needs to be reduced in size.
5. Avoid using "U" Underline to emphasize inline text. People will think the underlined text is a hyperlink. Rather use the "B" (Bold) or "I" (Italic) icons to emphasize a word or sentence.
   

   For professional and consistent presentation of your content…
   Do	Do Not
   News and Announcements We are extremely pleased to announce the opening of our second storefront in the beautiful city of San Jose, California. Please join us for our grand opening on April 3rd.	News and Announcements We are extremely pleased to announce the opening of our second storefront in the beautiful city of San Jose, California. Please join us for our grand opening on April 3rd.

6. Use the "Format" selector to change heading text size and create a logical hierarchy of content. Using this method allows consistent presentation for your site which is controlled by the Style Sheet.

Choosing the best domain name for your Website is a daunting task. Actually thinking of a great domain name is not hard, finding a great name, or even a good-enough name, that’s taken is the hard part. We’ve accumulated a number of guidelines to use when considering a new domain name which we’ll be sharing the next few blog posts; here’s the first:

.Com instead of .Net

This first guideline is the most absolute of them all—never use a .net domain as your primary business domain. The reason a company considers a .net domain is almost always because someone else already is using the .com version of the domain. Usability studies have proven that when someone hears or reads a domain name, by the time they type it in their Web browser they’re most likely going to type .com anyway. If you do choose to go with a .net, be aware that a huge percentage of the branding expense and effort you do for your Website will benefit the .com version, not yours.

Sometimes people see that their .com is not currently developed and assume that since there is no site on the .com the .net is a viable option. In these cases it’s even more important not to choose the .net. A domain squatter dreams about a company investing a ton of money into developing and marketing a Website on a .net for which the squatter owns the .com. It raises the value of the .com significantly and it’s very easy to squeeze the .net domain holder into paying an exorbitant price for the .com when the squatter puts up a porn site.

This means that even though there is the perfect domain name available (such as mycompanyname.net or myexactkeywords.net) you’ll be far better off to select a .com even if it’s not as desirable of phrase. Our upcoming posts will shed some light on how to do that.

What determines the success (or failure) of a Web development project?

While there are many important factors (both on the client and developer side) there are two all-powerful prime lynchpins that will make or break even the most qualified participants: Perspective and expectations. Some time ago I made a blog post on perspective, in this second of two posts I’ll discuss expectations.

Expectations

Success in almost any transaction or relationship is determined by establishing and meeting a set of shared expectations between parties. A $3 meal at a McDonalds can be just as successful as a $200 meal at a Smith & Wollensky Steakhouse. The same degree of success can be realized at both regardless of the vast difference between a dedicated waiter serving dry-aged prime beef and a mass produced sandwich handed to us in a crumpled paper bag. It’s all about us getting what we expect.

When a client and developer view a project from a shared perspective, setting expectations is the natural progress of collaboration. Without the collaborative systematic development of a set of shared exceptions we risk orchestrating an iPod dance party. Both parties may participate but they’ll each be in their own world and when the music stops they will have completely different perspectives from which to determine success.

Developing a shared perspective is the responsibility of the developer and starts with listening, interrogating really (in a nice way, without the light), to the client and extracting the core business goals of a project, the details of the client’s unique value proposition, the needs and profile of their customers and other such vital information.

Provocative and challenging questions should be presented to the client in this stage to help them gain an outside perspective and the developer needs to be willing to adjust their biases so that in the end there is an unambiguous meeting of the minds about the project goals. In addition to the primary goals, there are many technical parameters that need to be discussed and agreed upon including development environments, creative parameters, branding continuity, etc.

After goals and requirements have been collaboratively determined, the developer is responsible for drafting a formal systematic development process that articulates the specific developer tasks that will be provided to meet those goals, and establishes a work-flow time frame for project completion.

All of this is not that profound or new. It’s really just common sense. But from my observation, the temptation is often great to gloss over a formal development of a shared perspective and expectations. It’s usually in the context where the client and developer develop good initial rapport and feel confident that they’re “on the same page.” Feelings are great but Web development projects are too complex and expensive to rely on luck for success.