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?

  • 13
    If your business domain requirements specify that some feature shall not be available to the user except within a particular time frame, then it's "by design." If you don't like the idea of ux controls appearing and disappearing, disable them instead of hiding them. Regardless, the technique is perfectly valid. – Robert Harvey Jun 2 '15 at 14:44
  • 1
    I find the phrase "business initiated after a certain date" unclear. Do you mean business with your company (for customers signing up after a certain date) or business initiated with your client (so your client can only do certain things with the data in their app if their client signed up after a particular date)? In the former case, you're talking about available features to your customers. In the latter case, you're talking about restricting invalid actions on certain data (based on conditions in the data itself). The answer might be very different in those circumstances. – jpmc26 Jun 3 '15 at 0:43

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.)

| improve this answer | |
  • 2
    The UI has no business knowing the business rule about what was published when -- Alright, but even Stack Exchange has such UI rules. For example, the "delete" link doesn't appear for other users on closed questions until two days have elapsed, and the Migration option is disabled after 60 days. – Robert Harvey Jun 2 '15 at 14:51
  • I clarified the question based on this answer: some controls are going to be removed, and others are will be added, depending on the date. – NMrt Jun 2 '15 at 14:53
  • 13
    @RobertHarvey, but how is it programmed in the view? Is it something like if (showDelete) { <button>delete</button> } or if ((post.date - today).days > 2) { <button>delete</button> }? – Arturo Torres Sánchez Jun 2 '15 at 17:49
  • @ArturoTorresSánchez: The former - the whole idea is to put the business logic (such as date calcluation) into the server. Anyway, this would make a good question of its own :-). – sleske Jun 11 '15 at 12:10

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)

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.

| improve this answer | |

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.

| improve this answer | |

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.

| improve this answer | |

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.

| improve this answer | |
  • 1
    "it's better to simply deploy an update at the correct time" Nitpick: Not necessarily... . For example, deployment may require downtime, which is not practical at the time the switch must be made. Or maybe there will be some period of parallel use... it really depends. – sleske Jun 11 '15 at 13:54
  • Or maybe you want to have a "play jingle bells" button on Christmas day. You may not want to have to deploy this every christmas. – sixtyfootersdude Jun 18 '15 at 21:40

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:

| improve this answer | |
  • Yes, testing is really tricky if the UI can change based on various factors. If it must be done, it must be done, but it helps to keep variation to a minimum - and to provide a way to toggle the UI for testing, independent of things like current date. – sleske Jun 11 '15 at 13:55

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.

| improve this answer | |

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.