Anatomy of a SaaS Application Landing Page

This page is a work in progress...

There seems to be a standard pattern for SaaS product marketing sites. 

I've gone through a collection marketing sites for SaaS apps that were recommended for their UI/UIX goodness and tried to reverse-engineer the common structural qualities.  What I've found is a structural pattern (or design pattern, if you will) that represents what I think must be the current best practices for marketing product-type web services. 

Fundamental structure of a SaaS product marketing site 

Header

• logo
• primary navigation menu
• search bar
• login area

Primary Area

• top third to half of the page
• A clear and easily understood statement of what the product is - 
• freeagentcentral.com - 'Accounting software, simplified.'
• campaignmonitor.com - 'Email marketing software for designers and their clients'
• zferral.com - 'Easily create, track and manage custom referral programs (with zferral.com)'
• A place for a picture of the product (or video, or slideshow)
• A clearly dominant 'signup' or 'plans & pricing' button (this is usually green)
• https://tifollc.basecamphq.com/projects/7995821-tifo-website-redesign/posts/51359490/images
• https://tifollc.basecamphq.com/projects/7995821-tifo-website-redesign/posts/51359711/images

Secondary Area

• second third or bottom half of page, but allowing some of next section to be visible
• A set of secondary value proposition statements / explanatory paragraphs.
• getharvest.com - 'The best in time tracking and online invoicing', 'nothing to install or worry about', 'who uses harvest'
• campaignmonitor.com - 'create and send beautiful emails', 'manage lists and subscribers', 'powerful analytics'
• etc 

Tertiary Area

• teaser visible but requires scroll to view entirely
• logos of other brands people know and trust - social proof
• who uses
• partners
• integrations
• media mentions
• testimonials

Footer

• Sitemap links - e.g. links to anything not in top nav
• facebook, twitter, etc
• etc.
• copyright line

Common Content

Content-wise theres some variety in what different sites sort into the secondary and tertiary sections (and footer), and where they sort them, but you almost always see:

• value proposition statements
• ease of use statements
• 'actual' customer testimonials
• implied endorsement via logos of much larger companies (e.g. customers, partners, integrations, etc)
• additional, secondary call to action buttons
• impressive press mentions.

Miscellaneous

• The thing you want the visitor to do next is always the green button
• If you have to scroll to see the entire page, there's another green button at the bottom somewhere
• 
  

Site List

As a resource, here's a list of sites I referred to during my 'research'. As I find more examples, I may update this list:

• basecamphq.com
• http://www.getballpark.com/
• http://www.campaignmonitor.com/
• http://www.getharvest.com/
• http://www.freeagentcentral.com/
• http://zferral.com/

These guys are slightly off the beaten path, but still follow the basic formula -

• http://www.staction.com/
• http://www.wufoo.com/
• http://pluggio.com/
• http://chext.net/
• http://mixpanel.com/

And yet more food for the mill - some of these bend the rules in cool ways (rightsignature) - 

• rightsignature.com
• pulseapp.com
• http://www.crazyegg.com
• http://www.xero.com/
• http://urbanairship.com/

Not quite as awesome as the rest -

• http://www.getcashboard.com/
• invoicemachine.com (but I like the app)
• survs.com

The exceptions:

• flowtown.com

Django BDD Tools

I've been looking at Python testing tools this weekend. I really like the BDD discipline for testing and it seems that Python now has a few Cucumber clones to make this approach more reasonable:

• Pyccuracy - https://github.com/heynemann/pyccuracy/wiki/
• Freshen - https://github.com/rlisagor/freshen#readme
• Lettuce - http://lettuce.it/
• Morelia - http://pypi.python.org/pypi/Morelia/
• PyCukes - https://github.com/hugobr/pycukes
• pyhistorian - https://github.com/hugobr/pyhistorian

Also, I found a couple of tools that provide autotest-like functionality:

• peon
• autonose
• django test server

I'm using Django, so there's some Django-related stuff that's useful as well:

• django-test-utils 
• testmaker, crawler, twill runner and more, from Eric Holscher
• django-sane-testing 
• ...not convinced this is still necessary in Django 1.2+
• django-test-extensions
• Some useful PyUnit assertions for testing Django apps

Hosted Support Ticket Software Evaluation

Tender Support - http://tendersupport.com

By the entp guys (Lighthouse) this seems a solid tool. Much llke Lighthouse, it is light on features, but the features are all very well thought out and the presentation is clean and stylish. While there are reasonable customization options available through admin configuration, there doesn't seem to be any kind of user-visible id assigned to requests, so it fails one of my
critical criteria. Of course, there are a lot of API options, so anything's probably possible.

Demo site: http://design-service-usa.tenderapp.com

Small Business Accounting Software

Yesterday I started researching technology solutions for a potential client. The client has a growing auto repair business and has outgrown the software that he's been using for the last 7 years. The business is multi-site - they have three locations - but mostly managed from a single location. A large part or their business is specialty work - maintenance and repair of a commercial transportation companies vehicles, and the remainder is typical retail auto repair. When I met with them, they explained that they have evaluated a lot of off-the shell repair shop management applications over the past year, including all of the larger and/or popular ones targeted at their segment, and they haven't been able to find one that meets their specific needs.

The basic requirements are pretty common - point of sale, generation of estimates, work orders, and invoices, customer and vehicle history management, and inventory management. They use quickbooks for back-end accounting but there is no direct integration between their front and back office systems.  They also pointed out the abilty to easily create ad-hoc reports and to get exports of customer data for marketing would be very useful as well.

Whenever I encounter a situation like this my first thought is that finding the right existing solution is by far the best option. In terms of cost, timeliness and many other factors, buying an existing product that may not be *exactly* what you envision is usually better than paying someone significantly more to build you what you think you really want.  But if that's not an option, then custom development is in order and there are a few ways to go about it. Building from scratch is an option, but in a case like this where the general functions are very common customizing an existing, general purpose package is probably the right way to go. But the question becomes, what product do you start with?

My first thought was QuickBooks. They already have it in house, and are happy with it. But Quickbooks doesn't impress me a a great platform for building third party applications on. So what else? Microsoft Dynamics maybe? Well there's a confusing product family - it turns out there is no 'Microsoft Dynamics'.. instead there are four (or six, depending on how you count) different packages with roughly the same features but entirely different implementations, each competing within the MD family. It seems NAV is the way to go for my purposes, but RMS may also be a candidate. Of course, I haven't been able to find any pricing information yet, so these may yet be too expensive.

The open source world has some options as well - OpenBravo looks like a reasonable choice (mostly) and Opentaps deserves a look as well. And there's a few others like xERP and Compiere, etc I need to investigate more as well..

Django Middleware Fun

I have a Django app that lets users create and manage 'requests'. There are a few views that display and manipulate requests, and in each view I need to ensure that -

• the current user is of the correct type to access that view
• the current user has access to the request(s) she's trying to view - the request id's are part of the url

Pretty simple, right? So I have a piece of boilerplate code stuck in the front of my views that does the following:

• get the logged in user
• redirect to login page if no user or anonymous user
• get the logged in users' profile, and from that get their account id/object
• if the user doesn't have a profile, they shouldn't be here at all so fail with an 'access denied' message
• if the user doesn't have an account, they may be an admin - check for admin privs (is_staff)
• if they're not an admin and don't have an account, their user/account is invalid and support needs to fix them - tell them that before logging them out.

These steps basically validate the user has access to the app. Based on whether we're in a 'view/edit' or 'list/browse' type context, one of the following happens next:

• To ensure they have access to the 'current' order, we lookup the orderid in the set associated with their account. 
• If it's not there, it's probably somebody else's order and we give them an 'access-denied', unless
• they are staff members, in which case they are granted access based on a class level permissions system.
• To discover the set of orders the user has access to, we do an account based database query, unless the user is staff, in which case we just list everything

Over time the boilerplate starts to smell. Small variations arise from method to method based on specific stuff I need to do, or I figure a better, more elegant way to do the same thing and don't bother changing all the other boilerplates. Worse, when something global changes - for example, the emergence of 'staff' users - I have to make the same change in a lot of places, possibly in slightly different ways. 

My answer to this? Middleware!

Since I basically always need the account of the logged in user, I created a middleware class to set that in the current request when it was available.  This class also validates the current user is valid and permitted application access based on their 'role' or account type, so each view just has to handle the variant behaviour based on the staff/not staff dichotomy.  Since this logic may vary depending on the view, I think its appropriate to leave the view this work.

Simple stuff, probably, but cool anyway.

Not Quite Daily...

Ok. Well..
So about that 'daily blogging'...

Anyway -

I just finished recompiling Postgresql 8.4 on my big machine after upgrading to Snow Leopard a few weeks back. It was surprisingly easy - make clean; make; sudo make install. Cake.

On my laptop I took the MacPorts approach, and while that might seem simpler, it took about ten times as long since it had to download half the open-source world before it saw fit to actually compile PSQL. Once it did however, everything worked well - I have yet to test my homemade incarnation of PSQL, so there may be a shoe waiting to drop here.

Blogging Daily

To get into the habit, I'm making a committment to myself to blog daily for thirty days. Every day, I will create at least a paragraph or two of original content. For example, I just posted a cool python recipe I found on the net to my tumblr, but that won't count. This entry, on the other hand, does.

Today I'm completing my RT installation. We're installing RT to help us manage the support process as well as to support the design request workflow and interactions with service providers and consumers.  I'm finding it a little difficult to focus, and the docs seem to lack polish which is probably more discouraging than warranted.

The interesting part of this project is the process automation aspect.

1. Our customers send us requests through any one of a variety of means - email, fax, file upload and telephone support are all valid options (although the phone option is a rare special case). 
2. Once the order is received it is examined and 'cleaned' - a preprocessing step we perform to ensure requests sent to service providers meet a minimum quality and completeness standard. It's possible at this step cannot be completed without contacting the submitter to gather additional information, or clarify some ambiguity. 
3. Cleaned orders are then submitted to a service provider who fulfills that order, returning a completed 'design package'. During the course of creating the package, the service provider may have questions that need clarification as well - these questions are passed to the submitter and processing will halt until the proper clarification is recieved.
4. Orders completed by the service provider are validated by our customer service staff prior to delievery back to the requestor. Failed validation here can result in additional clarification interactions with the service provider as well.
5. Finally the verified, completed order is returned to the submittor for final acceptance. The existence of errors in the design will trigger a correction cycle where the service provider will be required to address the issues and return an updated design package.

These steps are in fact a simplification of the actual process, and there are points of flexbility in the process that I don't bother to note, but there are some common requirements that apply across all of the possible scenarios -

• Traceability -  every significant action in the lifecycle of an order must be logged.
  
• Visibility - it should be easy to see the current status of all orders, to access their history, and to be notified of changes in an orders status. This visibility should be available to all stakeholders of a particular issue (e.g. submitted-by for submitters, serviced-by for service-providers, and by account for service-reps)
  
• Accountability - the system should provide a basis for measuring performance, and helping stakeholders to meet committed goals - e.g. 24 or 48 hour turnaround times.
  
• Flexibility - the system should not lock us into a particular workflow, or prevent us from modifying the workflow unreasonably. For example, workflows will vary as the process matures, and workflows may differ based on submitter or service provider (or the two combined).
  

Our initial plan was to build this workflow into the system, but on second thought this didn't seem to be a great use of our time and resources.  The advantage of going with something like RT is that it has most of what we need out of the box. The disadvantages are yet to be cataloged (which is itself a disadvatage) but will probably include some necessary integration pain, and possible limitations related to integration.

Wish me luck - I'm off!