11

We have an awful system written in ASP.NET 2.0 that we need to add some functionality to. The problem is that a certain product has UI features that have to be turned on for business initiated after a certain date (and others turned off), while the page has to appear the same for existing business.

I am pushing for a rewrite of the page for new business as I instinctively find the idea of date-based JavaScript UI switches, and the mixing of web controls for the old and new business to be "untidy" (for want of a better word).

Is the practice of having time-based UI features a widely accepted practice, and if not, what are the known risks of pursuing that course of action?

NMrt
  • 487
  • 3
  • 9

8 Answers8

22

There's nothing wrong with tweaking a UI based on which features are enabled for a customer, or which deployment types they have chosen, but the change should

  1. depend on meaningful flags, e.g. "HAVE_EXPORT" to enable/disable an exporting option, not on weird date comparisons. The UI has no business knowing the business rule about what was published when, it should fulfill only its UI task and obey UI-specific instructions.
  2. Be controlled server-side, so that a customer cannot surreptitiously enable features for which they haven't paid.

(Note that the opposite - disabling features after a certain time - is a major no-no unless you've clearly communicated that you're selling a time-limited trial version. Creating such time bombs under any other circumstances will make people hate you faster than almost anything else.)

ravibhagw
  • 676
  • 4
  • 9
Kilian Foth
  • 110,899
12

The requirement itself isn't problematic, but there are good and bad ways to implement it. If you have code copied and pasted all over the place that looks like:

if (businessInitiationDate > cutoffDate)
  enableNewControlsForThisOneLittlePiece();
else
  enableOldControlsForThisOneLittlePiece();

That's going to be crazy hard to maintain, even if it seems quicker at the moment. For example, maybe at some point some older customers will want the new look. Maybe at some point there will be a third configuration with its own cutoff date.

Ideally, you want this if statement to appear exactly once in your code, preferably on the server side. However, you also want to avoid just duplicating the entire application and making changes. Find the common code and factor it out, then create small separate functions for just the parts that are different. Then enable or disable those functions from one central place.

Karl Bielefeldt
  • 148,830
7

Its a requirement, and while it appears to be smelly - basically configuration based on a datetime value - there's no reason time cannot be used to alter your UI. The classic case is a satnav display that changes from bright colours in daytime to a dark theme at night (and if you're really dedicated, a muted colour at in between).

However, one thing I can suggest as an improvement is to remove the concept of a date that enables the controls, but a version number. The version sets the UI configuration (ie you have a flag to say configured for NewCustomer, and in the future can be expanded to cater for the additional controls NewNewCustomer wants, and so on). This is much easier to handle in the code, and smells much nicer.

Then you only have 1 issue which is setting the version number based on some criteria, and this can be done by a date check today, possibly a server-side configuration option later, or even a cookie that is set by user login some time in the future.

gbjbaanb
  • 48,749
  • 7
  • 106
  • 173
5

This feels like a special case of a more general question: is it a bad practice to disable UI features for specific reasons according to predefined rules? The answer, then, is "of course not." Date handing in particular can be tricky because dates and times are difficult, but on general principle there's no good reason to not do it if it's what your business requirements call for.

Mason Wheeler
  • 83,213
3

If the changes have to do with some specific business purpose that is date-sensitive, then it's a necessary evil.

If this is about deploying a revision to the program that will change the program permanently, and the old design will never be used again, then it's better to simply deploy an update at the correct time.

Robert Harvey
  • 200,592
2

Sounds fine. It is quite common to have UI's adapt to different users, e.g. here on stackoverflow different features are enabled or disabled based on the karma of an individual user.

The reason you don't like it is that it obviously adds complexity relative to a solution where everybody see the same UI. However the complexity seem to be essential complexity, ie. it a business requirement, not an artifact of a bad architectural decision. Of course it will have a cost (which you should communicate to the business), but if the business decide it is worth the cost, you go ahead an implement it.

Known risks: The biggest risk is probably to get the UI tested in the various configurations. If you start going down the road of enabling/disabling UI features for various groups of users, you can quickly get an explosion of possible configurations.

You should also make sure to implement the restrictions int the business logic layer, so you verify that customers cannot perform operations they are not allowed to, even if the UI should not make it possible in the first place:

JacquesB
  • 61,955
  • 21
  • 135
  • 189
2

What you're describing is the concept of effective dating, which is by no means a novel idea and at its core a type of temporal problem to which you could apply a temporal pattern.

Essentially what you would do in your database is apply an effective date to either form modules or form versions (herein referred to as components), storing some metadata about those components and their effective start/end dates. You'll of course need some data about your users in the application as well.

It sounds like you may have some other more compelling reasons to consider rewriting this application. If effective dating problems are your only problems, I'd suggest that perhaps implementing effective dating is a better option. If not, you'll have to evaluate that based on you scenario.

ravibhagw
  • 676
  • 4
  • 9
1

It's a feature toggle with activation based on the date -- which is perfectly valid. Imagine if the feature was only for use during a promotional period, or had to end when a new government regulation kicks in at a certain date.

You're working in APS.NET and JavaScript, but the Java feature-toggle frame work Togglz specifically has a date (and time!) based activation rule.

user11393
  • 119