Diálogos nativos
Selectores de fichero, confirmaciones y avisos: qué gana usar los del sistema, qué permiso conceden, y el detalle que casi nadie configura.
Los detalles que casi nadie configura
Las tres primeras son las que se notan a diario. Un selector sin filtros, que siempre empieza en el mismo sitio y que no propone nombre es exactamente el tipo de cosa que hace que una aplicación se sienta descuidada sin que nadie sepa decir por qué.
Guardar la última carpeta
Merece el detalle porque tiene un matiz:
- Una carpeta por tipo de operación, no una global. La última carpeta de la que abriste no es la última donde exportaste, y usar la misma para las dos es peor que no recordar ninguna.
- En el estado de interfaz, no en configuración. Nivel 44.1: son rutas absolutas, que no deben viajar a otra máquina.
- Y comprobar que existe antes de usarla: la carpeta pudo borrarse o estar en un disco desconectado, y pasarle una ruta inválida al selector produce comportamientos raros.
Confirmaciones y avisos
La otra familia de diálogos, y aquí la decisión es distinta:
El orden de los botones es la razón práctica de preferir el nativo para confirmaciones simples: cada sistema los coloca a un lado distinto, y un diálogo propio con el orden equivocado hace que la gente pulse lo que no quería — en el peor momento posible, que es al confirmar algo destructivo.
Bloquear o no
Un detalle de comportamiento: los diálogos nativos pueden ser modales de la ventana —bloquean tu ventana pero no el resto del sistema— o modales de aplicación.
Y hay una consecuencia práctica: mientras un diálogo está abierto, tu aplicación sigue viva y puede seguir haciendo cosas en segundo plano. Lo que no debería hacer es cambiar la interfaz debajo — si al volver del selector la pantalla ha cambiado, el usuario acaba de elegir un fichero para algo que ya no está ahí.