Un saludos amigos, ya tips y tutoriales sobre Markdown hay muchos, así que esta no será una publicación más que gira en torno a este tema, más bien será sobre como no se debería maquetar y sobre lo que pienso acerca de la maquetación de cara al futuro, sin más preámbulos comencemos.

Digamos que a nuestros Frontends (Ej: Ecency y PeakD) no les interesa mucho como se ven nuestras publicaciones y mucho menos como están estructuradas, la importancia recae en la experiencia visual del usuario (no de la máquina) y los 7 días de vida de cada publicación, ya que maquetes como maquetes no va a depender de un algoritmo o máquina que interprete tu maquetado, lo entienda y le asigne algún valor. Solo si se ve bonito, tiene un contenido de calidad y el networking que hayas realizado en la plataforma te recompenzarán

Pero que pasa si de cara al futuro las publicaciones después de 7 días se les diera la oportunidad de monetizarse de alguna forma, o si el algoritmo cambiara para que máquinas incluidas las IA pudieran hacer mejor uso de él, o mejor aún que por algún motivo quisieras ganar mejor exposición de tu trabajo en los indexadores como Google, y para cerrar con broche de oro digamos que quieres lanzar tu propia web o blog y quieres reciclar de forma automática tus post de hive.

Entonces te verías con una gran cantidad de post por actualizar que difinitivamente no cumplen con los estándares para estas máquinas que no tienen ojos, solo saben extraer el contenido y leerlo semánticamente.

Cuando maquetas con HTML puede que puedas hacer algo más personalizado, pero en los Frontends de hive lo hacemos con Markdown, ahora, esto solo es conveniente porque es muy intuitivo y limpio, pero trae consigo la perdida de la semántica que nos brinda el HTML y al final ese Markdown es traducido a HTML por nuestro Frontend que lo traduce según sus criterios, generando una gran cantidad de divs en una especie de espaguetis.

Teniendo en cuenta que nuestro Markdown va a carecer de semántica casi completamente en el HTML final, que es el que las máquinas(ej: indexadores como robots de Google) reconocen, e interpretan, tenemos que optimizar nuestra maquetación para que sea lo más legible posible para ellos y puedan competir con webs que usan el HTML en todo su esplendor.

¿Aspectos que influirían de forma negativa desde mi punto de vista?

Voy a tocar ahora algunos aspectos que he visto en post que influirían de forma negativa teniendo en cuenta lo expuesto anteriormente:

Idioma: Esto es mortal jjjj, por ejemplo Google podría tomar como contenido duplicado una publicación diciendo lo mismo en dos idiomas, o no tomarse bien la idea de tener dos idiomas en la misma página, ya que esto lo confunde y, por lo tanto, podría penalizar esa página y hacer que otras la sobrepasen en el ranking de posicionamiento.

Un amigo me dijo que PeakD había integrado un traductor o algo así, eso sería algo un poco menos doloroso para máquinas, pues el contenido, el usuario lo escribiría en un solo idioma y el usuario consumidor de dicho contenido, en caso de que necesite la traducción, utilizaría ese traductor (Igual lo hago yo con una extensión en el navegador) pero bueno.

Un problema con respecto a esto del idioma, que si no queda en nuestras manos, es que a estas máquinas debes decirles en que idioma está la página, referencia geográfica o cosas muy específicas que tú no tienes el control en tus publicaciones usando estos Frontends y que podrías tener si crearas tu propio blog personalizado. Esto se puede omitir, pero si hay una página fuera de hive que le especifique todos estos detalles tiene más posibilidades de llevarse mejor con el robot de indexación jjjj.

Si publicas en uno o varios idiomas en la misma publicación será tu decisión, según el público que quieras alcanzar y los resultados que quieras obtener, pero cabe destacar que tener una página con idiomas no está bien visto por los robots, así como estamos acostumbrados a hacerlo en Hive.

h1 o #: Por favor no pongan ninguno en sus publicaciones, este se reserva para el tema central de la página y ya está incluido por defecto por estos Frontends cuando pones el título en el editor a la hora de redactar tu publicación.

He visto publicaciones que luego de poner una imagen que encabeza la publicación, vuelven a poner el título antes de comenzar a escribir (Me incluyo), parece ser como en el editor, al título se le reserva un espacio separado del contenido, cuando estás redactando el contenido piensas que le falta el título o h1 jjj, pero no es así.

h2,h3,h4,h5,h6 #:En HTML, dada su idiosincrasia semántica, podríamos poner varios teniendo en cuenta que hay etiquetas para encapsular contenidos que giran en torno a un tema como, podríamos hacer algo como esto:

<section>
  <h2>Etiquetas comunes</h2>
  <p>Lala lalal l ala la lalallalaa...</p>
</section>

<section id="news">
    <h2>Etiquetas importantes</h2>
    <article>
        <p>Lala lalal l ala la lalallalaa...</p>
    </article>
</section>

Esto lo interpretaría una máquina de maravillas, ahora en nuestro Markdown si pusiéramos esto, se generaría el siguiente HTML:

<div><h2>Etiquetas comunes</h2></div>
<div><p>Lala lalal l ala la lalallalaa...</p></div>

<div><h2>Etiquetas importantes</h2></div>
<div><p>Lala lalal l ala la lalallalaa...</p></div>

Como puedes observar nuestro Frontend Ecency hizo de las suyas y cambio la semántica tan exquisita y comprensible para máquinas y puso estas div(s) que no le aportan ningún significado a nuestro contenido para que pueda ser interpretados por máquinas.

Teniendo en cuenta lo anterior, mi recomendación es que pusiéramos uno solo de cada uno, ya que no se puede encapsular como en HTML, pero si por alguna razón necesitas resaltar varios títulos secundarios, recomiendo hacerlo por orden, todos los h2 primeros que los h3 y así sucesivamente y no poner h3 primeros y después h2 y mucho menos algún h1 después de los anteriores. Podríamos en caso de necesitarlo hacer algo como lo siguiente:

## Etiquetas comunes

Lala lalal l ala la lalallalaa...

## Etiquetas importantes

Lala lalal l ala la lalallalaa...

### Etiquetas de monos azules

Lala lalal l ala la lalallalaa...

### Etiquetas de monos azules con manchas blancas jjj

Lala lalal l ala la lalallalaa...

Cosas extrañas que debemos evitar.

Señores los encabezados están reservados como su nombre indica para los "encabezados", debemos evitar cosas extrañas como la siguiente:

# 

## <center><div class="phishy">•••••••••••</div></center> 

# 

Esto genera una salida visualmente así :

•••••••••••

La verdad es que es un separador muy bonito, pero el código HTML que genera es este:

<h1></h1>
    <h2>
        <center>
             ============
        </center>
    <h2>
 <h1></h1>

Digamos que esto es spam en el lenguaje máquina y, por lo tanto, penalizado o simplemente no óptimo. Con tal de darle un estilo más agradable y bonito se nos olvidó o no tuvimos en cuenta la semántica o el propósito para cada etiqueta. En este caso creo que se buscaba tamaño y engrosar los separadores para qué resaltarán más, pero no creo que sea lo ideal, así que pienso que hay que evitar cosas como esas.

Podríamos usar este separador, en cambio, de la siguiente manera:

<center><div class="phishy">**•••••••••••**</div></center>

Y su resultado visual sería:

•••••••••••

Es cierto que pudiera ser un poco menos vistoso, pero sería una mejor forma de usar las etiquetas.

Otra que puede buscando el tamaño y el grosor que proporcionan las etiquetas de encabezado es que intentáramos poner todo un contenido dentro de ellas como lo siguiente:

<h5> 
<div class="pull-left">  

*Tristeza de las palabras alegres*

Risa mirando los errores del pasado. 
Alegría recordando a alguien que se ha ido. 
Amor de alguien que está lejos. 
Futuro el que soñaste cuando niño. 
Esperanza que se acaben las guerras en el mundo. 
Ayudar aquel que está desprovisto. 
Deseo que no exista el infierno. 
Anhelo los abrazos de un amigo. 

</div> 
</h5>

Esto generaría una salida visual así:

---

"Tristeza de las palabras alegres"

Risa mirando los errores del pasado.
Alegría recordando a alguien que se ha ido.
Amor de alguien que está lejos.
Futuro el que soñaste cuando niño.
Esperanza que se acaben las guerras en el mundo.
Ayudar aquel que está desprovisto.
Deseo que no exista el infierno.
Anhelo los abrazos de un amigo.

---

Se ve genial, el tamaño y el grosor de letra es el que buscaba, pero las etiquetas no son las correctas, hemos metido todo dentro del h5, y no creo que sacrificar la correcta semántica del HTML a costa de generar un mejor aspecto visual sea una buena idea de cara al futuro.

Tendríamos que buscar opciones como nuestra acostumbrada negrita para resaltar el texto y la cursiva si queremos darle un toque de frescura, u otras, yo la verdad no conozco mucho sobre Markdown y puede haber una variante para lograr el mismo aspecto visual.

Cierres o usos incorrectos de las etiquetas

Resulta que en dependencia como coloquemos nuestras etiquetas pude darse el hecho de que a pesar que estén mal colocadas o usadas de forma incorrecta nuestro Frontend no lo tome en cuenta o simplemente adopte una estrategia para mostrarnos el contenido visualmente correcto, o sea que a pesar de a veces hacer cosas como el siguiente ejemplo no arrojarían una quebradura en alpecto visual de nuestro blog para x Frontend:

<center>sfdsfsfdsfd</div>

ó

<div class="pull-left"> 

 <center>
 Esto es un ejemplo
 </center>

En la primera cerramos mal la etiqueta center y en el segundo se nos olvidó cerrar la etiqueta div, en ocaciones puede que visualmente dependiendo de la estructura de tu publicación no se haga visualmente incorrecto esta forma de usar estas etiquetas en el Frontend que estes ussando, pero no quiere decir que todos los Frontends van a ser tan buenos o tan inteligentes con está publicación en particular y podrían mostrar quebraduras en el diseño.

Y sobre todo el contenido que guardaste va ser el Markdown en sí que todos los Frontends interpretarán de a corde a sus criterios y herramientas y si lo guardas mal puede visualizarse mal en algunos. Incluso si planeas hacer uso de él con un software propio como un blog podrías enfrentar o encontrar este problema.

Obtener saltos de lineas con etiquetas de encabezados

Por ejemplo, me refiero a hacer lo siguiente:

#

<center>Esto es un ejemplo

#

---

Con lo anterior me imagino que estén buscando un salto de línea, ya que el encabezado "# ó h1" es una etiqueta de bloque en HTML hará que el contenido anterior y posterior se separen y al dejarlo vacío hace esta función de salto de línea visualmente igualando a la función de la etiqueta "br" pero puede que con una separación distinta entre contenido y puede que a algunos les guste más, solo que esta es una etiqueta de encabezado que se reserva para el título o tema principal de la publicación y no creó que sea correcto usarla de esta forma.

Conclusiones

Esto comprende en parte lo que pienso respecto a la maquetación, ahora no me viene más nada a la cabeza, en caso de nuevas sugerencias haré otra publicación sobre este tema.

Aclarar que los aspectos abordadodos anteriormente no afectan para nada (a menos que se produsca una quebradura en tu publicación que afecte la experiencia visual del usuario) tu rendimiento basado en el sistema de recompensa actual de la cadena, solo planteo una optimización de nuestras publicaciones para poder tomar una mayor ventaja de ellas a medida que evoluciona nuestro ecosistema y nosotros mismos.

Sin más me despido de ustedes y espero que les ayude o le sirva de alguna forma esta publicación.

Gracias por su lectura

Vota por HiveCuba Witness

Separador HIVECUBA | Fuente

El contenido de esta publicación es de mi autoria y el gato es mío también