Responsive y Adaptive Design

jueves, 27 de febrero de 2014

Cuando se habla de Responsive y Adaptive web design suelen tomarse como lo mismo.

Pero buceando en la web podemos encontrar 3 visiones diferentes sobre estos términos: los que piensan que son dos cosas muy distintas que no tienen puntos en común ("tengo que elegir entre uno u otro"), los que sostienen que el Responsive Web Design (RWD) es un subconjunto del Adaptive Web Design (AWD) y otros (tal vez los menos?) que consideran que en realidad son dos conceptos que se complementan.

En una definición general podemos encontrar que se habla de Responsive Design cuando se piensa un sitio donde el contenido pueda ser reacomodado según el dispositivo donde se visualiza (desktop, tablet, celular, etc.) enviando siempre la misma información.

Muy genéricamente también encontramos que el diseño Adaptive se define como el diseño pensado en base a los dispositivos donde se visualizará una aplicación, diseñando una versión para cada uno de ellos, haciendo que sea el servidor el que detecte qué dispositivo lo está invocando y enviando el diseño adecuado para el mismo.

Tal como mencionamos, algunas visiones consideran al RWD como parte del AWD, como un subconjunto del mismo. Muchas puntualizan que el Resposive design tiene como objetivo el layout únicamente.

Si bien los dos conceptos tienen en común que se focalizan en permitir que los sitios puedan ser vistos en dispositivos de distintos tamaños o resoluciones buscando dar una mejor experiencia a los usuarios, Adaptive design es algo más amplio e íntimamente relacionado con la mejora progresiva, cosa de la que el RWD tampoco está ajeno. Es por ello que hay quienes consideran que ambos conceptos se complementan. Personalmente me inclino más por esta visión.

El AWD es un concepto más abarcativo y, según la definición de su creador Aaron Gustafson, utiliza mucho de los componentes de la mejora progresiva (PE - Progressive Enhancement) que se focaliza en el uso de los métodos de diseño necesarios que apunten al usuario y no a los browsers, donde el RWD debería ser una parte, pero siempre teniendo en cuenta  que el AWD es un "acercamiento más holístico del diseño web".

Desde el punto de vista de los usuarios de los sitios que desarrollamos, poco sabrán ellos sobre qué métodos fueron usados para crearlos. Sólo buscarán poder navegarlos de la forma más simple, rápida y clara desde cualquier "aparato" que se los permita y si no, simplemente los abandonarán. Es por eso que las herramientas y métodos que usemos en su creación deben llevarnos siempre a satisfacer de la mejor forma posible las necesidades de dichos usuarios.

Tomar lo mejor que cada uno nos brinda para lograr este objetivo puede ser una buena idea ...

    


Leer más...

Uso de texto en lugar de imágenes (icon fonts)

lunes, 24 de febrero de 2014

Desde hace ya un par de años una de las prácticas instaladas en desarrollos web es el uso de fuentes tipográficas en lugar de íconos o pequeñas imágenes o incluso sprites css. O sea, se manejan los íconos como textos lo que permite cambiar sus propiedades usando CSS.




El uso de estos “icon fonts” (icon web fonts) presenta muchas ventajas respecto de otras técnicas de inserción de imágenes dado que disminuyen la carga del servidor y las peticiones HTTP, no son tan complejos de implementar como los sprites, son adaptables a distintos dispositivos (los íconos pueden verse pixelados al cambiar de tamaño), se puede cambiar fácilmente sus propiedades, entre otras.

Varios son los sitios donde podemos encontrar conjuntos de font-icons – gratuitos y pagos - y abarcan una enorme variedad de temas. Algunas de estas colecciones hemos aplicado en nuestro web site.

Recomendamos aquí muy buenos artículos donde pueden leer más detalles sobre su implementación y sitios desde donde descargar colecciones:

CSS Tricks

(imagen: htttp://commons.wikimedia.org/wiki/File:Early_writing_tablet_recording_the_allocation_of_beer.jpg)

    
Leer más...

Probando Pentaho VI: esquema de un cubo con Mondrian

viernes, 14 de febrero de 2014

En un artículo anterior vimos que construir un esquema Mondrian adecuado es la base para cualquier análisis y visualización.
Comparto ahora algunas pruebas realizadas con Mondrian. Utilicé  la documentación provista por Pentaho.

Esquema Mondrian

Un esquema define una base de datos multi dimensional. Contiene un modelo lógico. Este modelo a su vez debe mapear a un modelo físico.
  • El modelo lógico consiste en las estructuras usadas para escribir consultas en lenguaje MDX. Esta formado por cubos, jerarquías, niveles y miembros.
  • El modelo físico  son las tablas de datos presentados previamente en  el modelo lógico. 
Los esquemas Mondrian son archivos de tipo xml. Se pueden editar manualmente, o bien por medio de la herramienta Workbench provista por Pentaho.

Workbench

Mondrian Schema Workbench es una aplicación que permite crear visualmente y testear esquemas Mondrian de cubos OLAP.

Creación del esquema de un cubo usando Workbench

1. Instalar Mondrian, que se puede bajar desde Source Forge
2. Descomprimir en el directorio donde se instalo el server de Pentaho.



3. Incluir el driver JDBC en el directorio 'Drivers': schema-workbench/drivers
4. Con el server de Pentaho activo, iniciar Workbench, (schema-workbench/workbench.bat ) obteniendo una pantalla del tipo



5. Conectarse a la base de datos, desde la opción 'options' del menú principal. Los parámetros para crear la conexión son los mismos que en el caso de la consola de usuario de Pentaho.



6. Este es un ejemplo de esquema de un cubo. Consulta la base en SQL 'AdventureWorksDW'. Tomando como tabla de 'hechos' o fact table FactInternetSales. La medida utilizada es 'SalesAmount'. Las dimensiones, dos básicas, son el tiempo (DimTime) y Región (tabla DimSalesTerritory).
Crear o editar los elementos en el esquema. Workbench valida los cambios contra las tablas del cubo y los nombres de las columnas.

En este caso, construimos la dimensión 'Region' contra la tabla 'DimSalesTerritory'.

 7. Para ver el código XML que subyace detrás del esquema, seleccionar View/XML. Muestra el XML del elemento actual, pero no se puede editar este archivo directamente.

<Dimension type="StandardDimension" visible="true" foreignKey="SalesTerritoryKey" highCardinality="false" name="Region">
    <Hierarchy name="Region" visible="true" hasAll="true" allMemberName="TODOS" primaryKey="SalesTerritoryKey">
        <Table name="DimSalesTerritory" schema="dbo">
        </Table>
        <Level name="Region" visible="true" column="SalesTerritoryRegion" nameColumn="SalesTerritoryRegion" type="String" internalType="String" uniqueMembers="true" levelType="Regular" hideMemberIf="Never" caption="Region" captionColumn="SalesTerritoryRegion">
        </Level>
    </Hierarchy>
</Dimension> 


8. Probar que la  estructura sea correcta, para esto abrir el  editor de MDX y conectarse. Si se hay algún error o campo mal indicado no se conecta y da error.
En ese caso muestra los resultados de la consulta MDX básica.


Resultaron de utilidad los artículos del blog Adventures with Open Source BI

    
Leer más...