Skip to main content
Home  ›  Blog

The Don't-be-DAFT pattern (Densely Abstract Features for Techies)

Don't you love it, when a tool/module helps you solve a simple problem - but is missing some trivial features. And to work around these limitations, you end up spending 3x more time, then if you had just created the whole functionality yourself. That is DAFT. Enter the Don't be DAFT pattern.

What is DAFT

DAFT is short for Densely Abstracting Features for Techies. While it is good to provide some simple "set this option here" dialogs for non-techies, for techies it quickly gets in the way.

Densely applies both to "dense = lots of features" as well as "dense = not thinking it through". Abstraction is when you go from specifics (CSS: Opacity 0.5) into a different way of viewing it (Setting: make-transparent-when-disabled). As to Features for Techies means functionality, which should be configured with a deeper technical know-how. 

Apple has always been very un-DAFT, while Microsoft used to be very DAFT, but changed it's ways (see below). You too should at least consider this.

How Systems/Modules Become DAFT

  1. It always starts simple. A developer (let's call him Foo) creates a simple-form component, or takes a cool gallery-JS plugin. Now he creates a nice GUI to configure it for non-techies. The GUI only shows some trivial settings, and Foo's first customer is happy. 
  2. The second customer can use this same component if Foo just adds 3 more settings. Foo adds these, and his second customer is happy. 
  3. After about 10 customers, the component is starting to look powerful, and it is suddenly used in more advanced scenarios. So now requests get more sophisticated - like "I need to add a custom CSS-class to the input-element, and dependending on the dropdown-value, it should disable some input fields"

Sound familier? Every developer has been there. And the DAFT solution is: create more configuration dialogs. Soon Foo's dialogs try to replicate all features of HTML, CSS and JavaScript. The GUI pretends to be simple, but in reality many settings require technical knowledge to really use - think of settings like CSS-Class, Validation RegEx, Responsive Break-Points or Post-Submit-Workflow

Foo now has a DAFT solution, where lots of techy-features have been abstracted into a configuration layer, but there's always just one setting missing. 

DAFT-Solutions Need 3-10x More Work

So DAFT (Densely Abstracting Features for Techies) is a missmatch between features, which need technical understanding, but pretend to be simple configurations. At its best, you just get lots and lots of configuration. This best-case never happens.

Normally you end up forcing the user to learn both the configuration-dialogs as well as it's inner workings, to correctly use it. So instead of only learning:

  1. a JS-Gallery-Plugin - let's say ScatteredPolaroids
  2. the JSON format of it's configuration
  3. the theming of this plugin

The customer/users which need the advanced features have to learn:

  1. all of the above
  2. how the config-dialogs translate into the JSON
  3. how the "much better" theming config translates into the plugin-theming
  4. how to override and inject something different with certain hacks
  5. how to work-around some of the settings which the config didn't cover correctly
  6. how to inject some JS into the setup, to correctly apply the overrides
  7. how to work around quicks which became necessary as the solution changed with time
  8. how to let the editor save item-specific data (as there are not enough fields in the original system) which the custom-overrides will use - these are often things like "just write the label for EN, but then add a hash and the FR translation, my work-around will handle the rest..."

Been there. Done that. And I know you've been there too. 

Don't Be DAFT

So things which need techy knowledge and are easy to do in simple technologies (like HTML or C#) shouldn't be further abstracted into dummy-user configuration-dialogs, because as needs grow, these simple config-dialogs become very complex as they begin to mimic all HTML and C# features, and they are always missing just this one important feature, forcing techies to jump through hoops and learn 3x more than without the DAFT configs.

User Roles and SoC to Not be DAFT

Before we continue, it's important to understand that different people (roles) can be in charge of different features - just like programmers create Modules (not editors). The core questions is "What is the role of an editor?" and "When should the editor leave it to professionals?" (see roles-examples of 2sxc here). If your roles are:

  • Editor edits content, adds the module, configures everything incl. very technical settings, theming etc.
  • System-Developer develops the module and does everything possible to maximize what the editor can configure

This will invariably lead to DAFT solutions. SoC (Separation of Concerns) like this is the first step to preventing the trap:

  • Editor edits content, adds the module, configures content and simple, installation-specific settings like "show in compact/large mode" which the site-developer gave him
  • Site-Developer is in charge of any installation-specific customizations, technical customizations, theming, etc.
  • System-Developer develops the module and keeps functionality separated between editor and site-developer, maximizing the technical freedom for the site-developer, so that the site-developer can maximize the comfort for the editor

Does it really need the Site-Developer aka the Techy-On-Site? YES!!! Because even simple things like "let's add a few fields to this" are usually done wrong by the editors even if you give them a GUI. They do something, it kind of works, but it quickly turns into a nightmare. Pretending it's an editor-activity makes it worse. 

Questions to Avoiding the DAFT-Trap

Feature-Creep is strongly releated to DAFT. It almost always starts with a wish looking like "I need this slightly more technical feature". And since the developer knows that HTML5 could do this, the developer hears "The customer needs a feature of HTML5, but doesn't need all of HTML5". The good-natured developer will then continue thinking "If I give him this switch here, I can let him have it, without him having to understand HTML5"

The questions I (Daniel, 2sic) always ask myself are these:

  1. Which real-life scenarios really need this feature?
  2. If we have this scenario, what are the next obvious requirements/scenarios?
  3. What additional features are needed to really work these scenarios/requirements?
  4. What other skills are needed to combine these features?

If you find out that this feature is actually needed in scenarios requiring much more know-how, you should not put it into the normal "editor-level" layer, but better to provide a sophisticated way for techies to work it. 

In 90% of all scenarios, it quickly becomes apparent that even trivial stuff like "I just need a color-picker for the editor" usually means that in real-life, the scenarios needing color pickers quickly get very sophisticated to do right - so it's probably not something for the editor at all. In the end a "Color: primary/secondary" feature may be much better. 

Providing Techy-Features

Providing the techies with a system where they can do "everything" is often much simpler than you think. Here some examples:

  1. HTML: Instead of abstracting things that create an HTML view (like creating custom templating-engines) it's much simpler to use Razor. Your initial template can react to some switches in the configuration, but any developer can easily override this. 
  2. Styling: instead of developing extensive custom (high-learn-curve) CSS frameworks, just implement the basics, and let the developer take it from there.
  3. Business Logic: Instead of creating a "can do everything workflow engine" it's easier to provide a code-hook where a developer can just add as much code as he wants.
  4. Configuration: often it's smarter to just provide a JSON config file which is difficult to edit, but allows configurations for which it would be hard to create a UI

Don't Re-Invent The Wheel

I think this is a core aspect both of feature-creep as well as "our GUI does it better than JSON" - much of it results in re-inventing the wheel, so you're adding new technologies, instead of leveraging existing stuff. 

So much of it is actually just Software-Architecture Best-Practices, like SoC, IoC, Decoupling your components, keeping the parts small and dedicated to a good purpose etc. Once you do that, you must always keep the mindset of "keeping things simple for the simple people" and "not re-inventing the wheel - it won't be better than the original". 

Non-DAFT is Faster and Cheaper

The hard thing about not being DAFT is that you have to think things through, instead of just quickly implementing a technical feature. But in the end you have many advantages:

  1. developing non-DAFT solutions is much quicker - because many features don't actually get developed by you at all, the implementor can do it
  2. non-DAFT solutions are much easier to support/maintain, because you don't have to support hundreds of micro-options which sometimes conflict each other
  3. documentation is much, much easier - because for many things you can just write "do this with Razor" or "if you want to go this way, the JS so-and-so is included - check out the docs"
  4. techy learning curve is much flatter, because most of the skills (HTML, CSS, JS, Responsive design, etc.) can be re-used
  5. learning for the editor-user is much easier, because his core activities aren't hindered by thousands of features that scare him...
  6. ...so training is also much easier & faster

Microsoft Stopped Being DAFT...

Microsoft used to try to provide a GUI for every possible setting. They stopped in 2006, when they realized that systems-management is better done with PowerShell than with GUIs.

This realization also moved into many programs from then on - including software tools (Visual Studio Code - where settings are json-based). Now thanks to Git, Gulp, Angular CLI and the rest, this concept has moved into every aspect of software development. 

...So It May be Something For You Too

I urge you to consider this for your solutions. We from 2sic are absolutely commited to Don't be DAFT, as our 20 years of experience has always shown that DAFT catches up with you. 

  • we have purchased many DNN modules which promised to solve an issue, and ended up taking too long to implement that "just one more thing"
  • we have spent hundreds of hours trying to look into 3rd-party modules, to "quickly and cheaply" deliver a solution - in never was quick or cheap, but we paid the price
  • all our solutions (foremost 2sxc) which we built on Don't be DAFT principles, stand the test of time, survive upgrades and are a joy to use

TL;DR

I hope 2inspire you, to review your work and your solutions with the focus of: "what are we actually trying to achieve, and are we achieving it this way". We believe that removing all advanced options from the normal GUIs and providing much more techy-solutions for these features protects the editor and ensures that the right people do the right part of the job. 

Love from Switzerland,
Daniel


Daniel Mettler grew up in the jungles of Indonesia and is founder and CEO of 2sic internet solutions in Switzerland and Liechtenstein, an 20-head web specialist with over 800 DNN projects since 1999. He is also chief architect of 2sxc (see github), an open source module for creating attractive content and DNN Apps.

Read more posts by Daniel Mettler