Explore

Tareas periódicas

Una estrategia sencilla para lograr tareas recurrentes en Coda, un #CodaTutorial.

Pablo Felip

Motivación

En los últimos años he pasado de utilizar herramientas específicas de gestión de tareas y proyectos, como la magnífica

Asana⁠

, a montar mis propios “tinglados” usando otras más generales, como

Notion⁠

, tanto por lo que hace a mi productividad personal como profesional. Las enormes posibilidades de personalización de Notion, así como su capacidad para gestionar de un modo más flexible la información de contexto relevante en cada situación son para mí factores cruciales que han propiciado esta evolución.

⁠

No obstante, a menudo toda esa adaptabilidad trae consigo la ausencia de funciones y características para hacer ciertas cosas que con otras herramientas más específicas vienen resueltas de serie.

Hablemos de tareas.

Las fantásticas bases de datos de Notion disponen de propiedades de tipo fecha. Además, podemos insertar bloques de fecha en cualquier parte de una página por medio del comando /date o simplemente escribiendo una fecha precedida del símbolo @. Además, las fechas pueden convertirse fácilmente en recordatorios que emitirán notificaciones dirigidas al usuario en el momento programado.

⁠

Desafortunadamente, en estos momentos Notion no ofrece un modo simple y directo de construir una lista de tareas (con o sin recordatorios) periódicas. Cierto, existen soluciones muy creativas, como

las que propone Thomas Frank⁠

. Pero estos hacks, bien siguen requiriendo que el usuario realice acciones manuales tales como establecer la fecha del siguiente vencimiento de cada tarea recurrente con el valor que muestra un campo calculado auxiliar (inconveniente), bien utilizan servicios de automatización de terceros, como

Make⁠

, lo que a su vez conlleva introducir más partes móviles, susceptibles de fallo, en nuestros sistemas, así como considerar aspectos relativos a sus límites de uso y costes de servicio.

Crear una infraestructura potente de gestión de tareas no debería requerir tanta complicación. En mi opinión, si aplicaciones de tipo navaja suiza como Notion (o

Coda⁠

) desean aumentar su popularidad y alcance deberían pulir aspectos como este.

La dificultad estriba, supongo, en cómo gestionar la especificidad sin menoscabar la versatilidad, característica diferenciadora tanto de Notion como Coda.

Tal vez el punto intermedio se encuentre en la puesta a disposición de los usuarios de un conjunto rico de megabloques predefinidos, que pudieran ser invocados rápidamente y personalizados con facilidad para adaptarlos a cada situación, algo que de hecho Coda ya está haciendo muy bien con sus templates intra página.

☝️ Pero centrémonos en Coda:

⁠

En Coda no existe una equivalencia directa con los ⏰ recordatorios de los elementos de fecha de Notion, pero afortunadamente esta herramienta cuenta con suficientes superpoderes como para construir, sin demasiados líos ni servicios de terceros, algo que se parece bastante a una lista de tareas recurrentes. En este

#CodaTutorial⁠

veremos cómo lograrlo utilizando únicamente botones y fórmulas de acción y propondremos, finalmente, varias mejoras que llevarían la solución propuesta unos pasos más allá.

Implementación

Requisitos de diseño

El objetivo es crear una tabla simple de tareas en la que al completar una tarea de tipo recurrente se genere una nueva instancia correspondiente al siguiente vencimiento, en función de su periodicidad establecida, que podrá ser semanal, mensual o anual.

Optaremos por generar una nueva instancia de la tarea original, en lugar de simplemente actualizar su fecha de vencimiento, para que de ese modo exista constancia de las tareas anteriores que ya han sido marcadas como completadas, lo que parece aconsejable.

Además, deberemos tener en cuenta la circunstancia de que una tarea periódica ya completada puede ser marcada como no realizada por el usuario para posteriormente ser finalizada de nuevo. Evitaremos instancias duplicadas en ese caso comprobando previamente que no ha sido ya generada con anterioridad.

En resumidas cuenta, el comportamiento perseguido es este:

⁠

Campos

Este tutorial está lejos de pretender desarrollar la construcción de un sistema de gestión de tareas completo, así que para mantener las cosas simples crearemos únicamente los siguientes campos de datos (columnas) en nuestra tabla de tareas:

Hecho

Toggle

Permite marcar la tarea como completada.

Tarea

Text

Nombre de la tarea.

Instancia

Number

Se utiliza para diferenciar las distintas instancias de cada tarea recurrente, que se numerarán siguiendo una secuencia creciente desde 1. Todas las instancias de la misma tarea compartirán el mismo nombre (campo Tarea). Estel campo se

establecerá inicialmente

⁠

al valor 1 al crear una nueva tarea.

⁠

Estado

Formula → Text

Etiqueta automáticamente el estado de cada tarea de acuerdo con la fórmula que puedes ver a continuación, basada en la estructura de control condicional

SwitchIf()

⁠

, el valor de la columna Hecho de la tarea y la función

Today()

⁠

SwitchIf(

thisRow.Hecho, "Completada",

Today() = thisRow.Plazo, "Vence hoy",

Today() > thisRow.Plazo, "Con retraso",

Today() >= thisRow.Inicio, "Iniciada",

"Propuesta"

)

Personalmente creo que los sistemas de gestión de tareas en los que el estado se calcula de acuerdo con la información de contexto disponible, como es este el caso, son más elegantes que los que precisan que sea establecido manualmente por el usuario.

Inicio

Date

Registra la fecha en la que se ha comenzado a trabajar en la tarea.

Plazo

Date

Indica la fecha de vencimiento de la tarea

Se repite cada

Select list

La usaremos para especificar el tipo de periodicidad de la tarea, puede ser “Semana", “Mes”, “Año” o ”Nunca” (si no se repite). Por defecto se ajusta automáticamente al valor Nunca cuando se crea una tarea.

⁠

Veces

Number

Se utiliza para indicar el número total de instancias (repeticiones) que tendrá una tarea periódica. Si se deje en blanco se asumirá que la tarea se repetirá de manera indefinida, siempre y cuando se haya seleccionado algún tipo de periodicidad en el campo Se repite cada, claro está.

Última

Formula → Date

Muestra, tan solo con fines informativos, la fecha de vencimiento de la última instancia de una tarea periódica a partir de los valores de los campos Plazo, Se repite cada y Veces. Fíjate en el modo en que se ha integrado la potente función

WithName()

⁠

, por partida doble y de manera anidada, con

Switch()

⁠

para simplificar la parte de la expresión que determina el vencimiento final de cada tarea recurrente utilizando las variables plazoOriginal y repeticiones.

Por otro lado, usamos

SwitchIf()

⁠

en lugar de

If()

⁠

, en primera instancia, puesto que la primera función,a diferencia de la segunda, no exige que indiquemos el resultado cuando no se cumple la condición facilitada y en este caso preferimos no devolver nada cuando se da esa situación (si no hay plazo, no hay fecha de último vencimiento). Otro tanto ocurre en el segundo SwitchIf() que se utiliza para calcular el vencimiento para cada tipo de periodicidad.

SwitchIf(

Not(IsBlank(thisRow.Plazo)),

WithName(

thisTable

.Filter(

Tarea = thisRow.Tarea And Instancia = 1

)

.First()

.Plazo,

plazoOriginal,

WithName(

SwitchIf(

thisRow.Veces <= 1,

thisRow.Veces.isBlank(),

-1,

thisRow.Veces - 1

repeticiones,

SwitchIf(

thisRow.[Se repite cada] = "Semana" And repeticiones != -1,

plazoOriginal + 7 * repeticiones,

thisRow.[Se repite cada] = "Mes" And repeticiones != -1,

RelativeDate(plazoOriginal, repeticiones),

thisRow.[Se repite cada] = "Año" And repeticiones != -1,

Date(

plazoOriginal.Year() + repeticiones,

plazoOriginal.Month(),

plazoOriginal.Day()

)

El último vencimiento se calcula de tres maneras distintas, dependiendo del tipo de periodicidad:

Sumando días al primer vencimiento (periodicidad semanal).

Usando la función

RelativeDate()

⁠

, que añade el número de meses indicado a una fecha dada (periodicidad mensual).

Desmontando la fecha del primer vencimiento e incrementando el número de años (periodicidad anual).

There are no rows in this table

⁠

Formato condicional

Para facilitar la revisión de las tareas se ha aplicado también formato condicional sobre la tabla (Tabla → Options → Conditional format) de modo que cada fila se coloreará en función del valor de la columna Estado: Propuesta / Completada / Vence hoy / Con retraso / Iniciada.

Para ello se han utilizado cinco reglas similares a esta, que no tienen mayor misterio:

⁠

Botones y acciones

Para que el mecanismo encargado de gestionar la generación de tareas recurrentes funcione correctamente necesitaremos un par de botones, que el usuario deberá utilizar para:

✔️ Completar una tarea.

✖️ Revertir la acción anterior, si fuera necesario.

¿Pero por qué razón precisamos de estos botones para marcar o desmarcar una tarea como completada? Después de todo la tabla ya cuenta con un campo Hecho, que contiene un interruptor accionable para ello.

Muy sencillo, porque a diferencia del #CodaTutorial anterior, en el que construíamos tablas dotadas con la capacidad de autoborrado de registros...

⁠

Tablas con autoborrado Automatizaciones de borrado automático de datos para las tablas de Coda, un breve #CodaTutorial. coda.io⁠

⁠

...en esta ocasión pretendemos resolver el problema eludiendo las potentes

automatizaciones⁠

de Coda, que pueden desencadenarse por tiempo o cuando se modifican los datos de una tabla, pero que no obstante presentan ciertos

límites mensuales⁠

condicionados por el plan de precios que se haya contratado. Como los botones son entidades reactivas, podremos ejecutar así las fórmulas de acción que necesitemos todas las veces que haga falta, sin preocuparnos por tropezar con eventuales límites de servicio.

Así pues, cuando el usuario pulse el botón...

⁠

⁠

1️⃣ Se modificará el estado del interruptor del campo Hecho de la tarea, de manera que indique que está completada.

Esto, a su vez, provocará el recálculo del campo Estado y la activación de la regla de formato condicional que depende de él.

2️⃣ Se comprobará si la tarea es periódica, tiene plazo y aún no se ha alcanzado el último vencimiento ni generado su siguiente instancia recurrente.

3️⃣ Si se dan todas las condiciones anteriores, se duplicará la tarea actual, asignándole el número de instancia siguiente en la serie y se actualizará como corresponde su nueva fecha de vencimiento, para cuyo cálculo se contemplarán las tres posibles periodicidades de las que ya hemos hablado al discutir el funcionamiento de la fórmula que calcula la columna Última.

Esta es la fórmula de acción que necesitaremos para hacer todo eso:

RunActions(

ModifyRows(thisRow, thisRow.Hecho, true),

SwitchIf(

And(

thisRow.[Se repite cada].In("Semana", "Mes", "Año"),

Not(thisRow.Plazo.IsBlank()),

thisRow.Veces > thisRow.Instancia Or

thisRow.Veces.IsBlank(),

Not(

thisTable.Filter(Tarea = thisRow.Tarea)

.Instancia

.contains(

thisRow.Instancia + 1

)

AddRow(

thisTable,

thisTable.Tarea,

thisRow.Tarea,

thisTable.Instancia,

thisRow.Instancia + 1,

thisTable.Plazo,

SwitchIf(

thisRow.[Se repite cada] = "Semana",

thisRow.Plazo + days(7),

thisRow.[Se repite cada] = "Mes",

RelativeDate(thisRow.Plazo, 1),

thisRow.[Se repite cada] = "Año",

Date(

thisRow.Plazo.Year() + 1,

thisRow.Plazo.Month(),

thisRow.Plazo.Day()

)

thisTable.[Se repite cada],

thisRow.[Se repite cada],

thisTable.Veces,

thisRow.Veces,

thisTable.Hecho,

False

)

⁠

⁠

1️⃣ En este caso únicamente modificaremos el estado del interruptor del campo Hecho de la tarea, indicando que no está completada.

Se usará esta sencilla fórmula de acción:

ModifyRows(thisRow, thisRow.Hecho, false)

El resultado

Esta es la tabla de tareas recurrentes que resulta tras aplicar todas las decisiones de diseño previas . Está viva, así que puedes jugar con ella para comprobar que se comporta del modo esperado.

⁠

✔️

✖️

Tarea

Instancia

Estado

Inicio

Plazo

Se repite cada

Veces

Última

Hecho

Tarea 1

Con retraso

07/07/2022

06/08/2022

Tarea 2

Con retraso

10/07/2022

Semana

31/07/2022

Tarea 3

Con retraso

05/07/2022

14/07/2022

Mes

14/09/2022

Tarea 4

Con retraso

01/08/2022

Año

01/08/2023

There are no rows in this table

⁠

Recuerda que el interruptor del campo Hecho, en la columna situada en el extremo derecho de la tabla, no debe ser utilizado directamente por el usuario, por lo que lo aconsejable es ocultarlo haciendo clic en Tabla → Columns → Visible columns → 👁️ Hecho.

Comentarios y siguientes pasos

Lo bueno de construir cosas con Coda es que en cuanto das algo por aparentemente terminado se te ocurre cómo mejorarlo. Bien pensado, tal vez sea un maldición 😏.

Nuestra lista de tareas recurrentes no es una excepción. Aquí van 4️⃣ mejoras que te lanzo, así a modo de desafío, para que las implementes, si te apetece. O como mínimo pienses un poco en ellas.

1️⃣ Mejorar los ajustes para definir la periodicidad:

Dos propuestas aquí:

Nuestra tabla soporta tareas que se repiten de manera semanal, mensual o anual. Pero no hemos previsto un mecanismo que permita crear fácilmente tareas que se repitan determinados días de la semana. Probablemente las fórmulas necesarias se van a complicar un poco, pero estoy seguro de que, no sin cierto análisis previo, es perfectamente posible lograrlo.

Estaría bien permitir, de manera alternativa al establecimiento del número de veces que se repetirá una tarea, la definición de una fecha límite tras la cual la tarea dejará de repetirse. En nuestra tabla de hecho ya mostramos la fecha de la última repetición programada, que te recuerdo se calcula a partir de las columnas que indican el número de repeticiones, la primer vencimiento y el tipo de periodicidad.

2️⃣ Introducir un sistema de notificaciones:

Para que los responsables de cada tarea (por cierto, nuestra tabla no identifica responsables, una cosa más que añadir) reciban notificaciones con antelación a su vencimiento será inevitablemente necesario, ahora sí, emplear las automatizaciones integradas en Coda, concretamente las que se ejecutan por tiempo.

Podríamos crear una automatización que:

Se ejecute todos los días a las 00:00h.

Revise las fechas de vencimiento de las tareas pendientes.

Identifique las tareas con vencimientos próximos, pongamos en los próximos ¿7 días?

Informe a las personas a cargo usando la función

Notify()⁠

o el

Pack de Gmail⁠

⁠

3️⃣ Generar repeticiones de las tareas sin usar botones:

⁠

Ya sabes que hemos optado por utilizar botones para no tener que depender de los probables límites de uso mensuales de las automatizaciones de Coda. Ya sabemos que hay una vida mejor, que suele ser más cara, pero no todo el mundo tiene que estar dispuesto a pagar por ella, claro.

Eso nos ha obligado a discurrir una pequeña astucia: utilizar el campo auxiliar Hecho para hacer carambola sobre la propiedad Estado de las tareas cuando estas se marcan como completadas o no completadas, algo que no tendría por qué ser estrictamente necesario.

El diseño alternativo pasa por tanto por tirar de esas automatizaciones, concretamente de las que se activan cuando cambia el estado de finalización de una tarea, para resolver esto de otro modo, tal vez más fino (esto es cosa de opiniones).

4️⃣ Mejorar la robustez del sistema

Como puedes ver, la fórmula que genera las nuevas instancias de una tarea periódica utiliza los valores de los campos Plazo y Veces, que se arrastran a lo largo de toda la serie. Además, todas esas instancias recurrentes quedan únicamente relacionadas entre sí por el nombre (campo de texto Tarea) y ordenadas en secuencia mediante los valores que escribimos en el campo numérico Instancia.

Esta estrategia es funcional, pero no podemos considerarla extraordinariamente robusta. Si esos campos se alterasen accidentalmente, el castillo de naipes se desmoronaría, por lo que conviene dificultar, si no impedir, las ediciones erróneas sobre ellos, en la medida que sea posible.

Y eso no es todo, hay otros problemillas menores en la solución propuesta que sin embargo te dejo para que descubras tú mismo.

Cierto es que esta fragilidad es inherente a muchos sistemas creados con Coda (o con otras herramientas similares), en los que resulta a menudo complicado aislar el armazón que les dota de consistencia (valores auxiliares, fórmula, etc.) de los propios datos que introducen y manipulan los usuarios. Y tiene mala solución, hasta donde yo sé, pero no quería dejar pasar la oportunidad de poner esta circunstancia sobre la mesa dado que me parece significativa.

💡 Y a ti, ¿se te ocurre algún otro modo de mejorar la gestión de tareas recurrentes?

⁠

Aunque puedes interactuar desde ya mismo con este documento (los cambios no se guardarán), lo ideal es que hagas una copia de él para poder destriparlo y modificarlo con total libertad.

⁠

¡Quiero una copia!

⁠

¿No tienes cuenta?

Registro

⁠