How can we help?


RFPs: Why they suck and don’t work.

Our company responds to anywhere in the neighborhood of 20 to 30 RFPs a year, and we’ve been in business more than 20 years. That’s a lot of RFPs. It’s also a lot of time contemplating their effectiveness. Or their lack thereof. 


The inherent problem with RFPs is that they force the organization that doesn’t have the expertise to do the work themselves to write the specifications for the project. In application and web development, that involves a lot of technology experience from people whose business isn’t technology. It’s the equivalent of a patient arriving at a hospital and saying, “I need brain surgery. Here’s how I want you to do it.” 


Based on that, three not-so-good things happen:

  1. The customer ends up asking for something that may or may not be the right fit
  2. The vendor must respond to the specs of the RFP whether or not it’s the right fit
  3. The customer may not be getting a realistic quote


In addition, there are probably key details that will be missed in the bid and those could affect the price. So even the comfort of having a fixed price RFP is a sort of myth in itself. Worse, some companies exploit that and low-ball the bid, knowing there will be significant overages later on.


In our experience, RFPs are bad for the client, bad for the vendor and bad for the project.


But there is hope. And a good solution. Here’s a scenario using an alternative approach to the RFP:


Say you need your website redesigned and you’ve found 4 developers that might fit the need. Instead of writing an RFP, have them submit an expanded Request For Information (RFI). You say to those vendors, “Here are the goals of the project, here is what we want to achieve (more web traffic, convert visits to sales, etc etc).” Then, ask the vendors for the standard credentials (number of employees, how long they have been in business, similar clients, etc).


But here’s where the expanded RFI blows the RFP out of the proverbial water: Ask the vendors, “Knowing our goals and looking at what we are doing now, and based on your experience, what are your recommendations? What are your observations? What are your ideas? And based on similar projects you have done, what were the costs for those projects?"


With this approach, the customer gets the vendors’ recommendations based on their expertise rather than a regurgitation of your specs. Also, you get insight into their thought processes and thoroughness, as well as an estimate of the cost of a similar project.


Now, here’s the big closer: once you’ve chosen the vendor who most closely matches your needs, together you then build the final specs for the project and from that, develop a firm, final quotation. This is the vendor who will guide you through the pitfalls, and can save you costs, save you time and save you a lot of the headaches that are endemic to the web development RFP world. You get what you want and what you need.



DNN vs SharePoint: Strengths, Weaknesses, and Which One You Need

DNN and Microsoft SharePoint. They’re both powerhouses when it comes to content management functionality, but there are differences it would behoove you (we love to say that) to understand when it comes to choosing one system over the other for your website.


Document management: If you are dealing with thousands or tens of thousands of documents, SharePoint is the better choice as SharePoint is basically built around a powerful document management system. For DNN, there are third-party document management modules such as DMX, which is great for smaller scale document management (hundreds or a few thousand documents).
Advantage = SharePoint.


Forms: Forms creation and processing is built-in with SharePoint. In DNN it requires plugging in third-party modules, such as Dynamic Forms. Both do the job just fine.
Advantage = none (tie).


Search: DNN provides a basic site-wide search, but does not include searching document content, so if you’re looking for content within a PDF document, you might be in a real pickle unless you also install a third-party module like DMX. SharePoint comes with site-wide search, including document content.
Advantage = SharePoint.


Integration with Office®: SharePoint is a Microsoft product and was built to integrate strongly with Office, including Outlook. DNN, not so much, and there’s very little out there in the way of third-party modules.
Advantage = SharePoint.


Customization: Both SharePoint and DNN are designed to be customizable. In SharePoint, it's the ability to create custom "Web Parts" based on a client's needs. In DNN, the same capability is possible through creating custom "Modules.” In short, both systems are well-designed and built to be customizable.
Advantage = none (tie).


Graphic design flexibility: Both SharePoint and DNN are structured to allow for flexible graphic designs, though in this area, DNN has proven easier and cleaner (coding-wise) to work with than SharePoint. It's not that something can't be done in SharePoint; it just might take a little longer versus DNN.
Advantage = DNN.


LDAP integration: This means that administrators can use the same sign-on that they use to log on to their workstation as they do to the website system. Both SharePoint and DNN provide this feature.
Advantage = none (tie).


Licensing cost:
DNN / Evoq License Cost: Community version: free; Professional version: $2999/yr.
SharePoint License Cost: License cost: approximately $6700
Advantage: DNN.


So which to choose for your enterprise website? Both are good. But if large-scale document storage is important, integration with Office®  or integration with internal systems, and if licensing cost is not an issue with your budget, then SharePoint may be the best way to go.
If cost, content management, design or customization is your priority, then DNN may be the better choice.


Both have their merits. We can help you choose.



It’s time to go “Mobile First”

According to industry reports, 60 percent of total digital media time spent from 2013 to 2014 was done from a mobile device. And that’s only going to increase. To effectively reach this audience, it’s time to start thinking about moving your website away from a Desktop First approach, and over to a Mobile First approach.


Traditionally, a website was built with its priority toward displaying on a desktop computer, where it could then be scaled down for use on a mobile device. That’s called “graceful degradation.” 

That’s worked just fine for several years, but with that 60 percent number climbin, that method isn’t going to cut it anymore.


With your audience primarily using mobile, you should be designing for Mobile First. With this method, your site is designed for mobile use primarily, then can be scaled upward to the desktop. That’s called “progressive enhancement.” 


We’re starting to see our clients and their needs going more toward this Mobile First philosophy, and that changes everything: how you look at navigation, how you look at prioritizing the content structure and the overall graphic design of the site.


Navigation, in the traditional Desktop First version, has tons of options: think pull-downs, subpages and deep, deep navigation menus. You can’t do that with Mobile First; what you need are fewer options that get people where they’re going in as few touches as possible. This can be done by creating more landing pages, for example, but the navigation menu itself should have very few choices.


Graphic design, if you are going Mobile First, means getting rid of the extraneous: flashy graphics and fluffy content have no place -- it will be ignored or even worse, drive users away. You have limited bandwidth and limited screen real estate to work with. Mobile First is all about action and content: content that is short and concise, and action that should be easy to get to and prominent (think register, sign up and purchase here).


It sounds easy to say Mobile First, but it truly is a complete mindshift. In some ways, it’s almost a throwback to the days when we first started (21 years ago) and the web was young. Back then you had very little bandwidth and small monitors that affected how you designed a website. Same thing today when it comes to mobile. The only difference now is that we can do far cooler stuff within the same limitations than we ever thought possible back then.


Maybe a better of way of saying it is it’s Back to the Future for all of us.



Review: Dynamic Forms Module for DNN

Need to create an email form, registration form, survey, or any other kind of form you once created as a PDF or paid a programmer to create for you? The Dynamic Forms Module for DNN fits the bill and then some.


We’ve been using the Dynamic Forms Module for a few years now and have put it through its paces, having used it in association, retail, b2b, government and healthcare websites using the DNN content management system.


Key features:

The Dynamic Forms Module for DNN allows non-technical folks to create and manage their own forms. Say you want to create a simple ‘request a quote for information’ form for your website. This module lets you create the fields you want the user to fill out (name, address, email and so on), then set how you want the form processed (emailed to a certain person or people) and send a confirmation and thank you to the visitor. More advanced forms such as event registration are a snap, even those where you can set your own business logic (for instance, the full-day event selected will automatically add the golf outing to the registration). You can also do credit card payment, required fields, have it attach documents and which type to accept, surveys -- even complex member surveys where the data submitted is automatically entered into a database that can be viewed or exported to, say, an Excel document. You can also push the data submitted to other databases without having to do any coding. And with the later versions of dynamic forms, the forms are mobile-responsive so they will reformat based on the user’s device.


What it’s useful for:

  • contact forms
  • job postings / resume submission
  • event registration
  • client / member surveys
  • order forms
  • light eCommerce



Because it is such a powerful module, that means there are a lot of tools and functions available. And the more tools available, the more there is to learn. Think of it like using Notepad as your word processor, and now you’ve switched to Microsoft Word. True, lots more features, but also lots more buttons to decypher. As an administrator, the Dynamic Forms module has a much higher learning curve than most other modules and will take time to master. Some of the tools are simple to grasp, but others are not exactly intuitive. In short, it’s going to take some time to master this dragon.




For us old-timers who still remember VCRs, I like to think of the Dynamic Forms Module like setting the clock on the VCR. Yes, it took some time to figure out how to make the thing stop blinking 12:00:00, but once I figured out, from then on it ran perfectly, dutifully recording whatever I told it to. Same with Dynamic Forms. It’ll hum along nicely once configured, but first there’s a decent learning curve to get past.


Link to the Dynamic Forms Module:


Cost (one-time) licensing:

$195.00 per DNN instance. Can be used across multiple portals within the same instance.




Mobile Website App or a True App? Which is right for you.

Sometimes clients come to us saying they want to develop a mobile app, when in fact what they might actually need is a mobile website app.


What’s the difference between the two? A true app (think of those icons on your smartphone) is an application built specifically for a mobile operating system such as Apple, Android or Windows. A mobile website app is a browser-based application (think Survey Monkey, Constant Contact or Google Analytics) that can run on a mobile device, or on the desktop.


The development and maintenance costs between these two methods are stark. It’s much less costly to create a mobile website app because you are creating it once and it runs off the browser, so it doesn’t matter what type of phone users have. If you are creating a true app, then you have to build one for Apple, one for Android and one for Windows if you want them to run on all three phones. Some functions can carry over, but a lot of them do not.


So, how do you choose which method? It depends on the functionality requirements of the app. 


For example, let’s say you’ve got a member directory and you want to be able to search it and display the results on a mobile device. The solution could be either a mobile website app or a true mobile app. But if you also want to be able to do that same search when you are not online, or find a member who is close by based on their current GPS location, now you’re talking a true mobile app. 


There are tools available that can (somewhat) blend these two approaches, allowing us to create a mobile website app that also integrates with some features on the phone. But, there are caveats. If it’s something simple like submitting a form with a couple photos, yes, but anything much more complex than that you can run into problems.


What’s the cost difference between a website mobile app and a true app?


Developing a simple website mobile app could cost as little as 5-10K. If we’re building a true app that needs to run on multiple platforms (Apple, Androids, etc.), the cost could easily begin at 40K and go up from there. Also, remember that with a true mobile app there are operating system updates to keep up with as Apple, Android and Windows update their phones. Our research says to plan for 10 percent of your project cost for updating a true mobile app annually.


Both methods have their advantages. The key to finding the right method at the right cost is to talk to developers like us. We can help get you there!




Newsletter Sign-Up

This isn't your grandpa's newsletter. You won't find fluff. Or news about who won the golf tournament. No, in our newsletter you'll find meaty information that will help you run your business better. Click here to sign up.