Deprecating the first function, a compatibility strategy

It happened, a user reported that a function was behaving weird, she did date ( current date ) to record and the month value in the resulting record was wrong, it was 10 instead of 11.

As a programmer I noticed instantly, in the date _ to record implementation I forgot the fact that in Javascript Date.getMonth returns zero indexed months, that means January is 0 and December is 11.

I wanted to fix the error, but there are many users out there that may be using this function, how could I fix it without breaking existing visualizations?

My first quick idea was one I used in the past for other kind of migrations, when reading the visualization configuration next time, check if there's a call to the "old" version, if so, change it for a call to the "new" and fixed one.

There's a problem with that solution, if the user noticed the problem and used the month field somewhere else in the logic, the change will break that logic by having months from 2 to 13.

Building a program transformation that would detect and fix that is really hard, and I may introduce weird changes that will surprise users.

That's why I decided to introduce a new version of the function alongside the current one, they both have the same representation in the UI, from now on only the new one can be selected, but the old one will still be available for existing logic that uses it.

The only difference is that when displaying the old version, a warning sign will appear, on hover it will explain that this version had a problem and that you should select the new version and change any month + 1 logic you may have.

Here's an example with the old and new function one after the other, notice the month field in a and b on the left side.

/galleries/post-images/deprecate-fn.png

On mouse hover:

/galleries/post-images/deprecate-fn-tip.png

This was done in a generic way to deprecate other functions in the future the same way.

We will try hard to avoid having to use it.

Lost in Migration: Missing Gestures and a Proposal

The pains that remain are the missing freedoms

-- Liminar Manifesto

There's a tension between a clean, simple user interface that can be displayed in small screens and used with touch; and a discoverable and beginner friendly one that provides with hints, context and extra information to help new users discover an application's capabilities.

At instadeq, we try to provide hints, context, and extra information by [ab]using tooltips.

Almost every part that can be interacted with, sets the correct cursor and provides a tooltip, to be sure that the information is noticed by users we display the tooltips at the bottom right corner of our application.

This is done to avoid the "hover and wait" interaction to discover if something has a tooltip, and the "I accidentally moved my mouse and the tooltip went away" problem.

All of this careful considerations go out of the window when using an application on a touch device.

There's no hover support there, there's no cursor change to hint that the user can interact with a thing and because of this, there's no easy and standard way to display tooltips.

Many different ways have been proposed and used but even then the user has to discover those and learn an application specific way of doing it.

Thinking and talking about this on the vis.social [1] I came with an idea.

A new gesture to discover user interface components that want to provide more context about themselves.

For lack of a name let's call it the enquire gesture.

The idea behind the gesture is twofold:

  • To inquire about all the UI components that can provide more information about themselves
  • To inquire a specific component for its details directly

The gesture works with a shape we all know, the question mark: ?

The interaction goes as follows:

  • The user starts using an application, is on a new screen and doesn't know what is possible on that screen
  • The user draws the top part of the question mark anywhere on the screen (the part without the dot)
  • The 'inquire-all' event is triggered
    • Here the application can highlight the components that have contextual information
  • The user either waiting for the components highlight or continuing with the gesture taps the question mark's dot on the component he/she wants to know more about
  • The ('inquire', target) event is triggered where target is a reference to the component that was tapped
  • The application can then display more information about that component the way it prefers (tooltip, dialog, popover, embedded UI section)

This gesture not only provides a way to replace tooltips but also a way to "come back" to the tour that some applications implement.

The thing with the tour feature in some applications is that it happens when you want to jump straight to the application to play with it and/or don't have time/willingness to go through a lot of information that you don't know when or if you are going to need.

But at the same time, you are afraid that if you skip the tour you won't be able to go back to it whenever you want.

But then, when you go back, you hope there's a skip button so you can go to the place you are interested.

As you may realize, I don't like many things about the tour feature :)

With the enquire gesture, you can ask the application to highlight the "tour locations" and you can jump straight to the ones you are interested, in in the order you want, whenever you want.

So, here's my proposal for a new gesture to replace tooltips and the tour feature in a standard way, feedback and implementations welcome.

[1] vis.social is a social space for anyone in data, visualization, creative coding, and related arts and research, if you are interested join us!