tdog.blog

Hi there! Welcome to our blog. Don't forget to sign up for our free RSS feed. We Triple Dog Dare Ya! And thanks for visiting!

Problem: Streetman Homes needed an updated look and an easy-to-manage web site.
Solution: We gave them a new fresh look and a powerful CMS.
URL: http://www.streetmanhomes.com

Streetman Homes is a builder of beautifully designed and crafted homes. They have nearly a dozen communities in Austin TX, each of which consist of homes with distinctive layouts and appointments. When our team went on an impromptu tour of various communities we were struck by the friendly staff, amazing locations, and truly open and innovative home layouts. Everything, down to the type of tile used in the master bathrooms, spoke of unerring quality and focus on the customer.

When we saw all that, the project manager and I both said, “Their current web site doesn’t do them justice!” So we set out to create a web presence that would give prospective customers a way to peak in through the window, so to speak, and view the beauty and craftmanship offered by the Streetman brand.

When we worked closely with Blake Houston (COO) and Tina Blanton, they told exactly where they needed their new web site to take them. They really needed a streamlined approach to keeping their online information up to date, and they needed an easy way to integrate with the good folks at NewHomeSource.com, where they listed their home inventory.

After performing the initial install and laying in our new design, we spent half a day training the necessary folks and setting up their new email addresses (the move to our CMS required new hosting to support PHP/MySQL). Since the initial launch in Summer 2005, we’ve made various tweaks to software and design and are in the process of helping them formulate ideas for other interactive promotions.

Bookmark:

Comments(1)

The MarketingSherpa folks have published over 500 case studies on various facets of email- and interactive marketing. The good folks at Search Engine Radio provide a fascinating 3-part series where she talks about some of their findings on landing pages (just fast forward through the commericals!).

Complete series.

Some notes on what I’ve learned:

• The first 300 vertical pixels are critical. Studies show that the less junk you put there (like heavy graphical banners, large logos, and other eyecandy) the more you’ll be able to sell. A simple headline that mirrors the ad or email promotion they received along with a convincing offer outpulls most design-heavy approaches.
• Asking visitors to add a product to their cart outpulls “buy now”.
• It’s okay to upsell and cross-sell, but wait to upsell until the visitor gets to the shopping cart or thank you page. Or, send them an email in a few days with a targeted promotion.
• The most-read copy on the page will be any words that have blue underline under them! We’ve been trained to mean that this is a link on the web, but even before the web, underlining means “IMPORTANT”. Guess what? If you’re a design agency that routinely removes underlining from links, you’re doing damage to your clients. STOP IT.
• People buy from people. Landing pages with pictures of people outperform landing pages without pictures of people.
• In a lot of cases, two- and three-column layouts are inferior in terms of sales to a simple one-column layout. A very simple letter-like landing page usually outpulls a much fancier approach.
• Remove navigation, or relegate navigation to “under the fold.” This will lower confusion among visitors.
• Large type outpulls small type. Stop being afraid of scrolling! Tell your designers to stop using microfonts.
• Stop using wide pages. When you hit 50 to 60 characters, move to the next line!
• Simplify your landing page URL. www.yoursite.com/tvoffer is much easier to keep in mind.

Bookmark:

Comments(0)

Problem: Austin Non Profit Organization needed a way to keep their web site updated.
Solution: We donated TopDog and set them up with cheap hosting.
URL: http://healthallianceforaustinmusicians.org/

Our good friends at Time Warner introduced us to the folks at HAAM (Health Alliance for Austin Musicians). They were in desperate need of a web site they could easily update. They also needed a clean new look.

Well, we unleashed Nicole on them. She created three or four beautiful layouts that would work well in a dynamic environment. Then we installed the core system, which gave them control over users, file uploads, pages, press releases, news items, and more, and included a scheduler and message center for content worker collaboration.

Bookmark:

Comments(0)

Thomas Davenport spells out some common attributes of knowledge work (and workers):

1. Knowledge Workers like Autonomy
2. Specifying the detailed steps and flow of knowledge-intensive processes is less valuable and more difficult than for other types of work.
3. “You can observe a lot by watching.”
4. Knowledge workers usually have good reasons for doing what they do.
5. Commitment matters.
6. Knowledge workers value their knowledge, and don’t share it easily.

The bottom line? Knowledge work is hard to model, and knowledge workers are more independent and secretive then workers in other industries. That’s why you have to watch closely if you want to replicate or improve processes.
Read it all here.

Bookmark:

Comments(0)

David goes over the issues and challenges related to corporate blogging. A worthwhile listen, especially for any organizations trying to learn the rules of this new medium live in front of an audience.

Bookmark:

Comments(0)

Intelligent Enterprise reports the results of its 2006 Intelligent Enterprise Strategic Management Survey that the top two IT expenditure priorities in the coming year are security/privacy (51.2%) and content/document management (50.2%).

Some interesting insights came from the survey:

Why the increased interest in document and content management? One possible explanation could be found in the fact that 50 percent of respondents confessed their firms make poor decisions because users can’t get enough good information. Ranking various sentiments on a scale of one for disagree strongly to five for agree strongly, 36 percent of respondents (the largest share) were neutral on the statement “our company has selected an enterprise content management standard and is consolidating on that platform.” Meanwhile, 32 percent agreed somewhat with the statement “our content control needs are basic and are addressed by network directories, intranets, basic document management and/or portals.” And 33 percent agreed somewhat with the statement “we’re moving toward XML-based management and reuse of content across applications, departments and channels of communication.” (emphasis added)

Check out the whole article.

Bookmark:

Comments(0)

1. Lop off any non-essential folks from the stakeholders list. Make these non-essential folks advisors or reviewers. Try to keep your primary stakeholder list as small as possible, and by that I mean 5-7 or maybe 9 max, not 20. I’ve been on projects with as many as 50 stakeholders, and that’s just miserable.
2. Don’t rewrite what’s already working. If you’re project includes writing functionality from scratch that already works elsewhere, really examine your motives carefully. Are you rewriting it because of not-invented-here syndrome or because the existing stuff doesn’t work or scale to your needs? If the latter, okay. If the former, leave it alone and figure out a way to integrate!
3. Prioritize! Take your entire list of requirements and categorize them into three groups: Must Have, Should Have, Nice to Have. Then sit down with your developers and figure out each item’s impact. You might figure out really quickly that all 9 items on the must have list put a serious dent in your budget and talent pool, but by tweaking 3 of them just slightly, you could actually save 30 days worth of work. Launch only if you have all the Must Haves and as many Should Haves as possible. Leave the Nice to Have’s for a future project.
4. It has to have kitchen logic. Many requirements will come in under the broad category “Wouldn’t It Be Neat If” or WIBNI. A colleague of mine from the Vignette days termed this kind of requirement, with its wild and crazy roots, as “science fictional.” You’ve heard of these. “We want our Web-based sales-lead generation tool to provide real-time data reports 24×7x365.” No matter that implementing true real-time anything means quadrupling the load on the system and tripling implementation costs and timelines. (However, a near real-time system can offer 90% of the benefits without too much added work!)

   Requirements have to have kitchen logic. You know what I’m talking about: requirements have to communicate a benefit stated in language that anyone can easily understand and relate to. Why go with XML? Is it because the three-letter acronym is so neat, or because every other article says we should use it? No! We should use it because it is easy to translate any XML document into other formats, which our particular organization needs.

5. Manage expectations. I’ve been on plenty of projects that start off as the equivalent of the Wright Brothers at Kitty Hawk, NC. We work and work and work and work and finally get off the ground for 30 seconds. Everyone is disappointed in the outcome. You ask why this is so and find out that everyone was expecting the team to put a man on the Moon. Even after you point out that the 30-second flight was something unheard of in the industry, everyone is still nonplussed. Why did this happen? Because one influential member of the business management team decided to share his vision via PowerPointware.

   A very wise man, my jeet kune do sifu, once told me that “An expectation is simply a resentment under construction.” Live by these words.

The problem in most cases is that IT abdicates its role as an equal partner at the table, either because of custom, board room politics, or just plain eagerness to please. Stop it. Draw some boundaries. Stand up for yourself. Remember: as an IT professional, you’re there to help the business leverage the power of your skill, intelligence, smarts, savvy, and geekitude to make the business more profitable.

Bookmark:

Comments(0)

1. Put three clear reasons on your home page why I should buy your product or hire your company. And phrase it in such a way that I can easily understand what you’re saying.
2. Put five links on your home page that drive traffic to latest news about your company, a white paper, your blog, or product/services pages. Make it a point to drive me deeper into your site.
3. Put together a page of testimonials and link to it prominently. Testimonials should be short (2-3 sentences), as specific as possible about your product or service (avoid the “you guys are great!” syndrome), and should always be signed with a full name, title, and company (if getting consumer testimonials, first and last name, city, and state are sufficient).
4. Put a call to action on each page. A good place is anywhere close to your search widget, or barring that, in the upper right hand corner. It can be a link or an image that drives visitors to a form they can fill out, or it can be an exortation to call a toll-free number.

Bookmark:

Comments(0)

Okay, so you’re about to launch into the brave new world of dynamic web sites. You’re gonna get the fully-loaded sales lead generation tool that integrates with a CMS and has database publishing capabilities. Cool. But before you can sign off on the deal, you have to figure some things out, which means having a chat with the folks in IT. The last time you talked to the guys in IT, you couldn’t really make sense of what they said, but it all sounded really good.

If you’re in this spot, you’ll need to go in there armed with good questions. Here’s a list of starter ones, divided into categories. Compatibility questions can give you a lot of information about what IT supports (or can support) right in house. Responsibility questions help IT formulate who is responsible for what systems–a very important thing to IT. Integration questions help you and IT discuss how to take the new system you are buying and place it in and among other existing systems. Scheduled maintenance and backups questions provide you with an opportunity to find out how robust your IT department’s non-emergency capabilities are.

Compatibility
1. What kinds of servers are we running?
2. What OS (usually Linux/Unix or Windows) and at what versions?
3. What databases are we running (mysql, postgresql, sql server, oracle, db2) and what versions?
4. What scripting languages do we support (php, asp, jsp, .net, python, perl, ruby) and what versions?

Responsibility
1. Do we need a service-level agreement? (SLAs are like contracts that guarantee certain percentage of uptime per month, or a certain response time to incidents, etc.)
2. Can IT support this project in-house, or if they can’t, can we outsource to the vendor?
3. What contact information do you need from the vendor if we do outsource it?
4. Does IT prefer or require a testing period or pilot program before full implementation?

Integration
1. What information do you need to have from the vendor about integration issues?
2. What information do you need to give to the vendor to make integration succeed?
3. Is there any offline or online documentation we can share with the vendor?

Scheduled Maintenance and Backups
1. What is the maintenance schedule for software, hardware, or OS in question?
2. What is the upgrade schedule?
3. What is the security patch schedule?
4. How often is the data backed up or mirrored?
5. Can we outsource backup or maintenance/upgrades of the application to the vendor, or does it need to be handled as part of a larger IT program?

Bookmark:

Comments(0)