Procesamiento de lenguaje natural para selector de fechas

Nuestro selector de fechas y conversor es una función muy potente. Me encantaría ver cómo podemos simplificar la adición de una fecha/hora a una publicación. Una forma común de hacerlo es mediante el procesamiento del lenguaje natural. Aplicaciones como Fantastical en iOS llevan años utilizando esto para la entrada de fechas.

En lugar de manipular el ratón para ingresar una fecha, podrías escribir algo como:

  • lunes a las 2 pm, lo que generaría la fecha y hora en tu zona horaria.
  • el próximo viernes a las 10 am NZST, lo que generaría la fecha/hora del próximo viernes en NZST.
  • 11 am, lo que generaría la fecha de hoy a las 11 am.
  • 8/9 al 8/13, lo que generaría un rango de fechas.

Esto podría reemplazar el modal que se muestra al hacer clic en el ícono del calendario en el editor por un cuadro de texto (con un botón de «Avanzado» que muestre el contenido del modal actual) o bien un modal separado activado mediante un atajo de teclado.

9 Me gusta

Esta biblioteca podría ayudar con la implementación: GitHub - wanasit/chrono: A natural language date parser in Javascript · GitHub

Dicho esto, sospecho que sería un desafío lograr un soporte de idiomas robusto para esto.

Los idiomas totalmente compatibles actualmente son en, ja y fr (de y pt tienen soporte parcial). Otros idiomas de la versión 1 (nl y zh) están en desarrollo.


Además, otro patrón de UX a considerar es reemplazar automáticamente las cadenas de fecha en el cuerpo de una publicación con objetos de fecha/hora de Discourse. Algo así como la “caja única” pero para fechas. Por ejemplo, si escribo “el próximo lunes a las 2 p. m.” en mi publicación, se convierte automáticamente en 2021-08-17T18:00:00Z.

5 Me gusta

¡Me encanta esta idea!

3 Me gusta

Me gusta mucho esta idea, ¿puedes mostrarme la maqueta de la interfaz de usuario de cómo ves que funcionaría? Eso es lo que falta aquí.

Es posible que ni siquiera sea necesaria una interfaz de usuario. Cuando se publica una entrada, el PLN podría procesarla, volver al cliente y confirmar con una ventana modal simple:

Se encontró 1 fecha. ¿Desea convertir a marcas de tiempo dinámicas?
- martes a las 2 p. m. --> [fecha de discourse]

O podría ser más simple. Haga clic en el icono del calendario y, en lugar de un selector de fechas, será un cuadro de texto simple.

Y de manera similar a nuestra ventana modal de invitaciones, podría haber un botón para controles avanzados que muestre nuestro selector existente de fecha/hora/zona horaria para opciones más detalladas.

Supongo que es para que @j.jaffeux decida, ¿no estoy seguro de si eso encaja en absoluto con la interfaz de usuario actual que tenemos? ¿Tampoco estoy seguro de que la gente normal quiera escribir tanto en lugar de hacer clic, especialmente en un smartphone?

Tiene sentido en Google Calendar porque puedes hacerlo mientras escribes el nombre del evento, por ejemplo, en lugar de escribir

“Fontanero”

escribes

“Fontanero 15:00 - 17:00”

pero eso es fácil porque estoy en un dispositivo con teclado.

De hecho, encuentro que nuestro modal es tedioso de usar tanto en el escritorio como en el móvil, por eso sugerí esta función en primer lugar. Es significativamente más rápido escribir hoy a las 11:31 a. m. en un modal que usar las ruedas de desplazamiento o hacer clic en un modal grande. El hecho de que muchos calendarios ya hagan esto hace que sea una menor carga mental para que la gente lo entienda.

1 me gusta

Estoy de acuerdo en el escritorio. No estoy de acuerdo en el smartphone, porque escribir en el smartphone es brutal. ¿Quizás este podría ser un comportamiento solo para el escritorio?

1 me gusta

Personalmente, estaría bien con eso.

Hay mucho código en las fechas que en realidad ya hace esto, trabajamos en esto con @daniel

Básicamente, hay 3 maneras de resolver esto:

  • un mejor modal
  • algún !comando
  • análisis de texto

El análisis de texto es genial, pero no lo resuelve todo y además tenemos que hacer que funcione para todas las configuraciones regionales. Pero estoy de acuerdo en que podríamos habilitar el soporte para un pequeño subconjunto. Ya está casi todo aquí, solo tendría que terminarlo/habilitarlo.

5 Me gusta