Ponderings and Wanderings

Dan Katz’s thoughts on marketing, customer service, woodworking, his baby boy and other musings.

Share presentations for visibility on SlideShare

Jun 2

Posted by Dan Katz in Best Practice, Marketing

YouTube is certainly well known for the success it has shown with marketers. Another effective tool is SlideShare. SlideShare offers the ability to post a presentation that others can view, share and comment upon just as you would a video on YouTube. There are a number of similar services, but SlideShare appears to have a solid user base.

Easy to use and requiring nothing more than a PowerPoint deck, SlideShare is easy to test out for marketing and communications campaigns.

What makes this really easy is a nice Microsoft PowerPoint plug-in. This allows you to work with the SlideShare features and post to the site right from within PowerPoint. Get it here.

No Comments

Drupal vs. WordPress

Jun 1

Posted by Dan Katz in Blogging, Software, WordPress

Let me start with a note on my bias – I love WordPress. This said, I have tried not to let it color this post that attempts to highlight when and where to choose between WordPress and Drupal. No matter, I look forward to some solid comments from all sides on these ramblings.

This evaluation really comes down to a definition of the task you desire. I have found that WordPress is the ideal selection for any blog. I have also found it to be an excellent choice for a small to medium Web site. Why? In two words, elegant simplicity.

On the setup side, WordPress is so simply to install, create themes, add enhancements that it is easy to get an excellent site up and running in a very short time. Then on the administration side, the user experience is an excellent one for those who are not familiar with technology. I have been able to bring luddites up to speed in WordPress post, page and comment management in mere minutes.

Drupal I have found to be more suitable to larger Web sites that require a greater level of development for custom applications, multiple themes, multiple languages and other aspects you would expect of a full bore content management system. For a blog or small Web site I find it to be overkill and adds a level of complication that adds too great an expense to sites that so not require custom applications.

This difference is apparent in the extensions to WordPress and Drupal. Drupal features a large set of modules to extend features. WordPress appears to offer many more. The difference comes not just in volume, but types. Drupal has a set that is clearly more technical in nature than WordPress. Also, a good number of the modules are seen as jumping off points for custom development. This is far different from the WordPress plug-ins that are targeted to the Web site maintainer who has little if any programming knowledge.

And this comes to the real difference I see with these two platforms. Drupal is clearly targeted first and foremost to code lovers and developers. This is readily apparent in the language used on the Drupal site, its blog postings and in general. Development discussions on the site are highly technical and constantly refer to a mix of PHO, JavaScript and JQuery as minimal requirements for Drupal development.

WordPress on the other hand has a greater balance between the average Joe that wants to have a blog/site and the developer. Surfing to wordpress.org you find that this is tailored much more to the layman than Drupal.org. WordPress also has a broad commercial path to get started via wordpress.com. Then when you do dive into development, you find that with minimal PHP skills you can customize and modify themes.

I find that this separate target of hard core a developer (Drupal) to the general population (WordPress) is clearly evident in area of theme management. In Drupal, the themes are all managed external to the Drupal interface. You compile and create the various layouts on the backend (as you do in WordPress) and then must manage these from the back end. In WordPress, you have access to theme templates form within the interface for modifications. This distinction is key. There are two levels of expectations here. In Drupal there is the expectations that the framework will usually require far more coding and management than should be permitted via the interface. WordPress on the other hand considers the possibility of editing templates to be something that should be permitted to the administrations right from its graphical shell.

Again, this comes back to suitability of task. I would not want a large scale site with numerous complex templates to be accessible by any old administrator – hence Drupal. However, if I have a small site where the admin, maintainer and developer are likely the same person and the theme is straight forward then the interface access is reasonable.

Here are some other side-by-side comparison.

Editing Interface

I hate the Drupal editing interface. The listing of pages without any management options means it takes me a long time to find and then adjust content. The content listing and editing options in WordPress are simply far more elegant than anything offered in the Drupal core or via any add on modules I have found. For this interface reason along I prefer WordPress.

Comments

WordPress has focused for years on its comment moderation capabilities. They are top notch. Drupal’s are rudimentary at best. Having now used both, I would have to eliminate Drupal as a blogging option for a site that expected high comment volume. Drupal is a fine technical solution. Drupal is simply not up to the task when it comes to the associated workflow.

Simplicity of Free Themes and Theme Design

WordPress and Drupal take a few minutes to install. Getting started with adding a free theme for WordPress takes a few minutes to find tens of thousands of items to get started. Drupal then takes quite a bit to customize even free themes. This difference real comes to the forefront with my experimentations. I can transfer an existing site with drop down menus and a couple of area designs to WordPress in half a day. The same effort took me (and an experienced Drupal developer) a week.

Media Library

WordPress offers a simple but elegant media library. And a couple of plug-ins really push it to an even better solution. Drupal’s media management is barebones. Media is considered a node or content element just like any other item such as a page or post. This is excellent when you want to develop a larger application on top of the framework. However, it falls short for a simple site.

Plug-Ins

WordPress offers not just one plug-in for everything imaginable – there must be three or four. The modules that extend Drupal are simply not as varied and there are less options for each task. More to the point, adding, testing and tweaking just seems to be so much faster and easier in WordPress than the developer focused interface offered via Drupal.

Here are some other articles for thought

Tags: , ,

3 Comments

Drupal CMS Alignment with Best Practices

May 26

Posted by Dan Katz in Best Practice

One of the things I fear when working with a developer is that they will claim to be as someone around here did to be a “code monkey.” Good Web site development and campaign delivery is not about creating code. It is about utilizing best practices to provide the best user experience. Those who solely want to work on the code level often miss the forest through the trees

Each CMS must be configured to align with marketing, user interface and other best practices. The following provides for common best practices that should be noted for attention with the Drupal CMS configuration. These items are included in this document to confirm the configuration as the technical defaults are often focused on specific functionality rather than such general best practices

Start Here

A great list of best practices in an easy to read format is available here: http://zzolo.org/thoughts/drupal-basics-and-best-practices Rather than recreate those items, just start and there and then come back to this document for more.

Installation Package

The Drupal core package for download from www.drupal.org has the most basic set of core files and modules. This is always supplemented with additional modules. Use of the Acquia Drupal package distribution from acquia.com can provide a simplified install with a large number of the modules that would have to otherwise be individually installed. This provides the entire core Drupal functions with added services from Acquia. The services from Acquia may not be desired and can be easily disabled.

Module Configurations

The following settings, configurations and modules should be installed and activated.

Configuration Options

The following basic configurations options should be set:

  • PING – Activate ping with a long list of ping servers..
  • User Administration – Any agency account management team Role should have the ability to add and configure users to be authors.
  • File Quota – Set the file size and upload quotas to at least 50 MB or unlimited for all users. The default of around 8 MB is almost always inadequate.
  • Full HTML – Set FULL HTML as the default input format.
  • File attachments – Activate file attachment capability for all users.
  • Video – Activate the video module for the easy inclusion of YouTube and other videos.

Modules

Modules provide functionality beyond the Drupal “Core.” It is the underlying philosophy of the Drupal CMS that any installation will contain a variety of these modules to provide services beyond the basic items built-into the CMS. The main issue when selecting these modules is that they are maintained by individuals often with no real development plan. They may break, be withdrawn or be incompatible with future versions of the Drupal core.

Even so, be sure to check the Drupal module availability prior to developing custom code.

The following are a variety of helpful modules that appear to be well maintained and respected by the Drupal community. This list has been determined based upon Drupal community recommendations and other base level best practice requirements.

Basic Modules

The following modules should e downloaded and installed for all sites. They provide base level functions that should be expected for delivery on all sites.

Basic Drupal Module Configuration

Draft

http://redesign.pparx.org/admin/settings/draft

This provides a method for an editing review with a draft of content. This way someone can make changes and hold then for review or come back later and complete edits and then publish.

To turn this on:

Place a check box in the “Allow drafts when editing” box

CustomError

http://redesign.pparx.org/admin/settings/customerror

This provides for a custom page to be displayed when Web server or browser error occurs. This is important otherwise a blank page is displayed with very little wrapper display.

To turn this on:

Design page nodes or HTML files to display for 403 and 404 errors and place these details in the settings.

Page Title

On content creation pages, gives you the chance to specify the page title rather than defaulting to the content’s title.

To turn this on:

Active – simply use area in form to set the page title.

Additional Modules

The following are common modules that provide some frequently required functionality.

Accounts/Roles

User1 should not be used for development, maintenance or other tasks. Set it aside for very restrictive use.

Layout and Development

Never alter the Drupal core. Instead adapt an existing module or create required customizations as a module. These methods will isolate customizations from the core and other modules so that the core may be updated without impact on custom development’

Use the Content Construction Kit and the Views module. You can bypass this kit and module, but future development and adjustments are easier if they are utilized.[1]

Use the From API. Define the forms in php syntax and let Drupal create the html. This will let other modules adapt the form and enables programmatic submission.[2]

With the Form API make sure to check text only fields with check_plain(). This will check the fields for malicious content such as scripts, HTML and so on.[3]

To tackle Drupal development is strong in HTML, CSS, JavaScript and jQuery[4]

For a normal (single site) installation, you should put all non-core modules or themes in the sites/all/modules or sites/all/themes folders. For a multi-site installation, put modules or themes in sites/all that you wish to have available for all sites.

Scalability

The following is a good resource for Drupal scalability – http://www.optaros.com/blogs/drupal-scalability. Most of these tips come from this page.

Choose modules carefully and deactivate them when they are not required. This would apply mainly to modules that assist in development. Deactivate these following the development cycle and reactivate when adjustments are required.[5]

CCK is a critical module but can slow down high-traffic sites. Consider its impact on such models. [6]

A theme is not just the look and feel. It is the data architecture and should be created with performance as a key concern,[7]

MySQL should be tuned for performance for any size site. See this page for four tips to follow : http://www.optaros.com/blogs/drupal-scalability.[8]

Use database, member and caching systems for files. The Cache Router module at http://drupal.org/project/cacherouter is recommended.[9]

Follow at least the basic guidelines for shared server and mySQL optimization as found on http://drupal.org/node/36628

Drupal Site for Best Practices

The Drupal site itself has a whole section on best practices. This is of course a great resource and no one should start developing in Drupal without reading these areas targeted to the deep developer audience.

· http://drupal.org/node/287350

· http://drupal.org/node/244642

· http://drupal.org/node/36628

· http://drupal.org/node/22283

· http://drupal.org/node/224921

Other Best Practices Sources

The following are some of the solid best practices locations I have found for Drupal. The information in this document is heavily drawn from these sites.

· http://www.slideshare.net/manugoel2003/drupal-best-practices

· http://zzolo.org/thoughts/drupal-basics-and-best-practices – Great great easy to read bullet list – start here.

· http://acquia.com/community/resources/webinars/seo-best-practices-your-drupal-site-0

[1] http://www.slideshare.net/manugoel2003/drupal-best-practices

[2] http://www.slideshare.net/manugoel2003/drupal-best-practices

[3] http://www.slideshare.net/manugoel2003/drupal-best-practices

[4] http://www.slideshare.net/manugoel2003/drupal-best-practices

[5] http://www.optaros.com/blogs/drupal-scalability

[6] http://www.optaros.com/blogs/drupal-scalability

[7] http://www.optaros.com/blogs/drupal-scalability

[8] http://www.optaros.com/blogs/drupal-scalability

[9] http://www.optaros.com/blogs/drupal-scalability

Tags:

2 Comments

Best Practice: Constant Contact List Segmentation

May 4

Posted by Dan Katz in Best Practice

Constant Contact provides methods to segment lists when they are collected from different data collection forms. This is conducted by using a different list name for each data collection form. The following practices can help with this segmentation

  • Import any external lists to a new list for each. Do not import these to lists used with data collection forms. If this import contains data from multiple external lists then use a column (custom data filed) for details on the original source list.
  • Create a general list for use with the main subscription form on the Web site. Something like – “General Web Contact” is a good name.
  • Use a different list for each form used with an advertisement, microsite or other campaign. Yes, you will have a large number of lists. This is absolutely fine.
  • You could use one list and have a custom field populated with a source name that is unique to each form. This is not the preferred method since this will have a single list that may become prohibitively large.
  • Where possible use the Constant Contact forms that are provided for inclusion as this can be a very easy and direct method to include the forms with minimal programming.
  • Use a plug-in/module for WordPress (http://wordpress.org/extend/plugins/constant-contact-signup-form-widget/) or Drupal (http://drupal.org/project/constant_contact) as these can help shorten programming cycles and make it easier to create the forms.

No Comments

Marketers Challenge; Gefilte Fish

Mar 19

Posted by Dan Katz in Marketing

I am sitting here eating a nice plate of gefilte fish. And it is not even Passover yet. But hey, I find these yummy. Certainly most members of the tribe I meet do not have the same preference for this delicacy. Few if any people really say – “hey, let’s go grab some gefilte for lunch.” This is a food crying out for a good marketing effort. It could start with a social media push to enhance the popularity of gefilte fish. As one site at http://me-eats.blogspot.com/2007/04/grandmas-gefilte-fish-for-pesach.html says, there is a story to tell. Then we could build this buzz to some cool interactive. I see the Facebook application now – send a friend a “fish ball”. Or, I would love to see little chattering gefiltes dancing on a JibJab ecard. Then this could be ready for a giant advertising campaign. We could run something to demonstrate to the world just how lovely ground up fish can be. (Only the good stuff here – it is kosher after all.)

Rise oh rise the understated hero that is the gefilte!

2 Comments