How can we help?


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!




Help! I Want to Build a Mobile App.

We see it with both startups and established companies: They want to build a mobile application. They have a vision, but need help with the details. Is it even feasible? How much will it cost? What's involved? 

First, let’s assume you've done the necessary up-front work. You've identified:

  • Your audience
  • Whether it is solving a problem
  • Your competition
  • Your return on investment

If you've hit these questions, you've at least addressed the basics of whether or not the app has potential. In essence, whether you're a startup or this is a value added to your organization, you should create a mini business plan for your app -- especially if it is intended to be a revenue-generator.


OK, now on to the meaty stuff:


1. Have you created a Vision Document?

This is critical. This is the floorplan. This is what creates the final deliverable and ultimately determines cost, timeline, phases and expectations. Without it, you're flying entirely blind. Worse, you're flying blind and don't even know how much fuel you’ve got!

Your vision doc needs to spell out in detail:

  • Specific functionality (I want it to do this, and then this…)
  • A walk-through of the app. Step-by-step, screen by screen. (If I click this, then it does this…)

Also, don't forget the things you need that are outside the app (reports, billing integration, etc.)

2. Have you thought through the business logic needed in the app?

Forms and front-end can be simple. It's the back-end logic where things get complex and time-consuming. An example of business logic might be:

  • Does every user have the same rights and functionality, or are there special features available based on user, or their group, etc?
  • Are there workflow requirements? For example, one user creates something, but another has to approve it before moving it along the process.
  • Does the user have multiple paths s/he can take during a process (whatever that process is)? How are those paths decided? Automatically? User choice? Based on some kind of data it's checking?

Remember, if some combination of business logic only happens once, it still needs to be planned for in programming. Run scenarios to catch it all.


3. What are the minimum features needed to roll out the app?

Does the app need everything completed in order to roll out, or can it be done in phases? What are the minimum Phase 1 requirements? Rolling out the app in phases can save cost and implementation time.

4. Do you have a guinea pig? 

One important way to save cost is to first create a wireframe mockup (with clickable buttons, etc.) and then run/beta test by your guinea pigs. What did they like? What would they change? What's not needed? It's amazing how many times the one feature you like (which might take up 60% of development time and cost) ends up being something your users can take or leave. Finding this out early can be a huge cost-saver.


FYI: Everything we just talked about? We can absolutely help you with that. Find out more at 


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.