Consejos para una mejor interfaz gráfica de usuario (GUI; NO! diseño gráfico): #1 No forzar la vista del usuario

Este es el primer post, de una serie, con consejos para lograr una mejor interfaz grafica de usuario (GUI). No están referidos al diseño gráfico en sí, sino, se trata simplemente de cómo organizar los elementos en el software o en alguna aplicación web.

Están basados en mi experiencia de trabajar con personas de diferentes perfiles. Por un lado, el usuario casual, con poco manejo de software (Rojas y Asociados). Y por otro lado, personas con un manejo intensivo de sistemas informáticos (Tarjeta Nevada).

Para la mayoría de los ejemplos, voy a usar webs. Dado que es conocido y fácilmente comprobable.

Consejo #1: No forzar la vista del usuario

La distribución de los elementos en la pantalla es muy importante. Hoy en día las pantallas tienen, en promedio , una resolución de 1024 x 768
pixeles. Sin embargo, de a poco, empiezan a emerger las pantallas anchas (widescreen).

He clasificado la pantalla en 2 zonas con diferentes niveles de uso: la zona importante y la zona secundaria.

La zona importante

La zona importante es el área donde van los elementos principales con las cuales interactuará el usuario. Es lo que se le quiere destacar al usuario. Por ejemplo, si  alguien ingresa a una pantalla para ver un listado, esta es la zona donde debería mostrarse dicho listado.

Es recomendable, que la zona importante esté en el centro de la pantalla. Dado que allí hay un mayor impacto visual, útil para para usuarios no entrenados.

Sin embargo, la zona importante debe estar apenas deslizada del eje vertical. Esto por razones  ergonómicas: teniendo en cuenta que se aconseja que el monitor esté a la altura de los ojos y, 
que los humanos tendemos a mirar más hacia abajo (nada) que hacia arriba (párpados); entonces, nuestro movimiento natural es mirar el centro y continuar hacia abajo. Ver la figura 1.

La zona secundaria

La zona secundaria de la pantalla es donde va información contextual a la importante. Si es un cuadro de confirmación, aquí nunca iría el botón de "Aceptar" o "Cancelar".

Esta zona le permite al usuario, seguir con otras actividades a la principal. Por ejemplo, si llegó aquí por error, puede continuar con alguna pantalla de un menú o barra de herramienta.

A veces, sirve para manipular la actividad en la zona importante. Por ejemplo, si usamos el Microsoft Paint, el lápiz (botón del costado) permite dibujar sobre el lienzo (zona importante).

En general, en la zona secundaria, se muestran las "otras tareas" que puede realizar el usuario sobre el software.

Ejemplos

Como ejemplo, van 2 casos. El primero es de
cnn.com. Aquí, la zona importante realza bien y tiene un 50% del área total usada para la interacción con el usuario.

El segundo caso es de Diario Uno de Mendoza. Aquí quise resaltar, la poca relevancia que tiene la zona importante (20%) ; y, lo mal distribuido que está respecto del centro (tomado en un monitor widescreen).

En resumen, la interfaz no debería forzar la vista del usuario. La zona importante debería estar en el centro y tener la relevancia necesaria para
llamar la atención del usuario.

Hasta la próxima!

Aplicando Lean al desarrollo de aplicaciones

McKinsey ha publicado un documento de cómo aplicar Lean al desarrollo de aplicaciones. Lean es la filosofía oriental que busca la mejora de la productividad eliminando los derroches. (En realidad, algunos de los temas tratados pueden ser extendido a desarrollo de proyectos)

El informe presenta los principales focos de derroches. El más sobresaliente es el cambio de requerimientos. Éste afecta en diversas fases tales como el desarrollo en sí y la fase de prueba.

McKinsey recomienda 3 pasos para la eliminación de los derroches.

1. Primero, rediseño del proceso con releases bimestrales.


2. Segundo, balanceo de carga de trabajo. Esto es unir desarrolladores y testers, e involucrar personal de otros grupos de trabajo en momentos críticos.


3. Tercero, gestión del proceso completo. Usando una planilla de cálculos que resalte los puntos críticos.

El artículo completo está disponible en:

Applying lean to application development and maintenance.
To make application development and maintenance more productive, IT managers are getting lean.

By Noah B. Kindler, Vasantha Krishnakanthan, and Ranjit Tinaikar.

ADO.Net Entity Framewrok: El NHibernate de Microsoft

En Febrero del 2008 se viene el Microsoft ADO.Net Entity Framework. Será incluído dentro de Visual Studio 2008 y Sql Server 2008. Es la alternativa de Microsoft a NHibernate. La noticia fue dada a conocer por Michael Pizzo en el último número de "The Architecture Journal" (Pizzo 2007).

El ADO.Net Entity Framework permitirá a la aplicación usar un modelo conceptual de herencia, relaciones y datos fuertemente tipados. Dicho modelo podrá ser mapeado a varios esquemas de almacenamiento.

El ADO.Net Entity Framework mapeará objetos de negocio a tablas relacionales. Con esto se ataca la impedancia existente entre el modelo orientado a objetos y el modelo entidad-relación. La idea principal es promocionar las reglas de negocio dentro de la base de datos(stored-procedures) a una capa superior (aplicación). Dicha idea se basa en la escalabilidad futura de la aplicación.

La configuración del Framework será out-of-band, es decir externa a la aplicación (.xml).

Finalmente, se actualizaron algunos componentes. El principal es el DataReader que ahora soporta polimorfismo, anidamiento y valores complejos.



Referencias
Pizzo, Michael (2007). An Application-Oriented Model for Relational Data. The Architecture Journal, 12, pp 19-25. http://www.architecturejournal.net

 

Sobre el autor

Pablo Pizarro es un Ingeniero en Informática que se especializa en
aplicaciones web empresariales. Está radicado en Mendoza, Argentina. Su
objetivo profesional es "mejorar la competitividad de las organizaciones a
través de la integración de la información". Actualmente, trabaja en el
área de I+D de la consultora minera Rojas y Asociados. Antes, trabajó en el área
de tecnología de Tarjeta Nevada (tarjeta de crédito). Hoy en día, se encuentra
desarrollando un proyecto sobre aplicaciones empresariales junto a otros
profesionales. Puede ser contactado a través de su email:
pizarropablo@gmail.com.

About the author

Pablo Pizarro is an Engineer in Information Technology, which specializes in
enterprise web applications. He lives in Mendoza, Argentina. His professional
objective is "Enhance competitiveness of organizations through the integration
of the information". Actually, he works in I+D department in Rojas & Associates
mining consultancy. Prior, he worked in the area of Technology in Tarjeta
Nevada (credit card). Today, he is developing a project about enterprise
applications with other professionals. He can be contacted at
pizarropablo@gmail.com.

ORM (Object Relational Mapping) Reloaded

Desde hace unos meses estoy usando el Google Analytics, y me dió un análisis sobre el blog: hay muchos accesos buscando información sobre el Object Relational Mapping.

Originalmente, fué un trabajo para la universidad en formato .Doc. No me gustó pasarlo a un formato HTML (formato actual en el blog) pues se hizo un post muy largo, . Así que lo republico aquí con un formato PDF.

Espero que este documento resulte útil.

ORM, Object Relational Mapping

La persistencia de la información es la parte más crítica en una aplicación de software. Si la aplicación está diseñada con orientación a objetos, la persistencia se logra por: serialización del objeto o, almacenando en una base de datos. Las bases de datos más populares hoy en día son relacionales. El modelo de objetos difiere en muchos aspectos del modelo relacional. La interfase que une esos dos modelos se llama marco de mapeo relacional-objeto (ORM en inglés).
En este documento describo el mapeo de un modelo de objetos hacia un modelo relacional. También, los aspectos a considerar cuando se elige un marco ORM: caché, transacciones, carga retardada, concurrencia. Y por último, una descripción de los 2 marcos ORM más usados en la tecnología Microsoft.Net: Ojb.Net y NHibernate.
Organicé el trabajo en 3 partes. En la primera parte, hablaré sobre el paso del modelo de objetos al modelo relacional. Introduciré el tema. Luego, describiré las técnicas de mapeo entre las tablas y los atributos de un objeto. Entonces, trataré sobre la complejidad de los ORM. Finalmente, describiré brevemente las tecnologías más usadas en la plataforma Micorosoft.Net.

Versión en pdf: pizarropablo.googlepages.com/ORM-ObjectRelationalMapping-PizarroP.pdf

 

Sobre el autor

Pablo Pizarro es un Ingeniero en Informática que se especializa en
aplicaciones web empresariales. Está radicado en Mendoza, Argentina. Su
objetivo profesional es "mejorar la competitividad de las organizaciones a
través de la integración de la información". Actualmente, trabaja en el
área de I+D de la consultora minera Rojas y Asociados. Antes, trabajó en el área
de tecnología de Tarjeta Nevada (tarjeta de crédito). Hoy en día, se encuentra
desarrollando un proyecto sobre aplicaciones empresariales junto a otros
profesionales. Puede ser contactado a través de su email:
pizarropablo@gmail.com.

About the author

Pablo Pizarro is an Engineer in Information Technology, which specializes in
enterprise web applications. He lives in Mendoza, Argentina. His professional
objective is "Enhance competitiveness of organizations through the integration
of the information". Actually, he works in I+D department in Rojas & Associates
mining consultancy. Prior, he worked in the area of Technology in Tarjeta
Nevada (credit card). Today, he is developing a project about enterprise
applications with other professionals. He can be contacted at
pizarropablo@gmail.com.

Qué es un arquitecto de software?

Algunos me preguntaron que era un arquitecto de software y cuál era la diferencia entre un lider de proyecto o jefe de desarrollo.

Pues bien, en mis palabras, un arquitecto de software es aquel que está involucrado con 1 o varios desarrollos de software, pero desde un punto de vista macro. Es decir, comenzando por los requisitos (funcionales y no funcionales) y hasta llegar a conocer el impacto que tendrá en el hardware del cliente.

El arquitecto de software tiene tres variables principales sobre cuales moverse: tiempo, satisfacción del cliente y, principalmente, costo de los desarrollos.

Una definición de arquitectura de software, según "El proceso unificado de desarrollo de software" de Jacobson-Grady-Rumbaugh, lo compara a la arquitectura en la construcción. La aquitectura de software es el conjunto de planos de un desarrollo de software. Planos con las características más importantes resaltadas dejando de lado los detalles. Caraterísticas como requisitos de los usuarios e inversores, plataforma (sistema operativo, harware, base de datos, protocolos de red), bloques de construcción reutilizables, condideraciones de implantación, sistemas heredados y requisitos no funcionales.

Finalmente, transcribo otra definición para arquitecto de software que puede ser encontrada en "What Does it Mean to be a Software Architect? - Part III" by Rob Daigneau ( http://www.designpatternsfor.net/default.aspx?pid=75 ):... a very simple starting definition for an architect:

1. A person who designs software systems and advises in the design of such systems.

2. A person who designs and guides a plan or undertaking related to software systems design.

I must emphasize that this was only a starting point. The follow-up question to this definition might be, “What do we mean by design, guide, and plan?” In response to this question, here are a few things that the architect might provide guidance and plans for:

The Creation, Capture, and Management of Business Requirements.

Software architects oftentimes play an integral role in the elicitation and organization of business requirements. The premise here is that the purpose of architecture is to ensure that the business needs are fulfilled, and the resulting architecture must be directly influenced by the business requirements. Architects should, at the very least, be well-informed concerning the scope of business requirements to be addressed, must understand how product features map back to business requirements and their associated benefits, and must also be kept up-to-date concerning the evolution of the functional specifications for the proposed software product.

Project Management Plans.

Software architects typically have a unique perspective on the factors that impact the project’s schedule, budget, risks, and required resources. These factors include aspects of the solution design (discussed in the following section), the true nature of the business requirements, and the most effective means to staff development efforts to build what is described in the solution architecture.

Architecture Plans.

This is the key concern of the architect. Here are some components of a typical architecture plan:

1. The creation of a solution design intended to achieve the desired business requirements.
   
   
   • The software design
   
   
   • The evaluation and selection of various technologies used to achieve certain functional or technical requirements
   
   
   • Trade-off decisions that affect software design or the selection of various technologies
   
   
   • Application integration strategies
   
   
   • Physical deployment strategies
   
   
   • "Buy, Borrow, or Build" decisions
     


2. Recommendations on product release strategies and versioning approaches.


3. The design of logical environments, and the processes that govern the flow of software deliverables from one environment to the next. This also typically includes capacity planning requirements, and recommendations for the specific software and hardware to be used along with associated configurations for each logical environment.


4. Strategies to ensure proper governance of IT assets.


5. The definition of standards and guidelines for design, coding, unit-testing, and build processes for the project or the organization.


6. The evaluation and selection of development related tools and technologies, and the definition of related processes.


7. Data conversion requirements.

La diferencia entre un líder de proyecto y un arquitecto está en el foco: generalmente el líder de proyecto se concentra en resolver las cuestiones más específicas del 1 o más proyectos. El arquitecto tiene la visión global de los proyectos.

En cuanto a las diferencias entre un Jefe de Desarrollo y un arquitecto está en las competencias: mientras que un Jefe de Desarrollo se desempeña mucho mejor guiando procesos de desarrollos, el arquitecto se desempeña mejor gestionando los proyectos que se llevan a cabo y la tecnología donde deberá aplicarse.

 

Sobre el autor

Pablo Pizarro es un Ingeniero en Informática que se especializa en
aplicaciones web empresariales. Está radicado en Mendoza, Argentina. Su
objetivo profesional es "mejorar la competitividad de las organizaciones a
través de la integración de la información". Actualmente, trabaja en el
área de I+D de la consultora minera Rojas y Asociados. Antes, trabajó en el área
de tecnología de Tarjeta Nevada (tarjeta de crédito). Hoy en día, se encuentra
desarrollando un proyecto sobre aplicaciones empresariales junto a otros
profesionales. Puede ser contactado a través de su email:
pizarropablo@gmail.com.

About the author

Pablo Pizarro is an Engineer in Information Technology, which specializes in
enterprise web applications. He lives in Mendoza, Argentina. His professional
objective is "Enhance competitiveness of organizations through the integration
of the information". Actually, he works in I+D department in Rojas & Associates
mining consultancy. Prior, he worked in the area of Technology in Tarjeta
Nevada (credit card). Today, he is developing a project about enterprise
applications with other professionals. He can be contacted at
pizarropablo@gmail.com.