Encuentre la solución JavaScript adecuada con una prueba de 7 pasos

 

 

 

  • ¡Registro!
  • Deploy Fast. Deploy Smart

  • Índice
    1. No es sobre ti
    2. Presentamos la prueba de 7 pasos para widgets de JavaScript
    3. 1. ¿Qué sucede si se desactiva JavaScript?
    4. 2. ¿Cómo cambiar la apariencia, la sensación y el contenido?
    5. 3. ¿Qué tan utilizable y semántico es el producto final?
    6. 4. ¿Entiendes lo que está pasando?
    7. 5. ¿Funciona bien con los demás?
    8. 6. ¿Qué tan dedicado es el mantenedor?
    9. 7. ¿Existe un plan de prueba? ¿Es fácil actualizarlo y ampliarlo?
    10. Una última palabra sobre el tamaño

    Christian Heilmann explica en este artículo cómo obtener más información sobre la solución JavaScript adecuada. Sin embargo, antes que nada, es importante comprender lo que significa desarrollar para la Web.

     

    Como desarrolladores y diseñadores web, tenemos muchas opciones para elegir en este momento. Para crear una aplicación web compleja o incluso simplemente darle vida a un sitio web con algún elemento de interfaz altamente interactivo, tenemos cientos de soluciones prediseñadas para elegir. Cada biblioteca viene con widgets y soluciones, y cada desarrollador intenta hacerse un nombre lanzando una solución original de JavaScript para un determinado problema de interfaz. Podemos elegir entre decenas de menús, carruseles de imágenes, pestañas, validadores de formularios y “lightboxes”.

    Tener tantas opciones nos facilita elegir, que es donde las cosas van mal. En la mayoría de los casos, medimos la calidad de una solución por su conveniencia para nosotros. Nuestras principales razones para elegir una solución sobre otra son:

    • ¿Hace lo que necesito que haga?
    • ¿Se ve genial?
    • ¿Suena fácil de usar?
    • ¿Querría usarlo?
    • ¿Utiliza el marco con el que estoy comprometido?

    Sin embargo, las cosas que realmente deberías buscar son diferentes:

    • ¿Qué tan estable es la solución? ¿Hay una buena alternativa disponible si ésta no funciona?
    • ¿Qué tan fácil es personalizar? ¿Necesitas ser un experto en JavaScript para modificar el widget?
    • ¿Qué tan utilizable y accesible es? ¿Están bloqueados los usuarios que no tienen ratón o están en un navegador móvil?
    • ¿Entiendes lo que está pasando? ¿Serías capaz de solucionar un problema y explicárselo a los demás?
    • ¿Es una solución contenida? ¿Podrán otros scripts interferir con él o contaminarían el documento?
    • ¿Qué tan dedicado es el desarrollador? ¿Se mantendrá la solución en el futuro?
    • ¿Qué es compatible y cómo se puede ampliar la funcionalidad? ¿Siempre hay una nueva solicitud de navegador y cliente a la vuelta de la esquina?

    En este artículo, mostraremos algunas formas de obtener más información sobre estos temas. Sin embargo, antes que nada, es importante comprender lo que significa desarrollar para la Web.

     

    No es sobre ti

    La mayoría de las razones por las que elegimos una solución particular de inmediato tienen mucho que ver con nosotros, y aquí es donde pisamos hielo fino. No consumimos lo que ponemos en la Web; más bien, lo hacen personas que no conocemos, y no podemos hacer suposiciones sobre su capacidad, configuración, comprensión técnica o gusto. No haremos que nuestro producto sea un éxito; solo lo construimos y, por lo tanto, somos los peores probadores posibles.

    He estado desarrollando profesionalmente para la Web durante más de 10 años, trabajando en todo, desde blogs personales hasta soluciones CMS empresariales multilingües y aplicaciones web complejas, y he aprendido una cosa en el camino: nunca construyas para ti o para el resto. cliente . En su lugar, construya para las personas que usarán el producto y para la persona pobre que tendrá que hacerse cargo del proyecto cuando usted se vaya.

    Por mucho que tengamos que actuar ahora para minimizar nuestra enorme huella de carbono, debemos dejar atrás una Web más limpia. Para que la Web siga siendo un mercado próspero y un entorno de trabajo sostenible, tenemos que cambiar la forma en que trabajamos en ella y dejar atrás soluciones inmantenibles, infladas y semiviables, aunque bonitas. Tenemos que facilitar a las personas el uso de aplicaciones web y evitar que otros desarrolladores pierdan horas tratando de entender lo que hicimos cuando se les pide que lo cambien o lo amplíen en una etapa posterior.

    Presentamos la prueba de 7 pasos para widgets de JavaScript

    Con este fin, he preparado una prueba de siete pasos para aplicarla a cualquier widget listo para usar que encuentre. Todas las recomendaciones tienen un fundamento, así que reflexione sobre ello antes de descartar los argumentos como “elitistas” o “no realmente adecuados para nuestro entorno”.

    No olvidemos que incluso cuando algo es gratuito, su desarrollador intentará vendérselo por la fama, y ​​muchas soluciones se defienden con uñas y dientes en las listas de correo en lugar de cambiarlas o actualizarlas. La razón es que, como desarrolladores, siempre estamos en movimiento. Mantener y ampliar una solución antigua no es tan atractivo como crear una nueva y atractiva. Esto lleva a ruinas que alguna vez disfrutaron del amor cuando eran lo último en tecnología pero que ahora se oxidan en Internet.

     

    Para mejorar cualquier solución lista para usar, utilizo principalmente una herramienta: la barra de herramientas para desarrolladores web de Firefox. Está disponible en el sitio web del complemento de Firefox y le brinda una manera fácil de probar lo que sucede en el widget de su elección.

    Bien, aquí va: siete cosas para probar al decidirse por una solución JavaScript.

    1. ¿Qué sucede si se desactiva JavaScript?

    La primera prueba que hago con cualquier widget es desactivar JavaScript... no después de que el documento se haya cargado sino antes. Desactivar JavaScript con la barra de herramientas del desarrollador web es muy fácil. Simplemente seleccione "Desactivar todo JavaScript" en el menú "Desactivar" y vuelva a cargar la página:

    La razón es que hay muchas razones por las que no se puede utilizar JavaScript: los servidores proxy de la empresa o los firewalls personales podrían filtrarlo, otros scripts podrían crear errores y alterar el suyo, o el sistema en uso podría simplemente no tener JavaScript habilitado. Piense en entornos móviles, por ejemplo.

    No necesita funcionalidad completa cuando JavaScript no está disponible, solo una interfaz funcional que no sobrecargue a los usuarios y elementos interactivos que funcionen. Si un botón no hace nada cuando los usuarios lo activan, esos usuarios dejarán de confiar en usted; después de todo, no has cumplido tus promesas.

    La sobrecarga es otro problema. Muchos widgets utilizan CSS y JavaScript para comprimir una gran cantidad de contenido en un espacio muy pequeño: piense en elementos de contenido con pestañas y carruseles de imágenes. ¿Cuál debería ser su alternativa? Si desactiva JavaScript y tiene 50 imágenes donde planeó 2, entonces sería una buena experiencia de usuario. Una mejor alternativa sería una solución del lado del servidor para la misma funcionalidad o mostrar las 2 primeras y luego ofrecer un enlace a una página de galería con las imágenes restantes.

    A veces, el JavaScript para un widget en particular es realmente muy bueno, pero los sitios web de demostración se han hecho mal. Ocultar elementos con CSS y luego revelarlos con JavaScript, por ejemplo, es muy común. Pero si JavaScript está desactivado, la solución fallará. Las buenas demostraciones y soluciones utilizan JavaScript para agregar una clase al cuerpo del documento y hacer que todo el CSS dependa de esa clase.

    El truco que debería hacer cualquier buen widget de JavaScript es hacer que cualquier funcionalidad dependa de JavaScript mediante el uso de JavaScript; De esa manera, nunca tendrás ninguna funcionalidad que no funcione. Esta técnica se llama "JavaScript discreto" y hace un tiempo escribí un curso sobre ella y establecí algunas reglas.

     

    2. ¿Cómo cambiar la apariencia, la sensación y el contenido?

    Es complicado mantener un widget cuya apariencia está codificada. No puede esperar que los futuros diseñadores sepan cómo cambiar un determinado color buscando en sus archivos JavaScript. Así es como terminamos con archivos CSS inflados, porque la gente agrega ID y clases aleatorias para mejorar la especificidad de sus selectores de CSS.

    Los buenos widgets tienen su apariencia contenida en un archivo CSS y le brindan identificadores (es decir, clases aplicadas dinámicamente) para aplicar su propio estilo. Si tiene que cambiar JavaScript para cambiar la apariencia, deberían sonar las alarmas en su cabeza.

    Esto empeora si tiene contenido como etiquetas de texto en JavaScript o si solo se puede mostrar una cantidad fija de elementos (como en el caso de los menús de navegación). Las etiquetas y la cantidad de elementos son lo que más cambia en cualquier producto Web. Para empezar, probablemente lanzará su producto en diferentes mercados y tendrá que traducir los botones y menús.

    Los buenos gadgets tienen objetos de configuración que le permiten cambiar la cantidad de elementos y definir las etiquetas de texto sin tener que cambiar el JavaScript principal. La razón de esto es que la parte funcional del widget debe estar separada del mantenedor. Si el widget tiene un problema de seguridad o rendimiento, debería poder reemplazarlo sin perder su trabajo de configuración y localización. De lo contrario, es muy probable que la gente mantenga código inseguro en la Web, que es una de las razones por las que nuestras bandejas de entrada están llenas de spam.

    3. ¿Qué tan utilizable y semántico es el producto final?

    Muchos creadores de widgets están muy contentos de anunciar que sus productos “cumplen con los estándares web” y son accesibles gracias a ello. Si bien el cumplimiento de los estándares web es importante, no indica la calidad o utilidad del producto. Realmente no se puede validar la semántica con una herramienta automatizada. Por ejemplo, los siguientes ejemplos son HTML válido:

    div div spanAnimals/span div divGiraffe/div divDonkey/div divCheetah/div divHippo/div /div /div div spanStones/span div divDiamond/div divRuby/div divOnyx/div /div /div/div
    ul libuttonAnimals/button ul lia href="giraffe.html"Giraffe/a/li lia href="donkey.html"Donkey/a/li lia href="cheetah.html"Cheetah/a/li lia href="hippo.html"Hippo/a/li /ul /li libuttonStones/button ul lia href="diamond.html"Diamond/a/li lia href="ruby.html"Ruby/a/li lia href="onyx.html"Onyx/a/li /ul /li/ul

    El segundo ejemplo funciona sin JavaScript y utiliza mucho menos HTML. También requiere mucho menos CSS para diseñar porque simplemente aprovecharías la cascada. Innovacion y creatividad

    Además, el HTML en el que se basa el widget es sólo la mitad de la historia. Lo que genera JavaScript también debe ser válido, utilizable y accesible, y puede comprobarlo cuando consulte la fuente generada en la barra de herramientas del desarrollador web.

    Para hacer esto, haga clic derecho en cualquier parte del documento y seleccione Desarrollador web → Ver código fuente → Ver código fuente generado :

     

    La usabilidad y la accesibilidad (la accesibilidad es, en esencia, simplemente una comprensión más integral de la usabilidad) son más difíciles de probar. Pero una muy buena prueba es comprobar qué tan accesible es un widget mediante el teclado. Los usuarios que solo usan teclado están en aumento y los widgets que funcionan solo con eventos al pasar el mouse no se podrían usar en un móvil con pantalla táctil, por ejemplo. Muchos widgets proporcionan acceso básico al teclado (por ejemplo, usar la Tabtecla para saltar de un enlace a otro y la Entertecla para activar cada uno), pero esta no es una accesibilidad adecuada.

    Por ejemplo, no se debe navegar por un menú tabulando cada uno de los elementos porque esto requeriría demasiadas pulsaciones de teclas. En cambio, el usuario debería poder desplazarse a la barra de menú principal y desde allí usar las teclas del cursor para navegar.

    Una ventana emergente modal (comúnmente llamada caja de luz) debería poder cerrarse con un teclado presionando la Escapetecla o presionando el botón "Cerrar". Si se trata de una caja de luz de varios elementos, también debería poder navegar por los elementos con las teclas del cursor.

    Los sitios web WAI del W3C tienen excelentes ejemplos de cómo deberían reaccionar los widgets al uso del teclado, y Todd Kloots de Yahoo hace un gran trabajo al explicar las técnicas detrás de la buena usabilidad del teclado (también como video y usando YUI3 y enfocándose en WAI-ARIA). Patrick Lauke de Opera también escribió un excelente artículo sobre el tema e hizo una presentación en Future of Web Design del año pasado. Si es usuario de Mac, asegúrese de activar el acceso al teclado antes de declarar que un widget es defectuoso.

    Las personas también necesitan poder cambiar el tamaño del texto en su navegador. Pruebe los widgets en varios tamaños de texto. Usar Internet Explorer 6 para esto es importante porque es el principal culpable de los problemas de cambio de tamaño de fuente. Los navegadores más nuevos hacen un trabajo mucho mejor al hacer zoom en toda la interfaz, pero no se puede esperar que los usuarios finales sepan cómo usarlos.

    4. ¿Entiendes lo que está pasando?

    Si has leído los libros de Harry Potter (o incluso has visto las películas), sabes que no debes confiar en la magia sin saber lo que está pasando. Un libro que responde a tus escritos es tan sospechoso como un widget que hace algo tan sorprendente que no tienes idea de cómo sucedió.

    Recuerde, si el doo-dad deja de funcionar, se le pedirá que lo arregle o que explique qué salió mal. Por lo tanto, es importante conocer al menos los conceptos básicos de qué hechizo de JavaScript se lanzó para transformar una lista de imágenes en un carrusel lleno de canciones y bailes.

    Los buenos widgets tienen documentación técnica para ese tipo de cosas, y algunos incluso activan eventos personalizados que te avisan cuando algo está sucediendo. De esa manera, puede depurar la herramienta esperando estos eventos y analizando el estado actual. También le permite ampliar la funcionalidad, a la que volveremos en el paso 7.

    5. ¿Funciona bien con los demás?

    El mayor problema con cualquier JavaScript en la Web en este momento es que su modelo de seguridad otorga a todos los scripts de la página los mismos derechos. Esto significa que un script incorrecto puede arruinar toda la experiencia del usuario porque puede anular partes de otro script.

     

    Los lugares donde los scripts pueden chocar son los nombres y eventos de variables y funciones. Si su widget no protege sus variables y nombres de funciones o si aplica la funcionalidad de eventos a elementos sin verificar que otros scripts estén haciendo lo mismo, tendrá un problema.

    Digamos que tiene un elemento con ID menuy tiene un script que convierte su contenido HTML en un menú desplegable y otro que mejora los diferentes enlaces mostrando un hermoso mensaje desplegable. Si ninguno de estos scripts se agrega a la funcionalidad existente y simplemente lo aplica, tendrá un hermoso menú desplegable o un menú, dependiendo de qué script se aplica en último lugar.

    La buena noticia es que para los widgets que se basan en bibliotecas, este "choque de eventos" es muy poco probable porque las bibliotecas solucionan este problema de forma inmediata. Puede probar el problema de los nombres de funciones y variables que otros scripts pueden sobrescribir. JSLint es una herramienta y un sitio web donde puede comprobar JavaScript en busca de problemas sintácticos, como variables desprotegidas. Sin embargo, es una herramienta muy estricta y no todas sus advertencias son realmente un factor decisivo. Pero probar con JSLint es el sello distintivo de un desarrollador web profesional. Quieres que tu código funcione bien con los demás.

    6. ¿Qué tan dedicado es el mantenedor?

    Al elegir un widget, debe estar seguro de que el responsable del mantenimiento se dedica a mantenerlo actualizado y a corregir el script para futuros navegadores y entornos. Este rara vez es el caso, y una gran cantidad de software se publica con una declaración "tal cual", eximiendo al creador de cualquier responsabilidad por los problemas que pueda causar ahora o en el futuro.

    El software, especialmente el que se ejecuta en el navegador y para consumo web, tiene que evolucionar constantemente. Cosas que alguna vez fueron lo último en tecnología ahora pueden resultar torpes. Algunos programas resultaron tener un rendimiento deficiente o ser claros agujeros de seguridad.

    Siempre que la gente afirma que tenemos un excelente entorno básico en la Web para el espacio de pantalla y la potencia de procesamiento, aparece algo que lo desmiente. En este momento, probar procesadores de dos o cuatro núcleos con resoluciones a partir de 1280 puede ser normal para nosotros, los diseñadores, pero dadas las cifras de ventas de teléfonos inteligentes y netbooks, planificar para audiencias distintas a estas de gama alta podría ser una buena idea.

    Para los desarrolladores, el mantenimiento es la tarea más aburrida. Cuando lanzamos widgets increíbles al mundo, no queremos pensar en esa fase de entrega de software. Por supuesto, la mayoría de los widgets se lanzan como código abierto, pero lamentablemente no muchos desarrolladores reparan o mejoran el trabajo de otras personas; construir y lanzar algo casi idéntico pero ligeramente modificado es mucho más divertido.

    Como usuario del widget de otra persona, no querrás que esto te vuelva a la cara, por lo que necesitas ver cuán dedicado es el desarrollador. Algunas preguntas para hacer son:

    • ¿Existe una forma sencilla de informar errores?
    • ¿Hay rastros de mejoras y correcciones de errores?
    • ¿Existe un historial de comentarios y cambios en el widget basado en esos comentarios?
    • ¿Se ha utilizado el widget en escenarios reales, grandes proyectos o implementaciones similares a la suya? ¿Cuáles fueron las experiencias de quienes lo usaron?
    • ¿Tiene la solución una comunidad (es decir, hay algunas personas en listas de correo o en foros que se ayudan entre sí, en lugar de sobrecargar al desarrollador original)?

    Si el desarrollador no tiene un gran interés personal en el widget o no hay un grupo de desarrolladores o usuarios comerciales, entonces existe una alta probabilidad de que vea pocas o ninguna corrección o mejora en el futuro, y usted será responsable de respaldar el siguiente. Versión del navegador que se comporta mal.

     

    7. ¿Existe un plan de prueba? ¿Es fácil actualizarlo y ampliarlo?

    Una última cosa a considerar es lo que sucederá en el futuro. Las afirmaciones de que el widget “funcionará en todos los entornos” son falsas porque eso no se puede hacer. El gran poder de la Web es que las soluciones de software pueden adaptarse al entorno en el que se utilizan. Si utiliza Netscape 4, debería ver algunas imágenes; si utiliza el navegador Webkit más nuevo, debería ver un elegante carrusel de imágenes con animación y desvanecimiento; esa clase de cosas.

    Un buen widget tendrá un informe de prueba comprobado que cubrirá en qué navegadores y entornos se ha probado y cuáles son los problemas conocidos. Siempre habrá problemas y afirmar lo contrario es arrogante o ignorante.

    Actualizar su widget debería ser fácil e indoloro, y debería haber algunas versiones implementadas, siendo las nuevas versiones compatibles con versiones anteriores.

    Ampliar el widget debería ser fácil. Hablamos anteriormente sobre no limitarnos a una cantidad particular de artículos o una apariencia determinada. Pero si realmente usa un widget, encontrará que debe anular ciertas funciones y reaccionar ante varios cambios. Los buenos widgets tienen una API (una interfaz de programación para ampliarla) o activan eventos personalizados para que usted los escuche. Los eventos personalizados son "momentos interesantes" en la interacción de un usuario con el widget. Por ejemplo, un botón le indicará al script cuándo lo ha activado, y si escribe el widget de cierta manera, podrá decirle al mundo (o en este caso, a otros scripts) cuando le suceda algo. Puede notificar que se ha abierto un contenedor, que han regresado datos de la Web o que un menú era demasiado grande para mostrarse a la derecha y tuvo que moverse hacia la izquierda.

    Los widgets creados con la biblioteca de interfaz de usuario de Yahoo, por ejemplo, vienen con muchos eventos personalizados:

    Esto le permite monitorear lo que está sucediendo (por ejemplo, con fines de depuración) y ampliar la funcionalidad. La página de demostración del control Autocompletar, por ejemplo, muestra en una consola de registro a la derecha lo que sucede "debajo del capó" cuando se utiliza el campo de autocompletar.

    Al suscribirse a estos eventos en JavaScript, anular la funcionalidad original por algo nuevo es bastante fácil; en este caso, tenemos un autocompletado que devuelve fotos y te permite recopilarlas.

    Los eventos personalizados son una excelente manera de ampliar un widget y al mismo tiempo mantener el código principal fácil de actualizar.

    Una última palabra sobre el tamaño

    Una última cosa que mencionar: algunos desarrolladores de widgets utilizan un determinado argumento para defender su solución, pero que es totalmente irrelevante para su decisión: el tamaño.

    Los términos publicitarios como “Un menú desplegable en 20 líneas de JavaScript” o “Una caja de luz con todas las funciones en menos de 2 KB” son divertidos y buenos para el ego del desarrollador, pero en realidad no son una medida de la calidad de la solución. Si bien debes evitar soluciones JavaScript que sean masivas (digamos 100 KB), el código que se ha escrito para que sea muy genérico y fácil de ampliar siempre será más grande que el código que se ha escrito para cumplir un único propósito. Cualquier widget cuyo tamaño se pregone con orgullo y esté destinado a ser utilizado por personas que no son tan buenas en desarrollo como el propietario inicial, de todos modos crecerá con el tiempo. A los desarrolladores les gusta jugar al juego de los números, pero el código mantenible es diferente al procesamiento extremo de números.

    Quizás quieras echar un vistazo a estos artículos relacionados:

    • 50 herramientas útiles de JavaScript
    • Escribir JavaScript rápido y con memoria eficiente
    • 15 comprobaciones esenciales antes de lanzar su sitio web
    • Bibliotecas prácticas de JavaScript y complementos de jQuery

    (al, lu, il)Explora más en

    • Codificación
    • Pruebas
    • javascript





    Tal vez te puede interesar:

    1. Diez soluciones útiles de codificación CSS/JS para desarrolladores web
    2. 5 soluciones de codificación útiles para diseñadores y desarrolladores
    3. Cómo solucionar problemas de cambio de diseño acumulativo (CLS)

    Encuentre la solución JavaScript adecuada con una prueba de 7 pasos

    Encuentre la solución JavaScript adecuada con una prueba de 7 pasos

    ¡Registro! Deploy Fast. Deploy Smart Índice No es sobre ti

    programar

    es

    https://aprendeprogramando.es/static/images/programar-encuentre-la-solucion-javascript-adecuada-con-una-prueba-de-7-pasos-768-0.jpg

    2024-05-20

     

    Encuentre la solución JavaScript adecuada con una prueba de 7 pasos
    Encuentre la solución JavaScript adecuada con una prueba de 7 pasos

    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