sep 18, 2008
Grupo ES
Comentarios desactivados

Columnas de altura 100% con CSS

Cómo maquetar una página con CSS y conseguir que la altura de las columnas ocupe todo el espacio disponible de la página.

05/9/08 – Con CSS podemos hacer muchas cosas de una manera rápida y sencilla. Pero muchas veces tenemos que emplear técnicas, algunas sencillas y otras no tanto, para conseguir efectos que de otra manera son imposibles. Es el caso que nos ocupa en este artículo, conseguir que las columnas en una maquetación CSS ocupen el 100% de la altura disponible. Es decir, tener una página maquetada a varias columnas, donde todas las columnas llegan hasta la parte de abajo de la página.

Quizás hayas llegado a este artículo porque no consigas un height: 100% en una columna al diseñar tu página con CSS y no necesites más explicaciones de lo que pretendemos conseguir. Pero si no es el caso y deseas ver un ejemplo de cómo se haría una maquetación CSS a dos columnas accede al artículo de DesarrolloWeb.com Maquetación CSS a dos columnas. Luego echa un vistazo a la página del ejemplo que se desarrolla en el artículo anterior.

Verás que la columna que tiene una especie de barra de navegación lateral sólo ocupa un área limitada del espacio que hay en vertical. Esto es porque en CSS las capas DIV crecen verticalmente justo lo necesario, atendiendo a los contenidos que se tienen que colocar dentro. Por mucho que intentemos colocar un estilo CSS height:100% a la capa de la columna pequeña, en principio, no conseguiremos que ocupe el mismo espacio que la columna grande. Pero claro, hay una solución a todo esto y podemos estar tranquilos porque es muy simple.

Creamos las columnas con capas flotando a izquerda y derecha

Luego ya sólo sería crear un contenedor que aparezca en el centro de la página y un par de columnas izquierda y derecha, donde estén flotando cada una hacia su lado. En otros artículos de desarrollo web .com hemos visto cómo hacer estas cosas con CSS.

El códido HTML quedaría así:

<div id=”container”>
<div id=”izquierda”>
Columna de la izquierda
</div>
<div id=”derecha”>
Esta columna de la derecha
</div>
</div>

El código CSS del ejemplo sería como este:

body {
background: #f0f0f0 url(fondo.gif) repeat-y 50%;
text-align: center;
}
#container{
margin:auto;
text-align:left;
width: 1000px;
}
#izquierda{
width: 670px;
float: left;
margin: 10px 0px 10px 10px;
}
#derecha{
width: 290px;
float: right;
margin: 10px 5px 10px 0px;
}

No tiene mucho misterio, si es que ya hemos seguido otros talleres publicados en desarrolloweb .com sobre la cómo maquetar webs con CSS. Os aconsejamos seguir la línea de artículos que comienza por el artículo Maquetación CSS.

Fuente: DesarrolloWeb

sep 18, 2008
Grupo ES
Comentarios desactivados

Como crear nuestra marca

 Difusión Vs. Complejidad, Potencial Vs. Limitaciones, Rigidez Vs Flexibilidad e In House Vs. Outsourcing. 4 reglas sencillas para crear nuestra marca.

1. Difusión Vs. Complejidad gráfica.

Por lo general marcas que van a tener una gran difusión en medios, deben tender a simplificar sus elementos.
Marcas con poca difusión pueden generar formas más complejas.

Esta regla se basa en la idea de no agotar al consumidor.
Si el consumidor se ve bombardeado por una marca compleja de forma constante, se produce un agotamiento que deteriora la marca.

Ejemplo malo: Movistar.
La marca movistar es una forma compleja de la que se abusa en los medios. Al final la marca se convierte en un bloque sin vida, repetido hasta la saciedad. La marca de Movistar debería ser gestionada con algo más de cautela.

Ejemplo bueno: BBVA.
BBVA es una marca azul, de un banco gigante. Podría ser una marca muerta, pero la sobriedad con la que es tratada la salva de quemarse. No habría nada peor que una marca tipo BBVA queriendo ser tu colega (pues eso es un poco lo que le pasa a Movistar).

La complejidad gráfica no solo hace referencia a que el símbolo sea complejo. Podemos trabajar con un símbolo sencillo, legible, etc… pero dotarle de elementos complejos para los faldones, tarjetas, literatura, etc…

2. Potencial Vs. Limitaciones.

Las limitaciones de una marca deben no figurar en la marca. Debemos poner el acento en el potencial.

Este aspecto está muy descuidado en muchas empresas que acuden a “limitaciones” a la hora de designar su marca.

El caso más común es el de la denominaciones de origen que ponen todo el esfuerzo en la región descuidando aspectos potenciales de los productos como el sabor, calidad, origen, autenticidad, etc…

Las marcas de los productos, servicios, deben ser creados atendiendo al potencial real de los mismos. Si el producto es de producción artesanal, o las materias primas son de valor, o se pone especial atención a la atención personal, debemos olvidar “limitaciones” geográficas (o de cualquier otro tipo) y poner el acento en lo que nos puede diferenciar. La localización no nos diferencia de otras localizaciones ya que es, por lo general, un aspecto ajeno al consumidor y requiere de un conocimiento detallado de las circunstancias particulares de la región.

3. Rigidez Vs. Flexibilidad

A la hora de crear una marca se pueden generar reglas extrictas sobre todos los aspectos de la marca creando enormes manuales y guías que cubren todos los aspectos de uso de la marca.

O se pueden crear reglas sencillas que aseguren unos mínimos sobre la integridad de la marca dejando el resto de los elementos al criterio de los colaboradores del proyecto.

Por lo general, un sistema rígido es bueno para:
- Empresas en las que el equipo de branding no intervienen en el equipo de desarrollo o implementación.
- Empresas pequeñas sin recursos. Es mejor tener algo consistente que algo que pueda sufrir mutaciones no controlables.
- Grandes corporaciones. Simple es mejor. Lo contrario suele llevar al caos.
- Arquitecturas de marca monolíticas.

Un sistema flexible es bueno para:
- Empresas que mantienen al equipo creador de la marca como el equipo desarrollador de la marca.
- Empresas con una arquitectura de marca de “producto”. Danone por ejemplo.

Los sistemas flexibles son complejos de desarrollar si el equipo de branding de la empresa no es un equipo con mucha experiencia en el desarrollo de identidades, proceso creativo, producción, etc.

Los sistemas rígidos pueden ser ilusionantes y no convertirse en “obstaculos” para los colaboradores en el proyecto, si se consigue transmitir con claridad los espacios creativos que el sistema ofrece más que hacer énfasis en las limitaciones creativas del sistema (exhibir el potencial y no las limitaciones).

4. In House Vs. Outsourcing

Los únicos casos dónde el “In House” es recomendable es en aquellos en los que la estructura corporativa está claramente definida la estrategia de marca.

Por lo general esto equivale a que junto al Presidente de la compañía exista un líder de “Corporate Communications” claro, visible y con autoridad para llevar este aspecto de la empresa con firmeza.

Si la empresa no tiene en su estructura esta figura, la marca se suele diluir entre departamentos pudiendo acabar en un sistema donde cada división crea su interpretación de la marca acabando con cualquier tipo de consistencia, harmonia, unión, claridad, mensajes…

Si esta figura no existe, lo mejor es sacar fuera la gestión de la marca y que una empresa externa lleve las riendas. Esta empresa puede ser una agencia de identidad, una agencia de publicidad, un estudio de diseño, etc…

Las ventajas del In House son claras frente al Outsorcing ya que la cultura corporativa se puede retroalimentar año a año, las necesidades se pueden comunicar de forma más clara, se puede crecer de forma orgánica, etc…

El Outsorcing es bueno si la empresa no tiene en su marca un claro potencial y es más económico (por tiempo, dinero, etc…) sacarlo fuera que crearlo dentro.
Autor: César Martin
http://alzado.org/articulo.php?id_art=594

sep 18, 2008
Grupo ES
Comentarios desactivados

21 trucos SEO, según Matt Cutts

Gracias a Ojobuscador nos llega la traducción del interesante artículo 21 Great SEO Tips From Google’s Matt Cutts:


1. Es mejor usar guiones que “guiones bajos” en las URL’s
2. Es mejor no usar redirecciones JavaScript
3. Google actualiza su índice constantemente
4. Esisten sistemas de detección de colores iguales (o muy cercanos) que el fondo
5. Los enlaces que se venden devalúan los sitios web
6. Google no puede acceder a zonas de registrados… así que “dale algo” como entradilla
7. Si usas Flash, haz una versión HTML y bloquea la flash con los robots.txt
8. Utiliza fiesdly URL’s con texto comprensible (sin pasarse)
9. Cada página ha de tener su propio título
10. Minimizar el número de redirecciones hasta llegar a una URL
11. Minimizar el número de parámetros de una URL
12. No usar el parámetro “id=…” o de sesiones
13. Google noconsidera de calidad los enlaces comprados para aumentar PageRank
14. Los “malos” SEO’s pueden ser recelosos a usar Analytics.
15. Google no está a favor de la compra-venta de enlaces
16. Google está enfocando sus sistemas a combatir spam en otros idiomas (no inglés)
17. Las redirecciones 302 se están comenzando a considerar redirecciones 301
18. Se recomienda no usar subdominios con contenido duplicado, y usar redirecciones 301 para corregirlo.
19. No usar la herramienta para eliminar dominios de Google para quitar un dominio canónico
20. Los buscadores pueden hacer tareas para solucionar la canonicación o quitar las sesiones de foros
21. Mucha gente usa error 404 (webs que pueden volver) contra el error 410 (webs que no van a volver)

Autor: Matt Cutts
http://www.ojobuscador.com

sep 18, 2008
Grupo ES
Comentarios desactivados

¿Por qué elegir PHP?

De acuerdo a las encuestas de NetCraft, PHP es ahora el módulo más popular para el servidor Apache, creciendo un 4% mensual sobre la totalidad de sitios de Internet. Aquí contamos algunas de las razones por la cual PHP se ha convertido en uno de los lenguajes de script más populares.

Un poco de historia

PHP (siglas que originalmente significaban Personal Home Page) fue primero escrito por Rasmus Lerdorf como un simple conjunto de scripts de Perl para guiar a los usuarios en sus páginas. Luego para satisfacer inquietudes del mismo tipo por parte de otra gente lo reescribe, pero esta vez como un lenguaje de script agregándole entre otras características soporte para formularios. Al ver como la popularidad del lenguaje aumenta, un grupo de desarrolladores crea para él un API, convirtiéndose así en el PHP3. Fue en ese momento cuando el parser de scripts PHP es completamente reescrito (el Zend Engine) dando vida al PHP4 mucho mas rápido, tal y como lo conocemos en la actualidad.

PHP actualmente significa Hypertext Preprocessor y esta listo para su mejor momento…

Cosas para tener en cuenta en un lenguaje de scripts

Las cuatro grandes características: Velocidad, estabilidad, seguridad y simplicidad.

* Velocidad: No solo la velocidad de ejecución, la cual es importante, sino además no crear demoras en la máquina. Por esta razón no debe requerir demasiados recursos de sistema. PHP se integra muy bien junto a otro software, especialmente bajo ambientes Unix, cuando se configura como módulo de Apache, esta listo para ser utilizado.
* Estabilidad: La velocidad no sirve de mucho si el sistema se cae cada cierta cantidad de ejecuciones. Ninguna aplicación es 100% libre de bugs, pero teniendo de respaldo una increíble comunidad de programadores y usuarios es mucho mas difícil para lo bugs sobrevivir. PHP utiliza su propio sistema de administración de recursos y dispone de un sofisticado método de manejo de variables, conformando un sistema robusto y estable.
* Seguridad: El sistema debe poseer protecciones contra ataques. PHP provee diferentes niveles de seguridad, estos pueden ser configurados desde el archivo .ini
* Simplicidad: Se les debe permitir a los programadores generar código productivamente en el menor tiempo posible. Usuarios con experiencia en C y C++ podrán utilizar PHP rápidamente.

Bueno otra característica a tener en cuenta seria la conectividad. PHP dispone de una amplia gama de librerías, y agregarle extensiones es muy fácil. Esto le permite al PHP ser utilizado en muchas áreas diferentes, tales como encriptado, gráficos, XML y otras.
Ventajas adicionales de PHP

* PHP corre en (casi) cualquier plataforma utilizando el mismo código fuente, pudiendo ser compilado y ejecutado en algo así como 25 plataformas, incluyendo diferentes versiones de Unix, Windows (95,98,NT,ME,2000,XP,bla,bla,bla) y Macs. Como en todos los sistemas se utiliza el mismo código base, los scripts pueden ser ejecutados de manera independiente al OS.
* La sintaxis de PHP es similar a la del C, por esto cualquiera con experiencia en lenguajes del estilo C podrá entender rápidamente PHP. Entre los lenguajes del tipo C incluimos al Java y Javascript, de hecho mucha de la funcionalidad del PHP se la debe al C en funciones como fread() o srtlen(), así que muchos programadores se sentirán como en casa.
* PHP es completamente expandible. Está compuesto de un sistema principal (escrito por Zend), un conjunto de módulos y una variedad de extensiones de código.
* Muchas interfaces distintas para cada tipo de servidor. PHP actualmente se puede ejecutar bajo Apache, IIS, AOLServer, Roxen yTHTTPD. Otra alternativa es configurarlo como modulo CGI.
* Puede interactuar con muchos motores de bases de datos tales como MySQL, MS SQL, Oracle, Informix, PostgreSQL, y otros muchos. Siempre podrás disponer de ODBC para situaciones que lo requieran.
* Una gran variedad de módulos cuando un programador PHP necesite una interfase para una librería en particular, fácilmente podrá crear una API para esta. Algunas de las que ya vienen implementadas permiten manejo de gráficos, archivos PDF, Flash, Cybercash, calendarios, XML, IMAP, POP, etc.
* Rapidez. PHP generalmente es utilizado como modulo de Apache, lo que lo hace extremadamente veloz. Esta completamente escrito en C, así que se ejecuta rápidamente utilizando poca memoria.
* PHP es Open Source, lo cual significa que el usuario no depende de una compañía específica para arreglar cosas que no funcionan, además no estás forzado a pagar actualizaciones anuales para tener una versión que funcione. Muchos de nosotros que hemos esperado que Allaire arregle algo apreciamos esto.
Algunas contras

El manejo de errores no es tan sofisticado como Cold Fusion o ASP.

No existe IDE o Debugger. Una IDE puede no ser importante para la mayoría de los programadores y un debugger ha sido prometido por Zend Tech para un futuro muy cercano.
Cuando debes utilizar PHP y cuando debes utilizar otro lenguaje

Si estas desarrollando bajo una plataforma UNIX o Linux, debes elegir entre Perl y PHP, ambos excelentes. Para mucha gente PHP es más simple a la hora de escribir scripts, haciéndolo más productivo en proyectos no tan grandes. ¡Claro que no existe razón para no tener PHP y Perl al mismo tiempo!

En ambientes Windows compite muy de cerca con ASP y Cold Fusion, aquí la elección se basa en asuntos un poco más técnicos y en la política que desee utilizarse para el sitio. ASP junto a IIS es probablemente más estable que PHP con IIS. Pero en términos puramente técnicos, PHP bajo Windows NT es mucho más estable que los otros dos (además de ser más rápido y utilizar menos recursos). De cualquier manera ASP ofrece una mejor integración con este ambiente sobre todo si se desea utilizar COM.
Conclusión

Como muchas otras cosas en la caja de herramientas de un programador, PHP ha sido creado casi accidentalmente. Empezando como experimento de una persona, modificado para adaptarse a las necesidades de muchos otros programadores de un lenguaje rápido, simple, robusto que pueda trabajar en conjunto a otros componentes. En los últimos tres años ha crecido de forma desmedida, tomando así el papel principal del scripting del tipo Server Side.

Como muchas otras cosas en la caja de herramientas de un programador, PHP ha sido creado casi accidentalmente. Empezando como experimento de una persona, modificado para adaptarse a las necesidades de muchos otros programadores de un lenguaje rápido, simple, robusto que pueda trabajar en conjunto a otros componentes. En los últimos tres años ha crecido de forma desmedida, tomando así el papel principal del scripting del tipo Server Side.

Autor: Agustín Dondo
http://www.programacion.net/articulo/porquephp/