Ha pasado mucho tiempo desde que abrí por primera vez un editor de HTML. En este tiempo he aprendido más cosas por testarudez que por capacidad y, este tipo de aprendizaje prueba-error2 es, sobre todo, frustrante. Sin duda, lo que yo habría agradecido más no son tanto los tutoriales como algún consejo de corazón, basado en la experiencia y no en lo que dice este o aquel consorcio.
Como se suele decir, haz lo que te gustaría que hiciesen por ti y aquí voy, mi humilde aportación para los que empezáis.
Repítelo como un mantra porque ese será el mayor de tus problemas, hacer que tus sitios web se vean bien en todos los navegadores de todos los sistemas operativos o casi…
Usar editores WYSIWYG puede estar bien pero procura comprobar las rutas de todas las partes de tu sitio no vaya a ser que el editor te haya hecho una mala pasada enlazandote con un archivo local. Por supuesto eso de comprobarlo sobre el sitio no suele funcionar ya que, desde tu ordenador, se verá divinamente. Con lo que volvemos al punto uno.
El HTML y el CSS son el fruto del trabajo de decenas de desarrolladores de todo el mundo, ellos saben más que tú y que yo, no tiene sentido inventar tu lenguaje o crear estilos sin ton ni son a base de clases y divs. Igual que deberías conocer el idioma que hablas deberías conocer todas las etiquetas a tu disposición y como usarlas.
Para seguir con el punto 3, aprende como funciona esto cuanto antes o todos tus “pequeños deslices” volverán para castigarte, sobre todo si tienes que editar una página html dentro de unos meses. Todos la liamos en ocasiones, si te sales mucho del guión déjate comentarios explicativos. No sabes lo fácil que uno olvida algunas cosas, lo que hoy es claro como el agua mañana seguramente será un jeroglífico de etiquetas.
Y dado que confío que entre mis queridos lectores haya gente más sabia y experimentada que yo, ahí os dejo los comentarios por si queréis dejar vuestro consejo a los más inexpertos.
Parece mentira que, con la importancia que tiene un dominio para un sitio web o una identidad corporativa, aún se puedan realizar estafas que acaban despojandote del mismo.
Publican hoy en Download Squad un interesante artículo sobre este tipo de timos, estafas y demás problemas que suelen surgir cuando la persona que quiere registrar el dominio tiene pocos conocimientos sobre la materia.
Entre las posibles situaciones que pueden acarrearnos problemas de este tipo, hay algunas que no van más allá del típico timo de toda la vida: esa ventajosa oferta (terriblemente ventajosa) que te llega de ninguna parte y te sugiere que cambies de tu registro actual a su servicio. Por supuesto, una vez transferido el dominio adios a la empresa, la oferta y la ventaja…
No obstante, más allá de estos “timos” existen otra serie de circunstancias más comunes e igualmente peligrosas:
Nadie está libre de encontrarse en una mala situación de estas, incluso tomando todas las precauciones (recordad el caso de aquel Carlos Sobera contra el otro), pero lo que queda claro es que el desconocimiento es el principal aliado de los desastres.
Sé que, en ocasiones, por comodidad preferimos dejar estas gestiones a terceros y dedicar nuestro tiempo a cosas más agradables pero ¿Sabéis el tiempo que puede llevar recuperar un dominio robado? En el caso de que se pueda recuperar, claro…
Para informaros de como recuperar un dominio “robado” leed el artículo original, en inglés, donde encontraréis unos cuantos enlaces y el procedimiento a seguir: Scammed out of your domain?
En Coding Horror han publicado un interesante artículo sobre las páginas de errores 404. Supongo que la mayoría (por no decir todos) los que seguis este blog sabéis perfectamente lo que significan: Página no encontrada.
Las páginas de error son frustrantes para nuestros visitantes, no encontrar algo que estaban buscando puede conducirles a abandonar nuestro sitio si no sabemos manejar los errores con elegancia. En Coding Horror nos dan 5 consejos, unos más sencillos de seguir que otros, para crear páginas 404 con sentido. Aquí tenéis una traducción libre y resumida de los mismos, con algunas aportaciones mías:
A esto me gustaría añadir que, por lo general, es menos frustrante para nuestros usuarios si nosotros mismos asumimos parte de la culpa de los errores. Llegar a una página de error ya es desagradable, cuanto más desagradable cuando parece que el que la escribió pensaba que si habías llegado a ella era porque eres tonto. Personalmente me crispa encontrarme errores que me instan una y otra vez a comprobar que he tecleado correctamente sin darme ninguna solución alternativa.
Finalmente, os dejo los enlaces que aparecían en el artículo original para que sigáis leyendo sobre el tema si os interesa:
Armonth ha hecho una traducción completa y literal del artículo, por si os apetece más leerlo completo en castellano aquí os dejo el enlace: Creando páginas de error 404 amigables para el usuario
Lo normal, cuando comenzamos con un sitio web, es que pensemos en él en un sólo idioma. No obstante, cada día es más común crear sitios en múltiples lenguajes, donde los usuarios puedan navegar en su idioma.
Hay muchas (muchísimas) consideraciones que hacer antes de lanzar una versión internacional de un sitio web (y seguramente las veremos más adelante). Una de las cosas que debemos plantearnos es ¿cómo vamos a plasmar en la URL las diferentes versiones internacionales?
Lo que, en principio, parece una tontería admite múltiples posibilidades. Todas con sus pros y sus contras, y todas dignas de ser bien estudiadas antes de tomar una decisión. En h3h, Brad Fults, ha hecho una revisión bastante exhaustiva de los 9 métodos disponibles: Designing URLs for Multilingual Web Sites
Para mí, de entre todas, las más sencillas y limpias son:
Estos días estoy volviéndome loca tratando de terminar mi portafolio web. Supongo que a todos nos pasa lo mismo, es dificil diseñar para uno mismo y muy facil perder el norte del diseño.
Como lado positivo, durante estos días he sumado unos cuantos puntos importantes a tener en cuenta a la hora de desarrollar nuestro portafolio.
Cuando creamos un sitio web es importante que nos aseguremos de que es accesible por cualquier usuario desde cualquier plataforma. No obstante, sobre todo a los diseñadores y desarrolladores de javascript, no nos gusta renunciar a las mejoras visuales y de usabilidad que nos pueden proporcionar ciertas técnicas. ¿Cómo podemos compaginar la accesibilidad de un sitio con las técnicas más avanzadas?
Existen dos respuestas: creando sitios web que se degraden aceptablemente o mejorando nuestros sitios paulatinamente.
La degradación aceptable (Graceful degradation) consiste en crear nuestros sitios web pensando en los usuarios de los principales navegadores y crear elementos que sustituyan a los no compatibles con navegadores antiguos o agentes de usuario no convencionales.
Un ejemplo claro de degradación aceptable es la inclusión de etiquetas <noscript> para los navegadores que no soportan Javascript.
La mejora progresiva (Progresive Enhancement) consiste en comenzar creando sitios simples, compatibles con todos los navegadores y agentes de usuario e ir introduciendo mejoras que, en caso de no ser compatibles, no provocarían cambios importantes en la página (salvo, por supuesto, la desaparición de algunas funciones no imprescindibles)
Ambos enfoques tienen sus pros y contras, para seguir indagando en el tema os recomiendo dos artículos, ambos en inglés:
Los que me conocéis ya lo sabéis, odio los sitios en Flash. Estoy segura de que hay muchas formas de utilizar Flash con sabiduría y buen gusto pero, desgraciadamente, los ejemplos de sitios que más sobresalen son los de los malos sitios. Por eso, Jamie Huskisson ha publicado una interesante lista de 21 cosas que puedes hacer para que tu sitio Flash de asco:
21 ways to make your Flash based site suck
De todos los «consejos», yo destaco especialmente:
3. Haz tu página en un pop-up con ancho fijo mediante Javascript
17. Usa tantas transiciones como puedas entre el contenido
20. La música debe volver a empezar siempre tras cargar una página
A todos nos ha pasado alguna vez. Estás diseñando una página y, por una razón u otra, no termina de verse bien. Hay algo que no funciona y estás tan atascado que, por mucho que lo intentes, no das con lo que es.
En SEOmoz, una vez más, nos dejan unos cuantos consejos para esos momentos: 8 Web design tactics to help you when you’re stuck.
De entre todos me apunto dos:
1. Diseña del interior al exterior: Olvidate un poco de la cabecera y comienza dando forma a los elementos del cuerpo. Es mucho más sencillo diseñar la cabecera cuando ya tienes una base sólida.
….
7. No recurras siempre a los mismos trucos. Que una cosa te haya funcionado bien en el pasado no significa que tengas que utilizarla siempre. Obligate a aprender formas nuevas de hacer las cosas
La etiqueta <title>, bien utilizada, es una excelente herramienta que nos ayudará a dar a conocer nuestro sitio web a los demás y nos permitirá facilitar las cosas a nuestros usuarios.
El W3C nos recomienda que estos títulos no tengan más de 64 caracteres y que sean descriptivos del contenido del sitio.
En principio, como su propio nombre indica, la etiqueta <title>, nos permite definir un título para nuestras páginas.
Para generar documentos válidos deberás incluir siempre una etiqueta title en la cabecera de tus páginas
…
Este título será el encargado de dar nombre a tu sitio web en numerosas situaciones, en la ventana del navegador, en los listados de favoritos, en el historial de navegación, en los resultados de los buscadores…
Todos cometemos errores alguna vez y estos son algunos de los más comunes a la hora de crear un título:
En las páginas estáticas es muy sencillo editar los títulos pero, todos los que usamos algún CMS tendremos que apoyarnos en plugins y «hacks».
Seguro que hay muchos más para otros CMS, si conocéis alguno interesante dejadlo en los comentarios.
Como me señalaba Rodolfo Pilas en los comentarios de 9 razones para no usar frames pueden existir proyectos en los que el uso de frames pueda resultar adecuado. Si no tienes más remedio que usar frames, al menos que sean accesibles y usables.
Por ejemplo:
…
Bienvenido a Nombredelsitio. Tu navegador no soporta frames y por ello tendrás que navegar por las diversas páginas de este sitio mediante los enlaces siguientes:
En el caso de los iframes deberás encerrar el contenido adicional entre las etiquetas <iframe> y éste sólo se mostrará a los usuarios cuyos navegadores no soporten frames.
Por ejemplo:
Esta página está bajo licencia libre
name y da información sobre su contenido o función con el atributo titlelongdesc de, al menos, uno de los marcos del framesetAdemás, como recompensa adicional, los buscadores podrán indexar tu sitio correctamente y mejorará tu posicionamiento.
Webmaster Libre es un blog de Alma Fernández Página alojada en Redcoruna