Diseño de un cuadro de texto, íntegro

 

 

 

  • Implemente rápidamente. Implementar inteligentemente
  • SmashingConf Nueva York 2024

  • Índice
    1. Breve
    2. ¿Cómo se agrega una nueva línea?
    3. Estilo Atextarea
    4. Deslizamiento del alcance
    5. Compatibilidad del navegador y mejora progresiva
    6. Pruebas de usuario
    7. Diseñando el sobretipo

    Crear sitios web es difícil. Exploremos la creación de un componente de principio a fin, en el contexto de una realidad exagerada donde los proyectos no son perfectos.

     

    ¿Alguna vez has pasado una hora (o incluso un día) trabajando en algo para luego tirarlo todo y rehacerlo en cinco minutos? Esto no es sólo un error de código de principiante; es una situación del mundo real en la que puedes encontrarte fácilmente, especialmente si, para empezar, no se comprende bien el problema que estás tratando de resolver.

    Es por eso que soy un gran defensor del diseño inicial, la investigación de usuarios y la creación, a menudo, de múltiples prototipos, también conocido como el viejo dicho de "No sabes lo que no sabes". Al mismo tiempo, es muy fácil mirar algo que otra persona ha hecho, lo que puede haberle llevado bastante tiempo, y pensar que es extremadamente fácil porque tienes el beneficio de la retrospectiva al ver un producto terminado.

    Jen Simmons resumió muy bien esta idea de que lo simple es fácil mientras hablaba sobre CSS Grid y las pinturas de Piet Mondrian:

    “Me siento como estas pinturas, ya sabes, si las miras con la sensación de '¿Por qué es eso importante? Podría haberlo hecho.' Es como, bueno, sí, podrías pintar eso hoy porque estamos muy acostumbrados a este tipo de pensamiento, pero ¿habrías pintado esto cuando todo a tu alrededor era victoriano, cuando todo a tu alrededor era de otro estilo?

    Siento que esto resume la sensación que tengo al ver sitios web y sistemas de diseño que tienen mucho sentido; es casi como si el hecho de que tuvieran sentido significara que fueran fáciles de hacer. Por supuesto, suele ser todo lo contrario; Escribir el código es la parte más simple, pero lo que requiere el mayor esfuerzo es el pensamiento y el proceso que conlleva.

    Con eso en mente, voy a explorar la creación de un cuadro de texto, en una exageración de las situaciones en las que muchos de nosotros nos encontramos a menudo. Con suerte, al final de este artículo, todos podremos sentir más enfático sobre cómo el viaje desde el principio. terminar rara vez es lineal.

    Una guía completa para las pruebas de usuario

    Entonces crees que has diseñado algo que es perfecto, pero tu prueba te dice lo contrario. Exploremos la importancia de las pruebas de usuario.Leer un artículo relacionado →

     

    Breve

    Todos sabemos que una planificación cuidadosa y la comprensión de las necesidades del usuario son importantes para el éxito de un proyecto de cualquier tamaño. También sabemos que con demasiada frecuencia sentimos la necesidad de apresurarnos para diseñar y desarrollar nuevas funciones rápidamente. Esto a menudo puede significar que nuestro sentido común y nuestras mejores prácticas se olvidan mientras nos esforzamos por pasar rápidamente a la siguiente tarea de la eterna lista de tareas pendientes. Enjuague y repita.

    Hoy nuestra tarea es construir un cuadro de texto. Bastante simple, debe permitir al usuario escribir algún texto. De hecho, es tan simple que dejamos la tarea para el final porque hay muchas otras cosas importantes que hacer. Luego, justo antes de hacer las maletas para irnos a casa, sonreímos y escribimos:

    input type="text"

    ¡Aquí vamos!

    Oh, espera, probablemente necesitemos conectar eso para enviar datos al backend cuando se envíe el formulario, así:

    input type="text" name="our_textbox"

    Eso es mejor. Hecho. Tiempo de ir a casa.

    ¿Cómo se agrega una nueva línea?

    El problema con el uso de un cuadro de texto simple es que es bastante inútil si quieres escribir mucho texto. Para un nombre o título funciona bien, pero muy a menudo un usuario escribirá más texto del esperado. Créame cuando digo que si deja un cuadro de texto durante el tiempo suficiente sin una validación estricta, alguien pegará todo Guerra y paz. En muchos casos, esto se puede evitar teniendo una cantidad máxima de caracteres.

    Sin embargo, en esta situación, hemos descubierto que nuestra pereza (o mala priorización) de dejarlo para el último momento hizo que no consideráramos los requisitos reales. Solo queríamos hacer otra tarea en esa eterna lista de cosas por hacer y llegar a casa. Este cuadro de texto debe ser reutilizable; ejemplos de su uso incluyen un cuadro de entrada de contenido, un cuadro de notas estilo Twitter y un cuadro de comentarios de los usuarios. En todos esos casos, es probable que el usuario escriba mucho texto y un cuadro de texto básico simplemente se desplazaría hacia los lados. A veces eso puede estar bien, pero en general es una experiencia horrible.

    Afortunadamente para nosotros, ese simple error no tarda mucho en solucionarse:

    textarea name="our_textbox"/textarea

    Ahora, tomemos un momento para considerar esa línea. R textarea: Lo más simple posible sin eliminar el nombre. ¿No es interesante o es simplemente mi mente pedante que necesitamos usar un elemento completamente diferente para agregar una nueva línea? No es un tipo de entrada ni un atributo utilizado para agregar varias líneas a una entrada. Además, ¿el textareaelemento no se cierra automáticamente, pero sí una entrada? Extraño.

     

    Este “momento para considerar” me hizo viajar en el tiempo hasta octubre de 1993, rastreando las profundidades de la lista de correo de www-talk . Claramente hubo mucha discusión sobre el futuro de la web y lo que debería contener “HTML+”. Esto era 1993 y estaban discutiendo ideas como input type="range"la que no estuvo disponible hasta HTML5, y Jim Davis dijo:

    "Bueno, supongo que es descabellado, pero puedes usar formularios HTML como parte de la interfaz de un juego".

    Esto realmente demuestra que la web no fue pensada sólo para documentos como se cree ampliamente. Marc Andreessen sugirió tener input type="textarea"en lugar de permitir nuevas líneas en el tipo de línea única text, [diciendo]: ( https://1997.webhistory.org/www.lists/www-talk.1993q4/0200.html )

    "Hace que el código del navegador sea más limpio; deben manejarse de manera diferente internamente".

    Esa es una buena razón para separar textareael texto, pero aún así no es con lo que terminamos. Entonces, ¿por qué es textareasu propio elemento?

    No encontré ninguna decisión en los archivos de la lista de correo, pero al mes siguiente, el documento de discusión HTML+ tenía el textareaelemento y una nota que decía:

    “En el diseño inicial de los formularios, los campos de texto de varias líneas eran compatibles con el elemento INPUT con TYPE=TEXT. Desafortunadamente, esto causa problemas en los campos con valores de texto largos, ya que SGML limita la longitud de los literales de atributo. El DTD HTML+ permite hasta 1024 caracteres (¡el valor predeterminado de SGML es solo 240 caracteres!)”

    Ah, es por eso que el texto va dentro del elemento y no puede cerrarse automáticamente; no pudieron utilizar un atributo para texto largo. En 1994, textarease incluyó el elemento, junto con muchos otros de HTML+, como optionen la especificación HTML 2.

    Bien, eso es suficiente. Fácilmente podría explorar más los archivos pero volver a la tarea.

    Estilo Atextarea

    Entonces tenemos un valor predeterminado textarea. Si rara vez los usa o no ha visto los valores predeterminados del navegador durante mucho tiempo, es posible que se sorprenda. A textarea(hecho casi exclusivamente para texto de varias líneas) se parece mucho a una entrada de texto normal, excepto que la mayoría de los valores predeterminados del navegador tienen un estilo de borde más oscuro, el cuadro un poco más grande y hay líneas en la parte inferior derecha. Esas líneas son el controlador de cambio de tamaño; en realidad no son parte de la especificación, por lo que todos los navegadores lo manejan (juego de palabras absolutamente intencionado) a su manera. Por lo general, eso significa que no se puede cambiar el estilo del controlador de cambio de tamaño, aunque puede desactivar el cambio de tamaño configurándolo resize: noneen textarea. Es posible crear un identificador personalizado o utilizar pseudoelementos específicos del navegador, como ::-webkit-resizer.

     

    Un área de texto predeterminada sin estilo ( vista previa grande )

    Es importante comprender los valores predeterminados, especialmente debido a la capacidad de cambiar el tamaño. Es un comportamiento muy singular; el usuario puede arrastrar para cambiar el tamaño del elemento de forma predeterminada. Si no anula los tamaños mínimo y máximo, entonces el tamaño podría ser tan pequeño como 9px × 9px (cuando revisé Chrome) o tan grande como tengan paciencia para arrastrarlo. Eso es algo que podría causar un caos en el resto del diseño del sitio si no se tiene en cuenta. Imagine una cuadrícula en la que textareahay una columna y un cuadro azul en otra; El tamaño del cuadro azul lo decide exclusivamente el tamaño del archivo textarea.

    Aparte de eso, podemos abordar el estilo de textareala misma manera que cualquier otra entrada. ¿Quieres cambiar el gris alrededor del borde por gruesos guiones verdes? Claro aquí tienes: border: 5px dashed green;. ¿Quiere cambiar el estilo del foco en el que muchos navegadores tienen una sombra de cuadro ligeramente borrosa? Cambie el esquema; sin embargo, de manera responsable, ya sabe, eso es importante para la accesibilidad. Incluso puedes agregar una imagen de fondo textareasi eso te interesa (se me ocurren algunas ideas que habrían sido populares cuando el diseño esqueuomórfico era más celebrado).

    Deslizamiento del alcance

    Todos hemos experimentado cambios en el alcance de nuestro trabajo, ya sea un cliente que no cree que la versión final coincida con su idea o simplemente intentas hacer un pequeño ajuste y terminas tardando una eternidad en terminarlo. Entonces yo (disfrutando creando la personalidad de un gerente de proyecto exagerado que nos dice lo que necesitamos construir) he decidido que nuestro textareasimplemente no es lo suficientemente bueno. Sí, ahora es multilínea, y eso es genial, y sí, incluso "destaca" un poco más con su nuevo estilo. Sin embargo, simplemente no se ajusta a la vaga necesidad del usuario en la que acabo de pensar ahora después de que pensábamos que casi habíamos terminado.

    ¿Qué pasa si el usuario escribe miles de palabras? ¿O arrastra el controlador de cambio de tamaño hasta el punto de romper el diseño? Tiene que ser reutilizable, como ya hemos mencionado, pero en algunas situaciones (como un cuadro para tomar notas 'Twittereqsue'), necesitaremos un límite. Entonces la siguiente tarea es agregar un límite de caracteres. El usuario debe poder ver cuántos caracteres le quedan.

    De la misma manera que comenzamos con inputen lugar de textarea, es muy fácil pensar que agregar el maxlengthatributo resolvería nuestro problema. Esa es una forma de limitar la cantidad de caracteres que escribe el usuario; utiliza la validación integrada del navegador, pero no puede mostrar cuántos caracteres quedan.

    Comenzamos con HTML, luego agregamos CSS y ahora es el momento de algo de JavaScript. Como hemos visto, avanzar como un toro en una cacharrería sin detenernos a considerar los enfoques correctos puede realmente frenarnos a largo plazo. Especialmente en situaciones en las que se requiere una gran refactorización para cambiarlo. Entonces pensemos en este contador; debe actualizarse a medida que el usuario escribe, por lo que debemos activar un evento cuando el usuario escribe. Luego necesita verificar si la cantidad de texto ya tiene la longitud máxima.

     

    Entonces, ¿qué controlador de eventos deberíamos elegir?

    • change
      Intuitivamente, puede tener sentido elegir el evento de cambio. Funciona textareay hace lo que dice en la lata. Excepto que solo se activa cuando el elemento pierde el foco, por lo que no se actualiza mientras se escribe.
    • keypress
      El evento de pulsación de tecla se activa al escribir cualquier carácter, lo cual es un buen comienzo. Pero no se activa cuando se eliminan caracteres, por lo que el contador no se actualiza después de presionar la tecla de retroceso. Tampoco se activa después de copiar y pegar.
    • keyup
      Este se acerca bastante, se activa cada vez que se presiona una tecla (incluido el botón de retroceso). Por lo tanto, se activa al eliminar caracteres, pero aún no después de copiar y pegar.
    • input
      Éste es el que queremos. Esto se activa cada vez que se agrega, elimina o pega un carácter.

    Este es otro buen ejemplo de cómo usar nuestra intuición a veces no es suficiente. Hay tantas peculiaridades (¡especialmente en JavaScript!) que es importante considerar antes de comenzar. Entonces, el código para agregar un contador que se actualiza necesita actualizar un contador (lo cual hemos hecho con un intervalo que tiene una clase llamada counter) agregando un inputcontrolador de eventos al archivo textarea. La cantidad máxima de caracteres se establece en una variable llamada maxLengthy agregada al HTML, por lo que si se cambia el valor, se cambia en un solo lugar.

    var textEl = document.querySelector('textarea')var counterEl = document.querySelector('.counter')var maxLength = 200textEl.setAttribute('maxlength', maxLength)textEl.addEventListener('input', (val) = {var count = textEl.value.lengthcounterEl.innerHTML = ${count}/${maxLength}})

    Compatibilidad del navegador y mejora progresiva

    La mejora progresiva es una mentalidad en la que entendemos que no tenemos control sobre lo que el usuario ve exactamente en su pantalla y, en cambio, intentamos guiar el navegador. El diseño web responsivo es un buen ejemplo, donde construimos un sitio web que se ajusta para adaptarse al contenido en una ventana gráfica de tamaño particular sin configurar manualmente cómo se vería cada tamaño. Significa que, por un lado, nos importa mucho que un sitio web funcione en todos los navegadores y dispositivos, pero, por otro lado, no nos importa que se vean exactamente iguales.

    Actualmente, nos falta un truco. No hemos establecido un valor predeterminado sensato para el contador. El valor predeterminado actualmente es “0/200” si 200 fuera la longitud máxima; Esto tiene sentido pero tiene dos desventajas. La primera, a primera vista no tiene mucho sentido. Debe comenzar a escribir antes de que sea obvio que 0 se actualiza a medida que escribe. La otra desventaja es que 0 se actualiza a medida que escribe, es decir, si el evento de JavaScript no se activa correctamente (tal vez el script no se descargó correctamente o usa JavaScript que un navegador antiguo no admite, como la doble flecha en el código anterior). ) entonces no hará nada. Una mejor manera sería pensar detenidamente de antemano. ¿Cómo haríamos para hacerlo útil cuando funciona y cuando no?

     

    En este caso, podríamos hacer que el texto predeterminado sea "límite de 200 caracteres". Esto significaría que sin ningún JavaScript, el usuario siempre vería el límite de caracteres, pero simplemente no informaría sobre qué tan cerca están del límite. Sin embargo, cuando JavaScript está funcionando, se actualizará a medida que escriben y podría decir "200 caracteres restantes". Es un cambio muy sutil, pero significa que aunque dos usuarios pueden tener experiencias diferentes, ninguno obtiene una experiencia que parezca rota.

    Otro valor predeterminado que podríamos establecer es maxlengthen el propio elemento en lugar de hacerlo posteriormente con JavaScript. Sin hacer esto, la versión básica (la que no tiene JS) podría escribir más allá del límite.

    Pruebas de usuario

    Está muy bien probar en varios navegadores y pensar en las diversas permutaciones de cómo los dispositivos podrían servir el sitio web de una manera diferente, pero ¿pueden los usuarios usarlo?

    En términos generales, no. Siempre me sorprenden las pruebas de los usuarios; La gente nunca usa un sitio como usted espera que lo haga . Esto significa que las pruebas de usuario son cruciales.

    Es bastante difícil simular una sesión de prueba de usuario en un artículo, por lo que, para los fines de este artículo, me centraré únicamente en un punto con el que he visto a los usuarios tener dificultades en varios proyectos.

    El usuario escribe felizmente, le quedan 0 caracteres y luego se queda atascado. Olvidan lo que estaban escribiendo o no se dan cuenta de que había dejado de escribir.

    Esto sucede porque no hay nada que le indique al usuario que algo ha cambiado; Si están escribiendo sin prestar mucha atención, entonces pueden alcanzar la longitud máxima sin darse cuenta. Esta es una experiencia frustrante.

    Una forma de resolver este problema es permitir la sobreescritura, por lo que la longitud máxima aún cuenta para que sea válido cuando se envía, pero permite al usuario escribir todo lo que quiera y luego editarlo antes de enviarlo. Esta es una buena solución ya que devuelve el control al usuario. Relatos Cortos

    Bien, entonces, ¿cómo implementamos la sobreescritura? En lugar de saltar al código, veamos la teoría. maxlengthno permite sobrescribir, simplemente deja de permitir la entrada una vez que alcanza el límite. Entonces necesitamos eliminar maxlengthy escribir un equivalente JS. Podemos usar el controlador de eventos de entrada como lo hicimos antes, ya que sabemos que funciona al pegar, etc. Entonces, en ese caso, el controlador verificaría si el usuario ha escrito más del límite y, de ser así, el texto del contador podría cambiar. decir "10 caracteres de más". La versión básica (sin JS) ya no tendría ningún límite, por lo que un término medio útil podría ser agregar al maxlengthelemento en HTML y eliminar el atributo usando JavaScript.

    De esa manera, el usuario vería que ha superado el límite sin que se le interrumpa mientras escribe. Aún sería necesario realizar una validación para garantizar que no se envíe, pero vale la pena el pequeño trabajo adicional para mejorar mucho la experiencia del usuario.

     

    Permitir al usuario sobrescribir ( vista previa grande )

    Diseñando el sobretipo

    Esto nos lleva a una posición bastante sólida: el usuario ahora puede utilizar cualquier dispositivo y obtener una experiencia decente. Si escriben demasiado, no los interrumpirá; en cambio, simplemente lo permitirá y los alentará a editarlo.

    Hay una variedad de maneras en que esto podría diseñarse de manera diferente, así que veamos cómo lo maneja Twitter:

    `` de Twitter

     

     

     



    SUSCRÍBETE A NUESTRO BOLETÍN 
    No te pierdas de nuestro contenido ni de ninguna de nuestras guías para que puedas avanzar en los juegos que más te gustan.



    Correo Electronico


    Diseño de un cuadro de texto, íntegro

    Diseño de un cuadro de texto, íntegro

    Implemente rápidamente. Implementar inteligentemente SmashingConf Nueva York 2024 Índice Breve

    programar

    es

    https://aprendeprogramando.es/static/images/programar-diseno-de-un-cuadro-de-texto-938-0.jpg

    2024-05-20

     

    Diseño de un cuadro de texto, íntegro
    Diseño de un cuadro de texto, íntegro

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20