Tesis Ingenieria de Sistemas - Trabajo de Grado - Web 2.0

Trabajo Final de Grado

Ingeniería de Sistemas - IUA

Tema:

Análisis de la tendencia Web 2.0, y su

aplicación a la relación cliente-empresa.

Juan Alberto Ortiz Fernandez

Asesor: Ing. Mariano García Mattío

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Declaración de Derechos de Autor

i

Declaración de Derechos de Autor

Esta obra esta publicada bajo la licencia Creative Commons Atribución-Sin Obras Derivadas 2.5

Argentina.

Puedes copiar, compartir y referenciar este e-book indicando a Juan Ortiz como fuente.

(http://blog.juanortiz.com.ar)

Para ver una copia de esta licencia, visita http://creativecommons.org/licenses/by-nd/2.5/ar/

http://blog.juanortiz.com.ar/

http://creativecommons.org/licenses/by-nd/2.5/ar/

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Dedicatoria

ii

Dedicatoria

A Ana y Juan, mis padres.

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Agradecimientos

iii

Agradecimientos

A mi familia.

A mis amistades.

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Abstract

iv

Abstract

El presente es un trabajo final de grado (TFG) de Ingeniería de Sistemas en el Instituto

Universitario Aeronáutico (IUA). El problema observado es la falta de un espacio online con

capacidades claras para generar el dialogo entre consumidores y empresas, en base a las fallas

presentes en sus productos o servicios. Para poder lograr cubrir esta necesidad el alumno

considera que este tipo de herramienta debe contar con características sólo provistas hasta ahora

por la tendencia Web 2.0 las cuales deberán ser estudiadas y comprendidas.

Por tanto el objetivo del proyecto es lograr comprender el concepto ambiguo de Web 2.0

entendiendo las formas en las que se manifiesta, sus implicancias sociales, y las tecnologías que le

dan soporte para lograr que su aplicación permita la implementación de un sitio web con

características Web 2.0 que eventualmente genere un espacio de diálogo entre consumidores y

empresas.

Para desarrollar el trabajo se ha realizado una investigación en base a diversas fuentes

bibliográficas analizando los conceptos de web 2.0, social media, patrones de diseño, y diversas

tecnologías aplicables. Posteriormente se consideran los patrones de diseño para definir

requerimientos y diseño de la solución de software utilizando UWE UML. Finalmente se realiza la

implementación del modelo teórico en base a proyectos open source y servicios de terceros.

El resultado final del proyecto en su marco teórico provee una comprensión sobre la tendencia

Web 2.0 y maneras de aplicación de esta a prácticamente cualquier contexto que se elija.

Además, incluye una aplicación al contexto cliente-empresa mediante una solución de software

online que sienta las bases para una comunidad de consumidores y empresas. En la actualidad

dicho servicio se encuentra funcional y su futuro crecimiento como comunidad requiere tiempo

de maduración y esfuerzo, por lo que el autor seguirá trabajando sobre el tema de manera

independiente una vez finalizada la etapa de tesis.

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Índice de figuras

5

Índice de contenidos

DECLARACIÓN DE DERECHOS DE AUTOR...................................................................................................... I

DEDICATORIA.............................................................................................................................................. II

AGRADECIMIENTOS ................................................................................................................................... III

ABSTRACT .................................................................................................................................................. IV

ÍNDICE DE CONTENIDOS .............................................................................................................................. 5

ÍNDICE DE FIGURAS ..................................................................................................................................... 9

ÍNDICE DE TABLAS ..................................................................................................................................... 12

1. INTRODUCCIÓN ................................................................................................................................ 13

1.1. ANTECEDENTES ............................................................................................................................. 13

1.2. SITUACIÓN PROBLEMÁTICA .............................................................................................................. 14

1.3. PROBLEMA .................................................................................................................................. 15

1.4. OBJETO DE ESTUDIO ....................................................................................................................... 15

1.5. CAMPO DE ACCIÓN ........................................................................................................................ 16

1.6. OBJETIVOS ................................................................................................................................... 17

1.6.1. OBJETIVO GENERAL .................................................................................................................... 17

1.6.2. OBJETIVOS ESPECÍFICOS .............................................................................................................. 17

1.7. IDEA A DEFENDER / PROPUESTA A JUSTIFICAR / SOLUCIÓN A COMPROBAR .................................................... 17

1.8. DELIMITACIÓN DEL PROYECTO ........................................................................................................... 18

1.9. APORTE PRACTICO ......................................................................................................................... 18

1.10. APORTE TEÓRICO ........................................................................................................................... 18

1.11. MÉTODOS DE INVESTIGACIÓN. .......................................................................................................... 19

1.11.1. MÉTODOS LÓGICOS ................................................................................................................... 19

1.11.2. MÉTODOS EMPÍRICOS................................................................................................................. 19

1.12. ENFOQUE METODOLÓGICO. ............................................................................................................. 20

1.12.1. PARADIGMA............................................................................................................................. 20

1.12.2. PROCESO ................................................................................................................................ 20

1.12.2. MÉTODOS ............................................................................................................................... 21

1.12.3. TÉCNICAS ................................................................................................................................ 21

2. MARCO CONTEXTUAL ....................................................................................................................... 23

2.1. ENTORNO DEL OBJETO DE ESTUDIO ..................................................................................................... 23

2.2. RELACIÓN TESISTA Y OBJETO DE ESTUDIO ............................................................................................. 24

2.3. ANÁLISIS DE LOS PROBLEMAS OBSERVADOS .......................................................................................... 24

3. MARCO TEÓRICO .............................................................................................................................. 26

3.1. INTRODUCCIÓN ............................................................................................................................. 26

3.2. THE CLUETRAIN MANIFESTO: LOS MERCADOS SON CONVERSACIONES.......................................................... 27

3.3. LA WEB 2.0 ................................................................................................................................. 28

3.4. SOCIAL MEDIA: LOS NUEVOS MEDIOS SOCIALES. .................................................................................... 29

3.4.1. REDES SOCIALES ........................................................................................................................ 30 3.4.1.1. Facebook ................................................................................................................................... 30 3.4.1.2. MySpace .................................................................................................................................... 31

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas - Índice de contenidos

6

3.4.1.3. Orkut ......................................................................................................................................... 31 3.4.1.4. LinkedIn ..................................................................................................................................... 31 3.4.1.5. Resumen sobre redes sociales .................................................................................................... 31

3.4.2. BLOGS .................................................................................................................................... 32 3.4.2.1. El blog como una herramienta de publicación de contenidos ....................................................... 32 3.4.2.2. El blog como medio de comunicación y tendencia social ............................................................. 33 3.4.2.3. La blogosfera .............................................................................................................................. 35

3.4.3. WIKIS ..................................................................................................................................... 35

3.4.4. PODCASTS ............................................................................................................................... 36

3.4.5. FOROS .................................................................................................................................... 37

3.4.6. COMUNIDADES DE CONTENIDOS .................................................................................................... 38 3.4.6.1. Flickr: fotografías. ....................................................................................................................... 39 3.4.6.2. YouTube: videos. ........................................................................................................................ 39 3.4.6.3. Delicious: marcadores (bookmarks). ........................................................................................... 40 3.4.6.4. Digg: noticas y contenidos. ......................................................................................................... 40

3.4.7. MICROBLOGGING ...................................................................................................................... 41 3.4.7.1. Twitter: el líder en microbbloging. .............................................................................................. 41 3.4.7.2. Usos del Microblogging .............................................................................................................. 41

3.4.8. SINDICACIÓN DE CONTENIDOS Y APIS EN LOS SOCIAL MEDIAS. ............................................................... 42

3.4.9. MASHUPS ............................................................................................................................... 43

3.4.10. UN BREVE RESUMEN DE LOS SOCIAL MEDIAS. .................................................................................... 45

3.5. CLIENTES, EMPRESAS Y LA WEB 2.0 ................................................................................................... 46

3.5.1. LOS CONSUMIDORES SON LOS PROTAGONISTAS. ................................................................................ 46

3.5.2. TENDENCIAS DE CONSUMO DE INTERNET ......................................................................................... 47 3.5.2.1. La base de clientes es verdaderamente global ............................................................................. 47 3.5.2.2. Los clientes están siempre conectados ........................................................................................ 48 3.5.2.3. Los clientes están conectados dondequiera que vayan ................................................................ 48 3.5.2.4. Los clientes no están simplemente conectados, están participando ............................................. 49

3.5.3. LA RELACIÓN ENTRE LOS USUARIOS DE INTERNET Y LAS MARCAS O PRODUCTOS. ......................................... 50

3.6. LAS EMPRESAS Y LA WEB 2.0 ........................................................................................................... 52

3.6.1. LOS DISTINTOS TIPOS DE BLOGS CORPORATIVOS ................................................................................. 53

3.6.2. OPINIÓN DE LAS EMPRESAS SOBRE EL IMPACTO DE LOS BLOGS ............................................................... 54

3.6.3. EJEMPLOS DE LA RELACIÓN DE EMPRESAS CON LA WEB 2.0 .................................................................. 55

3.7. LOS PATRONES DE DISEÑO WEB 2.0 ................................................................................................... 56

3.7.1. APROVECHAR LA INTELIGENCIA COLECTIVA ....................................................................................... 58

3.7.2. LOS DATOS SON EL PRÓXIMO "INTEL INSIDE" .................................................................................... 63

3.7.3. INNOVACIÓN EN EL ENSAMBLAJE: .................................................................................................. 67

3.7.4. EXPERIENCIAS DE USUARIO RICAS ................................................................................................... 71

3.7.5. SOFTWARE MÁS ALLÁ DE UN SOLO DISPOSITIVO: ................................................................................ 75

3.7.6. BETA PERPETUO ........................................................................................................................ 79

3.7.7. APROVECHAR LA LARGA COLA ....................................................................................................... 82

3.7.8. MODELOS LIGEROS Y ESCALABILIDAD COSTO-EFECTIVA ........................................................................ 86

3.7.9. RESUMIENDO LOS PATRONES DE DISEÑO.......................................................................................... 91

3.8. TECNOLOGÍAS PARA WEB 2.0 ........................................................................................................... 92

3.8.1. LAS BASES DE INTERNET .............................................................................................................. 93 3.8.1.1 El modelo Cliente-servidor, protocolos y navegadores. ................................................................ 93 3.8.1.2. Vínculos y búsquedas ................................................................................................................. 94 3.8.1.3. La exploración y búsqueda en Internet. ....................................................................................... 96 3.8.1.4. PageRank ................................................................................................................................... 97

3.8.2. ESTRUCTURA, PRESENTACIÓN Y CONTENIDOS. ................................................................................... 98 3.8.2.2. HTML ......................................................................................................................................... 98


7

3.8.2.3. XML ......................................................................................................................................... 101 3.8.2.4. CSS ........................................................................................................................................... 104 3.8.2.5. CSS y XML ................................................................................................................................ 104 3.8.2.6. CSS y HTML .............................................................................................................................. 106

3.8.3. TECNOLOGÍAS DE SCRIPTING. ...................................................................................................... 108 3.8.3.2. Scripting en el cliente ............................................................................................................... 109 3.8.3.3. Document Object Model y Dynamic HTML ................................................................................ 111

3.8.4. SCRIPTING EN EL SERVIDOR ........................................................................................................ 112 3.8.4.2. PHP con fuente de datos........................................................................................................... 113

3.8.5. APLICACIONES WEB DE XML ..................................................................................................... 117 3.8.5.2. Web Services ............................................................................................................................ 117 3.8.5.3. Un acercamiento a SOAP y WSDL .............................................................................................. 120 3.8.5.4. WSDL ....................................................................................................................................... 120 3.8.5.5. Namespaces ............................................................................................................................. 121 3.8.5.6. Estructura de un WSDL ............................................................................................................. 122 3.8.5.7. SOAP ........................................................................................................................................ 123

3.8.6. FORMATOS DE WEB FEEDS ........................................................................................................ 125 3.8.6.2. ATOM ...................................................................................................................................... 127 3.8.6.3. RSS 2.0 ..................................................................................................................................... 129 3.8.6.4. Publicando feeds ...................................................................................................................... 130

3.8.7. APLICACIONES DE INTERNET ENRIQUECIDAS. ................................................................................... 130 3.8.7.2. Ajax.......................................................................................................................................... 131 3.8.7.3. Servidor WPC ........................................................................................................................... 134 3.8.7.4. Cliente WPC ............................................................................................................................. 136

3.8.8. MASHUPS Y EL DISEÑO PARA LA REUTILIZACIÓN ............................................................................... 138 3.8.8.2. Sindicación de contenidos con Web feeds ................................................................................. 139 3.8.8.3. Mashups basados en WPCs. ...................................................................................................... 141

3.8.9. TAGGING .............................................................................................................................. 145 3.8.9.2. Tagging en Flickr ....................................................................................................................... 146 3.8.9.3. Delicious y los marcadores sociales ........................................................................................... 149 3.8.9.4. Folksonomias ........................................................................................................................... 151

3.8.10. DESARROLLO DE PROYECTOS WEB 2.0 .......................................................................................... 152 3.8.10.2. Metodologías de desarrollo tradicionales .................................................................................. 152 3.8.10.3. Desarrollo ágil de software ....................................................................................................... 153 3.8.10.4. Extreme Programming .............................................................................................................. 154

3.8.11. EL DESARROLLO WEB ............................................................................................................... 159 3.8.11.2. Model-Driven Web Engineering con UWE UML ......................................................................... 161 3.8.11.3. Ejemplo de modelado de análisis y diseño en UWE UML ........................................................... 162 3.8.11.4. Plataformas y librerías de desarrollo de cliente y servidor ......................................................... 169 3.8.11.5. Proyectos existentes como base. .............................................................................................. 170

3.9. CONCLUSIÓN .............................................................................................................................. 172

4. MODELO TEÓRICO .......................................................................................................................... 173

4.1. INTRODUCCIÓN ........................................................................................................................... 173

4.2. PLANIFICACIÓN ........................................................................................................................... 174

4.2.1. ETAPAS, ACTIVIDADES Y DURACIÓN. ............................................................................................. 174

4.2.2. DIAGRAMA GANTT .................................................................................................................. 175

4.3. REQUERIMIENTOS ........................................................................................................................ 176

4.3.1. DEFINICIÓN DE ACTORES DE NEGOCIO ........................................................................................... 176

4.3.2. NECESIDADES GENÉRICAS DETECTADAS EN LOS ACTORES DE NEGOCIO.................................................... 176

4.3.3. DEFINICIÓN DE LOS ACTORES DE SISTEMA....................................................................................... 177

4.3.4. APLICACIÓN DE LOS PATRONES DE DISEÑO AL CONTEXTO DEL PROYECTO. ............................................... 177


8

4.3.4.1. Aprovechar la inteligencia colectiva .......................................................................................... 178 4.3.4.2. Los datos son el próximo "Intel Inside”. ..................................................................................... 180 4.3.4.3. Innovación en el ensamblaje. .................................................................................................... 182 4.3.4.4. Experiencias de usuario ricas. ................................................................................................... 185 4.3.4.5. Aprovechar la larga cola............................................................................................................ 187

4.3.5. REQUERIMIENTOS DEL SISTEMA .................................................................................................. 188

4.4. ANÁLISIS Y DISEÑO ...................................................................................................................... 190

4.4.1. ANÁLISIS DEL SISTEMA .............................................................................................................. 191 4.4.1.1. Listado de casos de uso de sistema ........................................................................................... 191 4.4.1.2. Descripción de casos de uso de sistema .................................................................................... 192 4.4.1.3. Diagrama de casos de uso del sistema....................................................................................... 197

4.4.2. DISEÑO DEL SISTEMA ................................................................................................................ 198 4.4.2.1. Modelo de Contenidos ............................................................................................................. 198 4.4.2.2. Modelo de Navegación ............................................................................................................. 199 4.4.2.3. Modelo de Presentación ........................................................................................................... 200 4.4.2.4. Modelo de Procesos y Diagramas de flujo de proceso................................................................ 213 4.4.2.5. Decisiones de diseño del sistema ................................................................................................... 230

4.5. CONCLUSIÓN .............................................................................................................................. 232

5. CONCRECIÓN DEL MODELO ............................................................................................................ 233

5.1. INTRODUCCIÓN ........................................................................................................................... 233

5.2. IMPLEMENTACIÓN ....................................................................................................................... 234

5.2.1. PROYECTOS OPEN SOURCE Y SERVICIOS DE BASE .............................................................................. 234 5.2.1.1. phpBB 2.0.23 ............................................................................................................................ 234 5.2.1.2. AjaxCORE 1.4 ............................................................................................................................ 234 5.2.1.3. YouTube – API PHP Gdata ......................................................................................................... 234 5.2.1.4. Picasa – API PHP Gdata ............................................................................................................. 235

5.2.2. ESBOZO DE LA ARQUITECTURA DEL SISTEMA. .................................................................................. 235 5.2.2.1. Dependencia de traza entre modelo relacional y modelo de contenidos .................................... 236 5.2.2.2. Dependencia de traza entre archivos PHP y clases de procesos. ................................................. 237 5.2.2.3. Dependencia de traza entre archivos HTML y clases de presentación. ........................................ 239

5.2.3. MODELO DE DESPLIEGUE ........................................................................................................... 241

5.2.4. PROTOTIPOS DE INTERFACES ...................................................................................................... 242

5.3. PUESTA EN MARCHA .................................................................................................................... 245

5.3.1. INFRAESTRUCTURA NECESARIA .................................................................................................... 245 5.3.1.1. Tecnología y requerimientos del nodo Cliente. .......................................................................... 245 5.3.1.2. Tecnología y características del nodo Servidor. .......................................................................... 245

5.3.2. CAPACITACIÓN DE LOS USUARIOS ................................................................................................. 246

5.4. PREFACTIBILIDAD ......................................................................................................................... 247

5.4.1. PREFACTIBILIDAD TÉCNICA ......................................................................................................... 247

5.4.2. PREFACTIBILIDAD OPERATIVA. ..................................................................................................... 247

5.4.3. PREFACTIBILIDAD ECONÓMICA. ................................................................................................... 247

5.5. CONCLUSIÓN .............................................................................................................................. 249

6. CONCLUSIONES .............................................................................................................................. 250

7. BIBLIOGRAFÍA ................................................................................................................................. 251


9

Índice de Figuras

ILUSTRACIÓN 1: EDAD Y SEXO DE AUTORES DE BLOGS. TECHNORATI 2008:................................................ 33

ILUSTRACIÓN 2: BLOGGERS PERSONALES, CORPORATIVOS Y PROFESIONALES. ........................................... 34

ILUSTRACIÓN 3: PERCEPCIONES SOBRE BLOGS Y MEDIOS TRADICIONALES. ................................................ 35

ILUSTRACIÓN 4: ESTADÍSTICAS DE HITWISE SOBRE TWITTER. ..................................................................... 41

ILUSTRACIÓN 5: TWITTER DE BARACK OBAMA, CANDIDATO PRESIDENCIAL PARA ESTADOS UNIDOS. ......... 42

ILUSTRACIÓN 6: CAPTURA DE PANTALLA DE HOUSINGMAPS. ..................................................................... 44

ILUSTRACIÓN 7: BANDA ANCHA EN HOGARES CON INTERNET EN ARGENTINA. .......................................... 48

ILUSTRACIÓN 8: BLOGS INDEXADOS POR TECHNORATI - MARZO DEL 2003 A MARZO DEL 2007. ................. 49

ILUSTRACIÓN 9: CONTENIDOS SUBIDOS A INTERNET POR USUARIOS ARGENTINOS. ................................... 50

ILUSTRACIÓN 10: USUARIOS QUE CONSULTAN SITIOS PARA INFORMARSE SOBRE PRODUCTOS ................. 51

ILUSTRACIÓN 11: SEGMENTACIÓN DE BLOG CORPORATIVOS. .................................................................... 53

ILUSTRACIÓN 12: OPINIONES DE DIRECTORES DE COMUNICACIONES Y RR. PP. SOBRE BLOGS. ................... 54

ILUSTRACIÓN 13: CAPTURA DE PANTALLA DE IDEASTORM DE DELL. ........................................................... 55

ILUSTRACIÓN 14: IMPACTO DE LOS EFECTOS DE RED. ................................................................................ 58

ILUSTRACIÓN 15: PROCESO DE CARGA DE IMAGEN EN FLICKR. .................................................................. 60

ILUSTRACIÓN 17: SUBIDA DE IMÁGENES EN FLICKR.................................................................................... 61

ILUSTRACIÓN 17: PORCENTAGENES DE IMAGENES PUBLICAS Y PRIVADAS EN FLICKR. ................................ 61

ILUSTRACIÓN 18: PRESENTACIÓN DE PRODUCTO EN AMAZON.COM.......................................................... 62

ILUSTRACIÓN 19: NUBE DE TAGS DE TECHNORATI. .................................................................................... 63

ILUSTRACIÓN 20: USO DE CREATIVE COMMONS EN FLICKR. ....................................................................... 65

ILUSTRACIÓN 21: NIVELES EN LA CADENA DE DATOS DE MAPAS DIGITALES. .............................................. 66

ILUSTRACIÓN 22: CATEGORIAS DE APIS EN PROGRAMMABLEWEB.COM ................................................... 68

ILUSTRACIÓN 23: USO DE PROTOCOLOS POR APIS. .................................................................................... 69

ILUSTRACIÓN 24: WIKI SOBRE API DE TWITTER. ......................................................................................... 69

ILUSTRACIÓN 25: CAPTURA DE PANTALLA DE GOOGLE DOCS. .................................................................... 72

ILUSTRACIÓN 26: CAPTURA DE PANTALLA DEL SITIO TIVO.COM ................................................................. 76

ILUSTRACIÓN 27: CAPTURA DE PANTALLA DEL SITIO EBAY MOBILE ............................................................ 77

ILUSTRACIÓN 28: CAPTURA DE PANTALLA DEL SITIO TN Y LA GENTE .......................................................... 77

ILUSTRACIÓN 29: CAPTURA DE PANTALLA DEL SITIO SHOZU. ..................................................................... 78

ILUSTRACIÓN 30: COMPARACIÓN DE LIBERACIONES DE FLICKR Y MICROSOFT WINDOWS. ......................... 80

ILUSTRACIÓN 31: CICLO DE DE DESARROLLO DE BETA PERPETUO............................................................... 80

ILUSTRACIÓN 32: LINEA DE TIEMPO DE GOOGLE MAPS 2005-2006 ............................................................ 81

ILUSTRACIÓN 33: REPRESENTACIÓN GRAFICA DE "LA LARGA COLA". .......................................................... 83

ILUSTRACIÓN 34: MODOS DE LISTAR NOTICIAS DE CLARIN.COM ................................................................ 84

ILUSTRACIÓN 35: EJEMPLO DE GOOGLE ADSENSE. .................................................................................... 87

ILUSTRACIÓN 36: INTERACCIÓN ENTRE CLIENTE Y SERVIDOR. .................................................................... 93

ILUSTRACIÓN 37: MODELO SIMPLE DE PÁGINAS Y VÍNCULOS. .................................................................... 95

ILUSTRACIÓN 38: MODELO TIPO MOÑO DE PÁGINAS Y VÍNCULOS. ............................................................ 96

ILUSTRACIÓN 39: MOTOR DE BUSQUEDA. ................................................................................................. 96

ILUSTRACIÓN 40: EJEMPLO DE USO DE HTML. ........................................................................................... 99

ILUSTRACIÓN 41: EJEMPLO DE USO DE XML CON CSS. ............................................................................. 106

ILUSTRACIÓN 42: EJEMPLO DE USO DE HTML CON CSS. ........................................................................... 107

ILUSTRACIÓN 43: ESTRUCTURA DOM CON DOM INSPECTOR EN FIREFOX. ................................................ 111

ILUSTRACIÓN 44: SCRIPTING DE SERVIDOR CON PHP. .............................................................................. 112

ILUSTRACIÓN 45: EJEMPLO DE USO DE PHP, HTML Y JAVASCRIPT............................................................. 116

ILUSTRACIÓN 46: EL PARADIGMA DE LOS WEB SERVICES. ........................................................................ 117

ILUSTRACIÓN 47: LAS CAPAS DE LOS ESTÁNDARES DE WEB SERVICES. ..................................................... 118


10

ILUSTRACIÓN 48: VISTA DE LA ORIENTACIÓN A SERVICIOS. ...................................................................... 118

ILUSTRACIÓN 49: LA INFRAESTRUCTURA DE WEB SERVICES. .................................................................... 118

ILUSTRACIÓN 50: LA INFRAESTRUCTURA DE WPC. ................................................................................... 119

ILUSTRACIÓN 51: RELACIONES EN UN ARCHIVO WSDL. ............................................................................ 122

ILUSTRACIÓN 52: ESTRUCTURA DE UN MENSAJE SOAP. ........................................................................... 124

ILUSTRACIÓN 53: CREACIÓN DE POST EN BLOGGER. ................................................................................ 127

ILUSTRACIÓN 54: WEB FEEDS EN FIREFOX. ............................................................................................... 130

ILUSTRACIÓN 55: SOLICITUDES SINCRÓNICAS Y RECARGAS DE PAGINA. ................................................... 132

ILUSTRACIÓN 56: RECARGAS ASINCRÓNICAS DE PAGINA UTILIZANDO AJAX. ............................................ 132

ILUSTRACIÓN 57: INTERACCIÓN CLIENTE-SERVIDOR CON AJAX. ............................................................... 133

ILUSTRACIÓN 58: CAPTURA DE PANTALLA DE GOOGLE READER. .............................................................. 140

ILUSTRACIÓN 59: PAGINA PERSONAL PÚBLICA DE GOOGLE READER. ....................................................... 140

ILUSTRACIÓN 60: EJEMPLO DE GOOGLE MAPS. ........................................................................................ 144

ILUSTRACIÓN 61: MUESTRA DE IMAGEN EN FLICKR. ................................................................................ 147

ILUSTRACIÓN 62: NUBES DE TAGS EN FLICKR. .......................................................................................... 148

ILUSTRACIÓN 63: EJEMPLO DE PÁGINA PERSONAL EN DELICIOUS. ........................................................... 150

ILUSTRACIÓN 64: METODOLOGÍAS TRADICIONALES DE DESARROLLO DE SOFTWARE. .............................. 153

ILUSTRACIÓN 65: METODOLOGÍA ÁGIL DE DESARROLLO DE SOFTWARE. .................................................. 155

ILUSTRACIÓN 66: DIAGRAMA DE CASOS DE USO DEL EJEMPLO DE UWE UML. .......................................... 163

ILUSTRACIÓN 67: MODELO DE CONTENIDOS DEL EJEMPLO DE UWE UML. ............................................... 163

ILUSTRACIÓN 68: MODELO DE NAVEGACIÓN DEL EJEMPLO DE UWE UML. ............................................... 165

ILUSTRACIÓN 69: MODELO DE ESTRUCTURA DE PROCESOS DEL EJEMPLO DE UWE UML. ......................... 165

ILUSTRACIÓN 70: EJEMPLO DE FLUJO DE PROCESOS DEL EJEMPLO DE UWE UML. .................................... 166

ILUSTRACIÓN 71: MODELO DE PRESENTACIÓN DEL EJEMPLO DE UWE UML. ............................................ 168

ILUSTRACIÓN 72: DIAGRAMA GANT DEL PROYECTO. ................................................................................ 175

ILUSTRACIÓN 73: DIAGRAMA DE CASOS DE USO DEL SISTEMA. ................................................................ 197

ILUSTRACIÓN 74: MODELO DE CONTENIDOS............................................................................................ 198

ILUSTRACIÓN 75: MODELO DE NAVEGACIÓN. .......................................................................................... 199

ILUSTRACIÓN 76: MODELO DE PRESENTACIÓN - VENTANA PRINCIPAL. .................................................... 201

ILUSTRACIÓN 77: MODELO DE PRESENTACIÓN - ÍNDICES DE RECLAMOS, EMPRESAS Y PRODUCTOS. ........ 202

ILUSTRACIÓN 78: MODELO DE PRESENTACIÓN - VISUALIZACIÓN DE UN RECLAMO. ................................. 203

ILUSTRACIÓN 79: MODELO DE PRESENTACIÓN - AGREGAR Y MODIFICAR UN RECLAMO. .......................... 205

ILUSTRACIÓN 80: MODELO DE PRESENTACIÓN - REPORTAR RECLAMO Y COMENTARIO. .......................... 207

ILUSTRACIÓN 81: MODELO DE PRESENTACIÓN - REGISTRAR USUARIO, LOGIN, RECUPERAR PW. .............. 208

ILUSTRACIÓN 82: MODELO DE PRESENTACIÓN - VISUALIZACIÓN DE DATOS DEL USUARIO. ...................... 209

ILUSTRACIÓN 83: MODELO DE PRESENTACIÓN - MODIFICACIÓN DE DATOS DE USUARIO. ........................ 210

ILUSTRACIÓN 84: MODELO DE PRESENTACIÓN - MENSAJES PRIVADOS DE USUARIOS............................... 211

ILUSTRACIÓN 85: MODELO DE PRESENTACIÓN - CARGA DE IMÁGENES Y VIDEOS. .................................... 212

ILUSTRACIÓN 86: MODELO DE ESTRUCTURA DE PROCESOS - 1. ................................................................ 214

ILUSTRACIÓN 87: MODELO DE ESTRUCTURA DE PROCESOS - 2. ................................................................ 215

ILUSTRACIÓN 88: DIAGRAMA DE FLUJO DE PROCESO - AGREGAR RECLAMO. ........................................... 216

ILUSTRACIÓN 89: DIAGRAMA DE FLUJO DE PROCESO - MODIFICAR RECLAMO. ........................................ 217

ILUSTRACIÓN 90: DIAGRAMA DE FLUJO DE PROCESO - ELEGIR EMPRESA. ................................................ 218

ILUSTRACIÓN 91: DIAGRAMA DE FLUJO DE PROCESO - ELEGIR PRODUCTO............................................... 219

ILUSTRACIÓN 92: DIAGRAMA DE FLUJO DE PROCESO - AGREGAR IMAGEN. .............................................. 220

ILUSTRACIÓN 93: DIAGRAMA DE FLUJO DE PROCESO - AGREGAR VIDEO. ................................................. 221

ILUSTRACIÓN 94: DIAGRAMA DE FLUJO DE PROCESO - AGREGAR COMENTARIO. ..................................... 222

ILUSTRACIÓN 95: DIAGRAMA DE FLUJO DE PROCESO - REPORTAR RECLAMO. .......................................... 223

ILUSTRACIÓN 96: DIAGRAMA DE FLUJO DE PROCESO - REPORTAR COMENTARIO. .................................... 223


11

ILUSTRACIÓN 97: DIAGRAMA DE FLUJO DE PROCESO - VALORAR RECLAMO. ............................................ 224

ILUSTRACIÓN 98: DIAGRAMA DE FLUJO DE PROCESO - VALORAR COMENTARIO....................................... 224

ILUSTRACIÓN 99: DIAGRAMA DE FLUJO DE PROCESO - SOCIAL BOOKMARKS. ........................................... 225

ILUSTRACIÓN 100: DIAGRAMA DE FLUJO DE PROCESO - COMENTARIOS RSS. ........................................... 225

ILUSTRACIÓN 101: DIAGRAMA DE FLUJO DE PROCESO - EMPRESAS RSS. ................................................. 226

ILUSTRACIÓN 102: DIAGRAMA DE FLUJO DE PROCESO - PRODUCTOS RSS. ............................................... 226

ILUSTRACIÓN 103: DIAGRAMA DE FLUJO DE PROCESO - REGISTRAR USUARIO.......................................... 227

ILUSTRACIÓN 104: DIAGRAMA DE FLUJO DE PROCESO - MODIFICAR USUARIO. ........................................ 227

ILUSTRACIÓN 105: DIAGRAMA DE FLUJO DE PROCESO - ELIMINAR USUARIO. .......................................... 228

ILUSTRACIÓN 106: DIAGRAMA DE FLUJO DE PROCESO - ENVIAR MENSAJE USUARIO. ............................... 228

ILUSTRACIÓN 107: DIAGRAMA DE FLUJO DE PROCESO - LOGIN. ............................................................... 229

ILUSTRACIÓN 108: DIAGRAMA DE FLUJO DE PROCESO - RECUPERAR PASSWORD. .................................... 229

ILUSTRACIÓN 109: DIAGRAMA DE FLUJO DE PROCESO - LOGOUT. ............................................................ 229

ILUSTRACIÓN 110: DEPENDENCIA DE TRAZA ENTRE MODELO RELACIONAL Y MODELO DE CONTENIDOS. . 237

ILUSTRACIÓN 111: DEPENDENCIA DE TRAZA ENTRE ARCHIVOS PHP Y CLASES DE PROCESOS. ................... 238

ILUSTRACIÓN 112: DEPENDENCIA DE TRAZA ENTRE ARCHIVOS HTML Y CLASES DE PRESENTACIÓN. ......... 240

ILUSTRACIÓN 113: MODELO DE DESPLIEGUE. .......................................................................................... 241

ILUSTRACIÓN 114: PROTOTIPO DE INTERFAZ - HOME. ............................................................................. 242

ILUSTRACIÓN 115: PROTOTIPO DE INTERFAZ - CARGA DE RECLAMO. ....................................................... 243

ILUSTRACIÓN 116: PROTOTIPO DE INTERFAZ - VISUALIZACIÓN DE RECLAMO Y CARGA DE COMENTARIO. 244

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Índice de Tablas

12

Índice de Tablas

TABLA 1: COMPARACIÓN DE BLOG CON PAGINAS TRADICIONALES. ........................................................... 33

TABLA 2: FRECUENCIA DE OPINIÓN DE BLOGGERS SOBRE EMPRESAS ......................................................... 51

TABLA 3: RUBROS CONSULTADOS POR USUARIOS DE INTERNET EN ARGENTINA ........................................ 52

TABLA 4: COMPARACIÓN ENTRE APLICACIONES DE ESCRITORIO Y APLICACIONES DE INTERNET. ................ 64

TABLA 5: EJEMPLOS DE APLICACIONES DE LAS FUERZAS DE LA LARGA COLA. ............................................. 84

TABLA 6: RESUMEN DE LOS PATRONES DE DISEÑO .................................................................................... 92

TABLA 7: NOMBRES Y DESCRIPCIONES DE ELEMENTOS CONTENEDORES EN FORMATOS DE FEEDS. .......... 126

TABLA 8: NOMBRES Y DESCRIPCIONES DE ELEMENTOS DE ENTRADAS EN FORMATOS DE FEEDS. ............. 126

TABLA 9: PRACTICAS Y ETAPAS DE EXTREME PROGRAMING ..................................................................... 159

TABLA 10: PLATAFORMAS Y LIBRERÍAS DE AJAX Y JAVASCRIPT. ................................................................ 170

TABLA 11: ETAPAS, ACTIVIDADES Y DURACIÓN DEL PROYECTO. ........................................................... 174

TABLA 12: PATRONES Y PRÁCTICAS DE DISEÑO QUE SERAN APLICADOS EN EL PROYECTO. ....................... 178

TABLA 13: ESTRUTURAS DE URLS DE LOS ELEMENTOS DEL SITIO. ............................................................. 231

TABLA 14: COSTOS DE SOFTWARE ........................................................................................................... 247

TABLA 15: COSTOS DE PROYECTOS Y APIS DE BASE .................................................................................. 248

TABLA 16: COSTOS DE RECURSOS HUMANOS .......................................................................................... 248

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Introducción

13

1. Introducción

1.1. Antecedentes

“Una persona decide comprar un equipo celular. Durante la primera semana de uso el equipo no

presenta ningún problema, pero luego encuentra una falla en uno de los botones de acceso al

menú de usuario. Decide llamar a la línea de atención al cliente de la empresa donde y luego de

una larga conversación y esperas en línea, la operadora le indica que ese tipo de fallas no están

cubiertas por la garantía.

Ante esta situación, decide buscar una posible solución en Internet. Ingresa su modelo de celular

y una breve descripción del problema. Rápidamente encuentra una página que parece tener la

temática correcta, y en esta encuentra que el problema que ha tenido no es algo fuera de lo

común sino que se presenta en muchas unidades de dicho modelo. Mediante imágenes, texto y

video otras personas (de lo que nota no es solo un sitio sino una comunidad de consumidores)

han aportado ya sus quejas y posibles soluciones al problema técnico. En base a esto logra reparar

el problema de forma momentánea y adhiere su queja a la de las personas que ya lo han hecho.

Al tiempo las quejas son tantas que el problema se hace conocido gracias a la difusión que

permite la comunidad y afecta la venta del producto. La empresa no logra entender la causa,

hasta que se topa en internet con el mismo sitio. Alarmada, no ve otra opción que involucrarse en

la comunidad, dialogando con los clientes y buscando reducir el impacto de su error inicial. Los

productos son reemplazados por nuevas unidades, y el problema de la persona, solucionado

finalmente. Ahora la empresa estará atenta a los problemas que se planteen en la comunidad

buscando dialogar rápidamente con los usuarios antes de que sea tarde, al igual que muchas otras

empresas que ya pasaron por situaciones similares.”

En los últimos años Internet ha evolucionado a un siguiente plano, el cual ha sido denominado

“Web 2.0”1. Este término no representa una tecnología en particular ni tampoco una versión en el

sentido computacional, sino que intenta expresar una nueva forma para lo que conocemos como

comunicaciones interpersonales basadas en la Internet.

Es complicado esbozar una definición para esta tendencia, ya que al ser justamente una tendencia

evoluciona rápidamente al pasar de los años. Una buena definición actual es la siguiente:”Un

fenómeno social en relación con la creación y distribución de contenidos en Internet, caracterizado

por la comunicación abierta, la descentralización de autoridad, la libertad para compartir y usar,

dentro de un enfoque que trata a las relaciones humanas y económicas como conversaciones.” (1)

El caso hipotético planteado anteriormente resultaba inimaginable no hace mucho tiempo y

ahora es posible gracias a esta tendencia, aunque todavia no se presente en Argentina una

comunidad con carácterísticas que puedan realizar esta función de acercamiento entre

consumidores y empresas.

1 Esta tendencia fue nombrada y definida por Tim O'Reilly en 2005 (66).


14

Por tanto, el objetivo de este trabajo es plantear una solución de forma Web 2.0 a esta situación

que se presenta como una necesidad todavía pendiente de cubrir en Argentina. Para esto será

necesario comprender los elementos que componen al concepto ambiguo de Web 2.0,

entendiendo sus formas y tecnologías, y sobre todo las interacciones entre estos con los usuarios,

para lograr que su aplicación en base a patrones de diseño2 genere un impacto en el contexto de

las “críticas de productos”, permitiendo la implementación de una comunidad online en base a

una selección de dichos elementos, que genere un espacio de diálogo entre consumidores y

empresas.

1.2. Situación problemática

Al realizar un análisis de la situación actual encontramos que el proyecto tiene actualidad y

pertinencia debido a:

La falta de espacios de comunicación entre empresas y consumidores con las características

potenciales que ofrece un proyecto de tipo Web 2.0 en la Argentina.

Los fuertes efectos producidos por opiniones de clientes en Internet en números casos

durante los últimos años. Podemos encontrar ejemplos diversos en los cuales las empresas

han presentado un dialogo oportuno, así como también otros casos en los que la empresas no

reaccionan a tiempo. Mencionamos algunos para acercarnos a la idea:

En Abril del 2008 Michael Arrington, luego de 36 horas de no tener conexión a Internet y

de quejarse vía telefónica a su proveedor de servicio (Comcast) sin recibir una solución,

decidió publicar un mensaje en su cuenta de Twitter3 al respecto. Por la popularidad de la

persona, casi de forma instantánea mucha gente empezó a hablar del tema en blogs, y

luego de 20 minutos, un ejecutivo de Comcast se comunico directamente con él para

ofrecerle su ayuda (2). Comcast cuenta con un programa de seguimiento de mensajes en

Twitter, como una de sus estrategias para atención al cliente. El problema podría haber

sido mucho mayor.

El caso particular de Comcast fue impulsado por el mismo empuje de la Web 2.0: En 2007

fue creado un blog llamado “Comcast must die” (3) por Bob Garfield, un conocido

columnista y personalidad de radio, con el objetivo de dar un lugar a los clientes de

Comcast para que publicaran sus quejas, agrupándolas en categorías como “Problemas de

Internet “, problemas de teléfono” y “problemas de TV“. Rápidamente olas de mensajes

empezaron a llevar haciendo el blog cada vez más y más popular (4) .

En 2004 fue publicado en BikeForums.net (5) un video en el cual se mostraba en algunos

segundos como violar la seguridad de un candado para bicicletas mediante el uso de un

bolígrafo. Este a notica se disperso rápidamente por Internet, y para cuando la empresa

Kryptonite pudo reaccionar, ya era muy tarde, pues la noticia era una de las más leídas del

2 John Musser, Tim O’Reilly y el equipo de O’Reilly Radar definieron 8 patrones de diseño para proyectos

basados en el concepto de Web 2.0. (9) Ver más detalles en marco teórico.

3 Twitter.com es un sitio de microbloging, un tipo de social media analizado en el marco teórico. En él los

usuarios pueden publicar mensajes personales accesibles a otros usuarios. Actualmente cuenta con más de

1 millón de usuarios (120).


15

país. Fue necesario retirar del mercado los candados del modelo afectado por la noticia y

los modelos similares y entregar a sus clientes nuevos candados. CNN calculó que la

empresa necesitaría decenas de millones de dólares para recuperar su imagen dañada (6).

Si Kryptonite, hubiera conocido la notica a tiempo, podría haber minimizado el daño

dialogando directamente con los consumidores al momento de que la noticia fue pública.

El impacto de un proyecto de este tipo en la sociedad argentina, como ser el acercamiento al

dialogo entre consumidores y empresas, al brindar un espacio en que las personas puedan

expresar sus críticas sobre productos o servicios que no están satisfaciendo sus necesidades,

permitiendo que las empresas escuchen en un lugar imparcial y centralizado a sus clientes, y

puedan actuar en pro de resolver rápidamente problemas para minimizar el daño a su imagen

corporativa en base al dialogo. De esta forma se logra empresas eficientes que para lograr

negocios rentables satisfagan a los clientes, produciendo así una mejora continua, en cuanto a

productos, procesos y atención al cliente.

A nivel mundial es notable una tendencia a la mejora en la atención al cliente (y más aun, en la

relación entre clientes y empresas) ya que por diversas razones, el cliente cada vez parece tener

más poder sobre las acciones de las empresas gracias a las plataformas colaborativas y abiertas de

la Web 2.0. En Internet ya hay voces que hablan de esto: “las empresas deben escuchar y

responder a los clientes en un mundo Web 2.0 o arriesgarse a perderlos ante aquellas empresas

que si lo hacen.” (7)

1.3. Problema

La situación problemática que inspiro al alumno a la elección del tema de estudio es la falta de un

espacio online con capacidades claras para generar el dialogo entre consumidores y empresas, en

base a las fallas presentes en sus productos o servicios. Para poder lograr cubrir esta necesidad

este tipo de herramienta debe contar con características solo provistas hasta ahora por la

tendencia Web 2.0 las cuales deberán ser estudiadas y comprendidas.

1.4. Objeto de estudio

Para lograr el objetivo del trabajo será necesario conocer a los participantes del problema, es

decir, los consumidores, las empresas e Internet como medio de comunicación y entorno

tecnológico.

Sera necesario comprender el concepto Web 2.0 y las formas en las que se manifiesta en la

actualidad en base al análisis de los social media: Redes sociales, blogs, wikis, podcasts, foros,

comunidades de contenidos y microblogging.

Se llevara a cabo un breve relevamiento sobre la situación actual de los usuarios de Internet en

Argentina. Sera importante analizar las tendencias que se plantean en las empresas del país, así

como también el nivel de participación de los consumidores en social medias existentes. Además,

un análisis de los alcances actuales de internet respecto a disponibilidad, ancho de banda y

posibilidad de uso móvil será necesario para conocer los alcances actuales y proyectados de

Internet en Argentina.


16

Continuando con el análisis de Web 2.0, el eje del estudio consistirá luego en el análisis de los

patrones de diseño para proyectos:

Aprovechar la inteligencia colectiva.

Los datos son el próximo "Intel Inside”.

Innovación en el ensamblaje.

Experiencias de usuario ricas.

Software más allá de un solo dispositivo.

Beta perpetuo.

Aprovechar la larga cola.

Modelos ligeros y escalabilidad costo-efectiva.

Una vez comprendidos estos, será necesario realizar un acercamiento a las tecnologías y

estándares presentes en Internet, que son la base de los proyectos que implementen dichos

patrones de diseño. Analizaremos los lenguajes de programación básicos presentes en el modelo

cliente servidor utilizado en de Internet (como ser HTML, XML y CSS) y las posibilidades de realizar

scripting en ambas partes de dicho modelo (a través de lenguajes como Javascript en cliente y

PHP en servidor).

Además, será necesario comprender conceptos básicos para la aplicaciones de los patrones como

ser Ajax para la implementación de interfaces de usuario enriquecidas, Web services como base

del software como servicios, Web feeds como medio de sindicación de contenidos, tagging y

folksonomias como manera de ordenamiento de información y por ultimo metodologías de

desarrollo agiles para el desarrollo de proyectos.

1.5. Campo de acción

En base al estudio y comprensión del objeto de estudio, se buscara la manera de implementar

una solución al problema planteado haciendo hincapié en la aplicación de los siguientes patrones

de diseño:






Con esto alcanzaremos el análisis diseño y desarrollo de un sitio online con las características de

una comunidad de contenidos de fuertes características Web 2.0, haciendo foco principal en la

manera en que los usuarios y empresas pueden participar de forma colaborativa y buscando

efectos de red que potencien estas colaboraciones a través de interfaces simples pero

enriquecidas, que den soporte a estos medios para la creación de una base de datos de valor

agregado que logre alcanzar “la larga cola” que se presenta en el dominio de productos y servicios

de Argentina, implementando el sitio sobre desarrollos propios y de terceros (mediante el uso y

adaptación de aplicaciones open source y APIs de servicios).


17

Como se verá en el marco teórico, todos los patrones de diseño están interrelacionados y por

tanto, si bien no se hará un fuerte enfoque en los patrones que quedan fuera del alcance, sí se los

mencionara o se hará referencia a estos.

1.6. Objetivos

1.6.1. Objetivo general

Lograr comprender los elementos que componen al concepto ambiguo de Web 2.0, entendiendo

sus formas y tecnologías, para lograr que su aplicación genere un impacto en el contexto de las

“criticas de productos”, permitiendo la implementación de un sitio web en base a una selección

de dichos elementos, que genere un espacio de diálogo entre consumidores y empresas.

1.6.2. Objetivos específicos

Estudiar y comprender el concepto Web 2.0 y las maneras en que se manifiesta a través del

análisis de los social media.

Estudiar y comprender la manera en que se relacionan usuarios y empresas con Internet.

Estudiar y comprender los patrones de diseño Web 2.0 y las prácticas que implican su

implementación.

Estudiar y comprender tecnologías y estándares que forman la base para el desarrollo de

proyectos Web 2.0.

Definir requerimientos de un sitio web que tome la forma de comunidad de contenidos en

torno al domino de las “criticas de productos”, en base a la aplicación de los patrones de

diseño mencionados en el campo de acción y el análisis realizado sobre usuarios y empresas.

Modelar dicho sitio y sus interfaces, en base a la aplicación de los patrones de diseño

mencionados en el campo de acción, considerando las tecnologías y estándares estudiados.

Implementar el sitio en base a la aplicación de los patrones de diseño mencionados en el

campo de acción, utilizando como base desarrollos open source y APIs de terceros.

1.7. Idea a defender / Propuesta a justificar / Solución a comprobar

Se buscara defender la idea de que la tendencia Web 2.0 existe en la actualidad y de que es la vía

más apropiada para generar espacios de comunicación abiertos y colaborativos, aprovechando las

virtudes que presenta Internet tanto por sus características como medio de comunicación así

como también como una red de alta disponibilidad.

Se propone por tanto la aplicación de patrones de diseño relacionados con esta tendencia al

dominio presentado en la relación clientes-empresas en Argentina, para lograr el diseño e

implementación de un sitio online con características aptas para funcionar como solución al

problema planteado.


18

En base al desarrollo amplio del marco teórico se buscara conocer a la tendencia Web 2.0, las

formas en que se manifiesta y las tecnologías y estándares que le dan soporte, para proceder

luego a realizar el análisis de requerimientos de la posible solución que debe funcionar como un

nexo colaborativo entre los usuarios de Internet y las empresas.

1.8. Delimitación del proyecto

Los patrones de diseño Web 2.0 cubren un concepto muy amplio por lo que es necesario limitar el

alcance del proyecto, concentrándonos en los objetivos específicos destacados y descartando los

siguientes patrones:

Software más allá de un solo dispositivo.

Beta perpetuo.

Modelos ligeros y escalabilidad costo-efectiva.

1.9. Aporte practico

Como se menciono en el punto 2, el proyecto generaría un impacto social sobre el dominio de la

relación entre clientes y empresas, al brindar un espacio en que las personas puedan expresar sus

críticas sobre productos o servicios que no están satisfaciendo sus necesidades, permitiendo que

las empresas escuchen en un lugar imparcial y centralizado a sus clientes, y puedan actuar en pro

de resolver rápidamente problemas para minimizar el daño a su imagen corporativa en base al

dialogo, y de esta forma lograr empresas eficientes que para lograr negocios rentables satisfagan

a los clientes, produciendo así una mejora continua, en cuanto a productos, procesos y atención

al cliente.

Una de las características de la Web 2.0 es justamente el balance que se presenta en el poder de

publicación y difusión de contenidos. Las características colaborativas y los efectos de red

presentes en soluciones Web 2.0 serian la vía de canalización de las opiniones de los clientes,

potenciando la publicación y de difusión entre ellos y hacia las empresas.

Por tanto los beneficiarios de la implementación del proyecto serian tanto clientes como

empresas en este caso. Y a su vez, el análisis de Web 2.0 permite generar un conocimiento que

puede ser aplicado posteriormente en otros dominios.

1.10. Aporte teórico

La novedad que presenta el proyecto es el estudio y análisis de la tendencia Web 2.0. Habiendo

comenzado visiblemente alrededor del 2005, ha presentado una evolución creciente y constante,

presentando cambios permanentes que apuntan a la democratización de Internet como medio de

comunicación. El proyecto considera el estudio de esta tendencia, en base a publicaciones de los

últimos años mayormente en lengua inglesa. Los patrones de diseño a los cuales hace referencia

este anteproyecto han sido publicados en Noviembre del 2007, lo que da un indicio de la novedad

del objeto de estudio.

El análisis de las tecnologías y estándares proveerá un mapa que abarcara (sin realizar un análisis

profundo) los conceptos necesarios para construir la base para desarrollos Web 2.0.


19

Por tanto, los resultados de este trabajo podrán ser posteriormente generalizados y aplicados a

variedad de dominios con objetivos comerciales o no comerciales. Esto quedara claramente

sentado, ya que el mismo análisis y comprensión de Web 2.0 se basa mayormente en el estudio

de casos existentes en los cuales se manifiesta esta tendencia, abarcando una gran variedad de

ámbitos.

1.11. Métodos de investigación.

El desarrollo de este trabajo final de grado se basara en métodos de investigación empíricos y

lógicos. Por métodos empíricos nos referimos a modelos de investigación basados en la

experiencia y pruebas sobre el objeto de estudio, permitiendo reconocer características y

relaciones esenciales de los elementos considerados en este, lo que dará las bases para estudios

descriptivos.

1.11.1. Métodos lógicos

En base a la aplicación del pensamiento aplicado a la deducción, análisis y síntesis, se aplicaran

métodos lógicos para:

Analizar la situación problemática y definir el problema que se busca solucionar con este

trabajo.

Relacionar adecuadamente el marco teórico a desarrollar con el objeto de estudio y el

campo de acción.

Realizar el diagnostico final que relacione lo cubierto por el desarrollo del marco teórico.

Relacionar los patrones de diseño Web 2.0 con la situación problemática para definir

requerimientos de la posible solución y el consecuente análisis y diseño en el desarrollo

del modelo teórico.

Realizar la implementación de la solución, considerando lo generado en el modelo teórico

y el uso de las herramientas disponibles.

1.11.2. Métodos empíricos

Sera necesaria la aplicación de métodos empíricos en el desarrollo del proyecto para:

Conocer el entorno del problema para lograr una descripción del marco contextual, a

través de búsquedas en motores de búsquedas generalista y específicos en búsqueda de

documentación y opiniones, participación en social medias como ser foros, blogs y

comunidades de contenidos, y la observación directa del comportamiento de los usuarios

de Internet en estos social media.

Realizar el desarrollo del marco teórico y su correspondiente diagnostico, en base a la

observación directa de social media y comunidades de contenidos existentes en la

actualidad, análisis de información de libros, blogs y opiniones de referentes en temáticas

relacionadas con el objeto de estudio.

Determinar los requerimientos del modelo teórico, en base al análisis de soluciones

implementadas en otros ámbitos y utilización de documentación de las tecnologías,

estándares, desarrollos open source y servicios de terceros.


20

Realizar el despliegue de la solución planteada, observando los resultados de su uso y la

participación de los usuarios sobre el sistema.

1.12. Enfoque metodológico.

1.12.1. Paradigma

Como se denota de las consideraciones anteriores, el paradigma a ser utilizado será el deducido

del análisis de la tendencia Web 2.0 y de los patrones de diseño que este trabajo considera. Como

se ve en lo analizado en el marco teórico, la Web 2.0 plantea un nuevo paradigma sobre el modo

de uso de Internet como medio de comunicación, por tanto, se buscara su comprensión y

aplicación.

Podemos tomar como marco para entender este paradigma los puntos en común que reúnen los

social media analizados en el marco teórico:

Participación: promueven la contribución y la retroalimentación de cualquiera que esté

interesado en opinar. Hace difusa la línea entre medios y audiencia.

Apertura: la mayoría de los servicios de tipo social media están abiertos a la

retroalimentación y la participación. Promueven la generación de comentarios y el

intercambio de información.

Conversación: Mientras que los medios clásicos de comunicación se basan en la

“emisión” (contenidos transmitidos o distribuidos a una audiencia), los social media están

vistos como una conversación ida y vuelta.

Comunidad: los social media permiten que se formen comunidades rápidamente y que se

comuniquen de forma efectiva. Estas comunidades comparten intereses en común, como

ser el amor a la fotografía, temas de política o programas de TV.

Conectividad: La mayoría de los tipos de social media prosperan en su inter conectividad,

haciendo uso de links a otros sitios, recursos y gente.

Podemos destacar que las características presentadas por las soluciones que pertenecen a las

tendencias Web 2.0 no son en su un conjunto de leyes, sino más bien un conjunto de guías e

ideales que dan un marco de desarrollo y orientación.

1.12.2. Proceso

El proceso necesario para el desarrollo del proyecto debe servir de guía para el logro secuencial

de los objetivos específicos planteados para este trabajo. Primeramente se realizara una

aproximación al objeto de estudio que será plasmada en el marco teórico, analizando el concepto

Web 2.0, los social media, los usuarios de internet como consumidores y empresas, los patrones

de diseño, y las tecnologías y estándares que dan base a los proyectos Web 2.0, y las

metodologías que permiten el desarrollo de este tipo de proyectos.

Posteriormente, se aplicara un desarrollo en cascada para el desarrollo de la solución. Se elije este

enfoque debido a que la aplicación de metodologías agiles como las analizadas en el marco

teórico queda fuera del alcance de este trabajo, y el enfoque de cascada permite lograr un esbozo

claro de una primera etapa del prototipo. Por tanto, se procederá al desarrollo de:


21

Identificación de requerimientos: en base a los patrones de diseño y la comprensión de la

realidad de los usuarios de Internet como consumidores y empresas, se definirán los

requerimientos del sistema en una primera etapa de su desarrollo. Estos serán la guía de las

siguientes etapas.

Análisis: Nuevamente, y en base a la aplicación de los patrones elegidos, se procederá con el

análisis del sistema que brindara la solución al problema planteado.

Diseño: Sobre el análisis obtenido se continuara con el diseño de la solución, seleccionando

las tecnologías, desarrollos de base y servicios en los cuales deberá basarse la

implementación, así como también el desarrollo de interfaces de usuario que den un enfoque

Web 2.0 al sistema.

Desarrollo: Sin profundizar sobre las características tecnológicas y técnicas del proceso, se

analizaran los resultados de la implementación del sistema. No se hace un fuerte foco en este

punto ya que el enfoque del trabajo apunta más a la comprensión del paradigma y su posible

aplicación como tal que a la búsqueda de especificaciones de desarrollo e implementación.

Despliegue: Se colocara a disposición de los usuarios el sistema de forma abierta y publica

como un sitio web, considerando lo desarrollado.

1.12.2. Métodos

Como se menciona anteriormente, se aplicara una metodología en cascada, considerando en cada

paso la aplicación de los patrones de diseños considerados dentro del alcance del proyecto,

considerando las prácticas recomendadas en cada uno.

Se mantendrá un bajo nivel de especificaciones técnicas del software a desarrollar haciendo foco

principal en las interfaces de los usuarios y las formas en que estos se relacionaran con el sistema

y la información.

1.12.3. Técnicas

Podemos separar las técnicas a ser aplicadas en los siguientes grupos:

Recopilación de requerimientos: Se considerara la aplicación de los patrones a la posible

interacción de los usuarios consumidores y empresas con el posible sistema en base a lo

analizado en el marco teórico. Se generara así un listado de requerimientos del sistema y por

tanto de las posibles interfaces necesarias para el desarrollo del sitio aplicando los patrones

de diseño web 2.0 que se analizaran en el marco teórico.

Análisis, Diseño y modelado: Se generara un modelado general del sistema en base a casos

de uso de acuerdo a UWE UML, aplicando los diagramas que se consideren necesarios para

mostrar las interacciones de los usuarios con el sistema. Además, se realizaran esbozos de las

interfaces haciendo foco en la manera en que los elementos de interacción se distribuyen y se

relacionan con el usuario, utilizando para esto modelado de HTML y descripciones de dichas

interacciones.

Implementación: En base a lo desarrollado en el punto anterior, se desarrollara la aplicación

utilizando como base desarrollos open source existentes, adaptando estos para alcanzar las

interfaces deseadas y cambiándolos con servicios de terceros para por ejemplo agregar


22

capacidades multimedia al sitio. Se llevara a cabo una descripción de esto, sin profundizar en

detalles técnicos focalizándose mayormente en las funcionalidades de la implementación.

Herramientas: Para el desarrollo del proyecto se utilizaran las siguientes herramientas:

NetBeans PHP IDE: Esta aplicación provee un ambiente de desarrollo integrado para la

creación de aplicaciones PHP, con soporte completo de HTML, Javacript y CSS.

MagicDraw 1.51: Herramienta completa para UML, que permitirá el desarrollo de

modelos para las diferentes etapas del proyecto.

MagicUWE 1.2: Plugin para agregar modelos y diagramas de UWE UML a MagicDraw 1.5.

Microsoft Project 2003: Utilizado para el desarrollo de la planificación del proyecto,

mediante diagramas Gantt.

Microsoft Word 2007: Permitirá el desarrollo de la presentación del anteproyecto y del

proyecto de grado, con sus destacadas capacidades de procesamientos de textos.

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Marco Contextual

23

2. Marco Contextual

2.1. Entorno del objeto de estudio

Hemos definido previamente el objeto de estudio al desarrollar la introducción al proyecto,

observando que se presenta como un contexto amplio y complejo.

Internet en la actualidad se muestra como un contexto donde las personas desarrollan diversos

aspectos de du vida diaria, y esto es un hecho que se ha potenciado cada vez más durante los

últimos 10 o 15 años. Alrededor del 2004 este cambio ha sido más notorio: lo que era

previamente una red para obtener información publicada por fuentes unilaterales, se convirtió en

un autentico lugar de interacción donde la voz de cada persona tiene prácticamente un alcance

ilimitado. Esta revolución ha sido denominada Web 2.0.

Es un concepto ambiguo y complejo de entender, especialmente por la velocidad con la que se ha

desarrollado y por la magnitud de los cambios sociales que está produciendo. Gran parte del

esfuerzo de este trabajo será observar y comprender este cambio, para lo cual nos acercaremos a

los aspectos sociales y tecnológicos, y por lo tanto no podemos extendernos demasiado en este

apartado.

Por otra parte, se ha decidido enfocar además el estudio del comportamiento de los usuarios de

Internet en Argentina, para lograr aproximarnos a la relación consumidor –empresa. La evolución

histórica de esta relación ha presentado fuertes cambios y quiebres en el paradigma.

Inicialmente las empresas se orientaban a la producción, y los clientes solo podían consumir lo

que se presentaba en el mercado. Alrededor de 1950 se produce un primer quiebre en dicho

paradigma, donde las empresas empiezan a orientarse a las ventas, ya que fue necesario focalizar

el esfuerzo en vender lo que se producía ante el creciente nivel de competencia que se

presentaba en los mercados. Posteriormente se produce un nuevo quiebre alrededor de 1970,

surgiendo la actual orientación al marketing en donde las empresas notaron que eran los deseos y

necesidades de los consumidores los factores que realmente conducían el proceso.

Solo en esta última etapa surge como un factor de influencia el consumidor. Aunque es claro que

la balanza de poder sigue inclinada del lado de las empresas, ya que son las que cuentan con los

recursos para hacer escuchar su voz, mientras que un consumidor individual puede pasar

desapercibido.

En este punto es donde podemos hacer una referencia a Internet. Como mencionamos

anteriormente, hoy por hoy un usuario de Internet cuenta con medios para hacerse escuchar

prácticamente sin límites de costos ni barreras burocráticas. Hoy en día cualquier persona puede

publicar un contenido en un social media, y si un grupo de personas considera que sus palabras

son importantes, su voz se potenciara y llegara a tomar un gran peso. Existen múltiples casos que

pueden ser analizados para demostrar esta nueva realidad actual, como ser los mencionados en el

análisis de la situación problemática realizado previamente, o los que serán mencionados en el

desarrollo del marco teórico.


24

Es posible entonces trasladar esto a la relación cliente-empresa, y notar como la aplicación de

soluciones sociales basadas en Internet es una herramienta poderosa para inclinar cada vez más

la balanza a un nivel de equilibrio, y para generar un nuevo quiebre en el paradigma.

2.2. Relación tesista y objeto de estudio

El autor de este trabajo se ve inmerso en el entorno mencionado previamente y por tanto

afectado directamente con los problemas que se plantearon en la situación problemática. Por una

parte, ha desarrollado numerosos trabajos y aplicaciones que han utilizado a Internet como el

medio de soporte, observando una impresionante relación entre las necesidades de inversión y

los resultados que pueden obtenerse por las características del medio.

En los últimos años ha participado activamente en comunidades online centradas en diversas

temáticas, obteniendo apoyo y soluciones de otros miembros de las comunidades que de otra

manera hubieran sido muy difíciles de conseguir. Es decir, ha visto y experimentado el poder que

tienen los social media como una herramienta social de colaboración.

Por otra parte se encuentra inmerso en un mundo donde es necesario vincularse

permanentemente con empresas para satisfacer necesidades y ha podido observar la notoria

diferencia de poder que existe entre los consumidores y las empresas.

En Argentina no se encuentra en la actualidad un espacio libre y abierto donde los consumidores

puedan expresarse sobre las empresas y sus productos y servicios, ni donde compartir sus

opiniones con otros consumidores que puedan estar en situaciones similares.

Además ya hemos planteado la ambigüedad que existe aun en torno al concepto Web 2.0, y por

tanto el problema de no poder aprovechar su potencial.

Por tanto el problema planteado anteriormente requiere el desarrollo de este trabajo para lograr

comprender el concepto y lograr su aplicación a la relación cliente-empresa.

2.3. Análisis de los problemas observados

Como se menciono previamente no existe en la actualidad en Argentina un espacio que cuente

con las características para aprovechar las fortalezas de la Web 2.0 que analizaremos en el marco

teórico.

Recordemos cuales son los puntos clave que presentan los social media (concepto analizado al

introducir el paradigma del enfoque metodológico):










25






A la fecha del comienzo de este trabajo no se han encontrado medios online o no online en

Argentina que presenten estas características. Por tanto, se encuentra la necesidad de generar

una solución de software que pueda abordar el problema y se entiende que análisis de la

tendencia Web 2.0 es el medio por el cual se podrá aproximar la solución.

El desarrollo del marco teórico necesario para este proyecto implicara el análisis de diversos

proyectos que podrían ser considerados como similares, pero que se encuentran en otros

entornos. Especialmente notaremos esto en el estudio de comunidades de contenidos. Por tanto,

no se profundizará en este aspecto en el desarrollo del marco contextual.

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Marco Teórico

26

3. Marco Teórico

3.1. Introducción

El desarrollo del marco teórico buscara comprender los elementos que componen al concepto

ambiguo de Web 2.0, entendiendo sus formas y tecnologías, lo que será la base para el futuro

desarrollo de un modelo teórico y la concreción de dicho modelo.

En esta sección buscaremos cumplimentar los siguientes objetivos específicos:





implementación.


proyectos Web 2.0.

Abarcar todos estos puntos es una tarea desafiante que requiere una ardua investigación y

consulta de diversas fuentes. Si los objetivos específicos son alcanzados el autor de la tesis

obtendrá un conocimiento general que podrá plasmar en el documento, y dicho conocimiento

podría luego ser generalizado para diferentes contextos y proyectos.


27

3.2. The Cluetrain Manifesto: los mercados son conversaciones.

En el año 1999 Internet ya había marcado una revolución en la sociedad mundial en el paso de sus

primeros años de vida. En ese momento, y al igual que ahora, la gente vivía su vida diaria sin

tomar conciencia de los pequeños cambios que permanentemente esta revolución les imponía en

su entorno, en sus actividades, en sus negocios y especialmente en la forma de comunicarse y

relacionarse con otras personas. Estos cambios eran permanentes y lógicos, sutiles y hasta casi

naturales. Y definitivamente, eran rápidos y profundos.

En un intento de interpretar la situación, surge en Abril de dicho año The Cluetrain Manifesto. 4La

interpretación realizada por sus autores propone 95 conclusiones ordenadas como un manifiesto,

analizando y describiendo el impacto en consumidores, organizaciones, y en la relación entre

estos.

Esta publicación afirma que la interconexión masiva de las personas y negocios han producido

cambios en las condiciones de los mercados, en base a la rápida expansión de Internet y la

globalización económica. La característica principal de estos nuevos mercados es el hecho de que

las organizaciones y los consumidores se encuentran implicados en una gran conversación

altamente interrelacionada, donde las personas tienen una voz cada vez más fuerte.

Para obtener una breve idea del contenido del manifiesto leyendo algunas de sus primeras

conclusiones (8):

1. Los mercados son conversaciones. 2. Los mercados consisten de seres humanos, no de sectores demográficos. 3. Las conversaciones entre seres humanos suenan humanas. Se conducen en una voz

humana. 4. Ya sea transmitiendo información, opiniones, perspectivas, argumentos en contra o notas

humorosas, la voz humana es abierta, natural, sincera. 5. La gente se reconoce como tal por el sonido de esta voz. 6. La Internet hace posible tener conversaciones entre seres humanos que simplemente

eran imposibles en la era de los medios masivos de comunicación. 7. Los hiper-enlaces socavan a las jerarquías. 8. En los mercados interconectados como entre empleados intraconectados, la gente utiliza

nuevas y poderosas formas de comunicación. 9. Las conversaciones en red hacen posible el surgimiento de nuevas y poderosas formas de

organización social y de intercambio de conocimientos. 10. Como resultado los mercados se vuelven más inteligentes, más informados, más

organizados. La participación en un mercado interconectado hace que las personas cambien de una manera fundamental.

11. Las personas que participan en estos mercados interconectados han descubierto que pueden obtener mucha mejor información y soporte entre sí mismos que de los vendedores. Ya basta de la retórica corporativa acerca de añadir valor a productos de consumo general.

4 Publicado como libro en Enero de 2000 (117), originalmente fue presentado en un sitio web (119) en Abril

de 1999, y en la actualidad sigue disponible en dicho sitio, encontrando además las firmas de muchos

líderes de empresas y medios al manifiesto.


28

12. No hay secretos. El mercado en red sabe más que las empresas acerca de sus propios productos. Y ya sea que las noticias sean buenas o malas, se las comunican a todo el mundo.

13. Lo que ocurre en los mercados, también sucede entre los empleados. Una construcción metafísica llamada "Compañía" es lo único que queda entre los dos.

14. Las corporaciones no hablan en la misma voz que estas conversaciones interconectadas. Para su "audiencia objetivo", las compañías suenan huecas, opacas, literalmente inhumanas.

15. En sólo unos pocos años, la actual "voz" homogenizada del mundo de los negocios -- el sonido de misiones corporativas y folletos oficiales -- parecerá tan rebuscada y artificial como el lenguaje de la corte francesa en el siglo 18.

Con un estilo directo y claro, estas conclusiones y las 80 restantes expresan una realidad que en

los últimos años se ha vuelto cada vez más clara, pero que definitivamente aun está en camino.

Estos escritos fueron claramente adelantados a su tiempo en su época de publicación: Internet

aun no estaba preparada para los cambios. Tampoco los estaban sus usuarios y mucho menos las

empresas. Pero el cambio ya estaba gestándose y de forma vertiginosa.

Entre el año 1999 y el año 2004 muchos avances surgieron y transformaron Internet, y la forma

en que todos los jugadores se desempeñaron en ella. Esto fue analizado como una tendencia, la

cual fue llamada: Web 2.0. 5

3.3. La Web 2.0

El termino Web 2.0 no representa una tecnología en particular ni tampoco una versión en el

sentido computacional, sino que intenta expresar una nueva forma para lo que conocemos como

comunicaciones interpersonales basadas en la Internet.

Es complicado esbozar una definición para esta tendencia, ya que al ser justamente una tendencia

evoluciona rápidamente al pasar de los años.

En Noviembre del 2007 John Musser, Tim O’Reilly y el equipo de O’Reilly Radar en su publicación

“Web 2.0 Principles and Best Practices” (9) desarrollan su teoría en base a la formulación de la

siguiente definición: “La Web 2.0 es un conjunto de tendencias económicas, sociales y

tecnológicas que de manera colectiva forman la base para la siguiente generación de Internet – un

medio más maduro y distinguido caracterizado por la participación de los usuarios, la apertura y

los efectos de red”.

Por otra parte Alberto Ortiz de Zárate Tercero en busca de desarrollar su libro sobre las

influencias y usos de Blogs en la comunicación entre empresas y consumidores, desarrolla una

definición algo más cercana a los usuarios y el impacto social: “La Web 2.0 es un fenómeno social

en relación con la creación y distribución de contenidos en Internet, caracterizado por la

comunicación abierta, la descentralización de autoridad, la libertad para compartir y usar, dentro

de un enfoque que trata a las relaciones humanas y económicas como conversaciones.” (1)

5 Esta tendencia fue nombrada y definida por Tim O'Reilly en 2004 (66)


29

Notamos que ambas definiciones con orígenes distintos tienen fuertes puntos en común entre

ellas, y también con las conclusiones de The Cluetrain Manifesto.

Claramente, nos encontramos ante un nuevo nivel de la revolución que originalmente genero el

surgimiento de Internet.

El gran desafío que se presenta en la actualidad es lograr comprender estos cambios y el poder de

esta tendencia, capitalizando la experiencia y aplicándolo entornos sociales donde aun no ha

logrado su impacto. El desarrollo planteado en “Web 2.0 Principles and Best Practices” indica que

esta tendencia se manifiesta en una gran variedad de formas y tecnologías, y busca generar

patrones claros que permitan en primer lugar comprender lo que implica que algo sea Web 2.0, y

en segundo lugar y consecuentemente poder aplicarlos a productos y organizaciones.

Como mencionamos anteriormente, este trabajo persigue el objetivo de generar una solución de

tipo Web 2.0 para generar un espacio de dialogo y conversación entre consumidores y empresas.

Por tanto, es necesario conocer en mayor profundidad la relación es estos con Internet.

3.4. Social Media: los nuevos medios sociales.

Es complicado expresar con claridad y definir a la forma en que la Web 2.0 se manifiesta en forma

práctica. La Web 2.0 ha impactado en diferentes formas en el plano social, por lo que desarrollar

todas las posibilidades sería muy extenso. Recordamos entonces que este trabajo apunta a

analizar la relación entre los consumidores y las empresas.

Para acotar el campo de análisis podemos basarnos en el término “social media” y en la siguiente

definición de Antony Mayfield de Enero del 2008 (10):

Social media puede ser entendido como un grupo de nuevos tipos de medios online, donde la

mayoría comparten las siguientes características:














En base a esta definición pueden definirse siete tipos básicos de social media, aunque Mayfield

aclara: esta clasificación puede cambiar en base al surgimiento de nuevos social media, ya que la

innovación y el cambio han sido moneda corriente en los últimos años y meses (como dijimos


30

antes, la Web 2.0 es una tendencia, y las tendencias evolucionan rápidamente). Tenemos

entonces:

1. Redes sociales.

2. Blogs.

3. Wikis.

4. Podcasts.

5. Foros.

6. Comunidades de contenidos.

7. Microblogging.

Es necesario desarrollar estos conceptos y analizar ejemplos de cada uno, y de esta forma

acercarnos al ambiente donde se realizan las interacciones entre consumidores y las empresas.

En base a la visión de dicho autor, indagaremos en los puntos mencionados agregando conceptos

de otros. Del análisis y descripción de dichos social media surgirán tres conceptos que será

necesario considerar: sindicación de contenidos, APIs de servicios y mashups.

3.4.1. Redes sociales

Estos sitios permiten a la gente construir páginas web personales y generar nexos con otros

usuarios para compartir contenidos y comunicarse. Los usuarios al unirse al servicio deben crear

un perfil personal, para luego empezar a construir una red conectándose con amigos y contactos

que están en la red social del sitio, o invitando a otras personas a unirse a la red social.

Estas comunidades mantienen el interés de sus miembros mediante estrategias simples: siéndoles

útiles y proveyendo servicios de entretenimiento o que los ayudan a expandir sus redes.

Si bien existen cientos de redes sociales6 de diferentes tamaños y características, podemos

analizar algunos de los líderes para acercarnos más al concepto:

3.4.1.1. Facebook

En el año 2004 Mark Zuckerberg de tan solo 19 años de edad crea una comunidad online para ser

utilizada por los estudiantes de la Universidad de Harvard (11). Posteriormente decide convertir a

su red llamada “TheFacebook” en Facebook, esta vez abierta a todo público, creciendo de forma

vertiginosa contando en la actualidad con más de 110 millones de usuarios activos y la red social

con mas tráfico y 4° sitio con más visitas de Internet (12).

En esta red social los usuarios comparten imágenes, mensajes, afinidades e intereses comunes.

Pero comenta Antony Mayfield que el factor que llevo al éxito a esta red social fue su decisión de

“abrirse” y permitir el desarrollo aplicaciones que interactúen con los usuarios del sitio a cualquier

persona que lo desee mediante el uso de sus APIs7, sin costo alguno. Esto ha permitido el

surgimiento de una infinidad de aplicaciones, permitiendo a sus usuarios realizar un abanico de

6 Podemos encontrar un listado de las redes sociales más relevantes y datos sobre estas en (121).

7 En capítulos posteriores se realizara un desarrollo más profundo sobre las APIs de Facebook. Puede

encontrarse más información en (122).


31

actividades, desde cómo ser jugar al ajedrez, adherirse a causas, compartir fotos y hasta reglar

flores o mascotas virtuales.

3.4.1.2. MySpace

El proyecto nació a finales del 2003, siendo en la actualidad una de las redes sociales más

conocidas y usadas. El objetivo inicial de la empresa fue el de generar un espacio para que

músicos independiente pudieran difundir y compartir sus trabajos. Rápidamente creció y

evoluciono marcando tendencia en el concepto de Web 2.0, convirtiéndose en el sitio elegido por

más de 200 millones de usuarios a nivel mundial, que comparten diariamente en sus perfiles

imágenes, videos, canciones, y opiniones, comunicándose con amistades y generando

comunidades.

Siguiendo la tendencia de apertura demostrada por Facebook, a finales del 2007 MySpace une

fuerzas con Google (13) para desarrollar un conjunto de APIs llamadas OpenSocial8, en busca de

estandarizar y simplificar la creación de aplicaciones para redes sociales.

3.4.1.3. Orkut

Es la red social creada por Google en el 2006, con un objetivo similar al de otras redes sociales

como MySpace y Facebook, ofreciendo a los usuarios crear perfiles y compartir sus intereses.

Originalmente fue pensada para abarcar mayoritariamente a usuarios de Estados Unidos, pero

perdió terreno en ese mercado. Igualmente es una de las redes con mayor cantidad de usuarios

repartiéndose principalmente entre Estados Unidos (17.51%), India (17.37%) y Brasil(51.2%). (14)

Desde el momento en el que se empezó a desarrollar el proyecto OpenSocial, Google incluyo a

Orkut en la lista de sitios que darían soporte a dicho conjunto de APIs, como parte de la estrategia

para potenciar el desarrollo de su red social. (15)

3.4.1.4. LinkedIn

Esta es una de los mejores ejemplos de la aplicación de una red social sobre un nicho: LinkedIn es

una red social de profesionales. En su sitio la compañía expresa su filosofía de forma directa:”Las

relaciones importan. Tus relaciones profesionales son la clave de tu éxito profesional. Nuestro

objetivo es ayudarte a ser más efectivo en tu trabajo diario y abrirte las puertas a nuevas

oportunidades usando los vínculos profesionales que ya tienes”. A su vez, indica que cuenta con

más de 30 millones de profesionales de todo el mundo, cubriendo 150 industrias diferentes.

3.4.1.5. Resumen sobre redes sociales

Esta red social permite que los usuarios construyan su red de contactos profesionales y de

negocios por medio del sitio, en el que crean sus perfiles en base a sus experiencias laborales y

académicas, pudiendo también incluir sus relaciones con otros miembros de la red social,

especificando por ejemplo, donde y cuando participo en un proyecto o empresa con un miembro

en particular.

8 Puede encontrarse más información sobre OpenSocial en (123).


32

Además, los usuarios que buscan contratar publiquen trabajos y sus requerimientos, permitiendo

que los usuarios en busca de trabajo analicen su red de contactos y por tanto, poder ser

presentados con los emperadores por medio de algún contacto de la red.

Al igual que otras redes sociales, ha unido fuerzas con Google para el desarrollo de OpenSocial.

(16)

Como podemos notar, la fuerte estrategia de apertura de Facebook y su consecuente crecimiento

en el mercado de las redes sociales ha hecho reaccionar a los otros jugadores grandes de las redes

sociales, sumando fuerzas con el objetivo de crear la estandarización en OpenSocial en busca del

mismo efecto producido por Facebook: que cualquier desarrollador pueda generar aplicaciones

que interactúen con miembros de las redes sociales. Analizaremos ambos casos más adelante.

Este tipo de proyectos no solo han creado una revolución social sino también económica: Se

estima que el costo de MySpace es de10 mil millones y el de Facebook es de 15 mil millones de

dólares. Algo impresionante cuando consideramos que empresas con infraestructuras gigantescas

tienen un valor similar: se estima que el valor de YPF es de 15 mil millones de dólares, el mismo

valor que Facebook. (17)

La consultora de marketing Experian presento un informe sobre la actualidad y el rol futuro de

estos social media, indicando que en el año 2008 tomarían mayor fuerza y comentando que “el rol

será más importante que nunca, por lo que ninguna empresa, gobierno u ONG puede permitirse

ignorarlas.”. (18)

3.4.2. Blogs

Quizás la forma por excelencia de los social media: los blogs (termino derivado de “web log”).

Podemos tomar la siguiente definición de Alberto Ortiz de Zarate: “Un blog es un sitio web,

frecuentemente actualizado, compuesto de artículos generalmente breves que se disponen en

orden cronológico inverso, donde uno o varios autores escriben con libertad, mediante una

herramienta de publicación muy sencilla de utilizar”. (1)

El autor indica que esta definición no llega a transmitir las cualidades que hacen a los blogs tan

relevantes e interesantes en la actualidad. Expresa la importancia de analizar el concepto desde

varios puntos de vista. Tomamos algunos de estos para acercarnos más al concepto:

3.4.2.1. El blog como una herramienta de publicación de contenidos

Un blog es un sitio web que presenta algunas características diferentes a las de las páginas web

tradicionales. Se trata básicamente de un editor de contenidos simple e intuitivo, en un formato

de publicación para los visitantes que busca privilegiar los contenidos frente a la forma.

El blog está compuesto por las entradas (también llamados “posts”) publicados, ordenados en

forma cronológica comenzando por los más nuevos, y algunos elementos en una barra lateral que

ayudan a la navegación del sitio. Los servicios de blogs en la actualidad permiten que los posts no

se limiten solo a texto, contando con una gran simplicidad al momento de agregar contenidos

multimedia como ser imágenes o videos, aumentando las posibilidades expresivas de los autores.


33

Y a su vez, permite la colaboración de los visitantes del blog, pudiendo estos realizar comentarios

sobre los posts publicados.

Una de las características que han impulsado el uso masivo de blogs es la facilidad que se

presenta para crear un blog y publicar contenidos en el. Las opciones que se presentan permiten

que personas con poco o ningún nivel de conocimiento técnico puedan acceder a la publicación

de un blog, a través de servicios gratuitos como del el caso de Blogger (19) de Google o

Wordpress (20), donde la creación de un blog es posible en tan solo unos pocos minutos,

eligiendo un diseño en base a algunas opciones y sin tener que preocuparse el usuario por el

servicio de hospedaje del sitio. Wordpress por su parte, también permite bajar el código abierto e

instalar el blog en un servidor personal, y ambos servicios permiten a desarrolladores interactuar

con los servicios mediante APIs9.

Podemos entender algo mejor el concepto en base a la siguiente tabla comparativa:

Blog Página Tradicional

Muy fácil de editar Editada por un experto (webmaster)

Se actualiza con mucha frecuencia Los contenidos tienden a ser permanentes

El coste es cero o marginal Conlleva un coste de mantenimiento

Se estructura por orden cronológico Se estructura en áreas visuales

Permite la participación vía comentarios La participación está muy limitada

Privilegia el contenido Privilegia el aspecto visual, el diseño

Nos sorprende cada día Permanece relativamente estable Tabla 1: Comparación de blog con paginas tradicionales.

3.4.2.2. El blog como medio de comunicación y tendencia social

Como mencionamos anteriormente, el blog es uno de los social media, funcionando como medio

alternativo a los medios de comunicación masivos. La potencia del blog como medio está en la

condición bidireccional de la comunicación que establece, y la facilidad que brinda para formar

redes con otros blogs y otros medios.

A nivel interno el blog potencia la

comunicación al permitir la ágil

publicación opiniones por parte de

los autores, y también la rápida

respuesta a estas opiniones por parte

de los lectores, al encontrar la

posibilidad de publicar un comentario

en el post, quedando tanto el post

original y los comentarios a la

disposición de nuevos visitantes que

puedan ingresar al sitio.

9 Podemos encontrar información sobre las APIs de Wordpress en (124) y las APIs de Blogger en (125).

Ilustración 1: Edad y sexo de autores de blogs. Technorati 2008:


34

Pero como mencionamos anteriormente, no solo se realiza un dialogo entre autores y visitantes,

sino también en la interacción entre blogs a través de la llamada blogosfera, concepto que

analizaremos más adelante.

Por otra parte, el grupo de personas que mantiene activamente blogs (llamados “bologgers”) es

un grupo muy heterogéneo a nivel mundial.

Según el estudio de Technorati10 (21) del 2008 indica que dos tercios de los bloggers son

hombres, y solo la mitad del total de bloggers pertenece al rango etario de 18-34.

Además, indica que en general son profesionales o gente con considerable nivel académico y que

el 7% del total de blogs existentes se originan en Sud América.

A su vez, el estudio agrupa a los blogs en tres categorías: personales, profesionales y corporativos.

Definamos estas categorías y veamos algunos ejemplos:

Personales: La temática abarca intereses personales no relacionados a cuestiones laborales.

Profesionales: Blogs sobre la industria o profesión del autor, pero sin ser blogs oficiales de

alguna empresa.

Corporativos: Los autores escriben sobre una empresa desde una posición oficial.

Cuatro de cada 5 bloggers mantiene

blogs personales. Aproximadamente la

mitad de los bloggers mantiene blogs

profesionales, y finalmente, un 12%

son autores de blogs corporativos.

Pero por supuesto, estos grupos no

son mutuamente excluyentes.

Más de la mitad de los bloggers

profesionales y corporativos escriben

también posts personales, ya sea en

los mismos blogs o en otros de su

misma autoría.

Por último, cabe mencionar que los blogs están tomando cada vez más relevancia como un medio

de comunicación confiable y relevante, compitiendo cada vez más con los medios tradicionales de

comunicación.

En el mismo estudio mencionado anteriormente encontramos que existe una sensación general

de que los blogs están siendo tomados seriamente como fuentes de información. 37% de los

bloggers han sido citados en medios tradicionales debido a alguna de sus publicaciones en sus

blogs. La mitad de los bloggers creen que los blogs serán una fuente primaria de noticias y

10 Technorati es un sitio buscador especializado en blogs, que se ha convertido en autoridad en el tema y

una de las principales referencias. Realiza cada año desde el 2004 un estudio para conocer el estado de la

llamada blogosfera

Ilustración 2: Bloggers personales, corporativos y profesionales.

Grupos no mutuamente excluyentes – Technorati 2008.


35

entretenimiento en los próximos 5 años. Además, uno de cada cinco bloggers considera que los

periódicos tradicionales no sobrevivirán los próximos 10 años.

Ilustración 3: Percepciones sobre blogs y medios tradicionales.

3.4.2.3. La blogosfera

Una definición sencilla del término “blogosfera” es “conjunto de blogs”, aunque se habla de que

existen en realidad blogosferas, queriendo destacar que los blogs tienden a relacionarse entre

ellos creando distintas comunidades y redes, cada una con sus participantes y temas

característicos.

Destaca Alberto Ortiz de Zarate: “La importancia de los blogs no reside en cada uno de ellos, ni siquiera en la lista de los 100 más leídos, sino en el entramado de conversaciones que emerge de los enlaces y comentarios entre ellos Un blog, incluso en sus momentos más animados, es una pobre conversación.”. Indica que de la interacción de estos “emerge una conversación rica y multiforme, a la que se puede denominar con una expresión paradójica: individualismo comunitario.” Por tanto, es en estas blogosferas, en la interacción de múltiples blogs, donde se produce el

verdadero fenómeno de los blogs desde el punto de vista social, y donde es necesario realizar los

análisis sobre la relevancia del blog como social media y como parte de la revolución de la

tendencia Web 2.0.

3.4.3. Wikis

“Imagine que esta navegando en Internet, y se encuentra con un sitio en el cual le gustaría

agregar o modificar algo. Por ejemplo, tiene una referencia literaria o un link para agregar. O

encontró un error. Quizás tiene un artículo que le gustaría colocar en una página separada.

Entonces, simplemente hace click en el botón “editar”, cambia todo de la forma que le parece

correcto, agrega un par de ideas, confirma la transacción, y la nueva página esta online

inmediatamente!. En un historial, se encuentran grabadas las versiones anteriores de la página,

pudiendo visualizar los cambios previos o incluso volver la pagina a esos estados. Si todo es una

experiencia simple y transparente, usted está trabajando con una wiki”.

21

37

43

49

51

71

0 10 20 30 40 50 60 70 80

Los periodicos no sobreviviran los proximos 10 años.

Los blogs estan frecuentemente escritos mejor que articulos en medios tradicionales

Obtengo mas de mis noticias e informaciones desde blogs y no tanto desde medios tradicionales

Los blogs son fuentes de información tan validos como los medios tradicionales

Más gente recibira sus noticias y entretenimiento desde blogs que de medios tradicionales en los proximos 5 …

Los blogs estan siendo considerados seriamente como fuentes de información

Percepciones sobre blogs y medios tradicionales


36

De esta forma es introducido el concepto wiki en el libro “Wiki: Web Collaboration” (22). Si bien

dicho libro ha sido publicado en el año 2008, el concepto wiki es uno de aquellos que precede a la

tendencia Web 2.0. Ya en el año 1995 la primer wiki fue creada bajo el nombre de WikiWikiWeb11,

con un suplemento automatizado para el Repositorio de Patrones de Portland, con el objetivo de

dar apoyo a personas y proyectos relacionados a patrones, utilizando el término hawaiano “wiki-

wiki” en el significado de “rápido”. (23)

El concepto wiki se ha vuelto cada vez más popular y conocido base al éxito del proyecto

Wikipedia, una enciclopedia online de contenido gratuito creada en el 2001, escrita de forma

colaborativa por más de 75.000 voluntarios de todo el mundo trabajando sobre más de

10.000.000 artículos en más de 250 idiomas (24).

Si bien se plantea la veracidad de la información volcada en la Wikipedia, la confianza en sus

contenidos va creciendo a medida que más gente la utiliza y la calidad de la información y las

referencias en los artículos va mejorando. En el año 2005 la publicación científica Nature realizo

un estudio comparativo sobre el nivel de confianza en las entradas de las Wikipedia y la

Enciclopedia Británica. En sus resultados se marco que la Enciclopedia Británica era la más

confiable de las dos, pero lo que sorprendió fue la poca diferencia marginal entre los niveles de

confianza. (25)

En base a la idea original se han realizado muchas implementaciones de software, por lo cual hoy

en día es muy sencillo realizar la instalación de una wiki y utilizarla sobre cualquier proyecto.

Generalmente, podemos diferenciar dos opciones de usos para las wikis: Pueden ser utilizadas

como herramientas en un grupo cerrado, o pueden ser apuntadas directamente a virtualmente

toda persona que utiliza Internet.

Muchas organizaciones han encontrado una gran variedad de usos para las wikis12. Podemos

mencionar un ejemplo como ser el caso de la Javapedia (26), un sitio colaborativo online para los

desarrolladores de Java desarrollada por Sun Microsystems en base a TWiki (27), un software

gratuito y abierto para la implementación de wikis.

3.4.4. Podcasts

Son archivos de música o video que son publicados en Internet, y a los cuales los usuarios del

servicio pueden subscribirse 13 . A veces el término “vodcast” es utilizado para describir

específicamente a los servicios de video.

Es justamente la posibilidad de subscripción lo que hace al podcast poderoso como un formato de

social media. Los usuarios han tenido la posibilidad de subir archivos de estos tipos a Internet

desde hace mucho tiempo, pero la posibilidad de subscripción implica que dichos usuarios

pueden crear audiencias regulares y comunidades en base a sus producciones de audio o video.

11 La WikiWikiWeb original sigue online y en funcionamiento en http://c2.com/cgi/wiki.

12 Podemos encontrar un listado de wikis importantes y sus datos en http://en.wikipedia.org/wiki/List_of_wikis.

13 Mediante el uso de un servicio de subscripción, el usuario puede recibir actualizaciones automáticas de los servicios a

los cuales se ha subscripto. Este concepto será desarrollado en más detalle posteriormente.


37

Efectivamente coloca a autores individuales o empresas pequeñas al mismo nivel de juego que

medios de comunicación tradicionales en cuanto a competir por la atención de la gente sobre

contenidos de audio o video en Internet.

Los podcasts son parte de un cambio en los patrones de consumos de medios, que ven

incrementalmente como los usuarios escuchan o ven contenidos cuando y donde lo desean. Esta

revolución es denominada “time-shifting”: al estar los contenidos disponibles en un medio de

almacenamiento, estos pueden ser consumidos de la forma en que el usuario lo prefiera. Este

concepto también se aplica en otras tendencias, como ser el caso de los DVR (Digital Video 14Recorder), en los cuales es posible almacenar la programación de TV en un medio de

almacenamiento digital, pudiendo luego consumir los programas televisivos en el momento y la

forma de preferencia del consumidor pudiendo por ejemplo, saltearse los espacios publicitarios.

El time-shifting es un concepto que otorga mayor poder al consumidor de multimedios.

Cuando un nuevo podcast es publicado en un sitio, los servicios de subscripción de podcast de los

usuarios subscriptos (por ejemplo, el programa iTunes de Apple) son notificados de forma

automática, y entonces es bajado a la computadora personal del usuario. Este puede ser

consumido en la computadora o llevado a un dispositivo externo, como ser un reproductor de

archivos MP3.

Naturalmente el advenimiento de los postcast ha implicado también que muchos medios han

podido invadir el terreno tradicional de otros. Mayfield cita como ejemplo el caso de algunos

periodicos de Inglaterra, que han comenzado a producir programas al estulo de radio, y a

distribuirlos en sus sitios, que anteriormente se basaban en texto e imágenes, algo que en

argentina ya ha sido tambein aplicado en periodicos tradicionales como ser el caso de Clarin,

desde donde distribuye micros informativos con un resumen actualizado de las noticias del dia.

(27)

3.4.5. Foros

Los foros surgieron mucho antes que los términos “social media” y “web 2.0” y ahora son un

elemento poderoso y popular de las comunidades online. Son lugares de discusión, generalmente

sobre temas e intereses específicos. Se llama “hilo” a una discusión de un foro, y pueden existir

muchos hilos activos simultáneamente, permitiendo conversaciones simultaneas y claramente

definidas.

Estas características convierten a los foros en buenos lugares para encontrar e involucrarse en

una gran variedad de discusiones detalladas. En general podemos encontrar a los foros como un

agregado a sitios web, pero también existen muchos casos en que los foros son un sitio web por sí

mismos. Los foros son utilizados para buscar ayuda sobre temas específicos, compartir noticias,

para participar en debates o simplemente como lugar de ocio. En otras palabras, su variedad

refleja la variedad que se presenta en las conversaciones cara a cara.

14 Los DVR han tenido una gran explosión a nivel comercial, siendo un claro ejemplo el caso de TiVo

comercializado en Estados Unidos generando un cambio en la conducta de los televidentes en base al

concepto del time-shifting.


38

Estos sitios son moderados por administradores, quienes deben moderar las conversaciones,

analizando los casos en que las reglas del foro se vean quebradas por los usuarios. Sin embargo,

los administradores no guían o lideran las conversaciones, y esa es la diferencia principal que

existe con las conversaciones que suceden en un blog, donde un autor expresa siempre primero

su opinión, esperando los comentarios de su audiencia. Es decir, un blog tiene uno o varios

autores que pueden publicar contenido, mientras que en un foro cualquier miembro puede iniciar

una conversación en un hilo.

Los foros llegan a formar un gran sentido de comunidad, debido a que los miembros comparten

intereses en común y participan en los diálogos sobre estos. Mayfield indica que en base a estos

algunos actúan como comunidades cerradas, con poca o ninguna interacción y conexión con otros

formatos de social media, aunque aclara que esto puede ser debido a que los foros ya existían

antes del surgimiento de los otros social media e incluso antes de que se empezara a hablar de

este término, siendo una de las primeras maneras de formar comunidades online.

Este social media continúa siendo uno de los formatos fuertes en Internet, con muchas

comunidades que alcanzan a los cientos de miles de usuarios. Existen sitios en Internet

especializados en analizar los contenidos de las conversaciones que se producen en los foros,

como ser el caso de Boardtracker que analiza los posts en más de 32.000 sitios, permitiéndonos

realizar búsquedas sobre su base de datos de foros (28).

Un factor clave en el despliegue de los foros en Internet ha sido el factor de software de código

abierto, ya que muchos de las implementaciones de este formato de social media en la actualidad

cuentan con licencia de software libre. En su libro “Managing Online Forums” Patrick O’Keefe,

uno de los referentes en cuanto al desarrollo de comunidades en base a foros, analiza las

opciones de software disponibles, tomando algunos casos de software libre y de software pago

(29). O’Keefe destaca las funcionalidades provistas por phpBB (30), un software con licencia GPL15,

así como también el potencial de las comunidades que se han desarrollado en torno al desarrollo

de mejoras y estilos visuales gratuitos para phpBB.

3.4.6. Comunidades de contenidos

Las comunidades de contenidos pueden parecer un poco similares a las redes sociales: el usuario

se registra, tiene su página personal y puede establecer conexiones con otros. La diferencia está

en que el objetivo de estas comunidades de contenidos es el de compartir y organizar algún tipo

especifico de contenido.

Para acercarnos al concepto de este social media, tomaremos ejemplos de algunos sitios que se

han convertido en referentes a la hora de hablar de algún tipo de contenido.

15 GPL (General Public Licence) indica que el código está disponible para el uso y modificación, e implica que

las modificaciones del software deben ser liberadas bajo la misma licencia. Podemos encontrar más

información en (127).


39

3.4.6.1. Flickr: fotografías.

Este servicio está basado alrededor de compartir fotografías, permitiendo que los miembros de la

comunidad suban sus imágenes al sitio, eligiendo la posibilidad de hacerlas públicas o

simplemente compartirla con otros usuarios de confianza que están en la comunidad, como ser el

caso de amigos y familiares.

Una de las razones del éxito de Flickr es la aplicación de la licencia Creative Commons16 sobre las

imágenes que un usuario sube al sitio, eligiendo el usuario en caso de dejarlas abiertas al público,

lo que otros usuarios de Internet pueden hacer con estas dando opciones como ser: reproducir y

modificar libremente siempre cuando se de crédito al autor, reproducir y generar variaciones

solo para uso no comercial o reproducir pero no hacer derivaciones. Esto provee de un marco de

derechos de autor flexible a los usuarios, generando un alto grado de transparencia en el uso del

sitio y sus contenidos.

A su vez, para fomentar la interacción entre los miembros de la comunidad, es posible formar

grupos alrededor de intereses comunes. Existen por ejemplo grupos dedicados a deportes,

ciudades, animales o artistas. Por supuesto, también existen grupos en base a empresas muy

conocidas, e incluso de personalidades.

Flickr ha puesto a disposición de los desarrolladores un set de APIs, que permiten interactuar

libremente con el servicio, con lo que es posible generar aplicaciones para por ejemplo subir,

bajar y buscar imágenes de Flickr. (31)

La empresa iniciada en el 2004 obtuvo un rápido éxito en base a sus prácticas innovadoras, por lo

que fue comprada por Yahoo! en el 2005 por aproximadamente 30 millones de dólares (32), y es

uno de los referentes en el concepto Web 2.0.

3.4.6.2. YouTube: videos.

En base a la publicación de videos, YouTube ha generado una de las comunidades de contenidos

más conocidas y utilizadas, llegando a mostrar a sus usuarios más de 100 millones de videos por

día (33). Los miembros de la comunidad pueden subir videos e incluso crear sus propios canales

de videos. Una gran variedad de videos han sido subidos por los usuarios del servicio, pudiendo

encontrarse una inmensa variedad de temáticas y tipos de contenidos.

La naturaleza viral de los videos de este servicio se ve potenciada por la facilidad con la que los

usuarios pueden embeber un video de YouTube en sus blogs u otro entrono que acepte código

HTML, además de la posibilidad de interactuar con el servicio mediante las APIs provistas por el

sitio. (34)

YouTube comenzó como una pequeña empresa privada, y debido a su éxito llamo la atención de

Google, que la adquirió por 1.650 millones de dólares a finales del 2006. (35)

16Las licencias Creative Commons son aplicables a cualquier contenido publicado en Internet. Es

considerada parte de la tendencia Web 2.0, por lo que será desarrollada posteriormente. Podemos

encontrar más información en http://creativecommons.org/.


40

3.4.6.3. Delicious: marcadores (bookmarks).

El servicio provisto por Delicious permite que los usuarios mantengan su lista marcadores (o

bookmarks) online, despegándose de el concepto local incorporado en los navegadores de

Internet (como ser el caso de “Favoritos” del Internet Explorer de Microsoft). Al agregar un sitio,

el usuario puede agregar etiquetas o “tags” al marcador. Por ejemplo, si se quisiera agregar a

marcadores un sitio en el cual estamos revisando las especificaciones de una cámara de fotografía

digital, el usuario podría querer agregar los tags “sony” y “cámara” al marcador, para poder

organizar de mejor forma sus marcadores en base a estos metadatos.

A su vez, el usuario puede dejar como públicos sus marcadores, a disposición de otros usuarios o

servicios que deseen consultarlos. Esto implica el concepto de “marcadores sociales”, y el poder

que generan al indirectamente crear una folsksonomia17, ya que de esta forma los contenidos de

Internet son organizados mediante el aporte de cada usuario y sus metadatos agregados,

rompiendo con la estructura de organización clásica en categorías.

Por tanto, volviendo al ejemplo anterior el usuario podría realizar su búsqueda en la comunidad

en base a los tags que le interesan, obteniendo directamente lo que otros usuarios han

considerado importante, en contraste a la búsqueda algorítmica que provee un servicio de

búsqueda como ser el de Google: Toda inclusión y clasificación de recursos está realizada por

seres humanos en lugar de máquinas que procesan la información de forma automática según un

programa.

3.4.6.4. Digg: noticas y contenidos.

Los usuarios de este servicio tienen como fin compartir links a historias o noticias que consideran

interesantes, y estos links son votados por otros miembros de la comunidad. Una vez que la

historia ha conseguido un número critico de votos, la noticia es colocada en la página principal por

lo que obtendrá mayor atención por parte de los usuarios y los visitantes ocasionales al sitio. Es

decir, lo que genera esta comunidad es que la relevancia de una noticia o historia sea elegida por

la gente, no por un editor de contenidos de un medio en particular. En su sitio indica: “En Digg no

encontraras editores. Estamos aquí para proveer un lugar donde la gente puede determinar de

manera colectiva el valor de los contenidos, y por tanto estamos cambiando la forma en que la

gente consume información online.” (36)

La empresa nacida a fines del 2004 indica tener más de 20 millones de visitas únicas cada mes, y

se mantiene como una empresa pequeña e independiente con alrededor de 40 personas en su

staff.

Este servicio ha inspirado el surgimiento de otros similares pero apuntados a lugares e idiomas

específicos, como ser el caso de Menéame (37) que surgió en el año 2005 y fue liberado como

código abierto, contando con un éxito considerable en España y en el público hispano en general.

17

El concepto de folksonomia es muy relevancia en el estudio de Web 2.0, por lo que será desarrollado en

mayor detalle posteriormente al analizar tagging.


41

3.4.7. Microblogging

Es una combinación de redes sociales, mensajería instantánea y blogging en pequeña escala: el

usuario escribe mensajes breves (por ejemplo, de hasta 140 caracteres) que son retransmitidos

automáticamente a otros usuarios que han decidido seguir estas “actualizaciones” vía mensajería

instantánea o incluso a sus teléfonos móviles. Dichas actualizaciones también son publicadas en el

blog personalizado del usuario.

3.4.7.1. Twitter: el líder en microbbloging.

El concepto empezó a tomar fuerza

de la mano del proyecto Twitter

(38) a mediados del 2006. Si bien

existen otros proyectos cubriendo

el formato microbogging, Twitter es

el claro líder habiendo alcanzado

más de 1 millón de usuarios (2) en

Abril del 2008. Esta cifra es baja

comparada con el alcance de los

otros social media que estamos

considerando, por lo que aun es

considerada como un nicho.

A la fecha mencionada solo alcanza

al 0.0016% de los usuarios de

internet en Estados Unidos, pero

dicho numero representaba un

crecimiento del 60% respecto al

mes anterior (39). Y para Julio del

2008 el porcentaje alcanzaba el

0.0024% nuevamente mostrando un crecimiento vertiginoso. (40)

En base a estas cifras podemos considerar al caso de Twitter como el ejemplo a analizar en busca

de un mejor entendimiento sobre el concepto del microblogging.

3.4.7.2. Usos del Microblogging

Bill Tancer de la revista estadounidense Time lo define a Twitter como “un servicio Web 2.0 que

permite a los usuarios dar a conocer a su red social exactamente que están haciendo (o sintiendo

o pensando o comiendo) en cada minuto de cada día". (41)

Los usos del microblogging varían, aunque uno de los usos más populares es entre oficinistas

como medios para dialogar, o simplemente por cualquier persona para mantenerse en contacto

con una red de personas, compartir pensamientos o comenzar conversaciones.

En países como Estados Unidos está tomando mucha fuerza e introduciéndose en muchos

aspectos de la sociedad, como por ejemplo en la relación de los medios de prensa tradicionales y

sus espectadores. Un buen ejemplo de esto es el caso de CNN, que promueve su uso (42) para

Ilustración 4: Estadísticas de HitWise sobre Twitter.

Porcentaje de visitas a Twitter por parte de usuarios de Internet en

Estados unidos, comparado con otros sitios de microblogging. Julio del

2008


42

interactuar con sus espectadores mediante este social media. Podemos encontrar sus

actualizaciones en http://twitter.com/cnn.

Otro ejemplo es el uso de Twitter

como parte de la estrategia de

campaña política del candidato

demócrata a presidente Barack

Obama. Podemos encontrar sus

actualizaciones en su Twitter:

http://twitter.com/BarackObama.

En Argentina el microblogging está

empezando a tomar fuerza: el

periódico argentino Clarín comenta

que”el microblogging se legitima

como recurso para obtener y

producir noticias: mientras los diarios del mundo lo suman como canal de difusión, entre

los periodistas ciudadanos nace una nueva forma de conectarse”. (43) Para ver sus

actualizaciones podemos entrar a http://twitter.com/clarincom.

Más 90% de las interacciones con Twitter no son realizadas directamente en su sitio web (44),

sino que se canalizan a través de mensajería instantánea, mensajes de texto vía teléfonos móviles,

y aplicaciones de escritorios u otros sitios web que utilizan las APIs de Twitter (45). Estas APIs

permiten que programadores inventen variantes creativas del servicio. Como vemos, esta

estrategia es utilizada por otros social medias, con el objetivo de que la comunidad sea la que

mejore el servicio con sus propuestas.

Claramente este nuevo concepto está produciendo cambios sociales, y estos están empezando

lentamente a repercutir en nuestro país, pero es de esperarse que su efecto se acelere en los

próximos meses. Podemos tomar como parámetro los datos de los sitios Twitter de los medios de

comunicación arriba mencionados: Al 23 de Octubre del 2008 CNN tiene 9.309 seguidores,

mientras Clarín solo tiene 418.

3.4.8. Sindicación de contenidos y APIs en los social medias.

En los puntos anteriores hemos analizado los social media como espacios de generación de

contenidos por partes de los usuarios. Estos medios han abierto las posibilidades para que la

gente pueda expresarse libremente y sin intermediarios mediante la capacidad de generar textos,

imágenes, audios y videos, y virtualmente sin costos ni conocimientos técnicos. Esta realidad era

impensable hace tan solo unos pocos años.

Pero por supuesto, la producción de contenidos es solo la mitad de la historia. ¿De qué sirve

generar información si no podemos hacer que llegue a la gente? En todos los casos de social

medias mencionados anteriormente la cantidad de contenidos que se genera y que pueden ser de

interés para una persona es enorme, y por supuesto, los usuarios tienen escases de un recurso en

particular: tiempo. Verificar una por una todas las fuentes de contenidos (blogs, wikis, podcats,

etc.) que una persona encuentra interesante publiquen algo todos los días es algo complicado.

Ilustración 5: Twitter de Barack Obama, candidato presidencial para Estados Unidos.

.

http://twitter.com/cnn

http://twitter.com/BarackObama

http://twitter.com/clarincom


43

Para facilitar esta barrera es ampliamente utilizado el concepto de “sindicación de contenidos”.

Mediante el uso de alguna de las tecnologías en las cuales se ha aplicado el concepto, un usuario

de Internet puede subscribirse para recibir notificaciones y contenidos de forma automática de

cualquier fuente, siempre y cuando la fuente también tenga implementada alguna forma de

sindicación.

El formato más utilizado para la sindicación de contenidos es el formato RSS (Really Simple

Syndication)18, basado en archivos XML. Mediante el uso de este formato los usuarios pueden

mediante software llamados “agregadores” recibir las actualizaciones de todas las fuentes que así

lo desee y de manera automática, pudiendo consumir los contenidos en el mismo agregador o ir

directo a la fuente. Existe una gran variedad de agregadores, como ser el caso del Bloglines (46),

que es un servicio online gratuito.

Prácticamente todos los ejemplos de social media que hemos mencionado anteriormente

cuentan con este servicio de sindicación, siendo parte vital del flujo de información en Internet.

Por otra parte, se presenta en la mayor parte de los ejemplos mencionados la tendencia del

software como servicio al proveer APIs que sirven para redistribuir y reutilizar contenidos y

servicios: prácticamente todo contenido generado en social medias puede ser reutilizado

mediante APIs por terceros generando nuevos contenidos y potenciándose. Dichas APIs siguen el

paradigma del Software como Servicio19.

Las posibilidades de contar tanto con sindicación de contenidos así como también con APIs

abiertas de servicios forman parte de los pilares de la tendencia Web 2.0, y analizaremos esto en

más detalle al adentrarnos a los patrones de diseño Web 2.0.

3.4.9. Mashups

Mayfield define a mashup como la combinación de dos o más unidades de contenido (o software

o sitios web). Indica que es uno de los fenómenos que hacen a las sociales medias tan excitantes,

cambiantes y en ocasiones confusos y sorprendentes. Los mashups son posibles gracias a la

apertura que presentan los social media: la tendencia en los ejemplos que hemos analizado es la

de motivar a la gente a jugar con los servicios y reinventarlos, algo que también veremos más

adelante en los patrones de diseño.

Para acercarnos al concepto podemos analizar el ejemplo del sitio HousingMaps.com,

mencionado al explicar que es un mashup en el libro “Pro Web 2.0 Mashups: Remixing Data and

Web Services” (47). En este caso nos encontramos con una combinación de servicios de Craiglist20

18

Podemos encontrar las especificaciones del formato en http://www.rssboard.org/rss-specification.

19 También conocido como SaaS como abreviación de “Software as a Service”. El concepto fue mencionado

en (129), y definido en (130) Ha planteado una revolución en el desarrollo de modelos de software y de

negocio, y es importante para el desarrollo de los patrones de diseño.

20 El sitio fue lanzado en 1995 y cubre anuncios clasificados de 450 ciudades en 50 países. Su servicio es

encontrado en http://www.craigslist.org, y podemos encontrar más información en

http://en.wikipedia.org/wiki/Craigslist.

http://www.craigslist.org/


44

y Google Map. HousingMaps es útil en maneras que son fáciles de comprender, lo que provoca el

uso repetitivo del sitio. A su vez no requiere por parte de los usuarios más software que un

navegador web., y una de sus mayores fortalezas es que toma dos servicios muy conocidos y

utilizados para crear algo nuevo. Todos estos puntos son partes de la tendencia Web 2.0, como

veremos más adelante.

Craigslist es un sitio de anuncios clasificados muy utilizado, y en sus categorías de propiedades

provee links individuales hacia Google Maps al mostrar una propiedad, pero no provee un mapa

colectivo de todos los listados. Esto genera un desafío al momento de realizar una búsqueda

geográfica de una propiedad: cuando uno busca una propiedad, tiende a hacerlo en un vecindario

delimitado o de acuerdo a los accesos de transito. Al hacerlo con los listados individuales de

Craigslist, habría que tener muchos mapas individuales abiertos y manualmente crear un mapa de

la zona que nos interese para tener un claro panorama geográfico. Si elegimos un punto en el

mapa, podremos ver una propiedad listada en la categoría de casas, observando imágenes, textos

y por supuesto un link a la página de Craigslist donde se podrá ver más detalles de la propiedad.

Es decir, toda la información es extraída de Craigslist y mostrada en el mapa que es provisto por

Google Maps.

HousingMaps permite simplificar la búsqueda proveyendo la posibilidad de realizar búsquedas en

la base de datos de Craigslist de manera geográfica visualizando todos los listados en una zona

determinada mediante el uso de una interfaz de mapa, permitiendo luego acceder a los detalles

de cada uno de forma individual.

Ilustración 6: Captura de pantalla de HousingMaps.

Al buscar una propiedad a la venta en la ciudad de Austin, Texas, podemos ver el listado obtenido de Craigslist en la derecha , y el

mapa del centro de la ciudad con los elementos de dicho listado. A su vez, al elegir una de las propiedades del mapa obtenemos la

dirección, algunas imágenes, los datos de contacto de la persona que publico el anuncio, y el link al sitio de Craigslist con la

información detallada.


45

La mezcla y reutilización de los servicios e información sucede en el lado del servidor del sitio, que

no es ni la fuente de datos (Craigslist) ni la forma en la que se muestran los datos (Google Maps).

Los datos son tomados de la fuente de datos y transformados en mapas de Google Maps, los

cuales son embebidos en el sitio HousingMaps.

Por tanto, lo llamativo es como HousingMaps obtiene los listados de propiedades de Craigslist y

como logra crear mapas de Google Maps con esos datos: Por su parte Craigslist provee mediante

sindicación de contenidos un feed de RSS, del cual HousingMaps toma los listados de propiedades

específicamente. Y para generar y embeber los mapas, aprovecha la API ofrecida por Google

Maps.

Este innovador servicio no fue ideado ni por Craigslist ni por Google Maps, sino que fue le idea de

un desarrollador independiente quien logro algo simple y útil con una inversión prácticamente

nula, y que hubiera sido prácticamente imposible en el caso de tener que reinventar los servicios

que proveen los dos componentes del mashup.

Al desarrollar los patrones de diseño Web 2.0 mencionaremos numerosos sitios o social medias

que son mashups, ya que basan parte de sus funcionalidades en servicios de terceros, como por

ejemplo utilizar capacidades de videos mediante YouTube o imágenes mediante Flickr.

3.4.10. Un breve resumen de los social medias.

Los blogs (y de la mano los podcasts y microblogs por tener similitudes en sus características de

publicación) han ganado en popularidad y credibilidad, y se está produciendo una revolución

mediática, donde las voces de los usuarios de Internet son cada vez más fuertes. Análisis de la

blogosfera pueden dar una clara fotografía actual de los temas sobre los que la gente está

hablando, y las opiniones más fuertes sobre estos. En estos casos una persona o un grupo de

personas reducido funcionan como creador de contenido, pero con la posibilidad de realmente

dialogar con los visitantes del sitio y autores de otros blogs.

Los foros son el lugar por excelencia cuando la gente quiere debatir sobre un tema en particular,

en donde se vierten opiniones y conocimientos, pudiendo centrarse en torno a cualquier

temática, desde cocina, mantenimiento de redes o el gusto por el origami. Esto crea comunidades

de colaboración sobre distintos ámbitos, permitiendo generar conocimiento colectivo e

interacciones entre usuarios que de otra forma sería imposible lograr.

Por su parte las Wikis surgen como un lugar para acumular conocimientos sobre diferentes

temáticas, actuando también de manera colaborativa. A diferencia de los foros no existen

demasiados lugares para debates, sino que simplemente se trabaja para mejorar y optimizar

información y datos sobre un tema específico. Aquí lo importante no es la comunidad, sino el

refinamiento de los contenidos y es una herramienta que puede adosarse fácilmente a cualquier

tipo de proyecto.

A su vez, existen las comunidades de contenidos, donde el objetivo es compartir algún tipo de

contenido en particular, sin necesariamente expresar opiniones y conocimientos; videos,

imágenes y links son algunos de estos ejemplos. Al igual que los foros, aprovechan la colaboración


46

conectiva de los usuarios de Internet para generar grande bases de datos, y también para

organizarlas (como veremos más adelante al analizar el concepto de tagging y folksonomias).

Las redes sociales tienen una incidencia distinta a la de los otros medios, ya que el fuerte esta en

ofrecer herramientas para que la gente se relacione con sus conocidos y comparta su vida diaria

mediante medios digitales, y no están apuntadas a la generación de contenidos (aunque si son un

medio de distribución). Su uso se ha vuelto masivo y mantiene un crecimiento muy acelerado. Es

algo similar a la revolución que se presento en su momento con los celulares y el e-mail: todos

tienen estos elementos y se vuelven moneda común para comunicarse con nuestros conocidos, y

hoy en día virtualmente todos tienen una cuenta en Facebook (o MySpace, LikedIn u otras redes

sociales) o al menos se ven rodeados de gente que participa en redes sociales, sin necesidad de

ser personas muy adeptas a la tecnología o internet.

Si bien en Argentina todos los efectos mencionados de los social media se presentan en una

escala menor en comparación a otros países (como ser Estados Unidos, y muchos los países

Europeos o Asiáticos)21, la tendencia apunta a un crecimiento rápido, por lo que en los próximos

años o incluso meses notaremos cambios drásticos en relación al uso de estos medios.

Si recordamos los elementos en común que presentan los social media (participación, apertura,

conversación, comunidad y conectividad), podemos considerar que el potencial es enorme, y que

si son utilizados de una manera ética y estratégica podrían provocar cambios sociales muy

positivos.

3.5. Clientes, empresas y la Web 2.0

A continuación buscaremos obtener una imagen de cómo los usuarios de Internet, tanto en el

papel de clientes o de empresas, se relacionan con los diversos social medias, tecnologías, y

elementos de la Web 2.0.

En este aspecto podría profundizarse mucho debido al gran impacto social y económico que ha

tenido esta tendencia en los últimos años, pero será importante tratar de crear un panorama,

más que desarrollar el tema en detalle debido a que el tipo de trabajo teórico debe focalizarse en

otros puntos. Igualmente, en base a estadísticas y opiniones será posible conocer a los usuarios

de Internet a un nivel suficiente para plantear los requerimientos de la solución que este trabajo

propone.

3.5.1. Los consumidores son los protagonistas.

La reconocida revista estadounidense Time cada año elige la “persona del año”. En Diciembre del

2006 ocurrió algo que llamo la atención del mundo: La persona elegida fue “usted”. (48)

En dicha nota Lev Grossman comenta: “Si observamos al año 2006 desde una óptica diferente,

veremos una historia diferente, que no habla de conflictos o grandes hombres. Es una historia

sobre comunidad y colaboración en una escala nunca antes vista. Es sobre el gigantesco

21

Esto será analizado a continuación al acercarnos a la relación de los usuarios de Internet con la tendencia

Web 2.0.


47

compendio de conocimientos de la Wikipedia, el millón de videos de la red de YouTube y la

metrópolis online que es MySpace. Es sobre el poder que descansa en los pocos y la ayuda de unos

a otros por nada, y de cómo eso no solo cambia el mundo, sino también cambia la forma en la que

el mundo cambia”.

El efecto de la tendencia Web 2.0 no ha hecho más que crecer rápidamente desde sus inicios. Este

hito del 2006 nos muestra que ya no es algo que “esta por pasar”, sino que es algo que está

ocurriendo y a su vez, nos está cambiando. De esa fecha a esta parte han sucedido muchas cosas,

y han surgido permanentes cambios.

3.5.2. Tendencias de consumo de Internet

Los usuarios de Internet son personas, y toda persona puede ser vista como un consumidor desde

el punto del Marketing. Analizaremos ahora a estos, para obtener un panorama de su

comportamiento.

Por su parte, la publicación “Web 2.0 Principles and Best Practices” indica que diversos cambios

demográficos, tecnológicos y económicos están guiando a la tendencia Web 2.0. Comenta que

tras estos cambios están fundamentalmente los deseos de la gente de conectarse, comunicarse y

participar. Estas motivaciones son facilitadas por Internet en formas antes no imaginadas.

Dicho estudio menciona algunas tendencias de los consumidores en Internet:

1. La base de clientes es verdaderamente global.

2. Los clientes están siempre conectados.

3. Los clientes están conectados dondequiera que vayan.

4. Los clientes no están simplemente conectados, están participando.

Analizamos estas y sus impactos, analizando la aplicación de estas en el caso particular de

Argentina:

3.5.2.1. La base de clientes es verdaderamente global

Ya por el año 2005 un mil millones de personas tenía acceso a Internet. Estados Unidos ya no

ocupa la porción dominante del mercado (con un 24%), lo que deja un buen lugar para desarrollo

a otros mercados. Entre ellos, el de Sud América ocupa un 5%. Particularmente en el caso de

Argentina, según el estudio publicado por la consultora D’Alessio IROL (49) existían 10.320.000

usuarios en dicho año, y en Noviembre del 2007 la consultora Price & Cooke (50) indico que

existían 16.000.000, lo que representaba un 42% sobre la población del país y un claro

crecimiento en tan solo 2 años.

Existe un factor que afecta a todos los países del mundo por igual: los nativos digitales22. Son

aquellas personas menores de 30 años, generaciones que han vivido gran parte de su vida o

incluso toda su vida frente a la presencia de la informática e Internet. Este grupo de personas se

22 Marc Prensky acuño los términos “nativos digitales” e “inmigrantes digitales” en 2001 (131). En referencia

a estos dice: “Nuestros estudiantes han cambiado radicalmente. Los estudiantes de hoy ya no son las

personas para las cuales nuestro sistema de educación fue diseñado para enseñar.”


48

encuentra muy cómoda en el uso de Internet y por tanto se adapta rápidamente a los cambios

que la Web 2.0 presenta.

El impacto: La base de consumidores es sustancialmente mayor que en los últimos 5 años. Por

tanto, el mundo se está volviendo cada vez más interconectado, haciendo más práctico y posible

alcanzar micro mercados globales, siendo el indicador principal las preferencias de los nativos

digitales.

3.5.2.2. Los clientes están siempre conectados

La Internet banda ancha es cada vez

más común, lo que permite que los

usuarios estén conectados de forma

virtualmente permanente. En marzo del

2006 en Estados Unidos un 42% de la

población tenía acceso a Banda Ancha,

mostrando un crecimiento del 40%

sobre el año anterior. En el caso de

Argentina según el ITU (51) en el 2007

solo el 6.58% del total de la población

tiene acceso a Internet Banda Ancha

creciendo ampliamente en comparación

al 4.05% que se presentaba en el año

anterior. Si analizamos por ejemplo el caso particular de los hogares que tienen acceso a Internet,

la consultara Carrier y Asociados indica que el porcentaje ha crecido rápidamente en los últimos

años alcanzando un 94% del total de los hogares, y mostrando un 23% de crecimiento respecto al

año anterior (52).

El impacto: Al estar conectados permanentemente, Internet se vuelve parte esencial de la vida de

las personas. Y este tipo de conexión de alta velocidad se refleja directamente en la creación de

contenidos por parte de los usuarios, debido a la posibilidad de subir y bajar de Internet videos,

imágenes y audio, lo que permite a estos consumidores de multimedia convertirse en

generadores de multimedia.

3.5.2.3. Los clientes están conectados dondequiera que vayan

A finales del año 2006 existían en uso 2 billones de equipos de telefonía celular (53): el doble de

los usuarios de Internet en el momento. La tendencia en los últimos años ha sido el creciente

acceso a internet desde dichos equipos. El rápido crecimiento y mejora de estos equipos y otros

dispositivos móviles está acelerando esta tendencia. La consultora BuddeComm indica que en

Argentina en el año 2007 la telefonía celular alcanzo una penetración del 82%, un número muy

por arriba del promedio de Latino América. Las tres empresas operadoras de telefonía celular en

1322

45

72

94

0

20

40

60

80

100

2004 2005 2006 2007 2008

Banda ancha en hogares conInternet en Argentina - %

Ilustración 7: Banda ancha en hogares con Internet en Argentina.


49

el momento (Telecom Personal, Movistar y CTI Móvil) planeaban cambios en sus redes para el

lanzamiento de la tecnología UMTS 3G23, lo que potenciaría el uso de Internet móvil. (54)

La consultora Prince & Cooke señalaba ya el lanzamiendo masivo de 3G a fin del del 2008 y

comienzos del 2009 con un rápido crecimiento del mercado en Argentina, e indicando que el 2010

sera el año del depegue de la adopción en el país presentando estandarización y caída de precios

(55).

El impacto: Este rápido crecimiento generalizado está expandiendo el alcance de la red. Existe por

tanto la necesidad de la generación de estrategias para aplicaciones independientes de la

plataforma en la que corran. Los consumidores buscaran nuevos usos de Internet en sus equipos

móviles.

3.5.2.4. Los clientes no están simplemente conectados, están participando

La población de Internet se encuentra cada vez más cómoda respeto a la situación de contribuir

contenidos online en los distintos social media analizados anteriormente. Esto va desde

contenidos multimedia (como ser fotos, videos y audios) hasta la participación con conocimientos

y opiniones en grupos de discusión y foros, sumado al rápido crecimiento que se presenta en los

blogs personales y profesionales.

En Estados Unidos en promedio diario, 5 millones de usuarios crean contenidos a través de un

blog o un medio similar, 4 millones comparten música y archivos mediante redes Peer-to-Peer

(P2P) y 3 millones usan internet para opinar sobre una persona, producto o servicio. (56)

El caso particular de los blogs es

muy llamativo. Existían ya más de

70 millones de blogs indexados por

el motor de búsqueda de blogs

Technorati en Abril del 2007,

presentándose la creación de

120.000 de nuevos blogs cada día a

nivel mundial. Del total de los

blogs, el 3% están en idioma

español. (57)

Sumado al creciente potencial de

los blogs, existe la fuerte tendencia

de las redes sociales a nivel

mundial: En Abril del 2006 entre

las 10 redes sociales más

importantes abarcaban casi al 45%

de los usuarios totales de Internet. (58) Facebook, MySpace y Sonico suman juntos 150 millones

23

Esta tecnología pertenece a la “tercera generación” de telefonía móvil. La combinación de UMTS y el

protocolo de Internet (IP) permiten la prestación de servicios multimedia y el uso de banda ancha (132).

Ilustración 8: Blogs indexados por Technorati - Marzo del 2003 a Marzo del 2007.


50

de usuarios, siendo la última de estas tres fundada por un argentino en Julio del 2007. En Marzo

del 2008 dicha comunidad online ya contaba con 8 millones de miembros, con expectativas de

finalizar el 2008 con 30 millones de usuarios. Por último, existen casos destacables en el país

como ser el del sitio Psicofxp que cuenta en la actualidad con más de 800.000 usuarios. (17)

En el caso de Argentina, la consultora Carrier y

Asociados en base a un estudio realizado en

Noviembre del 2007 indica que en dicho país

“existen 5 millones de personas que participan

activamente de la Web 2.0 de los cuales 1,4

millón lo hacen con una frecuencia al menos

semanal (…) el principal contenido subido a la red

son fotos, compartidas por el 82% de los usuarios

2.0, lo que equivale a 4,1 millones de personas,

porcentaje que crece en la medida en que baja la

edad. Luego, con un 43%, sigue el upload de

texto, aunque en este caso este valor crece a

medida que sube la edad y aumenta la

antigüedad en el uso de Internet. Finalmente, se ubica el video, que es subido por sólo el 15%, lo

que equivale a unas 750 mil personas.” (59).

El impacto: Internet se está convirtiendo realmente en un medio de comunicación de dos vías, en

una plataforma de lectura-escritura en base a los social media. Los medios masivos y tradicionales

de comunicación están siendo desafiados por los contenidos generados por los usuarios.

Estas cuatro tendencias demuestran la creciente adopción de Internet por parte de los usuarios,

no solo como un medio de comunicación, sino como una parte importante de sus vidas.

3.5.3. La relación entre los usuarios de Internet y las marcas o productos.

Podemos analizar en más profundidad la relación entre los clientes y las empresas o productos

que consumen, tomando algunos ejemplos como ser el caso de los blogs.

Anteriormente mencionamos que en el caso de este social media los contenidos creados por los

usuarios están tomando cada vez más credibilidad y peso entre sus lectores. Como parte del

estudio “Estado de la Blogosfera”, Technorati incluye su análisis llamado “Las Marcas entran en la

Blogosfera” (21) donde indica que las discusiones y opiniones sobre marcas forman gran parte de

la blogosfera: Más de ocho de cada diez bloggers publican opiniones sobre productos o

empresas, y casi nueve de cada diez bloggers lo hacen sobre empresas que aman (u odian). Este

factor se presenta tanto en hombres como en mujeres por igual. Cada vez más gente del

marketing entiende que la blogosfera es un lugar donde es importante tener presencia: uno de

cada tres bloggers se acerca a ser un defensor de alguna marca, y más de seis de cada diez

recibieron oferta de pago de algún tipo.

82

43

15

0

20

40

60

80

100

Fotos Textos Videos

Contenidos subidos a Internet por usuarios Argentinos - %

Ilustración 9: Contenidos subidos a Internet por usuarios Argentinos.


51

¿Habla sobre productos o empresas en su blog? Frecuentemente Ocasionalmente Nunca

Publico opiniones sobre productos o empresas. 37% 45% 18%

Publico opiniones sobre empresas que amo (u odio).

41% 48% 11%

Publico información o rumores que escucho sobre las empresas.

31% 32% 37%

Publico sobre algunas de mis experiencias de la vida diaria en empresas y con atención al cliente.

34% 45% 21%

Tabla 2: Frecuencia de opinión de bloggers sobre empresas

Para acercarnos un poco a la relación de dichos usuarios de Internet con las empresas y productos

en el marco de Argentina, podemos tomar como referencia el informe de D’Alessio IROL en el

2006 (5).

Entre sus puntos sobresalientes indica:”El poder

comercial de Internet crece y se vuelve una

“vidriera gigante”: 9 millones de personas

consultan sobre productos y servicios para su

posterior consumo”. Además indica que para

nueve de cada diez personas Internet le fue de

utilidad en la decisión de una compra, la mitad de

las personas que utilizan Internet ya ha realizado

compras online, y que más del 60% realiza

compras por canales tradicionales luego de haber

consultado en la web.

Este informe también incluyo un detalle de los rubros de productos consultados y comprados

tanto online como por medios tradicionales por los usuarios de Internet. Incluimos aquí los

productos consultados:

86

13

1

Usuarios que consultan sitios para informarse sobre productos y servicios

Si

No

No responde

Ilustración 10: Usuarios que consultan sitios para informarse sobre productos y servicios.


52

Rubro Consultó (Respuestas múltiples - %)

AFJP 36

Alimentos (Delivery) 23

Alimentos (en general) 24

Deportes 44

Educación 48

Electrodomésticos 50

Temas de familia/Artículos para niños o bebés 31

Hardware (PC, impresoras, etc.) 46

Hogar (Muebles, artículos de decoración, mejoras) 43

Inscripción a cursos/eventos 44

Libros 41

Música (bajada online) 29

Remates 32

Ropa 23

Salud (sistemas médicos, farmacias, consejos, etc) 34

Seguros 20

Servicios financieros (Caja de ahorro/Cuenta corriente/Tarje)

36

Software 30

Suscripción de revistas/periódicos 23

Telefonía 33

Tickets de espectáculos 31

Vehículos 31

Viajes/turismo 47

Videos 22

Otros 2

No responde 4 Tabla 3: Rubros consultados por usuarios de Internet en Argentina

Destaca también “el canal Internet suma un nuevo canal a las Empresas de Consumo y Servicios,

pero no reemplaza otros canales. No se produce migración de uso de canales, sino que se amplían

los contactos con las empresas.”.

3.6. Las empresas y la Web 2.0

Las empresas han comenzado a utilizar cada vez más herramientas Web 2.0 de distintas formas

en los últimos años, de mantera tanto interna como externa, demostrando ser un medio

excelente para la cooperación y la comunicación. Como mencionamos anteriormente, este

estudio debe focalizarse en como las empresas se vinculan con los consumidores, por lo que

debemos dejar de lado el análisis de servicios e implementaciones que al aprovechamiento de la

Web 2.0 de forma interna en las empresas (como por ejemplo, el uso de wikis como medio de

cooperación en proyectos).

Enrique Dans explica en su artículo “La empresa y la Web 2.0” publicado en la revista “Harvard

Deusto marketing y ventas” (60) indica que a mediados de los años 90 (existiendo tan solo unos

45 millones de usuarios) alrededor del 80% de los contenidos de Internet eran generados por

empresas y medios de comunicación, quedando tan solo un 20% generado por los usuarios, es

decir, era una ”Web de las empresas”. Internet funcionaba en este sentido como una galería

comercial o un elemento más de su campaña de marketing, y por tanto en el fondo las empresas


53

solo replicaban lo que hacían en otros medios, generando solo páginas de representación a modo

de folletos. Esto presenta un gran contraste al panorama que hemos analizado de Internet en los

últimos años, donde Dans indica que alrededor del 85% de los contenidos actuales son generados

por usuarios, mientras que tan solo el 15% es generado por empresas y medios de comunicación,

lo que toma más peso al considerar que la cantidad de usuarios se multiplico hasta llegar a mas de

los mil millones.

De este análisis podemos ver claramente como se cambio el balance de poder, y por tanto porqué

las empresas se ven forzadas a tomar unan nueva postura en su relación con los clientes.

Uno de los social media que más impacto ha tenido en el aspecto de comunicación

indudablemente han sido los blogs, por lo que muchos de los análisis podemos realizarlos en base

a estos, extendiendo luego la tendencia a otros social media.

Dans explica que los blogs son la punta del iceberg: “no son el único fenómeno asociado a la

llamada Web 2.0, pero sí posiblemente el más llamativo y una buena manera de entender los

cambios que se operaron a lo largo de estos últimos diez años.” En referencia a la blogosfera

indica que “comienza, lentamente, a cambiar las pautas de interacción entre las personas y las

empresas. De la noche a la mañana, el poder de los clientes se multiplica por el tamaño del altavoz

que éstos poseen. Un simple episodio de insatisfacción de un cliente puede pasar, en cuestión de

horas, a convertirse en un problema que llegue a afectar a las ventas de la compañía o a la

cotización de sus acciones.”

3.6.1. Los distintos tipos de blogs corporativos

Volviendo a los blogs, si recordamos el análisis realizado sobre este social media anteriormente,

tenemos que una posible clasificación de estos es: personales, profesionales y corporativos. Para

analizar un poco más la relación de las empresas con Internet, debemos ahondar en el concepto

del tercer grupo, es decir, los blogs corporativos: aquellos en los que los autores escriben desde

una posición oficial desde una empresa.

Podemos considerar la siguiente segmentación dentro de los blogs corporativos planteada por

Javier Celaya y Pablo Herrera (61) :

Internos

Corporativos

Externos

Enfoque de ventas Enfoque relacional Enfoque conocimiento Enfoque de colaboración

Ilustración 11: Segmentación de blog corporativos.


54

Dentro de esta clasificación, debemos hacer hincapié en los blogs externos. El objetivo de la

creación de este tipo de blog es principalmente habilitar nuevos canales de comunicación con los

públicos externos de la empresa, como ser clientes actuales o potenciales, proveedores, medios

de comunicación, etc. Dichos autores indican que “varias empresas han decidido complementar

sus estrategias de comunicación con este tipo de herramientas, dado que consideran que les

aportan fluidez, transparencia y credibilidad.”

Entre los blog externos tenemos dos sub categorías:

Blogs de ventas (o de marketing): herramienta de comercialización tanto para las fases de diseño, como para el apoyo a un producto o servicio puesto en el mercado.

Blogs con enfoque relacional: aspiran a crear y mantener una relación más estrecha con las audiencias clave de la empresa.

Respecto a los blogs Enrique Dans concluye que “la empresa debe plantearse optar por lugares de conversación, “blogs” corporativos o personales de directivos que permitan disponer de una voz en la conversación diferente a las tradicionales notas de prensa.”

3.6.2. Opinión de las empresas sobre el impacto de los blogs

La revista TARGET publico un análisis realizado por la consultora CIO Research en base a la opinión

de periodistas, directores de comunicaciones y relacionistas públicos sobre la relevancia de los

blogs en Argentina a comienzos del 2008.

Tomaremos las opiniones de estos dos últimos grupos (contando con 54 y 60 muestras

respectivamente) para tener una aproximación a la opinión de los responsables de las empresas

en cuanto a comunicación externa y contacto con el consumidor se refiere. (62)

4,1

4,8

5,7

6,7

3,9

4,2

4,9

5,7

6,6

3,6

0 1 2 3 4 5 6 7 8

Son fuente de información confiable

Son una buena forma de realizar conmunicaciión institucional

Los blogs de periodistas son mas confiables que los medios para los que trabajan

Son efectivos para que la sociedad publique sus inquietudes

Son competencia de los medios tradicionales (radio, tv, diarios) R.R. P.P.

Dir. de com.

Opinión de Relacionistas públicos y directores de comunicación. - (1 al 10) Ilustración 12: Opiniones de directores de comunicaciones y relacionistas públicos sobre blogs.


55

Según Cecilia Mostro, socio gerente de la consultora mencionada, “las condiciones del escenario

argentino han logrado revertir la gran desconfianza que inspiraban hace un par de años, y, si bien

desde lo práctico no se ha convertido aun en una herramienta dominante o competitiva en

relación con los medios tradicionales, si aceptación desde el concepto le da toda la potencia para

lograrlo en el corto plazo”.

El estudio destaca las siguientes debilidades del blog como un medio: la falta de confianza, el

volumen de información, impersonalidad y la carencia de un marco regulatorio. A su vez, destaca

las siguientes fortalezas: la capacidad de llegar a todo tipo de público, la rapidez y la actualización

constante, la interacción, la libertad y el bajo costo.

Además, el estudio denota que la opinión generalizada es que los blogs son “un espacio para

crecer en el desarrollo de nuevos productos y para facilitar la comunicación con nichos específicos,

a los que antes era más difícil llegar.”

3.6.3. Ejemplos de la relación de empresas con la Web 2.0

Podemos mencionar a la empresa Dell como un ejemplo. Para esto debemos ir al caso

denominado “Dell Hell”, cuando el blogger Jeff Jarvis realizo una serie de posts (63) quejándose

de a modo de carta abierta al presidente de la empresa. Este hecho fue reflejado en revistas y

publicaciones económicas, llegando a tener trascendencia tanto en las ventas como en protocolos

y maneras de acción de la empresa desde entonces, ya que genero piliticas y acciones para

detectar este tipo de situaciones y relacionarse de mejor forma con los usuarios de internet.

Dell desarrollo el sitio “Dell

IdeaStorm” (que mantiene el slogan

“donde tus ideas reinan”)

promoviendo la opinión y

participación de sus clientes de

manera abierta en sus productos

actuales y futuros, y formando una

comunidad en el sitio. Al describir el

sitio indican que “creemos más que

nunca que la mejor forma de

comprender y servir a nuestros

clientes es hablarles de forma directa,

sin importar donde se encuentren”

(64).

El caso de Dell demuestra la

tendencia de interacción con clientes

que las empresas en forma

minoritaria están tomando, pero claro que aun son pocas las que logran ver el beneficio de tal

apertura.

Pero es posible aprovechar prácticamente todos los tipos de social media para lograr un mejor

contacto con los clientes, sin necesidad de crear un sitio especial para este objetivo. Una forma de

Ilustración 13: Captura de pantalla de IdeaStorm de Dell.

IdeaStorm de Dell es el lugar donde la empresa Dell interactúa

abiertamente con las opiniones y voces de sus clientes, buscando

sacar provecho de estas en lugar de ignorarlas o callarlas.


56

lograrlo es participar activamente en las diferentes redes sociales (por ejemplo, teniendo una

página en Facebook), comunidades de contenidos (por ejemplo, creando un canal de Youtube), y

otros social media disponibles.

Otro ejemplo de cómo algunas empresas grandes están comenzando a tomar un rol activo en la

conversación se da en Intel. Kellyn Feller, Manager de social media de la empresa explica como la

empresa busca cubrir todos los puntos posibles: “Nuestro rol es permitir el desarrollo de una

conversación y para eso usamos todas las herramientas posibles a nuestro alcance: blogs, foros

externos, campañas en Facebook, Second Life y Twitter. Tenemos 32 mil usuarios registrados en

nuestra comunidad: comunity.intel.com. La gente quiere formar parte de la conversación porque

considera que los que trabajan en Intel están técnicamente capacitados para resolver cualquier

problema y duda”.

Además, Feller opinó sobre el futuro de las redes sociales y otras herramientas 2.0: “Los seres

humanos somos seres sociales por naturaleza, queremos socializar. Hoy la web permite esto como

nunca antes. Y cada vez todo irá creciendo, más y más integrado.” (65)

3.7. Los patrones de diseño Web 2.0

Con el objetivo de identificar practicas y patrones aplicados por distintos proyectos en Internet

que han resultado exitosos y que pueden ser relacionados con los puntos planteados

anteriormente sobre la Web 2.0, en base a los patrones dos años antes identificados por O’Rilly

(66) se realizo un análisis de diferentes casos en “Web 2.0 Principles and Best Practices” (9).

Realizaremos a continuación una explicación de estos patrones desarrollados a finales del 2007,

explicando conceptos auxiliares importantes para su interpretación y el análisis breve de las

acciones realizadas en algunos casos.

Recordemos la definición planteada anteriormente: “La Web 2.0 es un conjunto de tendencias

económicas, sociales y tecnológicas que de manera colectiva forman la base para la siguiente

generación de Internet – un medio más maduro y distinguido caracterizado por la participación de

los usuarios, la apertura y los efectos de red”.

Esta definición es un buen punto de partida para comenzar con el análisis de los patrones y

acercarnos a su entendimiento. Presentamos a continuación un listado de estos:

1. Aprovechar la inteligencia colectiva: Crear una arquitectura de participación que use los

efectos de red y algoritmos para producir software que mejore a medida que más gente

lo utilice.

2. Los datos son el próximo "Intel Inside": Usar fuentes de datos únicas y difíciles de recrear

para convertirse en el siguiente "Intel Inside", en esta época en la que la información se

ha vuelto tan importante como la función.

3. Innovación en el ensamblaje: Construir plataformas para fomentar la innovación en el

ensamblaje, donde la combinación e interacción de datos y servicios crea nuevas

oportunidades y mercados.

4. Experiencias de usuario ricas: Ir más allá de los conceptos tradicionales de lo que es una

página web, para entregar experiencias al usuario mucho más ricas, combinando lo mejor

del software online y de escritorio.


57

5. Software más allá de un solo dispositivo: Crear software que abarque a los diferentes

tipos de dispositivos conectados a Internet, en base a la creciente omnipresencia de la

experiencia online.

6. Beta perpetuo: Alejarse de los antiguos modelos de desarrollo de software, en favor de

modelos de software como servicio (SaaS) online y continuamente actualizados.

7. Aprovechar la larga cola: Capturar nichos de mercado rentables a través economías de

bajo costo y alcance amplio permitidas por la Internet.

8. Modelos ligeros y escalabilidad costo-efectiva: Uso de modelos de negocio (y de

software) ligeros para construir modelos de productos y negocios de manera rápida y

rentable.

Cada uno de estos patrones es único, pero entre ellos son altamente interdependientes.

A su vez, podemos decir que los siguientes atributos son comunes a toda aplicación Web 2.0, y

que por tanto son la base que da soporte a los patrones mencionados:

Masivamente conectados: Los efectos de red nos llevan desde la publicación uno-a-

muchos y modelos de comunicación del pasado hacia verdaderas conexiones muchos-a-

muchos. En esta era los bordes se vuelven tan importantes como el centro, y los antiguos

modelos de publicación, comunicación, distribución y agregación se encuentran ante una

disrupción.

Descentralizados: La conectividad también provoca una disrupción en las estructuras

tradicionales de poder y control, llevando a una mayor descentralización. Los enfoques

de abajo-hacia-arriba compiten con los de arriba-hacia-abajo en todo, considerando

desde flujos de información globales hasta modelos de marketing o diseños de nuevos

productos. Los sistemas crecen desde los bordes hacia el centro, y no al revés.

Focalización en el usuario: El usuario es el centro de la Web 2.0. Los efectos de red an a

los usuarios posibilidades impensadas de participación, conversación, colaboración y

sobre todo, impacto. Los consumidores se han convertido en publicadores con mayor

control, las experiencias de estos son ajustadas a sus características en el momento de ser

utilizadas, e interfaces enriquecidas optimizan la interacción de con dichos usuarios,

pudiendo estos guiar el desarrollo de productos. Los clientes recompensan a las empresas

que los tratan bien, mediante lealtad y valiosas opiniones positivas de boca a boca.

Apertura: En Web 2.0 la apertura comienza con la formación de los estándares en los que

se basa Internet, y crece rápidamente hacia un ecosistema de apertura con aplicaciones

débilmente acopladas construidas en base a datos abiertos, APIs abiertas y componentes

reusables. Y apertura significa más que tecnología: implica mayor transparencia en

comunicaciones corporativas, propiedades intelectuales compartidas, y mayor visibilidad

respecto a cómo se desarrollan los productos.

Bajo peso: Una filosofía “menos es más, hay que mantener las cosas simples” se deduce

de la tendencia Web 2.0: el software se diseña y se construye mediante pequeños

equipos utilizando metodologías agiles; las soluciones tecnológicas se construyen sobre

formatos y protocolos simples; el software se vuelve simple de desplegar en base a

servicios y desarrollos open source; los negocios se focalizan en mantener las inversiones


58

y costos bajos; y el marketing tiende a basarse en técnicas viales simples de usuario a

usuario.

Emergencia: En lugar de basarse en estructuras de aplicaciones totalmente predefinidas,

las estructuras y comportamientos Web 2.0 pueden emerger en el tiempo. Una estrategia

flexible y adaptativa permiten que soluciones apropiadas evoluciones en respuesta al uso

real de las aplicaciones, y por tanto el éxito proviene de la cooperación, no del control.

Desarrollamos a continuación los patrones de diseño, considerando las mejores prácticas que

implican su aplicación.

3.7.1. Aprovechar la inteligencia colectiva

La clave para una ventaja competitiva en aplicaciones de Internet es la permitir a los usuarios

agregar su propio contenido a lo ya creado. Por tanto, es importante crear una arquitectura de

participación que use los efectos de red y algoritmos para producir software que mejore a medida

que más gente lo utilice.

Para lograr esto debemos entender dos principios:

Los usuarios agregan valor: A través de su participación activa y como efecto indirecto de sus

acciones los usuarios agregan valor. Son usuarios que crean contenidos, realizan comentarios,

hablan entre ellos, suben y comparten archivos, hacen recomendaciones, enlazan, agregan,

filtran, buscan entre otras tantas acciones. Cada una de estas acciones agrega valor y crea

nuevas oportunidades.

Los efectos de red magnifican este valor: Cuando un producto o servicio logra un crecimiento

en su valor a medida que el número de gente que lo utiliza crece ocurre un efecto de red.

Este efecto proviene no solo del hecho de que haya más nodos en la red, sino de la

interacción entre estos nodos.

Para entender mejor el concepto de “efectos de red”, analizamos dos teorías, originalmente

aplicadas a redes de telecomunicaciones.

Primero observamos la ley de Metcalfe (67), que indica que el valor de utilidad de dispositivos en

red (como ser teléfonos y computadoras) no se incrementa de una manera linear al aumentar

nodos en la red, sino que crece proporcionalmente al cuadrado del número de estos nodos. Esto

se aplica a Internet y a muchos de sus elementos: email, mensajería instantánea, blogs, etc.

Sin embargo, la ley de Reed (68) analiza

las capacidades de Internet como un

medio de de “formación de grupos”

indicando que estas son las que lo

convierten en un poderoso medio de

comunicación. Específicamente, indica

en el caso de aplicaciones que facilitan

la formación de subgrupos (como ser el

caso de las aplicaciones previamente

analizadas de redes sociales,

Ilustración 14: Impacto de los efectos de red.


59

comunidades de contenidos, o la misma blogosfera) implican un crecimiento de 2N , es decir, un

crecimiento mucho más rápido y exponencial.

Por tanto el software Web 2.0 debe ser diseñado para aprovechar la inteligencia colectiva a través

de una arquitectura de participación. Esto puede ser logrado involucrando a los usuarios de forma

explícita e implícita, minimizando las barreras de la aceptación del producto, y diseñando

productos que fomenten el efecto viral del crecimiento de red. El resultado final es que los

usuarios como individuos y como grupos se convierten en el motor de mejores productos, y de

rápidos y crecientes mercados.

Analizamos a continuación las prácticas que implican la aplicación de este patrón:

Pagar al usuario primero: Los productos Web 2.0 deben minimizar las barreras para la

adopción, asegurándose que los usuarios loguen sus objetivos rápida y eficientemente. Por

tanto será necesario generar una interfaz que permita al usuario cubrir sus necesidades de

forma intuitiva.

Podemos diferenciar entre los objetivos de los usuarios al menos dos niveles: los de primera

orden (por ejemplo, subir una foto, y los de segunda orden, que son en general aquellos

relacionados con los efectos de red, como ser participar en una comunidad). Los de segunda

orden nunca deben interponerse con los de primera.

Analicemos por ejemplo el proceso de carga de una imagen en Flickr. Una vez registrados al

servicio, podemos subir una imagen en tan solo 4 clicks y de una manera muy intuitiva.


60

Activar los efectos de red por defecto: Una de las formas de crear una base de datos es a

través del efecto indirecto de los usuarios buscando cubrir sus propios objetivos. 24 Es

necesario aplicar técnicas para que los contenidos aportados por un usuario se potencien por

medio de los otros usuarios, buscando así un crecimiento exponencial en base a la

cooperación y participación.

Un ejemplo de esto es el caso anterior de Flickr, en donde los usuarios pueden elegir al subir

una imagen si esta debe ser pública o privada, estando esta última opción seleccionada por

defecto. Al ser las imágenes públicas, otros usuarios pueden acceder a estas, utilizándolas o

haciendo comentarios sobre ellas, potenciando la interacción en la comunidad. Como

resultado, cuando luego de un año de existencia Flickr tenía 3 millones y medio de imágenes,

el 82% eran públicas. (69)

24

Dan Bricklin plantea 3 formas de construir bases de datos, y demuestra como esta forma en particular es

un potenciador para algunos ejemplos de la era Web 2.0, como ser el caso de Napster (133).

Pagar al usuario primero- Con tan solo 4 clicks el usuario puede subir una imagen a su cuenta en Flickr.

Ilustración 15: Proceso de carga de imagen en Flickr.


61

Esta simple pero importante práctica tiene su base en lo siguiente:

o Solo un pequeño porcentaje de los usuarios se tomaran conscientemente el trabajo

de agregar valor a una aplicación. (Por ejemplo, solo el 2% de los usuarios de la

Wikipedia son activos y contribuyen contenidos en un mes dado. (70))

o Por naturaleza, la gente es inercial y tiende a aceptar las opciones por defecto. (71)

Involucrar a los usuarios implícita y explícitamente: Para maximizar el valor de cada usuario

debemos aprovechar la participación explicita (como ser crear un nuevo contenido, mejorar

un contenido, comunicar y colaborar) y la participación implícita (el efecto indirecto de las

acciones de los usuarios, como ser a donde van, cuando, como, y que transacciones llevan a

cabo).

Por ejemplo, el sitio Amazon.com promueve la interacción explicita a través de opinión sobre

productos, e implícitamente mediante su motor algorítmico de recomendaciones generando

numerosos contenidos sobre el producto.

Al alcanzar los 3 millones y medio de imágenes, el 82%

de estas eran públicas en Flickr. Las imágenes son subidas como publicas

por defecto en Flickr.

Ilustración 17: Subida de imágenes en Flickr.

Ilustración 17: Porcentagenes de imagenes publicas y privadas en Flickr.


62

Proveer un contexto significativo para la creación: Debemos crear una arquitectura de

participación que haga más que solo invitar a la creación de contenido: debemos crear un

contexto de coherente y consistente. es necesario crear un contexto coherente. Nos

referimos a mecanismos para identidad, reputación, relaciones entre usuarios, identificación

de datos (URLs, tags, estc.), agregación y personalización.

Confiar en los usuarios: Es necesario proveer un contexto abierto para la participación,

interacción y realización de transacciones. Tomando nuevamente el ejemplo de Amazon.com,

encontramos que uno de los puntos fuertes de su estrategia se basa en las opiniones de

productos por parte de los usuarios. Otro ejemplo claro es el de la Wikipedia, que si bien

cuenta con un sistema de moderación y retroceso a versiones anteriores para controlar

posibles ataques a los datos, permite una gran libertad a los miembros de la comunidad en

cuanto a la creación y edición de artículos. Esto implica que las organizaciones ceden control

para compartirlo con sus usuarios. Es decir, deben confiar en estos.

Esta estrategia va de forma contraria a la mayoría de las culturas organizacionales, y es uno

de los desafíos más grandes al aplicar los patrones de diseño Web 2.0. Para esto es necesario

hacer una fuerte moderación de contenidos con reglas claras y flexibles, haciendo un fuerte

esfuerzo para evitar abusos contra el sistema.

Diseñar software que es mejor cuanta más gente lo usa: En base a los efectos de red,

podemos lograr que el software maximice su potencial. Tenemos como ejemplos a

virtualmente todos los casos de social media analizados previamente, y esto es un efecto

directo del aprovechamiento de los efectos de red que mencionamos previamente.

Ilustración 18: Presentación de producto en Amazon.com

En la presentación de cualquier producto de Amazon.com, la mayor parte del contenido es generado por los

usuarios ya sea de forma implícita o explícita.


63

En el caso de los marcadores sociales podemos tomar a Delicious. A medida que más y más

gente cree y aplique tags a contenidos en Internet, mejor será el criterio de clasificación al

utilizar a los tags como filtros para nuestra información, cuando el criterio que deseamos es el

ordenamiento de información en base a personas, no a algoritmos.

Facilitar la emergencia de los contenidos: La

interfaz debe predecir el comportamiento de los

usuarios, pero dejar siempre la libertad para usos

no esperados. De esta forma el usuario aportara

también al diseño de dicha interfaz, por lo que

surgirán formas inesperadas e innovadoras de

mostrar contenidos y permitir la navegación.

Un ejemplo que surgió en los últimos años es la

nube de tags: podemos ver un ejemplo en

Technorati que contiene una pequeña nube de tags

que se actualiza constantemente en base a los tags

aplicados a posts en los blogs indexados por Techonorati por parte de los autores de dichos

blogs. Cuantos más veces se repita un tag, es decir, mas posts tengan ese tag, mayor será el

tamaño de la palabra lo que facilita la navegación hacia los contenidos más populares, de

forma automática basándose en el uso real y no en una estructura previamente pensada de

navegación.

Relación con otros patrones:

Los datos son el próximo "Intel Inside": Una arquitectura de participación exitosa es la base

para la construcción de una valiosa base de datos de contenidos generados y enriquecidos

por los usuarios.

Innovación en el ensamblaje: En base a la generación de APIs, empresas como Amazon.com u

otras citadas previamente generan una arquitectura de participación, dándole a terceros

elementos para construir aplicaciones que potenciaran el valor del servicio.

3.7.2. Los datos son el próximo "Intel Inside"

El mercado esta desplazándose gradualmente desde aplicaciones de escritorio para individuos

hacia un modelo de servicios online compartidos. Este patrón indica que en general el éxito de las

aplicaciones y servicios online proviene de la información, no solo de la función. Existen muchos

ejemplos de esto, como ser el caso del buscador Google: Su base de datos de sitios indexados es

lo que da el valor verdadero al servicio, más allá de las interfaces simples y agradables con las que

llegan a su público. Si los resultados de búsquedas no fueran efectivos, nunca hubiera alcanzado

su éxito. Por tanto, es necesario establecer una estrategia de datos, no solo una estrategia de

producto, para poder obtener una ventaja competitiva.

Ilustración 19: Nube de tags de Technorati.

Nube de tags en base a los posts en blogs

indexados por Technorati del 3/11/2008, una día

antes de las elecciones presidenciales de Estados

Unidos.


64

Aplicaciones de Escritorio Aplicaciones de Internet

Software propietario Uso de APIs (Microsoft y Apple.)

Uso de efectos de red y de software como servicio ( Google, Amazon y EBay.)

Integración de componentes “

Monitores, Placas madre, discos.

Linux, Apache, MySQL, y PHP.

Formas de mantener a usuarios cautivos mediante código propietario

CPU (Intel, AMD) Datos (adWords, NAVTEQ)

Tabla 4: Comparación entre aplicaciones de escritorio y aplicaciones de Internet.

Si miramos a la “era del escritorio”, descubrimos que por más de 15 años la campaña de branding

“Intel Inside” de Intel se basaba en que en cada sistema abierto de hardware existían

componentes propietarios y de código cerrado. Comparando las aplicaciones existentes en ambas

eras podemos ver estructuras o frameworks similares, pero con nuevas reglas. Nuevas ventajas

competitivas se encuentran en las capas superiores e inferiores de la pila emergente de Internet:

En la capa superior del software, la ventaja competitiva viene de los efectos de red y del uso del

software como servicios. En la capa inferior, el control de los datos provee la ventaja competitiva.


Buscar poseer fuentes de datos únicas y difíciles de recrear: NAVTEQ (72) es uno de los

líderes mundiales en cuanto a proveedores de datos de mapas digitales. Entre sus clientes

podemos encontrar a Microsoft y Google, que usan sus contenidos para crear servicios como

Google Maps y Microsoft Vitual Earth (y casualmente, en su estrategia de branding utilizan la

frase “NAVTEQ On Board”, algo que suena similar al caso de “Intel Inside”). NAVTEQ tuvo

éxito en la creación de una base de datos único y valioso, lo que le dio grandes ganancias en el

año 2006.

Aunque NAVTEQ invirtió aproximadamente $700 millones de dólares para crear estos datos,

existen muchos mecanismos de bajo costo, especialmente los basados en aprovechar los

efectos de red en base a una estructura de participación que permiten a los mismos usuarios

de un servicio construir una base de datos. Delicious, YouTube y Flickr son algunos de estos

ejemplos entre los social media analizados.

Mejorar los datos básicos: Los datos de tipo “commodity” no tienen porque mantenerse en

ese estado. Un ejemplo de esto es el de Amazon.com, que sobrepaso a la competencia al

mejorar por diversos medios la información básica provista por catálogos de libros: mediante

las opiniones de los usuarios del sitio, historiales de compra y otros cálculos en base a

algoritmos convirtieron una base de datos básica y disponible públicamente en una base de

datos atractiva y difícil de recrear.

25

El termino económico “ ” hace referencia a productos y servicios genéricos, básicos y que no

presentan mayor diferenciación.


65

La mayoría de los sitios de contenidos de internet permiten ahora que los usuarios

enriquezcan los datos mediante comentarios, puntajes o tags. Delicious utiliza estos medios

para por ejemplo mejorar y enriquecer marcadores de navegadores, dando la opción a los

usuarios a importar estos y aplicar metadatos. Por tanto, debemos buscar formas para que los

miembros de una organización, clientes o socios puedan agregar valor a los datos existentes

o de tipo commodity.

Los usuarios controlan sus propios datos: Es importante entregar a los usuarios formas de

agregar o quitar sus datos del sistema. Esto demuestra a los clientes que deberían confiar en

el servicio, y a su vez que la empresa tiene la suficiente confianza en el servicio que provee

como para permitir a los usuarios tomar sus propios datos personales y eliminarlos del

sistema llevándolos a donde deseen.

Para tener confianza en realizar este tipo de estrategias de datos debemos recordar que el

valor real proviene del contexto, no de los datos básicos, por lo cual las bases de datos

cerradas no llegan a aprovechar todas las fortalezas que provee Internet.

Algunos derechos reservados, no todos:

Cuando los beneficios provienen de efectos

virales y colectivos, la limitación sobre

protectora de derechos intelectuales puede

perjudicar el crecimiento. Por tanto, es positivo

en muchos casos asegurarnos que existan bajas

barreras para la adopción estableciendo formas

apropiadas de propiedad intelectual y de

propiedad de datos.

Entre los casos analizados previamente, hemos

encontrado que existen modelos flexibles y con

beneficios colaterales probados, como ser el de

los modelos de licencias GNU o las Creative

Commons que permiten que software, datos o

contenidos puedan ser compartidos, mientras

preservan los derechos de autoría originales.

Estas estrategias han sido utilizadas como mencionamos previamente en el caso de Flickr,

permitiendo que más de un millón y medio de fotos tengan una licencia de este tipo (73).

Definir una estrategia de pila de datos: Es importante entender cuáles son las ventajas que

atañen a los diferentes niveles de valor de una cadena de datos.

Por ejemplo, el resumido espacio de mapas online de Google Maps. Solo algunos

proveedores, como ser el ya mencionado NAVTEQ, proveen los datos de mapas digitales de

base, que luego deCarta procesa y prepara los datos, para que las aplicaciones de Google

entreguen a los usuarios y aplicaciones de terceros que en base a las APIS provistas por

Ilustración 20: Uso de Creative Commons en Flickr.

Los usuarios de Flickr pueden optar por diferentes tipos

de licencias Creative Commons para sus imágenes, lo

que potencia la reutilización y creación de nuevos

contenidos mientras mantiene los derechos de autor.


66

Google, pueden generar otras capas superiores de uso en

mashups. (74) Claro que los límites entre estas capas no

son claramente delimitados, por lo que existe una tensión

y competencia natural entre ellos.

Por tanto, mientras utiliza los datos de NAVTEQ y el

procesamiento de deCarta, Google Maps se estableció

como el punto de conexión interna y la marca más

conocida en cuanto a mapas digitales respecta.

En base al éxito de Google Maps, deCarta ha creado sus

propias APIs colocándolas a disposición de los usuarios y

desarrolladores. (75)

Ser dueño del índice o del formato: El éxito no siempre

proviene de poseer los datos, sino que a veces puede

derivar de establecer un liderazgo en localizar, organizar, acceder o dar formato a los datos.

Uno de los mejores ejemplos es el buscador Google: no es dueño de las páginas que muestra

en sus resultados de búsquedas, sino que simplemente posee el mejor algoritmo para

indexarlas. Otro claro ejemplo es el ya mencionado buscador e indexador de blogs Technorati.

En casos más actuales, tenemos el ejemplo del mencionado LinkedIn, que busca claramente

ser el lugar por defecto donde se registren perfiles laborales.

Diseñar los datos para su reutilización: En la misma forma en que los datos se están

volviendo tan importantes como la funcionalidad, la reutilización de datos se está volviendo

tan importante como la reutilización de software, y el diseño de datos se está volviendo tan

importante como el diseño de sitios.

El concepto de datos reutilizables se manifiesta en mecanismos de acceso a los datos, en el

diseño de los datos, en la presentación de los datos y las licencias de los datos. Estos puntos

implican seguir estándares como ser el mencionado RSS y microformats, haciendo que los

datos sean fácilmente apuntados y buscados, utilizando licencias suficientemente flexibles y

proveyendo de mecanismo claros de sindicación y redistribución.

Tercerizar o proveer administración al acceso de datos: Mientras que los costos de

almacenamiento y uso de ancho de banda han disminuido dramáticamente, la demanda de la

administración de grandes cantidades de datos todavía presenta un desafío. Esto es

particularmente verdadero para contenidos como ser audio, video e imágenes. Como

resultado, existen nuevas oportunidades de servicios que pueden ser provistos, ayudando a

otros a superar dicho desafío.

Por ejemplo la red social previamente mencionada MySpace terceriza el servicio de imágenes

principalmente a tres empresas (Photobucket.com, ImageShack y Slide.com) que reciben más

de la mitad de su tráfico desde dicho social media (76). En el caso de YouTube, terceriza el

almacenamiento y descarga de videos a la empresa Limelight Networks, generándole a esta

Ilustración 21: Niveles en la cadena de datos de mapas digitales.


67

más de 1 millón de dólares mensuales en ganancias al proveer la infraestructura necesaria

para dar soporte a la mencionada content community. (77)


Aprovechar la inteligencia colectiva: Las aplicaciones basadas en datos son la base para crear

estructuras de participación efectivas

Innovación en el ensamblaje: Las soluciones de plataformas y ecosistemas existen para

compartir información.

3.7.3. Innovación en el ensamblaje:

La plataforma es más poderosa que las aplicaciones en sí. No solo Internet se está convirtiendo en

una plataforma que reemplaza gradualmente a los sistemas operativos de escritorio, sino que

sitios individuales se están transformando también en plataformas y componentes de

plataformas. Por tanto, es importante no solo plantear una estrategia de aplicación sino también

una estrategia de plataforma.

En la era de la PC Microsoft repetidamente demostró el gran valor comercial de crear no solo las

aplicaciones de software, sino las plataformas para las aplicaciones. Sus productos como ser

Windows, Office, SQL Server y otros se convirtieron en la fuerte base donde ecosistemas enteros

eran creados.

La aparición de la tendencia Web 2.0 presento cambios fuertes y abrió nuevas oportunidades de

plataformas por varias razones: Primero, el cambio de software estándares propietarios a

estándares de código abierto basadas en tecnologías maduras y estandarizadas de protocolos.

Segundo, la evolución de sitios estáticos a sitios dinámicos a sitios como los mencionados entre

los social media previamente (por ejemplo, Facebook, Flickr, YouTube, Twitter entre muchos

otros), donde cada vez toman más forma de plataformas que permiten la creación de nuevos

ecosistemas.


Ofrecer APIs de los servicios: Las APIs (Application Programming Interfaces) son el núcleo de

cualquier estrategia de software como plataforma.

Hace algunos años las APIs provenían de empresas como Microsoft, Apple y RedHat. En la era

de la Web 2.0 las APIs provienen de empresas como Flickr, Facebook, YouTube y Twitter. Un

ejemplo claro es el de la API de eBay, lanzada originalmente y de forma innovadora en el

2001, genera en la actualidad el 60% de los listados de eBay, teniendo unos 6 mil millones de

llamados a la API por mes. (78)


68

Otros ejemplos son los de los de las

comunidades de contenidos Flickr y YouTube,

siendo el primero la base para casi 400 mashups

en torno a imágenes (79) y el segundo

alcanzando números similares (80) y por tanto

potenciando su arquitectura de colaboración

para aprovechar la inteligencia colectiva.

Como vimos previamente, la mayoría de los

jugadores fuertes entre los social media y la

tendencia Web 2.0 cuentan con APIs en la

actualidad, pero no solo ellos han incursionado

en esta estrategia de plataforma: Ya en

Noviembre del 2008 John Musser, uno de los

autores de “Web 2.0 Principles and Best

Practices”, registraba más de 1000 APIs de

servicios Web, alcanzando una gran variedad de temáticas y tamaños de proyectos. (81)

Diseñar para la reutilización: El contenido digital se presta para ser desarmado y reutilizado,

un principio que no se ha perdido en empresas innovadoras como Apple, cuando revoluciono

la industria musical al permitir que los consumidores puedan crear colecciones de música

digital, una canción a la vez.

Anteriormente, MapQuest y Microsoft MapPoint eran servicios muy exitosos de mapas

digitales online, pero la estrategia de Google Maps de convertirse en plataforma mediante sus

APIs permitiendo la reutilización y remezcla a desarrolladores cambio las reglas de los

servicios de mapas digitales online, dejando a sus competidores muy por detrás.

Aplicar las mejores prácticas en APIs: Los proveedores de APIs exitosos han establecido

realmente un conjunto de técnicas de comprobado éxito para ayudar que sus servicios sean

más atractivos y útiles para sus usuarios y por tanto establecer y hacer crecer un ecosistema

para desarrolladores viable. Estas prácticas se enfocan en crear una infraestructura de apoyo

que incluye foros, blogs y wikis, dando apoyo a documentación completa y actualizada que

incluye ejemplos de código en distintos lenguajes de programación, suporte a múltiples

protocolos y formatos de datos, utilizando ID de desarrolladores para poder realizar

seguimiento de estos, y mecanismos de administración de las cuentas de dichos

desarrolladores.

Usar los estándares existentes: Cuanto más estandarizadas son las formas en que se puede

acceder a un contenido, es más probable que sea consumido. Un ejemplo de esto son las APIs

de Yahoo!, que pueden devolver información tanto en XML como en formato JSON (82),

siendo el primero útil para aplicaciones de tipo servidor y el último para aplicaciones de tipo

cliente.

Ilustración 22: Categorias de APIs en ProgrammableWeb.com

Las APIs son parte de la estrategia Web 2.0 de gran

variedad de servicios: 15 categorías principales al

alcanzar las 1000 APIs registradas en el sitio

ProgrammableWeb.com


69

Por su parte, el formato microformats se

vuelve cada vez más común debido a que es

fácil de indexar e integrar ya que puede ser

embebido en páginas con HTML

tradicionales. Otro ejemplo fuerte son los

formatos RSS y Atom, que cada vez son más

relevantes y utilizados, cumpliendo el papel

de “pegamento” de la Web 2.0.

En el artículo previamente mencionado de

John Musser, encontramos un análisis de la

distribución de protocolos utilizados en las

más de 1000 APIs que ha indexado en su sitio (81). De esto podemos notar que se reduce a

una cantidad limitada de protocolos populares, y a su vez que algunos tienen un peso

considerable, como ser REST y SOAP.

Construir los modelos de negocios en las APIs: Las mejores estrategias de plataformas

aplican las fortalezas de su núcleo de negocios en sus APIs, para que los intereses tanto del

proveedor como los de terceros estén alineados en una forma mutuamente beneficiosa.

Por ejemplo, las APIs de Amazon.com están directamente conectadas a su sistema de

afiliados lo que implica que cada vez que se produce una venta basada en las APIs, los

beneficios son compartidos por Amazon.com y el desarrollador que utilizo las APIs.

Otro ejemplo es el caso de eBay mencionado en uno de los puntos anteriores, el 60% de sus

listados provienen del uso de las APIs, por lo que fue importante trabajar en que estas

generen listados con ubicaciones eficientes.

Usar Web 2.0 para dar soporte a la

plataforma: Las plataformas abren las

puertas de un amplio abanico de

oportunidades, pero solo tienen éxito

cuando tienen un buen soporte.

Es importante aplicar principios Web 2.0

como ser bajas barreras de adopción,

herramientas en base a efectos de red y

técnicas para construir y dar soporte a un

ecosistema de colaboración.

Esta práctica es realizada por

prácticamente todos los ejemplos que

hemos analizado de proyectos Web 2.0

previamente, que dan soporte a sus plataformas por medio de wikis, foros, blogs y otras

herramientas similares, utilizadas como medio para la colaboración de desarrolladores.

Ilustración 23: Uso de protocolos por APIs.

Distribución del uso de protocolos en las más de 1000 APIs

indexadas por ProgrammableWeb.com.

Ilustración 24: Wiki sobre API de Twitter.

Twitter da soporte sobre sus APIs a su comunidad de

desarrolladores mediante el uso de una wiki, donde

potencia el efecto colaborativo de los usuarios.


70

Un ejemplo es las ya mencionadas APIs de Twitter, que da soporte a su comunidad de

desarrolladores mediante el uso de una wiki colaborativa (45) y mantiene un blog donde los

desarrolladores de Twitter pueden comunicarse con los usuarios de las APIs. (83)

Ser cliente de su propia plataforma: Este patrón puede incrementar la calidad a través de

aplicaciones realistas y cercanas a los desarrolladores de las APIs, así como también reducir

costos por medio de la reutilización.

Un ejemplo de esto es el sitio de eventos Eventful, en conde prácticamente toda la

producción del sitio está basada en su propia API (84), y otro ejemplo claro es el de Yahoo!

Tech (85) donde se puede realizar búsqueda de productos tecnológicos, estando el sitio

basado en las Yahoo! Shopping APIs (86).

Direccionamiento granular de contenidos: La pagina web ya no es la unidad de datos

definitiva de Internet: ahora pueden ser considerados así también los posts individuales de un

blog, elementos independientes de un RSS, ediciones de artículos wiki, o nodos XML

devueltos en una llamada a una API. Este último formato representa el futuro del acceso a

datos online. Cuanto más fina la granularidad en este sentido, mayor será el potencial de

reutilización de los datos.

Podemos ver como elementos tan fundamentales como la estructura de una URL puede ser

utilizada para mostrar la estructura lógica de un sitio, por ejemplo encontramos en Flickr la

siguiente URL mostrando claridad al usuario: http://www.flickr.com/photos/tags/flowers.

En muchas maneras, esta estructura se ha convertido en una línea de comando funcional

y en un modelo de datos por defecto sobre el cual otros pueden construir. En este

sentido es importante considerar que URL simples, claras y legibles son buenas para los

usuarios del sitio, los desarrolladores de aplicaciones de terceros y motores de búsqueda.

Utilizar su plataforma para construir la confianza y lealtad de los clientes: Como

mencionamos previamente, la portabilidad de los datos es uno de los puntos importantes en

esta nueva era de Internet. Una de las motivaciones detrás de la creación de las APIs de Flickr

fue que los propios fundadores del servicio consideraban que no podían confiar en un servicio

que no les permitiera utilizar sus datos donde ellos quisieran. Por tanto, dichas APIs permiten

el acceso a toda la información, e indirectamente genera apertura y confianza por parte de

sus usuarios.

Otro ejemplo es el caso de Google Maps: el primer mashup que existió en base a este servicio

fue HousingMaps.com mencionado al explicar el concepto de mashup anteriomente, que

combinaba los anuncios de ventas y alquiler de departamentos y casas del sitio de anuncios

clasificados Craigslist con los mapas digitales, teniendo este mashup la particularidad de no

estar basado en APIs de Google Maps (ya que en su momento, no existían dichas APIs), sino

que el autor realizo una ingeniería inversa del servicio. Al descubrir esto, Google no tomo

represalias, sino que tomo esto como un ejemplo de lo que podía suceder si abría sus

servicios a otros desarrolladores. Por tanto, genero las APIs del servicio y gano muchos

usuarios desarrollando a la vez confianza.

http://www.flickr.com/photos/tags/flowers


71

Por tanto, notamos que una mayor transparencia y apertura son componentes claros de la

perspectiva Web 2.0.

Aprender de cómo los clientes reutilizan los servicios: La manera en que los clientes utilizan y

reutilizan los datos y servicios pueden ser una muy valiosa herramienta de aprendizaje para el

modelo de negocio. A medida que aplicaciones de terceros y nuevos usos surgen, se crean

oportunidades de ligar estos nuevos elementos de conocimiento a las estrategias de los

productos y del negocio.

Hablando sobre el ecosistema de mashups, el CEO de Google Eric Schmidt comenta que

“Nosotros no tenemos los recursos para construir todo. Dependemos de manera crítica de las

creaciones de las comunidades de desarrolladores”. (87)


Modelos ligeros y escalabilidad costo-efectiva: Es recomendable prestar atención a modelos

de tecnología ligeros como ser REST y RSS, para alcanzar a una gran base de manera costo-

efectiva. Al crear una plataforma que facilite el desarrollo por parte de terceros más que el

desarrollo de desarrolladores internos lleva a reducir esfuerzos y disminuir costos.

Beta perpetuo: En particular, considerar las operaciones como una herramienta o habilidad

de altísima importancia.

3.7.4. Experiencias de usuario ricas

Los sitios web estáticos están cediendo lugar a una nueva generación de aplicaciones

enriquecidas basadas en Internet, que cuentan con la habilidad de combinar muchos de los

mejores elementos de las experiencias de escritorio y online. Por tanto, es necesario crear

mejores experiencias para ayudar a los usuarios en la transición desde un modelo de interfaces de

escritorio a un modelo online.

No hace mucho tiempo, existía una indiscutible distinción entre utilizar una aplicación basada en

escritorio y una aplicación basada en un navegador: experiencias altamente interactivas y rápidas

con interfaces graficas ricas, en contrapartida a interfaces basadas en páginas caracterizadas por

ser lentas, con esperas después de cada click. Esta brecha se ha reducido rápidamente mediante

el surgimiento de una nueva generación de sofisticadas aplicaciones online, redefiniendo lo que

es posible en un navegador.

Esta combinación de los puntos fuertes de experiencias de escritorio y capacidades online crea

nuevas oportunidades que son muy poderosas. Ya no son necesarias las aplicaciones de clientes

pesadas para crear una interesante experiencia para el usuario, así como tampoco las aplicaciones

clásicas como una planilla de cálculo son estrictamente para el uso de un solo usuario ni en una

sola computadora. Las aplicaciones actuales basadas en navegadores son construidas utilizando

técnicas (como ser el caso de Ajax) que dan soporte a interacciones continuas, despegándose de

solo el click hacia acciones como el arrastrar y soltar, y llenas de multimedia. El resultado es una

mayor satisfacción por parte de los usuarios, y una genuina ventaja competitiva.

Ejemplos de esto son los servicios de correo electrónico y mapas de Google, que han revolucionado

sus segmentos de productos, y en los últimos tiempos también surgió el caso de Google Docs que


72

ha presenta herramientas de procesamiento de texto y planillas de cálculo online, no solo

reproduciendo la experiencia de escritorio sino que también agregando la posibilidad de

colaboración y una real independencia de plataforma. Aunque si observamos también los

ejemplos de social media mencionados previamente, encontraremos en sus interfaces numerosos

elementos que apuntan a enriquecer la experiencia del usuario, mostrando una tendencia que

resulta irreversible, ya que este tipo de interfaces se vuelven cada vez más un requerimiento

funcional más que algo accesorio.

Por tanto: utilizar software basado en Internet ya no implica una pérdida en la calidad de la

experiencia del usuario. Ahora podemos ver el poder de aplicaciones interconectadas que

permiten la colaboración y el uso de datos enriquecidos con experiencias de interfaces rápidas y

simples.


Combinar lo mejor de las experiencias de escritorio y online: En este punto nos referimos a

entregar a los usuarios aplicaciones que potencien las fortalezas de escritorio (como ser,

interactividad enriquecida y rápida performance) con las fortalezas de la red (como ser,

independencia de la plataforma, acceso independiente del lugar, y colaboración).

Como mencionamos anteriormente el

caso de Google Docs es uno de los

mejores ejemplos de cómo se

herramientas tradicionales de escritorio

están evolucionando hacia una “oficina

online”: los usuarios del servicio pueden

editar documentos de forma colaborativa

desde estaciones conectadas a Internet

usando interfaces agiles y similares a las

que eran ofrecidas por las aplicaciones de

escritorio. Y además, el modelo de

negocio ha cambiado, beneficiando a los

usuarios en un aspecto extra: el costo. Es

cada vez más común que se apliquen

modelos de negocio basados en software

como servicio, como ser el uso de publicidades.

Pero como mencionamos antes, no se debe buscar solo remplazar las aplicaciones de

escritorio, sino también agregar valor mediante el potencial de Internet: en el caso

mencionado, es destacable nuevamente la posibilidad de colaboración entre usuarios sobre

un mismo documento.

Usabilidad y simplicidad primero: Buscar la aceptación y uso por parte del usuario y eficiencia

de servicio para último son prioridades y no deben ser sacrificadas en pro de utilizar nuevas

tecnologías o interfaces. Es importante no permitir que las innovaciones por más tentadoras

que sean puedan comprometer los verdaderos objetivos de las aplicaciones. Por ejemplo,

Ilustración 25: Captura de pantalla de Google Docs.

Google Docs permite a los usuarios del servicio trabajar de

forma colaborativa sobre documentos, tomando lo mejor de

las experiencias de escritorio y online, a través de interfaces

web enriquecidas.


73

aplicaciones de entrada de datos corporativas no necesitan ventanas que tengan

transparencias, pero si pueden beneficiarse de optimizaciones en el proceso de ingreso de

datos, como ser ayudas en la escritura y correcciones de textos en tiempo real. Es decir,

debemos buscar que una de nuestras estrategias sea la simplicidad.

Por ejemplo, anteriormente las aplicaciones que dependían de audio y video digital,

especialmente los contenidos generados por los usuarios, pasaron por muchos problemas

complejos. Pero proyectos innovadores como el de YouTube han simplificado

dramáticamente los previamente complejos procesos relacionados a los contenidos

multimedia con una plataforma de audio y video basado en Internet: está centrada en

navegadores, busca eliminar los problemas de compatibilidad de tipos de archivos, y provee

interfaces y componentes simples de usar e independientes del tipo de navegador. Es

importante notar que también el concepto de componentes de este tipo que son fácilmente

integrables en virtualmente cualquier otro entorno web han creado una gran innovación en

el ensamblaje, donde los usuarios pueden rápidamente utilizarlos en sus sitios webs o blogs,

difundirlos en sus perfiles de redes sociales u otras aplicaciones online.

Buscar que el uso coincida con los requisitos: Las últimas técnicas y tecnologías dan soporte a

un amplio espectro de interacción y posibilidades innovadoras, y prácticamente cualquier

aplicación tiene algún punto de implementación en este espectro.

Por ejemplo, Google Finance utiliza una combinación de tecnologías como ser Javascript y

Flash para otorgar a sus usuarios experiencias enriquecidas.

Otro ejemplo es el caso de Google Analytics, que ha revolucionado el análisis de datos

estadísticos sobre los sitios web y sus consumidores.

Búsqueda sobre la estructura: Así como motores de búsquedas basados en algoritmos (como

ser Google) son en general más atractivos y útiles que directorios creados por usuarios (como

ser el caso de Dmoz.org o la estructura de Yahoo!), las formas de acceder e incluso crear

contenidos en sitios individuales es ahora típicamente guiado por algoritmos de búsqueda y

de otros tipos.

En los primeras etapas de internet, solo los sitios más grandes podían costear generar

búsquedas en sus propios sitios, pero hoy en día la situación ha cambiado y prácticamente

ningún sitio, por más pequeño sea, puede darse el lujo de no tener mecanismos de búsqueda

interna entre sus contenidos, especialmente dado que los mecanismos para que esto sea

realizable han sido simplificados y son ofrecidos incluso de forma gratuita por buscadores

como Google mediante widgets y servicios.

El servicio Delicious automáticamente sugiere tags en base a una combinación de factores,

incluyendo el contenido de la URL que está siendo agregada a los marcadores, los tags

generados por el usuario previamente, y tag de otros usuarios. Esto hace al proceso más

rápido y simple para el usuario, creando a su vez una forma más consistente de agregar

estructuras de tags para toda la comunidad.


74

A medida que la naturaleza y estructura de contenidos se vuelve menos predefinida y emerge

de la dinámica de los comportamientos y participación de los usuarios, aumenta la necesidad

de algoritmos más inteligentes y poderosos.

Preservar el direccionamiento de los contenidos: En virtud de crear experiencias sin el clásico

concepto de Internet de “hacer click, recargar la página y mostrar el contenido”, algunas

aplicaciones de tipo Web 2.0 están dejando en cierta forma la metáfora de la “pagina” en

Internet. Pero al hacer esto, estas aplicaciones corren el riesgo de olvidar los beneficios que

trae el direccionamiento directo a contenidos (que vimos anteriormente en el patrón de

innovación en el ensamblaje), como ser el hecho de que una página o un conjunto de datos ya

no sea equivalente a una URL.

Por tanto es importante utilizar y establecer técnicas que aseguren que los contenidos son

aun pueden ser encontrados por usuarios (por ejemplo, mediante el uso de marcadores) y por

maquinas (por ejemplo, motores de búsqueda, aplicaciones de terceros y otras herramientas).

Por ejemplo, Google Maps permite que los usuarios hagan zoom a cualquier lugar del mundo

en sus mapas digitales, pero la URL nunca refleja estos cambios de locación.

Lamentablemente, esto implica que los contenidos no implican una URL diferente, por lo que

se pierde mucho en cuanto a los efectos de red se refiere. La solución provista pro Google fue

muy simple: agregar un botón que dice “Vinculo a esta página” que hace que el navegador se

refresque y contenga una URL que identifica el lugar específico donde el usuario está situado

en el mapa digital.

Personalización profunda y adaptativa: Una experiencia Web 2.0 centrada en el usuario va

mucho más allá que la interfaz: la aplicación del usuario aprende dinámicamente del

comportamiento del usuario, anticipando sus necesidades, recordando sus preferencias y

adaptándose de manera apropiada.

Un claro ejemplo es el ya mencionado Amazon.com, que a pesar de ser uno de los sitios con

mayor volumen de tráfico en Internet, genera prácticamente cada página en tiempo de

ejecución, incluyendo lo que algunos de sus competidores brindan como paginas estáticas.

Esto permite que haya lugar para la optimización de la experiencia pata cada usuario,

incrementando tanto la lealtad de los usuarios como las oportunidades de beneficio para la

empresa de acuerdo a su modelo de negocio.

Gmail automáticamente sugiere direcciones de correo al usuario en base al uso histórico del

servicio, quitándole a este la necesidad de recordar las direcciones o tomar un paso extra

abriendo la libreta de direcciones.


Modelos ligeros y escalabilidad costo-efectiva: Aplicaciones de cliente livianas basadas en

navegadores son facilitadores para ciclos de productos rápidos que los de escritorio.


75

Innovación en el ensamblaje y beta perpetuo: Experiencias enriquecidas para los usuarios

simplifican la transición de aplicación es de escritorios hacia modelos de software como

servicio.

3.7.5. Software más allá de un solo dispositivo:

La PC ya no es el único medio de acceso a las aplicaciones basadas en Internet, y por tanto las

aplicaciones que se limitan el acceso solamente a un solo tipo de dispositivo tienen menor valor

que aquellas que pueden tener diversos tipos de conexiones. Por tanto, es necesario diseñar

aplicaciones que desde un primer momento integren datos y servicios haciéndolos disponibles

para computadoras, dispositivos móviles y servidores de Internet.

Estamos ingresando en una era nueva, en la que miles de millones de dispositivos en todas las

formas y tamaños están conectados a Internet. Prono la PC no será el medio de acceso principal, y

eso ya es realidad en países como Japon y Korea. Se está volviendo cada vez más común que

personas se conecten a Internet desde distintas fuentes varias veces al día: La computadora de

escritorio de una oficina, la notebook, la computadora del hogar, consola de juegos, un

reproductor de multimedia portátil, y teléfonos celulares por mencionar algunos. Sin embargo,

este escenario de multi acceso pronto tendrá un crecimiento aun más vertiginoso debido al

rápido crecimiento de la cantidad de dispositivos capaces de conectarse a Internet, y de las

mejoras en los servicios de conexión a Internet, donde las velocidades de transferencia y la

independencia del lugar donde se realice la conexión van ampliando cada vez más estas

posibilidades. Aquí es donde la web como plataforma realmente alcanza todos los límites.

Mas interacciones están abarcando tanto a los usuarios como a los dispositivos, tomemos dos

ejemplos claros:

Imágenes: Fotografías pueden ser tomadas desde dispositivos móviles, enviadas vía email

o conexión a Internet inalámbrica hacia una computadora para ser editadas, y subidas a

un servicio online donde se compartan imágenes, recibiendo estas comentarios, puntajes,

asignación a grupos temáticos por medio de colaboración de otros usuarios, luego

sindicadas vía RSS y APIs hacia otros dispositivos, donde pueden ser descargadas.

Música: Los usuarios de computadoras de escritorio pueden crear listas de música

mediante bases de datos online, y descargarlas a sus dispositivos portátiles. Luego los

historiales de música escuchada son subidos desde estos dispositivos a servicios de musca

online, y filtros colaborativos combinan son combinados de forma algorítmica para crear

estaciones virtuales de radio, que transmiten a navegadores y otros dispositivos, o incluso

equipos de música hogareños con capacidad de conexión a Internet pueden conectarse a

estas transmisiones directamente en las casas de los usuarios.

Sin embargo, todavía estamos lejos de llegar a la visión de la conectividad sin límites de lugar o

tiempo. Mantener información sincronizada y siempre disponible sobre esas plataformas es un

gran desafío, pero a la vez una oportunidad igualmente grande. Las colaboraciones deben ser

consistentemente independientes de los dispositivos. Los dispositivos se están teniendo cada vez

mas capacidades de conocer su propia localización, Muchas plataformas tiene limitaciones en

cuanto a performance pura, capacidades de entrada y salida de datos, habilidades limitadas o

incuso ninguna habilidad para funcionar si no están conectadas a Internet. Aplicaciones Web 2.0


76

exitosas deben lograr aprovechar esta omnipresencia para alcanzar todos los mercados,

facilitando el uso de nuevos escenarios, y ganar ventajas competitivas.


Diseñar desde un primer momento para compartir datos entre dispositivos, servidores y

redes: La interconexión generalizada de las redes ha abierto nuevas oportunidades de

productos, al permitir la conexión de usuarios y dispositivos de forma masiva al utilizar

variedad de dispositivos e interconectarlos aprovechando los efectos Web 2.0 más allá de las

tradicionales computadoras. Veamos algunos ejemplos de este patrón.

La estrategia planteada por Apple con su

iTunes aprovecha la fortaleza de las redes,

computadoras de escritorio y dispositivos

móviles. Este enfoque combinado con un

amplio abanico de opciones de música

para descargar, genero un gran cambio de

paradigma en la industria de la música.

Otro ejemplo es el caso de Microsoft y su

consola Xbox con el servicio de multimedia

online Xbox Live, creando una plataforma

con contenidos generados y compartidos

por los usuarios, rankings, feedbacks,

perfiles de usuarios y listas de amigos. Un

ejemplo más es el del DVR TiVo, que

cuenta con un sistema de subscripción online que aprovecha la inteligencia colectiva tanto

implícitamente mediante los hábitos de los televidentes como explícitamente mediante los

votos de estos: en su sitio web la sección “más populares” se basa en el comportamiento de

los usuarios y podemos encontrarlo en su sitio web. (88)

Estar atentos a la locación: Como mencionamos antes, los dispositivos están atentos a su

locación, por lo tanto, es posible encontrar oportunidades en base a este factor. Tecnologías

como Bluetooth y GPS se están volviendo cada vez más comunes en los dispositivos móviles y

si bien es mejor contar con estas características, la tecnología de locación no es siempre

indispensable para aprovechar este concepto de locación.

Por ejemplo, el servicio de redes sociales Dodgeball.com permite a los usuarios generar citas

de forma casi aleatoria en base a la proximidad geográfica de los usuarios, aunque esta

información es suministrada por los usuarios, sin ser necesario contar con dispositivos que

faciliten los datos de locación. Por otra parte, hay servicios que si utilizan las capacidades

tecnológicas de los dispositivos: otra red social llamada The Plazes aprovecha las capacidades

GPS de dispositivos como ser el iPhone, para indicar donde se encuentran tanto los amigos así

como también otra gente que concuerde con el perfil buscado por el usuario. (89)

Ilustración 26: Captura de pantalla del sitio TiVo.com

TiVo involucra a los usuarios creando rankings en base al

comportamiento de los consumidores en los dispositivos

DVR de sus hogares, conectados al servicio online.


77

Extender la Web 2.0 a los dispositivos: Es

importante buscar áreas donde otros

patrones y prácticas Web 2.0 pueden ser

aplicados en base a los diversos dispositivos

existentes, sin considerar solamente las

computadoras.

Un ejemplo es el caso de eBay que ya

hemos mencionado anteriormente. Para

cubrir este patrón, el servicio permite

notificación por SMS de ofertas en subastas

del usuario, acceso vía equipos móviles

mediante una aplicación especifica e incluso

mensajes de voz que alertan al usuario para

notificarlo cuando una subasta de si interés esta pro terminar, expendiendo todos sus

servicios a los móviles pero de una forma adaptada.

Usar el poder de las redes para hacer los dispositivos más inteligentes: Aunque los

dispositivos móviles se están volviendo cada vez más poderosos, las capacidades de los

servidores siguen siendo aun mayores. Por tanto, es una buena práctica quitar peso en los

móviles, trasladando el procesamiento a los servidores y devolviendo solo resultados livianos

a los dispositivos.

Existen servicios como SCANBUY que permiten que compradores ingresen códigos de barra

en sus dispositivos móviles para recibir de forma casi instantánea información de los

productos y poder por ejemplo, comparar precios. (90) Este es un claro ejemplo del

aprovechamiento del poder de los servidores y redes, exigiendo a los dispositivos móviles solo

un mínimo de esfuerzo en cuanto a procesamiento y ancho de banda, ofreciendo un servicio

online muy poderoso a los usuarios.

Aprovechar los dispositivos como fuentes

ricas de datos y contenidos: Los

dispositivos móviles no solo alcanzan

capacidades de generar textos, sino que

cada día su poder como herramienta de

generación de multimedia va creciendo,

por tanto podemos aprovechar dichas

capacidades ya que poseen características

únicas, al poder generar contenidos en

cualquier momento o lugar y con muy

poco esfuerzo. Existen muchos servicios

online que buscan aprovechar este tipo de

capacidades.

Ilustración 27: Captura de pantalla del sitio eBay Mobile

eBay ha generado distintas maneras de integrar su modelo

de negocio a dispositivos móviles y manteniendo la

tendencia Web 2.0.

Ilustración 28: Captura de pantalla del sitio TN y La Gente

En Argentina el canal de noticias TN ha creado un servicio

para que su audiencia pueda enviar imágenes desde sus

dispositivos móviles, siendo estas publicadas online.


78

En Argentina tenemos el ejemplo del canal de noticas TN, que genero su sitio “TN y la Gente”

donde recibe actualizaciones de los televidentes de noticias, quienes capturan todo tipo de

hechos desde sus dispositivos móviles. De esta forma, se logra ampliar la cobertura de

noticias mediante la creación de una comunidad de “periodismo ciudadano”, alcanzando un

potencial de cobertura que de otra manera seria imposible lograr.

Considerar la “producción-por-click” como

prioridad: Los dispositivos tienen limitaciones

en cuanto a mecanismos de entrada de datos y

pantallas se refiere en comparación a las

computadoras de escritorio, por lo que es crítico

minimizar las barreras en estos dos aspectos. Y a

su vez, existe una gran variedad de dispositivos

(desde teléfonos móviles, consolas de juegos y

ejemplos como el mencionado TiVo) por lo que

existe una gran variedad de casos en estos dos

aspectos.

Es importante aplicar un esfuerzo considerable

en el diseño de interfaces que optimicen la

habilidad de los usuarios para utilizar los

servicios en dichos dispositivos.

Por ejemplo, el servicio de imagen y video móvil ShoZu se focaliza en la simpleza de uso como

su principal factor de éxito, funcionando como intermediario entre el usuario y otros servicios

de Internet, como ser YouTube, Flickr, Facebook y Blogger, buscando simplificar los pasos

para cada acción maximizando el uso de cada interacción del usuario con su dispositivo móvil.

Permitir la independencia de ubicación de los datos: Es importante permitir que los usuarios

mantengan sincronizados datos entre dispositivos sin problemas. John Musser menciona

algunos ejemplos de productos de empresas como ser Intellisync de Nokia que permiten

mantener dicha sincronización entre dispositivos, y comenta que también surgen

componentes de capas de infraestructura como las APIs de Amazon S3 que permiten a

programas de terceros acceder al almacenamiento y sincronización de datos.


Innovación en el ensamblaje: Esta aproximación al software más allá de un solo dispositivo

puede ser visto como una extensión natural del aprovechamiento de Internet como una

plataforma.

Experiencias de usuario ricas: Los dispositivos móviles son cada vez más sofisticados, y están

facilitando la creación de experiencias enriquecidas más allá de las computadoras.

Ilustración 29: Captura de pantalla del sitio ShoZu.

En base a simplicidad de interfaz ShoZu hace de

intermediario entre dispositivos móviles y servicios

como YouTube o Facebook.


79

3.7.6. Beta perpetuo

Cuando dispositivos y programas se conectan a internet, las aplicaciones dejan de ser solo

software para convertirse en servicios permanentes. Esto tiene un impacto significativo en todo el

proceso de desarrollo y entrega de software. Por tanto, ya no se debe agrupar las nuevas

funcionalidades en actualizaciones monolíticas, sino que es necesario agregar estas mejoras de

forma regular como parte normal de la experiencia del usuario. Y por tanto, debemos hacer que

los usuarios prueben permanentemente estas nuevas funcionalidades, estructurando el servicio

para que revele la forma real en la cual dichos usuarios lo utilizan.

Millones de usuarios acceden al software de Google cada día y sin embargo nunca tienen una

razón para hacer la siguiente pregunta “¿Que versión de Google es ésta?”. La razón de esto es que

en la era de la Internet los usuarios piensan en términos de servicios, no de software

empaquetado, y esperan que estos servicios simplemente estén disponibles y que mejoren con el

tiempo. Sin versiones, sin instalaciones y sin actualizaciones. El ciclo tradicional de diseño-

desarrollo-prueba-envío-instalación del software empaquetado está terminando.

El éxito ahora recae en la adopción del modelo de desarrollo del perpetuo beta, en el cual el

software es continuamente refinado y mejorado, tomando los usuarios el papel de co-

desarrolladores y las operaciones se convierten en una habilidad principal. Esto es lo que

podemos llamar desarrollo 2.0.


Liberar temprano y rápido: Esta regla del modelo de desarrollo open source (91) es ahora un

factor crítico para el éxito del software basado en Internet. Es necesario usar técnicas y

metodologías agiles e iterativas de de desarrollo para empaquetar correcciones de errores y

mejoras en publicaciones incrementales que respondan a la retroalimentación de los

usuarios. El uso de pruebas automatizadas y procesos de construcción y liberación para

racionalizar el manejo de calidad y administración son necesarios

eBay por ejemplo libera una nueva versión de su servicio aproximadamente cada dos

semanas. Flickr por su parte llevo esto un paso más adelante, realizando cientos de

liberaciones incrementales en un periodo de 18 meses desde Febrero del 2004 hasta Agosto

del 2005. Si comparamos esto con los ciclos tradicionales que se presentan en el cado de

ejemplo de Microsoft Windows notaremos la clara diferencia de paradigma.

Y no solo los nuevos productos se pueden beneficiar por estas formas: El Yahoo! Messenger

avanzo de una liberación cada 18 meses a 4 cada año.


80

Hacer participar a los usuarios como co-desarrolladores y probadores en tiempo real: El

comportamiento real de los usuarios provee un modelo mucho más correcto para la

evaluación de nuevas características que investigaciones de mercado de marketing,

prototipos o cualquier otra forma de producción no basada en la retroalimentación.

La naturaleza de las aplicaciones basadas en Internet y las habilidades del creador para

activamente monitorear como el software es utilizado implican un cambio dramático desde

los días del software de escritorio. Es estadísticas de los usuarios y la experimentación

controlada sirve para tomar decisiones informadas sobre los productos.

Es necesario establecer modelos de retroalimentación, como las pruebas dinámicas A/B, las

cuales a un pequeño porcentaje de los visitantes de un sitio les es presentada una interfaz con

características y funcionalidades alternativas.

Por ejemplo, Amazon.com utiliza muchas veces por día este tipo de pruebas en su sitio. Los

resultados de estas pruebas alimentan rigurosos procesos guiados por estos datos que dan

indicadores no solo del producto sino también del negocio.

Instrumentar los productos: En el

proceso de desarrollo es necesario

planificar e implementar no solo las

aplicaciones que utilizaran los

usuarios, sino también una plataforma

para capturar información de cómo

estos usuarios están usando el

producto. Lo que los usuarios hacen en

general da más y mejor

retroalimentación que lo que los

usuarios dicen.

Esta plataforma de instrumentación

debe ser guiada por objetivos de

negocio y estar planificada y pensada

Ilustración 30: Comparación de liberaciones de Flickr y Microsoft Windows.

Comparando la cantidad de veces y las fechas en que Microsoft y Flickr liberaron nuevas versiones

de sus productos podemos notar con claridad el cambio de paradigma en el ciclo de desarrollo de

software.

Ilustración 31: Ciclo de de desarrollo de beta perpetuo.

Ciclo de de desarrollo de beta perpetu, incluyendo el

producto, aplicaciones de seguimiento y los requerimientos.

En base a la medición obtenida en las pruebas con usuario,

se compara constantemente el cumplimiento de objetivos.


81

tan cuidadosamente como el producto en sí mismo.

Así como se explico en la dinámica A/B de prueba, la información obtenida debe responder

preguntas especificas como una forma de medir cuán bien se están alcanzando los objetivos y

llevando el desarrollo del producto.

Para este proceso se utilizan las llamadas “aplicaciones sombra”, que son básicamente

herramientas internas y privadas construidas para monitorear el ya mencionado

comportamiento del usuario en la ejecución en tiempo real del servicio. Estas aplicaciones no

tienen que ser necesariamente grandes y complejas, sino ser relevantes. Por ejemplo, Flickr

desarrollo un reporte de “usuarios más solitarios” que permitió identificar a usuarios que no

estaban invitando a amistades al servicio. Flickr se agrego a sí mismo como amigo de esas

personas, con el objetivo de enseñarles como utilizar los servicios de mejor manera.

Crear nuevos productos de manera incremental: Productos nuevos y existentes deberían

evolucionar mediante ciclos rápidos, retroalimentación de los usuarios e instrumentación.

Experimentar con nuevas ideas de productos a través de procesos incrementales y

planificados.

Google lanzo algunos de sus productos más exitosos, incluyendo Google Maps y Gmail, a

través de esta metodología. El Google Maps beta fue lanzado públicamente en Febrero del

2005, y se mantuvo como beta por 8 meses. Durante ese tiempo, Google obtuvo

retroalimentación muy significativa de los usuarios, aumentando prestaciones de forma

incremental, y ganando ventajas competitivas rápidas, ganándole terreno así a competidores

más lentos como Microsoft y Yahoo!.

Hacer que las operaciones sean una habilidad principal: Cuando el software esta siempre

disponible y online, ya no es solo el desarrollo de este lo que determina su éxito, sino que sus

operaciones (las tareas diarias y permanentes de administración de datos y servicios) también

pasan a ser un factor clave.

El éxito de Google no solo se debe a su sus algoritmos de búsqueda, ya que la forma en que

administra sus centros de procesamiento de datos y servidores toma un alto valor para llevar

el servicio a los usuarios permanentemente. Al hacer estas tareas de forma optimizada se

crea una ventaja competitiva significativa en cuanto a costos y calidad. Estas estrategias y

competencias operacionales incluyen:

Ilustración 32: Linea de tiempo de google Maps 2005-2006

Google Maps se mantuvo como beta durante sus primeros 8 meses, en los que en base a la

retroalimentación de sus usuarios agrego rápidamente nuevas funcionalidades al servicio.


82

o Utilizar técnicas de escalamiento horizontal y componentes de hardware de tipo

commodity para una tolerancia a errores simplificada y una alta disponibilidad.

o Utilizar software de bajo costo (en general open source) para aprovechar las grandes

comunidades generadas en todo a estos, que proveen soporte y documentación.

o Asegurar que se cuenta con adecuados sistemas de monitoreo y administración.

o Asegurar que el planeamiento de operaciones y el personal son las principales

prioridades.

o Alimentar en base alecciones aprendidas de experiencias operacionales a los núcleos

de los productos: prestaciones, estabilidad y escalabilidad.

En el nivel de aplicaciones, esto implica que el equipo de desarrollo ya no simplemente

inicializa las operaciones y las deja funcionando olvidándose de ellas, sino que deben integrar

de forma activa el desarrollo, la administración de datos, los ciclos de retroalimentación y las

mediciones.

Usar herramientas y lenguajes dinámicos: Los modelos de ciclos de liberación y desarrollo

agiles se benefician de herramientas y lenguajes apropiadamente flexibles. Es bueno utilizar

lenguajes dinámicos e independientes de plataformas como ser Pyton, PHP y Ruby para

permitir y fomentar la habilidad de cambio, rapidez y productividad.

Hay que considerar plataformas de desarrollo que se focalizan en la simplificación y la

productividad, como ser Ruby on Rails para Ruby, Django para Python y Zend para PHP.

Un ejemplo del éxito es el sitio Basecamp. Para el desarrollo de este sitio la empresa

37signalds desarrollo la plataforma Ruby on Rails, y la empresa indica que las características

de la plataforma ayudaron a construir el exitoso sitio en 4 meses y con un equipo de 2.5

personas (92).


Modelos ligeros y escalabilidad costo-efectiva: Las técnicas agiles de desarrollo de software

son ideales para dar soporte a ciclos de liberación rápidos, porque están preparados para el

cambio. Integrar modelos y procesos ligeros de desarrollo y liberación como complemento del

concepto de beta perpetua. Combinar esto con componentes commodity y de bajo costo para

construir una base de operaciones escalable y tolerante a errores.

Innovación en el ensamblaje: La beta perpetua es el proceso base para el desarrollo de una

plataforma web, y depende de muchas de las mismas competencias de núcleo.

3.7.7. Aprovechar la larga cola

Los sitios pequeños contienen la mayor porción del contenido de Internet y por tanto pequeños

nichos son el potencial principal para las posibles aplicaciones de Internet. Esto implica la

necesidad de utilizar el alcance de Internet para llegar a los mercados que antes hubieran sido

difíciles de capturar de una manera económicamente conveniente.


83

Una gran clase de oportunidades existe ahora,

siendo que antes resultaba prácticamente

inalcanzable. Estas oportunidades fueron

consideradas por Chris Anderson en su modelo

económico llamado “The Long Tail” o “La Larga

Cola”. (93) Este modelo demuestra este cambio de

un mundo de opciones limitadas y mercados

masivos hacia un mundo virtualmente sin límites

de opciones y nidos de mercado, indicando que es

Internet y sus características el motor de este

cambio.

Podemos entender este modelo aplicándolo al marketing de micro-mercados: “Los productos que

tienen baja demanda o un volumen de ventas bajo componen colectivamente una cuota de

mercado que rivaliza o incluso supera los relativamente escasos productos de venta masiva”. (1) Si

consideramos los números actuales que presenta Internet, estos nichos de mercado se vuelven

extremadamente atractivos.

Este concepto es uno de los pilares de la tendencia Web 2.0, y por tanto es importante que las

estrategias apunten a alcanzar a la “larga cola” y no solo competir por lo que se ubique a la

cabeza.

Algunas razones por las que Internet es un excelente medio para aprovechar la larga cola son:

Espacio infinito: Muchas limitaciones del mundo físico están ausentes en Internet, como ser

el espacio donde colocar contenidos y las ubicaciones geográficas fijas, generando asa un gran

espectro.

Micro-mercados: Como mencionamos antes, la mayor parte de los contenidos de Internet se

encuentra en sitios pequeños, y en estos se encuentra la mayor parte de posibilidades y de

audiencia.

El costo como una ventaja: La naturaleza del comercio online disminuye considerablemente

los costos de distribución, inventario y ventas.

Tim O’Rilly utiliza este concepto para explicar las razones de porque el sistema de publicidad de

Google ha tenido éxito con su sistema adWords realizando una comparación con el sistema de

publicidades DoubleClick que de acuerdo a su modelo de negocios se limitaba a costosas

publicidades en sitios muy populares, y por tanto contaba con contratos publicitarios en algunos

miles de sitios fuertes. En contrapartida, Google se enfoco en realizar publicidades de texto,

amigables al usuario y sensibles al contexto, realizando contratos con todo tipo de sitios sin

importar su relevancia o tamaño. Es decir, Google enfoca su estrategia en el poder colectivo de

los millones de pequeños sitios que en realidad conforman la mayor parte del contenido de

Internet y por tanto, logra dominar el mercado de la publicidad online. (66)


Ilustración 33: Representación grafica de "la larga cola".


84

Construir en base a las fortalezas de la larga cola: Podemos decir que este modelo esta

guiado por tres principios: herramientas democratizadas de producción, costo de consumo

disminuido debido a la distribución democratizada y las nuevas formas de conectar a la oferta

y la demanda.

Estas nuevas herramientas de producción en manos de millones de consumidores (que ahora

podemos considerar productores) son la larga cola. Las nuevas formas de distribución como la

Internet hacen a esta cola más gruesa (generando mayor liquidez y consumición), y el mejor y

más claro alcance a mercados guía a los negocios desde los grandes a los nichos (mediante la

búsqueda y el filtrado). La siguiente tabla ejemplifica esto:

Fuerza Negocio Ejemplo

Producción democratizada

Constructores de herramientas para la larga cola, productores.

Cámaras de video digitales, software para la edición de música y video y el blog como herramienta.

Distribución democratizada

Agregación para la larga cola Bienes físicos: Amazon.com e eBay. Bienes digitales: Google y Cragslist. Información: Goolge y Wikipedia. Comunidades: MySpace, Bloglines.

Conexión entre oferta y demanda

Filtros para la larga cola Google, blogs, recomendaciones en base a algoritmos.

Tabla 5: Ejemplos de aplicaciones de las fuerzas de la larga cola.

La necesidad de todas esas capacidades continuara creciendo. David Hornik indica que “el

verdadero dinero (en la larga cola) está en la agregación y el filtrado, y esos serán

interesantes negocios en el futuro.” (94)

Usar administración de datos algorítmica para que

oferta y demanda se igualen: Hay una nueva frase

que ya prácticamente se ha convertido en un refrán

para quienes navegan en Internet: “Los clientes que

compraron esto también compraron X”. Y es el claro

ejemplo de la aplicación de técnicas algorítmicas

para ayudar a los consumidores a encontrar

productos que apunten a su interés real, como en el

caso que vimos de Amazon.com en el patrón

“aprovechar la inteligencia colectiva”. A medida que

el número de productos disponibles aumenta, este

tipo de filtros colaborativos se hace cada vez mas

critico.

Utilizar una arquitectura de participación para que

oferta y demanda se encuentren: Una arquitectura

abierta de participación puede cumplir un poderoso rol complementario a las ya mencionadas

técnicas algorítmicas para alimentar de mejor manera las necesidades de los nichos.

Ilustración 34: Modos de listar noticias de Clarin.com

Clarin.com aprovecha “la sabiduría de las

multitudes” filtrando las noticias en base al

comportamiento de los usuarios.


85

La filosofía “La sabiduría de las multitudes” de James Surowiecki (95) está siendo aprovechada

por empresas y productos de todo tipo como medio para filtrar y buscar en la larga cola.

Capitalizar esta sabiduría de las multitudes puede ir desde opiniones sobre productos hasta

rankings de popularidad y otros puntos similares. Un ejemplo es el del periódico argentino

Clarín, que en su sitio web ofrece filtros para sus usuarios, poniendo a su alcance las notas

más leídas, las más recomendadas y las más comentadas.

Aprovechar el auto servicio de los clientes para alcanzar toda la red de manera costo-

efectiva: Al permitir que los usuarios administren sus propias cuentas les permite mayor

control e información, reduciendo a la vez los costos de soporte al cliente que es una de las

barreras más grandes para el crecimiento escalable.

Prácticamente todos los servicios de Google están basados en este concepto de auto-servicio,

al igual que el modelo planteado por los social media mencionados en muchos ejemplos

anteriores.

La misma estrategia puede ser aplicada para clientes de empresas y negocios: El nuevo

producto de software como servicio Office Live de Microsoft sigue este modelo de auto-

servicio para alcanzar a los negocios pequeños y medianos de la larga cola.

Aprovechar las ventajas del bajo costo de estar online: Los costos de producción e inventario

pueden ser mantenidos bajos al cumplir un rol de agregación (por ejemplo, el caso de eBay) al

utilizar modelos de envío (por ejemplo, Apple para por las canciones de iTunes luego de ser

vendidas) y construcción en base a demanda (por ejemplo, la división BookSurge de Amazon

que brinda a los usuarios servicios de publicación y distribución).


Modelos ligeros y escalabilidad costo-efectiva: Es posible ganar en base a los beneficios de la

larga cola al utilizar modelos de negocios sindicados y bajos costos mantenidos. Modelos de

precios escalables y elásticos permiten alcanzar más mercados.

Los datos son el próximo "Intel Inside”: Poner a disposición de los mercados los datos y

contenidos implica hacerlo mediante pequeñas cantidades de información. Por ejemplo,

iTunes vende música por canciones y no por discos enteros, y periódicos como el New York

Times vende noticias individuales.

Aprovechar la inteligencia colectiva: Utilizar la producción por parte de los usuarios para

aprovechar el potencial de la larga cola.


86

3.7.8. Modelos ligeros y escalabilidad costo-efectiva

La escalabilidad en la Web 2.0 se aplica tanto a modelos de negocio como a la tecnología. Los

cambios en costos, reusabilidad, procesos y estrategia implican que se puede hacer mucho más

con mucho menos. Por tanto, adoptar una estrategia escalable y costo-efectiva que acompañe a

los modelos de negocio, modelos de desarrollo y tecnología para entregar productos al mercado

más rápido y de forma más económica sin sacrificar crecimiento futuro.

En la Web 2.0 los negocios deben escalar y por tanto también deben hacerlo las tecnologías que

los implementan. Y al aplicar un estilo liviano y escalable muchos de los costos tradicionales y

riesgos pueden ser reducidos. Es menor la cantidad de capital necesaria antes de ver el resultado

de una inversión. Ya no son necesarios los grandes equipos de desarrollo de software para que las

aplicaciones puedan tomar vida. Ya no son necesarios los grandes presupuestos de marketing

para lograr llegar al público deseado y hacer conocer la empresa o producto. Y ya no es necesario

construir todas las herramientas para comercio electrónico dentro de cada proyecto. Para

entender esto podemos considerar los siguientes puntos:

Todo va en camino a ser commodity: El hardware, el ancho de banda y el software tienen

tendencias a reducir su costo a medida que se vuelven más masivos, como está

sucediendo.

Reutilización: Software muy poderoso, como ser Linux, Apache, MySQL y PHP

combinados con librerías muy completas de componentes pre codificados han hecho muy

practica la creación de sofisticados sitios en costos tiempos y presupuestos.

Estrategia: Las lecciones de la “burbuja .com” de los años 90’ motivan formas orientadas

al aprendizaje para la financiación de nuevos negocios y el desarrollo de nuevos

productos.

Efectos de red: Efectos virales de boca-a-boca para el marketing y promociones

combinan modelos de ingresos que crecen en cuanto más gente los utiliza.

Procesos: La adopción de procesos de desarrollo agiles, ciclos de productos altamente

iterativos y un compromiso más fuerte con los clientes reduce costos, tiempos y riesgos.

Es decir, el modelo actual de la web es “lo pequeño es el nuevo grande” (96). En muchos de los

ejemplos analizados de social media hemos encontrado que este patrón es un pilar muy sólido

para el éxito. Por ejemplo, el caso de Flickr que realiza mil transacciones por segundos y entrega 2

millones de imágenes utilizando menos de una docena de servidores de bajo costo mediante el

aprovechamiento de software open source gratuito en cada capa de la plataforma, abarcando

desde servidores web a bases de datos. Es la filosofía de Internet como una plataforma de

desarrollo extendida a modelos de negocios.


Escalar en base a la demanda: En una era guiada por los efectos de red, casi todo aspecto de

un negocio y producto debería ser diseñado para comenzar de forma pequeña y luego escalar


87

en base a la demanda: el modelo de tecnología, el modelo de ingresos, e incluso el modelo de

recursos humanos.

En el lado de la demanda del mercado las dinámicas esenciales de los efectos de red se están

haciendo más prominentes: un crecimiento gradual con un punto de inflexión potencial en el

cual se dispara un crecimiento exponencial. En el lado de la oferta, nuevas economías de bajo

costo permiten una mayor flexibilidad a la hora de escalar en la tecnología, el marketing y el

personal.

Digg, la comunidad de contenidos mencionada anteriormente que funciona como filtro a

noticias y contenidos en Internet comenzó en el 2004 con un presupuesto de dos mil dólares,

un servicio de hosting de 99 dólares mensuales, software gratuito open-source y

desarrolladores tercerizados de diez dólares la hora. En 2006, Digg ya estaba entregando a sus

usuarios más de 100 millones de páginas cada día y utilizando más de 90 servidores, pero con

solo 15 personas en su personal. (97)

Sindicar los modelos de negocio: En la economía de red de Internet existe un ecosistema

online de componentes modulares y modelos de negocios sindicados que permiten que las

empresas construyan todo o parte de su negocio en base a componentes de otros. Por

ejemplo, al insertar unas pocas líneas de código en un sitio web es posible obtener ganancias

mediante anuncios publicitarios, realizar transacciones de comercio electrónico, mostrar

videos o imágenes, o realizar búsquedas en el sitio. No hace mucho este tipo de componentes

hubieran requerido un gran esfuerzo, tiempo y costo para ser construidos.

Un ejemplo que optimiza este modelo de sindicación es el de Google adSense: los usuarios

que desean mostrar contenidos publicitarios en sus sitios solo deben crear una cuenta en el

servicio, y luego insertar unas pocas líneas de código Javascript, y así comenzar a publicar

anuncios que en base a su contexto, mostraran publicidades relevantes de distintos

anunciantes, y todo en un par de minutos, sin una inversión inicial y sin conocimientos

técnicos.

Ilustración 35: Ejemplo de Google adSense.

El modelo sindicado de negocios adSense de Google permite que un usuario publique publicidad contextual en su

sitio con solo insertar unas pocas líneas de código JavaScript en unos pocos minutos, y sin necesidad de una

inversión inicial ni conocimientos técnicos más allá del de saber manejar su sistema de administración de

contenidos, como ser el caso del panel de administración en un blog de Blogger.


88

Otro caso que mencionamos anteriormente es el de Amazon.com que realiza una sindicación

de su modelo de ventas online, mediante un modelo de afiliados que ya paso el millón de

usuarios que reciben una comisión de ventas cada vez alguien realiza una compra en

Amazon.com habiendo hecho click previamente en el sitio del afiliado.

Es una buena idea entonces integrar el modelo de negocio de terceros en el modelo de

negocios de un proyecto, y por supuesto, sería muy bueno sindicar el modelo del proyecto

también hacia terceros.

Tercerizar cuando es práctico y posible: A medida que ciertos tipos de tecnologías de

información se convierten en servicios y están disponibles para los usuarios, dejan de ser

ventajas competitivas. Vemos que esto ocurre en muchos niveles desde la base de

infraestructura para almacenamiento y procesamiento de datos hasta el desarrollo, prueba y

administración de operaciones de software.

Esto implica que existen oportunidades para tercerizar de forma estratégica en cada uno de

los niveles, y por tanto es muy raro el caso en el cual estos requerimientos deberían ser

manejados como parte del desarrollo de un proyecto. Este tipo de práctica se aplica desde

proyectos pequeños de dos personas hasta empresas multinacionales.

Un ejemplo es en el caso de servidores para sitios y servicios online, donde encontramos el

servicio de almacenamiento en base a demanda de Amazon S3 (Simple Storage Service) (98),

en el cual los usuarios pagan por el servicio en base al nivel de consumo que tengan en cuanto

a almacenamiento de datos y banda ancha, generando una gran flexibilidad para proyectos

que comienzan pequeños y pueden crecer exponencialmente, sin tener que preocuparse por

la infraestructura que los sostiene.

Más allá del nivel de infraestructura, es recomendable evaluar cada aspecto del ciclo de vida

de desarrollo y operaciones para determinar donde es posible tercerizar estas funciones no

estratégicas, para poder dedicar más tiempo y creatividad en las funciones del modelo de

negocio del proyecto. Y la posibilidad de tercerizar servicios que brinda la globalización

permite que servidos de desarrollo de bajo costo, soporte y operaciones estén disponibles

para empresas de todos los tamaños.

Proveer infraestructuras, funciones y experiencia a terceros: En el otro lado de la

tercerización, es bueno capitalizar las nuevas oportunidades de proveer servicios para el

siempre creciente grupo de necesidades no satisfechas en los diferentes niveles de

infraestructura, funciones y experiencia.

Si revisamos algunos de los ejemplos mencionados en el patrón de “Los datos son el próximo

“Intel Inside”” tenemos el caso de MySpace, que se focaliza en manejar y mejorar sus

habilidades como red social, tercerizando servicios especializados como ser el manejo de

imágenes a empresas como Photobucket. Y el caso de YouTube que utiliza los servicios de


89

almacenamiento y ancho de banda de Limelight Networks para entregar los videos a sus

usuarios.

Nuevas empresas como ser 3Tera (99) están buscando proveer web hosting virtualizado con

estilo de auto-servicio diseñado específicamente para empresas Web 2.0 pequeñas y

medianas.

Escalar los modelos de precios e ingresos: Ahora que se provee el software cada vez más

como un servicio online y ya no como aplicaciones empaquetadas y versionadas, los modelos

de venta y precios de algunos software tradicionales ya no son aplicables. En su lugar han

surgido modelos más escalables y flexibles.

Las más exitosas estrategias de ventas y ingresos no son aquellas basadas en “un solo plan se

ajusta a todos”, sino que incorporan múltiples modelos de fuentes de ingresos y fijaciones de

precios escalables y por niveles. Así los ingresos y la fijación de precios se alinean con los

atributos principales de la Web 2.0:

o Los efectos de red son alentados a través de bajos costos y barreras bajas a la

adopción, proveyendo un camino de crecimiento.

o La fijación de precios bajos o incluso gratuitos aprovecha la larga cola al alentar la

adopción generalizada incluso para personas individuales o pequeñas operaciones.

o Los modelos de publicidad dan soporte a una estrategia de plataforma mediante el

software como servicio, que es gratuito o de bajo costo para el usuario.

o Mantener precios razonables para el usuario motiva la participación, lo que genera

un crecimiento fomentado, comunidades y finalmente, datos generados por el

usuario como parte de una estrategia como la mencionada en el patrón de “Los datos

son el próximo “Intel Inside””.

Modelo de Ingresos

A favor En contra Ejemplos

Publicidad sindicada

Los usuarios obtienen contenidos y servicios gratuitos Servicios de bajos precios gratuitos motivan la adopción.

No siempre están apuntados a mercados correctamente No son apropiados para todos los escenarios

Publicidad contextual en base a texto de Google adSense.

Publicidad en base a sponsors

Los usuarios obtienen contenidos y servicios gratuitos Servicios de bajos precios gratuitos motivan la adopción. Las publicidades pueden ser más apropiadas para los contenidos y la audiencia.

No tan escalable desde el punto de vista de la larga cola

Publicidades variantes con relaciones directas entre publicitarios y publicadores. TechCrunch

Subscripciones Simplicidad Modelo de ingresos recurrente Bajo costo o nulo inicial promueve la adopción.

Los costos disuaden a algunos usuarios. Algunos usuarios (como ser departamentos IT de

Los servicios de Salesforce.com. Basecamp de 37signals. Muchos de los servicios Premium son ofrecidos


90

Opciones de costos fijos o variables (en base al uso)

empresas) prefieren modelos más tradicionales como ser el de licencias.

como servicios de subscripción escalables.

Comisión por transacciones

Atado directamente a las acciones de los clientes. Permite que los usuarios (en este caso socios) compartan las ganancias.

No aplicable para todos los modelos de negocios.

Los programas de afiliados de Amozon.com y eBay.

Servicios Premium

Opciones de mejoras atractivas para los usuarios gratitos o que consumen publicidades.

Algunos clientes no estarán interesados en mejoras.

Los servicios adicionales de impresión de fotografías de Flickr. Microsoft Office Live

Licencias de productos

El modelo más tradicional y por tanto familiar a los usuarios.

Menos flexibilidad y escalabilidad. No se aplica bien para el software como servicio.

Programas tradicionales de escritorio como ser Microsoft office. Programas tradicionales para empresas como ser Oracle.

Fallar rápido, escalar rápido: Tener éxito en Web 2.0 requiere innovación, pero la innovación

implica riesgos. Para mitigar estos riesgos es necesario adoptar filosofías de fracaso rápido y

escalado rápido que motiven nuevas ideas y experimentación con estas, pero que reconozcan

que la falla de proyectos es posible, y que cuanto más rápido se genere una adaptación al

fracaso más rápido se estará listo para encarar nuevos proyectos. La velocidad es crucial,

tanto en la ejecución como en la toma de decisiones.

Diseñar para el escalamiento: La escalabilidad no es algo que sucede por accidente. Es

necesario comenzar con decisiones tácticas y estratégicas que permitan el escalamiento a

medida que el negocio o el producto crece:

o La simplicidad escala: El crecimiento rápido es fomentado al esquivar soluciones

complejas, particularmente en tecnologías y diseños.

o El auto-servicio escala: Como muchos negocios que aprovechas la larga cola lo

demuestran, dar el poder a los usuarios de auto gestionarse les da mayor control y

simultáneamente mantiene bajos los costos operativos y de soporte. El impacto de

esto es amplificado a medida que se genera el crecimiento.

o Sistemas emergentes escalan: La búsqueda de Google entrega resultados

emergentes a medida que los usuarios de Internet generan contenidos y los vinculan

mediante links. El modelo de eBay también facilita la emergencia. Wikipedia escalo a

más de un millón de artículos (10 veces el tamaño de la Enciclopedia Británica) en

base a su diseño abierto, descentralizado y emergente.


Beta perpetuo: El desarrollo de procesos y herramientas agiles y livianas complementan a

modelos de negocios livianos.


91

Innovación en el ensamblaje: Las plataformas facilitan el escalamiento y motivan a otros

a hacer trabajos e innovaciones que aportan al proyecto.

3.7.9. Resumiendo los patrones de diseño

Es complicado poder mantener una visión clara de los patrones de diseño en un primer momento.

Para ayudar en esto podemos tomar como referencia la siguiente tabla adaptada de la publicación

de “Web 2.0 Principles and Best Practices” en base al desarrollo de este trabajo:

Patrón Términos relacionados

Ejemplos Practicas

Aprovechar

la inteligencia

colectiva.

Arquitectura de participación

Los usuarios agregan valor

Efectos de red

Creacion colectiva

Wikipedia

Flickr

Amazon Delicious

Technorati

Pagar al usuario primero.

Activar los efectos de red por defecto.

Involucrar a los usuarios implícita y explícitamente.

Proveer un contexto significativo para la creación.

Confiar en los usuarios. Diseñar software que es mejor a medida que

más gente lo usa.

Los datos son

el próximo

"Intel

Inside”.

Estrategia de datos.

Creative Commons

Amazon

eBay

NAVTEQ

Craigslist YouTube

Buscador de Google

Technorati LinkedIn

Buscar poseer fuentes de datos únicas y difíciles de recrear.

Mejorar los datos básicos.

Los usuarios controlan sus propios datos. Algunos derechos reservados, no todos.

Definir una estrategia de pila de datos.

Ser dueño del índice o del formato.

Diseñar los datos para su reutilización. Tercerizar o proveer administración al acceso

de datos.

Innovación en

el ensamblaje. La Web como

plataforma.

Mashups. Remezcla

Pequeños pedazos débilmente acoplados.

APIs

REST y SOAP.

Google Maps

Twitter

Amazon Facebook

Eventful

Flickr

HousingMaps

Ofrecer APIs de los servicios.

Diseñar para la reutilización.

Aplicar las mejores prácticas en APIs. Usar los estándares existentes:

Construir los modelos de negocios en las APIs.

Usar Web 2.0 para dar soporte a la plataforma.

Ser cliente de su propia plataforma. Direccionamiento granular de contenidos.

Utilizar su plataforma para construir la confianza y lealtad de los clientes.

Aprender de cómo los clientes reutilizan los servicios.

Experiencias

de usuario

ricas.

Aplicaciones de Internet Enquiquecidas

Ajax

GMail Google Docs

Google Analytics

Google Maps YouTube

Combinar lo mejor de las experiencias de escritorio y online.

Usabilidad y simplicidad primero.

Alcanzar los requerimientos de los usuarios.

Priorizar la búsqueda sobre la estructura. Mantener el direccionamiento de los

contenidos.

Personalización profunda y adaptativa.

Software más

allá de un

solo

Computación ubicua

26

iTunes

TiVo eBay

Diseñar desde un primer momento para compartir datos entre dispositivos, servidores y redes.

26

Integración de la informática en el entorno de la persona, de forma que los ordenadores no se perciban

como objetos diferenciados. http://es.wikipedia.org/wiki/Computaci%C3%B3n_ubicua


92

dispositivo. SCANBUY TN y la Gente

Shozu

Intelisync

Estar atentos a la locación. Extender la Web 2.0 a los dispositivos.

Usar el poder de las redes para hacer los dispositivos más inteligentes.

Aprovechar los dispositivos como fuentes ricas de datos y contenidos.

Considerar “un-click-por-producción” como prioridad.

Permitir la independencia de ubicación de los datos.

Beta

perpetuo. Fin del ciclo de

adopción de software

Software como servicio

Desarrollo 2.0

Extreme Proggraming27

Google Flickr

Amazon

Basecamp

Liberar temprano y rápido. Hacer participar a los usuarios como co-

desarrolladores y probadores en tiempo real.

Instrumentar los productos.

Crear nuevos productos de manera incremental.

Hacer que las operaciones sean una habilidad principal.

Usar herramientas y lenguajes dinámicos.

Aprovechar

la larga cola. Micro-mercados Sabiduria de las

masas

Amazon eBay

adWords

iTunes

Office Live

Construir en base a las fortalezas de la larga cola.

Usar administración de datos algorítmica para que oferta y demanda se igualen.

Utilizar una arquitectura de participación para que oferta y demanda se encuentren.

Aprovechar el auto servicio de los clientes para alcanzar toda la red de manera costo-efectiva.

Aprovechar las ventajas del bajo costo de estar online.

Modelos

ligeros y

escalabilidad

costo-efectiva.

Sofware y hardware de tipo commodity.

Ecalabilidad

37Signals adSense

Digg

Amazon S3

Flickr Photobucket

Limelight

Escalar en base a la demanda: Sindicar los modelos de negocio.

Tercerizar cuando es práctico y posible.

Proveer infraestructuras, funciones y experiencia a terceros.

Escalar los modelos de precios e ingresos.

Fallar rápido, escalar rápido.

Diseñar para el escalamiento.

Tabla 6: Resumen de los patrones de diseño

3.8. Tecnologías para Web 2.0

Implementar proyectos en base a lo planteado sobre la tendencia Web 2.0 implica desarrollar

modelos, estrategias y tácticas en base a la aplicación de los patrones y mejores prácticas que

hemos mencionado anteriormente, dejando en un plano secundario a las tecnologías que les dan

soporte y base.

Pero por supuesto, es imposible crear una pirámide como esta si no hay una base solida. Por

tanto, en esta parte del marco teórico vamos a acercarnos a la parte técnica que implica el

enfoque Web 2.0.

En su libro “Unleashing Web 2.0: From Concepts to Creativity” (100) los autores comentan sobre

la tendencia Web 2.0 y referencian a las definiciones creadas por O’Reilly, buscando comprender

27

Metodología ágil de desarrollo de software que será analizada posteriormente.


93

a la tendencia mediante la exploración y la observación critica de los desarrollos que han sido

atribuidos a la Web 2.0 en base a puntos de vista técnicos y de negocios.

Esta parte del marco teórico tomara una fuerte base en esta publicación, y haremos un hincapié

fuerte en el primero de estos dos puntos de vista, ya que hemos cubierto el segundo mayormente

con los patrones de diseño Web 2.0 publicados por O’Reilly.

Este análisis técnico permite reconocer diversas líneas de desarrollo cuyo punto final es la Web

2.0, pero cuyas raíces pueden ser claramente reconocidas y registradas. Muchos sitios y servicios

que se analizan en este proyecto existen desde antes que surgiera el concepto Web 2.0, por lo

que notaremos que estos no son el resultado, sino partes de los origenes, es decir, sitios y

servicios que sentaron las bases y han sido líderes en esta tendencia.

Podemos comenzar con una perspectiva histórica, analizando como surgió inicialmente Internet,

observando los avances tecnológicos que sentaron el camino para que esta red logre el alcance

actual. A continuación observaremos los avances en las tecnologías de Internet, haciendo énfasis

en los lenguajes, formatos y estándares que hay sido desarrollados en años recientes. Luego

observaremos los núcleos de Web 2.0, los mecanismos técnicos como ser las APIs, las llamadas de

procedimientos Web, los mashups, las aplicaciones de internet enriquecidas y el uso de tags y

folksonomias. Fianlmente realizaremos un analisis de procesos utilizados para desarrollo web.

3.8.1. Las bases de Internet

3.8.1.1 El modelo Cliente-servidor, protocolos y navegadores.

Si bien Internet ya ha sido utilizada desde los últimos años de los 70’ de diversas formas como ser

la transmisión de archivos y correo electrónico, se presento un punto de inflexión que libero el

potencial de esta infraestructura de red, y fue el surgimiento de un nuevo servicio. Este permitía

el envío de archivos escritos en el lenguaje HTML (Hypertext Markup Language), y mediante el

uso de una aplicación denominada “navegador” instalada en una maquina local era posible

interpretar este archivo de forma grafica.

El navegador Mosaic del año 1993 fue el primer navegador grafico, y contaba con las

características de acceder a datos utilizando Internet, el protocolo FTP, u otros servicios de

Internet, y la renderizacion de HTML y por supuesto, funcionaba basado en el principio de cliente-

servidor, que todavía es la base de Internet.

Si bien el concepto es básico para el alcance del

proyecto, es necesario refrescar brevemente

algunos detalles de este, ya que servirá de

fundamento para temas futuros.

Básicamente, los clientes requieren servicios, y

los servidores los brindan. Cuando un cliente

quiere un servicio como ser el acceso a una base

de datos, envía una petición al servidor

correspondiente. Este procesa la petición y

devuelve el resultado al cliente.

Ilustración 36: Interacción entre cliente y servidor.

La interacción básica de Internet entre navegadores y

servidores web está basada en el modelo de red cliente-

servidor.


94

Este esquema analizado con más detalle por otros autores (ej, Tanenbaum), se ha vuelto

extremadamente exitoso en las aplicaciones de software, y como mencionamos anteriormente es

la base de las interacciones entre navegadores y un servidor de Internet.

Una característica de este concepto es que comúnmente funciona de manera sincrónica: Mientras

el servidor está procesando el pedido, el clientes estará inactivo y en modo espera. Una vez que la

respuesta llega el cliente continuara su acción. Por ejemplo, si el cliente ha pedido una página en

la cual parte de la información depende de una base de datos, la página no puede ser completada

hasta que toda la información ha sido procesada. Esto ha sido lo más común en el contexto de

Internet hasta no hace mucho tiempo.

Dos estándares fueron la base para el impulso de Internet: el mencionado HTML (Hypertext

Markup Language) y el protocolo HTTP (Hypertext Transfer Protocol) que es utilizado para realizar

las llevar las peticiones del cliente al servidor y para llevar las respuestas del servidor al cliente.

Así, da la base para el modelo cliente-servidor en Internet, y como veremos, esto se ha

modificado solo levemente desde la llegada de los servicios web. Por su parte HTML se ha vuelto

una herramienta muy exitosa para publicar contenidos e información en Internet, ya que es un

lenguaje simple que no necesita un amplio conocimiento de programación para ser comprendido

en sus niveles más básicos, y también su alta tolerancia a fallas, ya que en caso de surgir errores

en el código, estos serán simplemente ignorados en general.

Como consecuencia de los primeros indicios del poder de Internet, comenzaron a surgir nuevos

navegadores iniciándose así una gran lucha sobre estos por parte de empresas como Netscape

que lanzo su Netscape Navigator en Octubre de 1994 en base al proyecto original de Mosaic y

Microsoft que lanzo su Microsoft Explorer en Agosto de 1995, en versiones muy lejanas de

navegadores con capacidades de las que presentan los de hoy en día. Esa batalla fue finalmente

ganada por Microsoft, pero luego surgieron otros que tomaron fuerza, como ser el caso de

Mozilla Firefox.

En estas etapas tempranas Netscape introdujo algunos concepto que potenciaron el poder de

Internet,( como ser cookies, nuevas capacidades de HTML como ser los marcos y más tarde el

lenguaje Javascript) siendo que posteriormente algunas de estas innovaciones se convirtieron en

estándares mediante organizaciones como ser W3C (Workd Wide Web Consortium) y ECMA

(European Computer Manufacturers Association).

3.8.1.2. Vínculos y búsquedas

La base de la popularidad de Internet en un comienzo puede ser considerada la posibilidad de que

una página o un documento HTML contenta hipervínculos o simplemente vínculos, que son

referencias a otras páginas (en otros sitios o en el mismo sitio). Este concepto rompe la linealidad

de lectura tradicional presentada en los textos.

A gran escala, podemos decir que Internet es una gigantesca colección de documentos

conectados por hipervínculos y esto puede ser percibido desde un punto de vista más técnico

como un grafico en el cual los documentos HTML individuales son nodos unidos por los vínculos.


95

Estos vínculos están compuestos por un nombre y

una URL (Universal Resource Locator, que es la

dirección lógica de una página web). Cuando el

usuario hace click en un vínculo, el navegador

contacta al servidor web correspondiente a esa URL

a través de un conjunto de protocolos que entre

otras funciones, cumplen la resolución de nombres

de dominios28. Estos vínculos son los que permiten

la “navegación” a través de Internet, y la idea

básica de esto es que si algo que el usuario está

buscando no se encuentra en la pagina donde esta,

puede utilizar un vinculo para dirigirse a otra donde

encontrara información más relevante o incluso

vínculos que lo lleven a otros lugares donde

encontrar dicha información. Sin embargo, los

vínculos no necesariamente apuntan a otras

páginas, sino que también pueden dirigirse a otros lugares dentro de la misma página.29

Volviendo a la idea del grafico de nodos, podemos decir que en la actualidad es extremadamente

grande, conteniendo estimativamente más de diez mil millones de nodos. Seguir vínculos implica

crear “caminos” en el grafico (secuencias de nodos que se siguen). Sin embargo, es interesante

destacar que estos caminos no se generan de una forma aleatoria, sino que en general

representan la “búsqueda” de un término o una combinación de términos contenidos en un nodo.

Es decir, estos caminos representan un patrón de conducta en el usuario.

Ahora, este grafico es dinámico, cambiando constantemente y por lo tanto haciéndose imposible

conocerlo completamente. Por lo cual no es posible realizar búsquedas de manera comprensiva,

ya que no hay indicadores de cuan larga una búsqueda debería ser, o por cual camino debería

seguir.

Otra cosa destacable es que los contenidos de Internet no están totalmente interconectados. En

(101) se realizo un estudio en el cual el grafico tenía una forma similar a la de un moño, con

diversos componentes:

Un núcleo central que contenía paginas entre las cuales los usuarios podían navegar con

gran facilidad.

Otro gran grupo, llamado de “entrada” que contenía paginas que apuntaban al núcleo

pero que no podían ser alcanzadas desde este.

28

Esto se refiere a traducir la dirección lógica (URL) a una dirección física (IP) para hacer posible la conexión

al servidor web.

29 Un análisis más técnico sobre navegación puede ser encontrado en (102).

Ilustración 37: Modelo simple de páginas y vínculos.

Podemos pensar a Internet como un conjunto de

nodos (páginas web) conectados (mediante los

vínculos).


96

Un tercer grupo grande

llamado de “salida”, con

páginas que podían ser

alcanzadas desde el núcleo

pero que no vinculaban hacia

este.

Y finalmente, un grupo más

pequeño de páginas que si

bien interconectaban entre sí,

no tenían vínculos hacia el

núcleo, e incluso podían

encontrarse paginas

totalmente desvinculadas.

Como consecuencia de esto, un

usuario quizás no pueda encontrar un

camino entre dos páginas elegidas al

azar, debido a la posibilidad de que no

estén interconectadas.

3.8.1.3. La exploración y búsqueda en Internet.

Como consecuencia de lo anterior, Internet depende de la exploración, como ser la progresión en

caminos o secuencias de nodos sin objetivos predeterminados. Este concepto tiene una

perspectiva extremadamente práctica, en cuando a cómo encontrar información en este

“hiperespacio” o como lograr comprender este grafico tan grande y dinámico para una aplicación

o uso en particular. Aquí es donde es necesaria la actividad de “búsqueda”.

Los motores de búsqueda son la

herramienta más importante que

existe para encontrar información

en Internet. En la última década

se presento una fuerte lucha

sobre el dominio del mercado de

estas herramientas, siendo en la

actualidad el motor de búsqueda

Google el líder del mercado, en

base a su algoritmo de búsqueda

y sus prácticas.

La búsqueda es algo que se ha

vuelto generalizado, y hoy en día

los usuarios realizan búsquedas

en motores de búsqueda

mediante un grupo de palabras,

observando luego una pequeña

Ilustración 38: Modelo tipo moño de páginas y vínculos.

El grafico de Internet puede ser considerado en forma de moño,

contando con 4 grupos de páginas.

Ilustración 39: Motor de busqueda.

Un motor de búsqueda está compuesto típicamente por tres componentes:

un rastreador, un indexador y un servidor.


97

porción relevante de los comúnmente miles o millones de páginas que pueden contender esos

términos, según el criterio del motor de búsqueda. Y a su vez, se realizan búsquedas directamente

dentro de sitios o en grupos de sitios específicos, ya que podemos hablar del caso mencionado de

Technorati, un buscador específicamente de blogs.

Desde una perspectiva técnica, un motor de búsqueda está basado en técnicas de obtención de

información (102) y tiene tres componentes principales: un rastreador, un indexador y servidor.

El rastreador explora Internet por distintos caminos, realizando copias de las páginas y

entregándoselas al motor de búsqueda para que las analice (revisitando las paginas cada cierto

intervalo de tiempo). Este análisis es realizado por el indexador, que extrae términos de las

páginas y las inserta en una base de datos (el índice). Cada término es asociado con el documento

original correspondiente y su URL. Finalmente, el servidor es el que responde a las consultas de

los clientes. Cuando un usuario realiza una búsqueda sobre algún término en especial, el

indexador devolverá un determinado número de páginas que pueden ser relevantes, y estas son

ordenadas por el servidor, donde la idea es siempre mostrar los resultados más relevantes

primero. Y en este punto de “que es lo relevante” es donde se encuentra lo más complejo.

3.8.1.4. PageRank

La popularidad de Google se debe a que la empresa desarrollo una forma innovadora de realizar

las búsquedas en base a términos y de asignar relevancias a los resultados.

Andes de que este enfoque fuera aplicado, los motores de búsqueda simplemente devolvían un

listado de resultados en los cuales los términos aparecían, y el usuario debía investigar sobre la

relevancia de estos. El cofundador de Google Larry Page tuvo la idea de que no todos los

resultados de una búsqueda eran igualmente relevantes, por lo que sugirió que era necesario

aplicar un ranking de relevancia a estos resultados, y para esto desarrollo junto a Sergey Brin en

la Universidad de Stanford un algoritmo al que llamo PageRank que utiliza una formula recursiva

para calcular el ranking (103).

Monika Henzinger, antigua directora de investigaciones de Google explico la idea del algoritmo de

la siguiente manera: “Consideremos el caso de un doctor. Cuanta más gente recomiende al doctor,

mejor se supondrá que este doctor es. Esto es similar al caso de un ranking de las páginas web:

cuantas más paginas contengan links a una página p, mayor será el ranking de la pagina p.

Sin embargo, la calidad del doctor también depende de la calidad de la persona que lo

recomienda. Hace una diferencia si la referencia proviene de un colega, o de un vendedor, o de la

industria farmacológica. Si el doctor es recomendado por otro doctor, esa recomendación contara

al 100%, la recomendación de una enfermera sin educación profunda sobre medicina contara solo

un 60%, la de un paciente un 20%, y la de un vendedor (que tiene un interés muy distinto al de un

doctor) contara un 0%. El principio detrás de esto (también encontrado en citaciones científicas

clásicas) es así basado en la idea de observar a los links que van apuntados hacia la pagina p para

calcular el ranking de p, pero hacerlo de una manera recursiva aplicando el mismo concepto de

ranking a todas las páginas de donde emergen estos links.”


98

Al pasar los años el algoritmo agrego muchos otros criterios aparte de los arriba comentados para

mejorar los resultados de las búsquedas30.

Es importante recordar el concepto analizado previamente de “la larga cola”, y comprender que

se aplica de forma directa sobre las búsquedas de Internet, ya que la mayoría de las consultas a

motores de búsqueda son sobre termino poco frecuentes, es decir, la mayor parte están en la

larga cola.

Si bien el algoritmo puede perfeccionarse constantemente agregando criterios más complejos, es

muy difícil llegar a igualar la capacidad de una persona: aplicar intuición, experiencia,

razonamiento y conocimiento de un dominio o tema en particular a los resultados de una

búsqueda, con el objetivo de diferenciar cuales son buenos resultados y cuáles no. Esto

demuestra que existe un gigantesco lugar para la mejora continua en el campo de la búsqueda en

Internet31.

Los algoritmos deben aprender más aun de los procesos de búsqueda que surgen del

comportamiento de los usuarios. Más allá del concepto de la búsqueda basada en términos,

existen otras ideas en base a búsquedas de textos, interpretación de textos, asociaciones de

palabras o taxonomías aplicadas al campo de la búsqueda en Internet, y en el caso de la Web 2.0

están surgiendo conceptos revolucionarios que analizaremos luego.

3.8.2. Estructura, presentación y contenidos.

.Como se menciono anteriormente, así como el hardware necesario para dar soporte a proyectos

de Internet se ha vuelto de tipo commodity, los costos en el área de la tecnología del software se

han reducido significativamente, y una manifestación de esto es el caso de LAMP: un acrónimo

común para referirse al desarrollo de software en base al uso de herramientas open source,

utilizando a Linux como Sistema operativo, Apache como servidor web, MySQL como base de

datos y PHP como lenguaje de programación.

3.8.2.2. HTML

También se menciono al lenguaje HTML como el lenguaje predominante en el desarrollo de

páginas web, proveyendo capacidades para estructuras basadas en texto denotando tablas,

parágrafos, listas entre otras opciones, complementando estos textos con formularios, imágenes,

links y por tanto, interacción en base a una estructura de elementos llamados “tags” o “markups”

(cuya traducción seria “márgenes”). Estos siguen algunas reglas sintácticas simples, y son

utilizadas para describir tanto el contenido como la presentación de un documento.

Veamos un ejemplo de una página HTML, aplicada para mostrar unos elementos de un catalogo

de DVDs.

30 Podemos encontrar un análisis más detallado de los aspectos algorítmicos y matemáticos detrás de

PageRank en (134).

31 Para información actualizada sobre motores de búsqueda es posible consultar

http://searchenginewatch.com/.


99

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//

“http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<title>Catalogo de DVD</title>

<meta name="author" content="Juan Ortiz">

</head>

<body>

<h1>Catalogo de DVD</h1>

<table width="500">

<tr>

<td bgcolor="silver">

<b><a href="http://www.imdb.com/title/tt0298228/">Le Fabuleux destin

d'Amélie Poulain</a></b> (2001)

</td></tr>

<tr><td>Director: Jean-Pierre Jeunet</td></tr>

<tr><td>Actores: Audrey Tautou</td></tr>

<tr> <td bgcolor="silver">

<b><a href="http://www.imdb.com/title/tt0120737/">The Lord of the Rings:

The Fellowship of the Ring</a></b>(2001)

</td></tr>

<tr><td>Director: Peter Jackson</td></tr>

<tr><td>Actores: Elijah Wood, Ian McKellen</td></tr>

</table>

</body>

</html>

Este código nos daría como resultado lo siguiente, al ser guardado en un archivo de extensión

.html y ejecutado en un navegador:

Como vemos existe una gran variedad de tags en HTML, y estos son utilizados para indicar que

ciertos pedazos de código tienen un significado semántico especial, y estos tags son definidos en

el estándar de HTML que se esté utilizando.

Si notamos la primera línea del código, ahí se indica que se está utilizando “HTML 4.01

Transitional”, una versión introducida por el W3C en 1999, existiendo diversas especificaciones

hoy en día, pero siendo esta una de las más comunes. Esto es llamado el DTD (Document Type

Definition), y en la misma línea se indica la URL donde pueden encontrarse los detalles de la

especificación incluyendo los tags validos y la forma de utilizarlos.

Ilustración 40: Ejemplo de uso de HTML.


100

Observemos brevemente algunos de los tags utilizados, encontramos que el documento HTML

está compuesto por una cabecera y un cuerpo, delimitados por los tags <head></head> y

<body></body>, indicando que todo lo contenido entre estos tags pertenecerá a esos bloques y

por tanto tendrá las propiedades correspondientes.

Los datos de cabecera son no son en general mostrados en el navegador directamente, sino que

contienen el titulo del documento, que será mostrado en el titulo del navegador, metadatos

(como ser en este caso, el autor del documento), y otros tipos de tags que comentaremos más

adelante.

En el cuerpo se da la estructura y los contenidos que serán mostrados en el navegador. Podemos

ver que se estrutura la pagina con un titulo (entre tags <h1></h1>) y una tabla (entre tags

<table></table> con la propiedad de ancho de 500 pixels) que contiene los elementos del

catalogo, divididos en columnas (entre tags <tr></tr>) y filas (<td></td>, algunas con un color gris

de fondo). A su vez, encontramos textos y links, teniendo los links la estructura <a

htref=”URL”>TEXTO</a>.

Esto es suficiente para lograr comprender el concepto de los tags mínimamente y de cómo el

HTML se utiliza. 32

La mayor parte de los tags del ejemplo anterior son utilizados para denotar la estructura del

documento (como ser tablas, filas o links). Encontramos también tags como ser el caso de

<b></b>, que indica que una porción de texto deberá ser mostrada en negrita, por tanto

definiendo la forma en la cual el contenido es presentado. Otros elementos en algunos tags como

ser width de una tabla o bgcolor son llamados propiedades, y definen también como el contenido

es mostrado, sin necesariamente hablar de la estructura. Estos son llamados “tags y atributos de

presentación”. A su vez, encontramos elementos como ser los textos y las URLs, que tampoco

hablan de estructura o de presentación, sino que son contenidos. Es decir, podemos encontrar

tres tipos de elementos que podrían ser considerados independientes en su naturaleza.

La separación de la estructura, presentación y contenido se ha convertido en un tema de interés

cuando las páginas web comenzaron a ser diseñadas para utilizarse y visualizarse en más y más

dispositivos (computadoras, teléfonos móviles, etc.) ya que cada tipo de dispositivo tiene sus

propias capacidades, características y restricciones por lo que necesitaran distintas formas de

estructura y presentación para mostrar los contenidos. Y además, el HTML de las páginas es

prácticamente generado en todos los casos de manera dinámica por aplicaciones, siendo muy

extraño el caso en que se utilicen archivos de texto estáticos, y la separación de estos tipos de

elementos daría lugar a la reutilización: en base a una estructura, pueden aplicarse distintas

formas de presentación, y a su vez mostrar distintos tipos de contenidos.

Más adelante notaremos formas para lograr esta separación, pero podemos mencionar un

pequeño ejemplo aunque aún no hemos desarrollado la teoría completamente: Los contenidos

32

Podemos encontrar más detalles del lenguaje en (135).


101

puros podrían estar almacenados en una base de datos. Podríamos tener distintas formas de

presentación, guardadas en distintos archivos CSS (Cascading Style Sheet), distintas estructuras en

diferentes archivos de tamplate, y a su vez una aplicación en un lenguaje de servidor como ser

PHP sería la encargada de tomar los datos de la base de datos, introducirlos en una estructura y

aplicarles el estilo correspondiente, devolviendo al cliente un archivo HTML generado de forma

dinámica específicamente por ejemplo, para ser utilizado en un dispositivo móvil contemplando

sus características y limitaciones.

3.8.2.3. XML

Los tags de HTML están predefinidos, y si bien hay formas de utilizar tags adicionales (por

ejemplo, embebiendo lenguajes de scripting) en general no pueden ser definidos por el usuario.

Esto es diferente en el caso de XML (Extensible Markup Language), lenguaje en base a tags que da

soporte a una gran variedad de aplicaciones y que no tiene ningún tipo de tags predefinidos, sino

que se basa en las definiciones del programador, por lo que es considerado un “meta lenguaje”. 33

El estándar XML ha sido ampliamente en los últimos años, siendo uno de los pilares de las

tecnologías de Internet. Es un subgrupo simplificado del SGML (Standard Generalized Markup

Language) y es ampliamente utilizado para compartir e integrar información entre aplicaciones.

Los lenguajes basados en XML son a su vez razonablemente legibles y entendibles para el

humano, ya que los tags para cada caso son en general elegidos de tal forma que mantengan una

relación con el contenido que encierran dentro de un documento.

Desde que fue lanzado en 1995, se han desarrollado muchos lenguajes en base a XML, pudiendo

ser clasificados principalmente en los orientados a aplicaciones y los orientados a tecnología. A

continuación mencionaremos algunos que se encuentran en esta última categoría, como ser

XHTML, SOAP WSDL, RSS y ATOM, pero más adelante veremos algunos de aplicaciones como ser

RDF y OWL.

Con el objetivo de validar, procesar y

transformar documentos XML, se han

desarrollado una gran variedad de

herramientas, pudiendo mencionar

archivos DTD (Document Type

Definition) o archivos XSD (XML Schema

Definition) para las especificaciones,

lenguajes de consulta como ser XPath y

XQuery, y lenguajes de transformación

como ser XSL y XSLT. Estos junto a XML

forman la base tecnología para los

lenguajes mencionados anteriormente.

33

Podemos encontrar más información sobre las recomendaciones de tags en el sitio de W3C

(http://www.w3.org/MarkUp/#recommendations) e información detallada sobre XML en (136).

Existen diferentes componentes relacionados al XML. Aquí

podemos ver algunos de estos.


102

Existen también plataformas enteras basadas en XML, como ser BizTalk, RosettaNet y ebXML que

utilizan herramientas y lenguajes para especificar proceso de negocios y documentos.

Los documentos de XML deben estar bien formados, es decir, cada tag debe tener apertura y

cierre en el mimo nivel. Es por esto que los documentos se estructuran en arboles, y una serie de

características de XML se derivan de esto. Por ejemplo, la búsqueda de un tag específico en un

documento se basa en buscar el camino en la estructura de nodos del árbol.

Podemos decir que los tags definen elementos. Podemos ver un ejemplo de un código XML

aplicado para el caso anterior del catalogo de DVD.

<?xml version="1.0" encoding="UTF-8"?>

<DVDCatalog>

<Title>Catalogo de DVD</Title>

<DVD category="Comedy" language="fr">

<Title>Le Fabuleux destin d'Amélie Poulain</Title>

<IMDBLink>http://www.imdb.com/title/tt0298228/</IMDBLink>

<ASIN>B0000A02Y4</ASIN>

<Director>

<Person>

<Firstname>Jean-Pierre</Firstname>

<Lastname>Jeunet</Lastname>

</Person>

</Director>

<Actors>

<Person>

<Firstname>Audrey</Firstname>

<Lastname>Tautou</Lastname>

</Person>

</Actors>

<Year>2001</Year>

</DVD>

<DVD category="Fantasy" language="en">

<Title>The Lord of the Rings: The Fellowship of the Ring</Title>

<IMDBLink>http://www.imdb.com/title/tt0120737/</IMDBLink>

<ASIN>B00005U515</ASIN>

<Director>

<Person>

<Firstname>Peter</Firstname>

<Lastname>Jackson</Lastname>

</Person>

</Director>

<Actors>

<Person>

<Firstname>Elijah</Firstname>

<Lastname>Wood</Lastname>

</Person>

<Person>

<Firstname>Ian</Firstname>

<Lastname>McKellen</Lastname>

</Person>

</Actors>

<Year>2001</Year>

</DVD>

</DVDCatalog>


103

Podemos ver que la estructura del documento está bien formada, y notamos que si bien no hay

semántica definida para los elementos, el documento es fácil de entender para un lector humano,

lo que es visto como una de las ventajas del XML. Aquí el elemento catalogo contiene dos

elementos DVD, pudiendo ver claramente sus elementos titulo, director, actores y año.

Los documentos XML pueden ser restringido en el uso de los esquemas de formatos, definiendo

estos cuales elementos pueden ser usados en un documento, que atributos pueden tener, y como

los elementos deben ser anidados.

Continuando con nuestro ejemplo, vamos a restringir que un catalogo pueda solamente contener

DVDs, a través de la especificación del esquema en un archivo DTD.

<!ELEMENT DVDCatalog (Title, DVD+)>

<!ELEMENT DVD (Title, IMDBLink, ASIN, Directors, Actors, Year)>

<!ATTLIST DVD category CDATA #REQUIRED language CDATA #REQUIRED>

<!ELEMENT Director (PERSON)>

<!ELEMENT Actors (PERSON+)>

<!ELEMENT Person ((Lastname, Firstname) | (Firstname, Lastname))>

<!ELEMENT IMDBLink (#PCDATA)>

<!ELEMENT ASIN (#PCDATA)>

<!ELEMENT Title (#PCDATA)>

<!ELEMENT Year (#PCDATA)>

<!ELEMENT Lastname (#PCDATA)>

<!ELEMENT Firstname (#PCDATA)>

En este documento DTD indicamos que como un subelemento de DVDCatalog, un documento

válido debe tener un titulo y al menos un DVD (indicado con el signo +). A su vez, un DVD debe

tener título, el link de IMDB.com, el ASIN (Amazon Standard Identification Number,

posteriormente utilizaremos este dato), directores, actores y año. Los DVDs también pueden

tener atributos, pueden o no tener director, deben tener al menos un actor, y cada uno de los

valores es del tipo PCDATA (Parsed Character Data). Podemos notar que el elemento persona

consiste en dos subelementos nombre y apellido. Podemos verificar claramente que el

documento XML del catalogo cumple con este DTD.

Como mencionamos anteriormente, existen muchos lenguajes basados en XML, y son

especificados utilizando DTDs. Un ejemplo de esto es XHTML34 (Extensible Hypertext Markup

Language), que es una reformulación de HTML en un formato XML. Es llamado “extensible”

porque utiliza la construcción de nombres de dominio35 de XML para permitir que otros lenguajes

basados en XML puedan ser incluidos en el código.

En nuestro ejemplo hemos elegido los nombres de los elementos y sus atributos, para dar una

estructura de datos para nuestro catalogo, haciéndola coincidir con la información que queremos

almacenar en el documento. Sin embargo, no hemos dado instrucciones de cómo debe ser

34

Podemos encontrar información sobre el DTD de XHTML en (137) y más sobre el lenguaje en (135).

35 Hablaremos más sobre nombres de dominio de XML más adelante, cuando tratemos el tema de Web

services.


104

representada esta información, logrando la separación de contenidos que habíamos mencionado

antes. Un navegador por lo tanto no sabrá cómo interpretar este documento como una página

web.

Más adelante veremos cómo podemos agregar información de presentación a un documento

XML, y como la misma técnica puede ser utilizada para dar formato al contenido de un

documento HTML con los archivos de estilo.

3.8.2.4. CSS

Los estilos CSS (Cascading Style Sheets) permiten la definición de estilos para elementos de

documentos estructurados. Esto implica que es posible aplicar CSS36 a archivos XML y HTML.

Vemos a continuación un ejemplo de ambos casos.

3.8.2.5. CSS y XML

Como mencionamos antes, los documentos XML no tienen una semántica predefinida, y por tanto

los navegadores no saben cómo interpretarlos. Utilizando CSS podemos definir la forma en deben

ser presentados los elementos.

Veamos un ejemplo para el caso del catalogo:

DVDCatalog {

display: block;

margin: 5px;

width: 500px;

}

Title {

display: block;

padding: 0.1em;

margin-top: 0.1em;

}

DVDCatalog > Title {

font: bold large sans-serif;

text-align:center;

}

DVD > Title {

font: large sans-serif;

background-color: silver;

}

DVD {

display: block;

font: normal medium sans-serif;

}

Person {

display: inline;

}

Director > Person:before {

content:"Director: ";

36

En los puntos siguientes mostraremos solo algunas aplicaciones de CSS con poco detalle. Para más

información es posible consultar (138).


105

}

Actors:before {

content:"Actores: ";

}

Actors {

display: block;

}

Year {

display: none;

IMDBLink, ASIN{

display: none;

}

Como podemos notar, el archivo consiste de secciones de la forma “selector {propiedad:valor;}. ”.

Pueden incluirse muchos pares de propiedades y valores dentro de las llaves, y el significado de la

sección de un selector es el siguiente: Todos los elementos que son del tipo “selector” serán

mostrados utilizando las propiedades y valores incluidos en las llaves.

En el código mostrado anteriormente, la primera sección define las reglas para el elemento

DVDCatalog. Donde sea que ese elemento sea encontrado, se mostrara como un bloque de 500

pixeles de ancho y un margen de 5 pixeles en todas las direcciones. La segunda sección define las

reglas para Title en una forma similar, y notamos que este se aplica para todos los títulos, es decir,

los el titulo del catalogo y los títulos de los DVD. Pero para diferenciar a estos dos, las secciones 3

y 4 tienen selectores un poco más avanzados, como ser DVDCatalog -> Title indica el titulo

correspondiente al catalogo, mostrándolo con letras en negrita, mientras DVD -> Title lo muestra

con fondo gris. Vemos algo similar en el caso de Director -> Person:before, que usa además el

pseudo-elemento before, indicando que antes que un elemento de este tipo se muestre, se debe

aplicar formateo adicional. Sin embargo, la propiedad content permite que texto adicional se

muestre antes del elemento. Usamos este selector para mostrar “Director:” antes del nombre del

director. Un texto similar es mostrado antes de Actors para mostrar “Actores:” antes de la lista de

actores. En general, los pseudo-elementos son implícitamente aplicables cuando existe un

elemento ordinario. Otros pseudo-elementos seleccionan la primera letra o la primera línea de un

elemento que contiene texto. La última sección especifica que el IMDBLink y el ASIN no se

muestren. Los otros bloques tienen selectores de una de las formas comentadas y definen estilos

para otros elementos de este documento XML.

Ahora que hemos definido un archivo de estilo CSS, debemos indicarle al navegador que debe

utilizarlo para darle formato al momento de mostrar el archivo XML, y para esto insertamos la

siguiente línea luego de la primera línea del archivo XML:

<?xml-stylesheet media="screen" type="text/css" href="mi_estilo.css"?>

El atributo media indica que el archivo CSS relacionado en href debe ser utilizado cuando se

muestra el archivo XML en pantallas de alta resolución y a color (screen). Existen muchos tipos de

media, como ser handeld para pantallas pequeñas con ancho de banda limitado, y print para

presentaciones formateadas para ser impresas.


106

Si abrimos el archivo XML en un navegador podremos verlo con el formato deseado.

Como podemos ver un archivo CSS puede

permitir que un archivo XML sea mostrado en

Internet, aunque no es común publicarlos de

forma tan directa. Una razón de esto es que

los archivos XML pueden llegar a tomar un

gran tamaño y por tanto en general son

guardados en bases de datos., y en general no

hace flat amostrar todos los datos que

podrían incluirse en un archivo XML (por

ejemplo, muy rara vez sería necesario mostrar todos los elementos de un catalogo de DVD). Por

tanto es común que solo se seleccionen ciertas partes o incluso que se integran distintas fuentes

de datos en una página web. Para hacer esto, los datos guardados en formato XML en bases de

datos son accedidos mediante lenguajes de consulta como ser XSLT o XQuery37(Melton and

Buxton, 2006), con el objetivo de construir una página XHTML o HTML. Por tanto, es mucho más

común agregar hojas de estilo a documentos HTML, y a continuación veremos cómo se realiza

esto.

3.8.2.6. CSS y HTML

Para ejemplificar la aplicación de CSS sobre archivos HTML, podemos volver al primer ejemplo

planteado donde explicábamos el concepto de tags. Para poder utilizar CSS de forma más

completa, vamos a remplazar las partes de representación del archivo, como ser tals tablas, por

contenedores <div> anidados. Estos elementos generar bloques de texto sin dar mayor

información sobre la semántica del bloque. Por tanto, los tags div deben ser utilizados cuando no

hay un tag semánticamente significativo que pueda usarse. Como veremos en el ejemplo a

continuación, también hemos borrado otros elementos de presentación, como ser colores de

fondo, y remplazamos la indicación del texto en negrita <b> por el tag <h2>. A su vez, al div que

remplaza la tabla le asignamos el atributo class con el valor de DVDCatalog, y así respectivamente

con otros.

Y a su vez, de la misma forma en que lo hicimos con el archivo XML, relacionamos al documento

con la hoja de estilos agregando una línea de código, esta vez incluida en la cabecera del código

HTML.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>



<link rel="stylesheet" type="text/css" href="mi_estilo_html.css">

</head>

<body>

<div class="DVDCatalog">

37

Para más información sobre consultas sobre datos XML es posible consultar (139).

Ilustración 41: Ejemplo de uso de XML con CSS.

Resultado al ejecutar el archivo XML con un estilo CSS

asociado en un navegador


107

<h1> Catalogo de DVD </h1>

<div class="DVD">

<div class="DVDHead">

<h2><a href="http://www.imdb.com/title/tt0298228/">

Le Fabuleux destin d'Amélie Poulain</a></h2> (2001)

</div>

Director: Jean-Pierre Jeunet<br>

Actores: Audrey Tautou

</div>

<div class="DVD">

<div class="DVDHead">


The Lord of the Rings: The Fellowship of the Ring</a></h2>(2001)

</div>

Director: Peter Jackson<br>

Actores: Elijah Wood, Ian McKellen

</div>

</div>

</body>

</html>

Y a continuación incluimos el código del archivo CSS correspondiente, donde podemos ver

claramente como se ha logrado una separación del contenido y la presentación. El primer selector

define que todo texto en el documento debe ser mostrado con la familia de tipografías sans-serif

a menos que sea sobrescrito por otro selector mas especifico. El segundo selector usa la notación

de punto que significa que todos los elementos div que pertenecen a la clase DVDCatalog deben

tener 500 pixeles de ancho y 5 pixeles de margen, y utilizamos el mismo constructor para dar

estilo al selector div.DVDHead.

* {

font-family: sans-serif;

}

div.DVDCatalog {

margin: 5px;

width: 500px;

}

h1 {

text-align: center;

}

h2 {

font: bold large sans-serif;

display: inline;

background-color: transparent;

}

div.DVDHead {

padding: 0.2em;

margin-top: 0.3em;

background-color: silver;

}

El resultado es una página similar a la que vimos inicialmente, siendo la única diferencia visible la

tipografía. Pero lo importante es que en este segundo ejemplo tenemos una estructura interna

más clara, y que puede ser adaptada con facilidad a diferentes usos.

Ilustración 42: Ejemplo de uso de HTML con CSS.

Resultado al ejecutar el archivo HTML con un estilo CSS

asociado en un navegador.


108

Aunque los ejemplos mostrados son pequeños, muestran con claridad las diferencias en el uso

apropiado y el uso apropiado de HTML. El agregado de CSS y su consecuente uso lleva a códigos

con más significado semánticamente, y esto es algo esencial en proyectos grandes, siendo que

prácticamente ningún sito hoy en día puede darse el lujo de no aplicar esta separación de

presentación y contenidos.

3.8.3. Tecnologías de scripting.

A continuación analizaremos las posibilidades que brindan las diferentes tecnologías de scripting

disponibles en la actualidad, con el objetivo de realizar consideraciones como desarrollar

contenidos de Internet interactivos y dinámicos. Los análisis realizados sobre HTML, XML y CSS

serán de utilidad para esto.

Es necesario discutir sobre estas tecnologías primero, para posteriormente poder utilizar los

conceptos como base para las principales tecnologías que dan soporte a aplicaciones que brindan

experiencias enriquecidas para el usuario, uno de los patrones de Web 2.0.

Considerando el modelo cliente-servidor, es importante observar que mientras toda la

información incluyendo programas se almacena en los servidores, dichos programas pueden ser

ejecutados en ambas partes. Un navegador ejecutara típicamente código HTML mientras que el

servidor realizara distintas funciones que darán como resultado contenido HTML. En ambos casos

se ha vuelto una práctica común el uso de lenguajes de scripting, también llamados lenguajes de

programación de scripting: lenguajes que típicamente son interpretados, y que en general se

distinguen porque no tienen la necesidad de ser compilados para ser ejecutados, sino que se

mantiene como código fuente siendo interpretados línea por línea cada vez que son ejecutados.

Podemos también referirnos al código de lenguajes de scripting simplemente como “scripts”.

Por tanto, hablamos de scripting en el cliente si utilizamos un lenguaje de scripting para mejorar

el código HTML interpretado por un navegador. La aplicación principal de esto es realizar páginas

más dinámicas, como veremos más adelante. En este punto acotaremos nuestra visión y análisis

al caso de Javascript38, un lenguaje de scripting orientado a objetos. En general el servidor

entregara código HTML con código Javascript embebido, y el cliente lo reconocerá cuando este

procesando el documento, realizando la ejecución del código. En este sentido es importante

aclarar que esta práctica lleva a que el código quede publicado abiertamente, por lo que podemos

decir que el scripting de cliente es intrínsecamente open source.

Por otra parte, hablamos de scripting en el servidor cuando se utiliza código para la generación de

contenidos en base a HTML de forma dinámica en el servidor. En general se realizan conexiones a

bases de datos, adaptando las respuestas a las necesidades del cliente. Existen muchas

tecnologías que cumplen esta función y son ampliamente utilizadas, como ser ColdFusion, Java

Server Pages, Javascript en el lado del servidor, Ruby y PHP. En este análisis desarrollaremos

ejemplos utilizando PHP y Javascript, con lo cual podremos abarcar el concepto.

38 El lenguaje ha sido desarrollado por Netscape, y es importante aclarar que no tiene relación alguna con el

lenguaje Java de Sun Microsystems. Podemos encontrar más información sobre el lenguaje en

https://developer.mozilla.org/en/About_JavaScript


109

En general el scripting en el servidor se realiza en base al protocolo CGI (Common Gateway

Interface). Este protocolo implica una comunicación entre ambas partes, realizando básicamente

lo siguiente:

1. El cliente provoca una ejecución de un script CGI en el navegador, en general con

parámetros tomados de un formulario

2. El servidor reconoce esto e inicia el programa CGI, que puede realizar acciones arbitrarias

(como ser el acceso a una base de datos), pero luego genera código XHTML que es

enviado al navegador.

3. El cliente interpreta el código y genera la nueva página.

Las llamadas CGI requieren una copia del programa, que en el caso de los scripts es el intérprete

del lenguaje de scripting, para correr pada petición.

3.8.3.2. Scripting en el cliente

El igual que lo realizado en el caso de HTML, analizaremos un ejemplo de la aplicación de

lenguajes de scripting en el cliente para poder acercarnos al concepto. Podemos aprender más

sobre las aplicaciones de Javacript en las referencias mencionadas anteriormente.

Para embeber código Javacript en un documento HTML se utilizan los tags <script>, indicando que

el código incluido entre ellos no debe ser interpretado como HML, algo similar a lo que

analizamos en el caso de códigos CSS. También es posible incluir el código en un archivo separado

de extensión ”.js”, relacionado mediante la propiedad src del tag <script>. Veamos a continuación

un ejemplo para demostrar su uso.

Si recordamos, hemos estructurado los contenidos del catalogo en bloques div. Ahora haremos a

la pagina un poco más dinámica, haciendo que estos bloques se colapsen o se expandan a través

de un click, ocultando y mostrando por tanto la información que contienen, pero sin necesidad de

que haya que recurrir el servidor para lograr esto (una de las propiedades del scripting de cliente,

como mencionamos antes).



<html>

<head>




<script type="text/javascript">

function toggleDVDDisplay(id) {

var contentElement = document.getElementById(id);

if (contentElement.getAttribute('expanded')=='false') {

contentElement.style.display = 'block';

contentElement.setAttribute('expanded', 'true');

} else {

contentElement.style.display = 'none';

contentElement.setAttribute('expanded', 'false');

}

}

</script>

</head>


110

<body>


<h1> Catalogo de DVD </h1>

<div class="DVD">

<div class="DVDHead"

onClick="toggleDVDDisplay('B0000CABBW')">



</div>

<div class="DVDContent" id="B0000CABBW">

Director: Jean-Pierre Jeunet<br>


</div>

</div>

<div class="DVD">


onClick="toggleDVDDisplay('B00005U515')">


The Lord of the Rings: The Fellowship of the Ring</a></h2> (2001)

</div>

<div class="DVDContent" id="B00005U515">

Director: Peter Jackson<br>

Actores: Elijah Wood, Ian McKellen

</div>

</div>

</div>

</body>

</html>

Podemos notar tres cambios: El tag script en la cabecera, el cambio en el elemento div de la clase

DVDHead, y el agregado de un nuevo div que envuelve los contenidos de un DVD.

Podemos ver como entre los tags script de la cabecera HTML se define una función

toggleDVDDisplay, que toma el parámetro id como input. Al igual que en otros lenguajes, los

bloques de código son limitados por llaves. La segunda línea define la variable contentElement a

la cual se le asigna el resultado de la llamada a la función document.getelementById(id). El objeto

document es la pagina web actual, por lo que esa función traerá como resultado una vinculación

con el objeto que lleve por nombre el valor de id. La tercer línea abre un bloque de if-then-else

que cambia dependiendo del valor del atributo expanded. Si el objeto esta expandido, lo

colapsara (líneas 4 y 5), y si está colapsado lo expandirá (líneas 7 y 8).

El siguiente paso una vez que entendemos la pequeña función, es comprender como es ejecutada

y como es que recibe el valor de input. Ahora cada cabecera de DVD tiene el atributo

onClick=”toggleDVDDisplay(‘VALOR’), tiendo el valor el numero ASIN el identificador único del

DVD según Amazon que mencionamos inicialmente. El atributo onClick es lo que se llama

“atributo de evento intrínseco”, y permite que un script sea ejecutado cuando el evento “Click”

ocurre en el elemento donde está incluido. De esta forma, se ejecuta la función y se le envía como

parámetro el ID del elemento que esta signado en los div que envuelven a la clase DVDContent, el

tercer cambio que hemos mencionado. Cuando se ejecute la función al hacer click en el titulo del

DVD, se evaluara si el div cuyo id es enviado se encuentra colapsado o expandido, actuando de

manera consecuente, y por tanto mostrando u ocultando el contenido de dicho div.


111

3.8.3.3. Document Object Model y Dynamic HTML

Este pequeño script accede a partes del documento HTML, para tomar los valores de variables

que representan atributos HTML, y para definir los estilos de los elementos. Esto no lo hace

directamente manipulando los tags HTML y sus contenidos, sino que lo hace a través de objetos

que se encuentran presentes en el contexto del script ejecutado. En efecto, hemos mencionado al

objeto document que contiene la pagina en sí, y esto nos da pie para analizar la relación de un

documento HTML y el DOM39 (Document Object Model), que es la descripción que le indica al

navegador como debe representar el árbol de HTML como un conjunto de objetos, con

relaciones entre estos y métodos para acceder a esos objetos a través de varias estructuras. Es

justamente el DOM el que le da a un script la posibilidad de trabajar con los elementos de una

página web.

Podemos ver una parte del DOM de nuestro

ejemplo de catalogo utilizando un plugin del

navegador Firefox llamado DOM Inspector.

Podemos ver el nodo de datos

correspondiente con su clase y sus

propiedades de estilo en el lado derecho de la

imagen, y notamos como el elemento que

analizamos se remarca en un rectángulo.

El objeto document el objeto que contiene la

pagina web, y hemos utilizado su método

getelementById(id) para seleccionar

elementos a través de sus identificadores.

Como los identificadores son únicos, es una

forma conveniente de seleccionarlos. Existen

otras funciones que devuelven elementos,

como ser getelementByClassname y

GetelementsByName, aunque se diferencian

en que pueden devolver más de un elemento

ya que los nombres pueden repetirse,

mientras que los identificadores únicos no.

Es importante mencionar que la combinación de HTML, CSS, scripting de cliente (generalmente

Javascript) y DOM toma el nombre colectivo de DHTML (Dynamic HTML). Esto es para acentuar

que esta combinación es considerablemente más que el solo HTML, que queda estático una vez

que fue cargado.

Utilizando HTML para los contenidos, CSS para los estilos, scripting para lógica de programación, y

DOM para funcionar como pegamento entre los tres anteriores las paginas pueden cambiar su

apariencia en base a eventos pero sin realizar peticiones al servidor y por tanto, sin recargar la

página entera.

39

Podemos encontrar las especificaciones del estándar por W3C en http://www.w3.org/DOM/

Ilustración 43: Estructura DOM con DOM Inspector en Firefox.

Utilizando el DOM Inspector del navegador Firefox podemos

ver la estructura DOM de nuestro ejemplo.


112

El termino Dynamic en DHTML no incluye un cambio en el HTML de la pagina. Una vez que fue

cargado, su apariencia efectivamente puede ser manipulada, pero sus contenidos siguen siendo

los mismo. Y por tanto, cuando necesitemos cambiar algo de los contenidos HTML, será necesario

realizar un pedido al servidor y recargar la pagina. Para liberarnos de esta restricción, necesitamos

un mecanismo que permita realizar cargas de pedazos de código HTML, sin necesidad de cargar

toda la pagina. Esto es exactamente lo que Ajax ofrece, y analizaremos esta tecnología

posteriormente. Dynamic tampoco se refiere a páginas que son diferentes cada vez que son

visitadas y que son diferentes para cada usuario. Esas páginas son dinámicas en el sentido que

utilizan diferentes fuentes de datos y aplican scripting de servidor para adecuar los contenidos al

usuario particular. Para lograr esto veremos a continuación el scripting en el servidor.

3.8.4. Scripting en el servidor

Básicamente, un cliente realiza una petición de una página web enviando una URL (y quizás algo

de información extra, como ser por ejemplo los datos ingresados en un formulario por el usuario)

(1). Luego el servidor ejecuta un script de servidor (como ser en el lenguaje PHP40 utilizando un

intérprete de PHP.) (2). Este script puede interactuar con una base de datos u otra fuente de

datos externa como ser un archivo XML (en donde los datos del posible formulario pueden ser

guardados, o donde se puede obtener datos adicionales) (2 y 4). Luego el intérprete de PHP

genera código HTML (5) y este es enviado al cliente (6).

40

Podemos encontrar más información sobre PHP en http://www.php.net/

<html>

<head>

<title>

Catalogo de DVD

</title>

</head>

<body>

<h1>

Catalogo de DVD

</h1>

<html>

<head>

<title>

<?php echo $pageTitle;?>

</title>

</head>

<body>

<h1>

<?php echo $pageHeader;?>

</h1>

Fuente

de datos

externa

URL +

datos de formulario

Procesador

de PHP

1

2

3

4

5

6

CLIENTE

SERVIDOR

SERVIDOR WEB

Script PHP

Salida del

servidor web

Ilustración 44: Scripting de servidor con PHP.


113

3.8.4.2. PHP con fuente de datos.

Volviendo a la imagen anterior, podemos ver una porción de código PHP. Si no fuera por las líneas

entre <? ?>, el código se comportaría como HTML ordinario, pero estas contienen código PHP

embebido. El resto de las líneas son HTML común. Una vez procesado por el interprete y

ejecutados los scripts, se obtendrá como salida un archivo con contenido HTML pero con

extensión .php.

En realidad, incluso un archivo enteramente HTML guardado como .php funciona como un

archivo PHP valido., ya que el interprete solo busca el código PHP entre los limites mencionados

anteriormente, dejando el código HTML intacto.

Analizando ahora brevemente los segmentos de código PHP, podemos encontrar que la primera

línea es echo $pageTitle, siendo echo una función que simplemente imprime los parámetros que

lo siguen, como ser en este caso una variable. La segunda línea es similar solo que contiene otra

variable $pageHeader. Vale aclarar que el código de la imagen no muestra como estas variables

obtuvieron sus valores, pero podemos asumir que fueron tomados de una fuente de datos

externos, como ser una base de datos, por tanto la salida del intérprete luego de aplicar la función

echo muestra sus valores, siendo por ejemplo “Catalogo de DVD” el valor de la variable

$pageTitle. Y es interesante notar que ante la vista del cliente será imposible detectar que partes

del código estaban presentes anteriormente en HTML y cuales son contenidos HTML generados

sin llegar a ver nunca el código PHP, lo que hace un fuerte contraste con el caso del scripting de

cliente, donde el script si queda publicado.

Podemos ver a continuación el ejemplo de nuestro catalogo de DVD utilizando PHP y nuestro

primer ejemplo de archivo XML como fuente de datos:

<?

$dom = new DomDocument();

$dom->load("catalogo.xml");

$xp = new domxpath($dom);

$title = $xp->query("/DVDCatalog/Title");

printDocumentHead($title->item(0)->nodeValue);

$dvds = $xp->query("/DVDCatalog/DVD");

foreach ($dvds as $node) {

$asin = getSubNodeContent($node, 'ASIN');

$imdbLink = getSubNodeContent($node, 'IMDBLink');

$title = getSubNodeContent($node, 'Title');

$year = getSubNodeContent($node, 'Year');

$director = getFullNamesOfPersons(

$node->getElementsByTagName('Director')->item(0));

$actors = getFullNamesOfPersons(

$node->getElementsByTagName('Actors')->item(0));

printDVD($asin, $imdbLink, $title, $year, $director, $actors);

}

printDocumentFoot();

function printDocumentHead($titleText) {

?>



<html>

<head>


114

<title><?echo $titleText?></title>




function toggleDVDDisplay(id) {


if (contentElement.getAttribute('expanded')=='false') {



} else {

contentElement.style.display = 'none';

contentElement.setAttribute('expanded', 'false');

}

}

</script>

</head>

<body>


<h1><?echo $titleText?></h1>

<?

}

function printDocumentFoot() {

?>

</body>

</html>

<?

}

function printDVD($asin, $imdbLink, $title, $year, $director,$actors){

echo '<div class="DVD">';

echo '<div class="DVDHead" onClick="toggleDVDDisplay(\''.

$asin.'\')">';

echo '<h2><a href="'.$imdbLink.'">'.$title.'</a></h2> ';

echo '('.$year.')';

echo '</div>';

echo '<div class="DVDContent" id="'.$asin.'">';

echo 'Director: '.$director.'<br>';

echo 'Actores: '.$actors;

echo '</div>';

echo '</div>';

}

function getFullNamesOfPersons($personList) {

$persons = $personList->getElementsByTagName('Person');

$i = 0;

foreach ($persons as $person) {

$fullNames[$i] .= getSubNodeContent($person, 'Firstname').' '.

getSubNodeContent($person, 'Lastname');

$i++;

}

return implode(", ", $fullNames);

}

function getSubNodeContent($node, $subNodeName) {

return $node->getElementsByTagName($subNodeName)->item(0)->nodeValue;

}

?>

Claramente este ejemplo es más largo y complejo que otros analizados anteriormente por lo que

nos detendremos un poco en varias de sus partes, aunque es importante recordar que esta parte


115

del marco teórico no pretende ser un manual de PHP, sino que tan solo pretende esbozar la

funcionalidad de los scripts de servidor.

El último bloque del ejemplo define una función, y podemos notar que la forma de realizar la

definición es muy similar a la utilizada en javascript. La función getSubNodeContent toma los

parámetros $node y $subNodeName y tomaran un nodo del documento XML y el nombre del

nodo vinculado respectivamente. Al igual que en Javascript, en PHP no hay tipos de variables

acompañando las variables, ya que esto es opcional en PHP al ser un lenguaje de programación

dinámicamente escrito. La función contiene una sola línea de código con el comando return,

indicando que el resultado del código de la línea es el valor devuelto por la función. Por tanto,

cuando la función es llamada, el valor de retorno se calculara y se devolver a al lugar donde la

función haya sido llamada. El resto de las líneas contienen el acceso a un objeto que se espera

este en $node. El símbolo -> indica por un lado que $node es un objeto, y por otra parte que su

función getElementByTagName debe ser llamada, obteniendo como parámetro el nombre del

nodo vinculado. Esta función devolverá este nodo, que a su vez es un objeto, sobre el cual se usa

nuevamente el símbolo –> para extraer los ítems de un arreglo que a su vez son objetos, de los

cuales se obtiene el valor $nodeValue que contiene el valor del nodo.

Al igual que en el ejemplo de Javacript donde accedimos al DOM del HTML, estamos utilizando

ahora PHP y su modelo DOM para acceder a los contenidos del archivo XML.

Analizamos otra función, como ser el caso de getFullNamesOfPersona($personList). Esta toma un

nodo de XML que contiene personas y devuelve sus nombres y apellidos separados por comas.

Podemos recordar que el archivo DTD definido para este archivo XML definía esta estructura

permitiendo que Firstname y Lastname se encontraran en orden indistinto. A su vez el nodo

persons se encuentra como nodo vinculado a nodos Director donde exactamente una persona

debe estar y el nodo Actors. El árbol transversal que esta función necesita es por tanto un poco

más complejo que la que se presenta en el caso de getSubNodeContent. Primero,

getElementByTagName(‘Person’) guarda todas las personas en $persons(como probablemente

más de un elemento será devuelto, $persons es un arreglo). Las siguientes líneas hacen un ciclo

de código recorriendo el arreglo para construir un segundo arreglo, que contiene los nombres de

las personas en primer lugar y luego los apellidos. Podemos notar que ninguna variable fue

definida previamente, y si bien esta práctica no es recomendable, PHP lo permite ya que crea las

variables con el tipo de variable que considera necesaria a medida que se van llamando. La última

línea devuelve el arreglo en forma de cadena de texto utilizando la función implode, uniendo los

elementos del arreglo con una coma.

Podemos notar que estas dos funciones discutidas hasta el momento no generan nada de código

HTML, sino que solo devuelven valores y objetos. Las otras tres funciones que restan son las

encargadas en este caso de generar el código HTML, y notamos que tanto

printDocumentHead($titleText) y printDocumentFoot() son simples de comprender, siendo que

imprimen en HTML las partes superiores e inferiores de la pagina.

La última función por analizar es printDVD, que toma 5 parámetros conteniendo la información de

un DVD. Todas las líneas comienzan con el comando echo, lo que generara la impresión de lo que

contienen, y podemos observar los parámetros directamente incluidos en las variables.


116

Para hacer que todo funcione, debe existir algún tipo de programa principal que haga uso de estas

funciones para generar así el archivo, y eso es lo que hemos definido en las primeras líneas del

código fuente Las cuatro primeras crean e inicializan tres variables que permiten acceder al

archivo XML y procesarlo, para asi poder utilizarlo como una fuente externa de datos. La variable

$dom es inicializada como el DOM del documento mediante $dom = new DomDocument() u el

archivo XML es cargado en el documento mediante $dom->load(“catalogo.xml”). La siguiente

línea crea un objeto $xp de tipo DOMXPath que puede ser usado para realizar consultas al DOM

con una expresión de consulta del lenguaje XPath como es mostrado en los consiguientes

bloques. El siguiente comienza con la expresión de Xpath /DVDCatalos/DVD que selecciona todos

los elementos DVD vinculados con el elemento DVDCatalog, quedando ahora guardado en $dvds

un arreglo de nodos de DVD.

El resto del programa principal se encarga de la generación del código HTML, y una vez que la

cabecera es generada pro printDocumentHead (que contiene todos los datos e cabecera

incluyendo los códigos Javascript vistos antes), un ciclo foreach recorre el arreglo de DVDs y

ejecuta el código en cada ciclo para cada DVD contenido en $dvds. Ahora la función

$getSubNodeContent y la función $gerFullNamesOfPersons son usadas para preparar las variables

para la salida del código de un DVD. Por ejemplo, la variable $asin es llenada con el contenido del

elemento ASIN. Al finalizar cada ciclo, se llama a la función printDVD generando el código para

cada uno. Finalmente una vez generados todos los DVDs del archivo XML, se imprime el pie de

página cerrando el código HTML.

Cuando se corre el script (o más bien, cuando su URL se ingresa a un navegador) los comandos

PHP se ejecutaran como se ha explicado, y el resultado será entregado al cliente. Y notaremos que

le resultado tiene el mismo aspecto que el devuelto en el caso del ejemplo de scripts de cliente, y

efectivamente para el cliente es el mismo, ya que el código HTML será en este caso idéntico, solo

que creado de forma dinámica por el servidor.

Ilustración 45: Ejemplo de uso de PHP, HTML y JavaScript.

Si observamos el código fuente del resultado del archivo PHP notaremos que solo contiene código HTML y Javascript, y

por tanto es prácticamente el mismo resultado que vimos anteriormente en el caso de scripting de cliente.


117

Hemos visto como CSS nos da un mecanismo para dar formato y estilos a HTML y a XML, de tal

forma que el primero puede ser formulado sin aspectos de presentación y el último puede ser

presentado de forma apropiada. Luego las tecnologías de scripting nos dieron dos formas de

comportamiento dinámico: el scripting de cliente nos brinda Dynamic HTML permitiendo cambios

en la presentación sin la necesidad de cambios en el HTML (y por tanto si necesidad de hacer

peticiones al servidor que generarían la recarga de la pagina) y el scripting de servidor que

permite la creación dinámica de HTML y conexiones a fuentes de datos para entregar código

HTML en base a las necesidades del cliente. Posteriormente analizaremos la tecnología Ajax, que

en cierta forma combina estas dos ideas de scripting, para poder tomar el paso siguiente a

presentaciones dinámicas y contenidos dinámicos.

3.8.5. Aplicaciones Web de XML

A continuación analizaremos dos aplicaciones importantes de XML en más detalle. Primero,

discutimos sobre Web services, que son comúnmente basados en estándares que hacen un fuerte

uso de XML para descripción, publicación ejecución y otros propósitos correspondientes a

servicios. Luego analizaremos RSS y ATOM, que son dos formatos basados en XML para la

sindicación de contenidos y la subscripción a contenidos. Ambos ejemplo utilizan una gran

variedad de características de XML y representan aplicaciones que son ampliamente utilizadas

para dar base a los recursos Web 2.0. Por tanto, sirven como buenas ilustraciones de lo que es

posible hacer con XML, y da idea de otras posibles explotaciones.

3.8.5.2. Web Services

Los Web services extienden el paradigma cliente-servidor con la noción de un registro explicito,

resolviendo el problema de localizar un servicio de una forma apropiada para Internet.

Un servicio (cliente) cuando busca un

servicio envía una petición a un

registro de servicios. Si el servicio

buscado es encontrado, el cliente

puede contactar al proveedor del

servicio y utilizar dicho servicio. La

situación y el procedimiento son

similares al caso de buscar un servicio

en la vida real al consultar una guía

(como ser, las Páginas Amarillas) para

ver las alternativas disponibles, elegir

uno y contactarse. El proveedor ha

publicado previamente su servicio (o servicios) en el registro. Por lo tanto, los Web services

ocultan todos los detalles de su implementación y las plataformas en los cuales están basados, y

simplemente muestran una URI (Uniform Resource Identifier) que apunta a su proveedor. Como

en general se supone que los Web services son interoperables, estos pueden ser combinados con

otros servicios para crear nuevas aplicaciones con más funcionalidades.

Ilustración 46: El Paradigma de los Web services.


118

Publicar, encontrar y vincular Web services

son actividades realizadas por solicitantes de

servicios y proveedores que usan estándares

específicos. En la capa más baja utilizan

transporte ordinario de redes, luego

encontramos el protocolo HTTP para datos de

Internet. Sobre esto se encuentra el estándar

SOAP41 basado en mensajes, luego WSDL 42

(Web Services Description languagues) es

utilizado para la descripción de los servicios y

finalmente encontramos al UDDI43 (Universal

Description, Discovery and Integration) para la

publicación y descubrimiento.44

En ocasiones es necesario agregar

más capas a la estructura, y para esto

se construyen encima de UDDI en

base a lenguajes como ser WSFL y

BPEL que especifican procesos donde

los pasos en dichos procesos son

completados por Web services.

Finalmente, varios servicios en acción

necesitan algún tipo de

coordinación o garantías

transaccionales, lo que es

posible a través de estándares

como WS-Coordintation y WS-

Transaction.

Mencionamos antes que la

orientación a servicios es en

efecto un paradigma

fundamental en base a la idea

de que una funcionalidad

compleja puede ser separada

en una colección de servicios

41

w3.org/TR/soap/

42 w3.org/TR/wsdl

43 www.uddi.org/

44Vale notar que si bien UDDI es una especificación en sí mismo, es en realidad la especificación de un Web

service descripto utilizando WSDL.

Interacción del servicio:

WS-Choreography, WS-Coordination, WS-Transaction

Composición del servicio: WSFL, BPEL

Publicación y descubrimiento del servicio: UDDI

Descripción del servicio: WSDL

Mensajes basados en XML: SOAP

Red: HTML

Servicio

Funcionalidad Propiedades

Servicio


Servicio


Servicios de

nivel más alto

Servicios de nivel más bajo

Mensajes SOAP

Registro UDDI

Mensajes SOAP

(Para publicar la

descripción de

servicios)

Mensajes SOAP

(Para buscar servicios)

Solicitante del servicio

Objeto Aplicación

(Cliente)

Stub

Middleware

basado en SOAP

Proveedor del servicio

Objeto Aplicación

(Proveedor del servicio)

Esqueleto

Middleware

basado en SOAP

Descripciones de servicios

Middleware basado en SOAP

Ilustración 47: Las capas de los estándares de Web services.

Ilustración 48: Vista de la orientación a servicios.

Ilustración 49: La Infraestructura de Web services.


119

más elementales. Esto ha ganado más interés a medida que las arquitecturas de Software

Orientado a Servicios (Service-Oriented Software o SOAs) han ganado popularidad siendo la base

para sistemas de larga escala.

Los Web services están alineados con la vista de estructura de capas descrita, algo que puede ser

encontrado en otros escenarios relacionados la computación (como ser hardware, redes,

aplicaciones). El agregado que tienen los Web services es que no están vinculados a un repositorio

central, e incluso podemos decir que los proveedores y consumidores de servicios están

débilmente acoplados, ya que cada Web service es esencialmente un componente de software

individual, teniendo una URI única que puede ser localizada desde cualquier lugar de Internet.

Además, WSDL permite la creación automática de “stubs” y respectivamente esqueletos.

Como mencionamos los Web

services están basados en

estándares y utilizan el

esquema de repositorio.

Muchos otros tipos de servicios

que se encuentran en Internet

no tienen estas características,

pero representan formas

modernas de las llamadas a

procedimientos remotos, pero

lo que los diferencia de los

Web services es el hecho de

que pueden ser llamados

desde cualquier lugar de Internet, por lo que nos referiremos a los Web services como WPCs

(Web Procedure Calls) de ahora en más. Entre estos es posible distinguir si usan una forma

estandarizada y formal para describir sus interfaces (como ser WSDL) e incluso algunos pueden o

no usar SOAP como su formato de mensajes. Esta diferenciación puede ser apreciada en la

imagen.

Si las interfaces son formalmente descriptas, stubs y esqueletos pueden ser creados de forma

automática.

Podemos tomar un ejemplo para acercarnos más al concepto. Cuando analizamos el patrón de

diseño Web 2.0 “Modelos ligeros y escalabilidad costo-efectiva” mencionamos el caso de Amazon

S3. Este servicio45 procesa datos enviados a través de diversos protocolos, incluyendo SOAP.

Existen también formas no basadas en estándares para descubrir S3, por lo que podemos

clasificar este servicio como una API que también da soporte a WPCs.

En muchos casos las WPCs van más allá de la idea de los Web services: Google ofrecía una API

para realizar búsquedas a través de su motor vía WSDL y SOAP, pero ha discontinuado esto en

45

La especificación del servicio de Amazon S3 (un documento WSDL) puede ser encontrada en

s3.amazonaws.com/doc/2006-03-01/AmazonS3.wsdl

Mensajes SOAP

Solicitante del servicio

Objeto Aplicación

(Cliente)

Stub

Middleware

basado en SOAP

Proveedor del servicio

Objeto Aplicación

(Proveedor del servicio)

Esqueleto

Middleware

basado en SOAP

Compilador WSDL

(Cliente)

Compilador WSDL

(Servidor)

WSDL del proveedor de servicio

Ilustración 50: La Infraestructura de WPC.


120

diciembre del 2006 para ahora ofrecer una API de búsqueda con Ajax46. Entonces por más que nos

referimos a esto como un Web Service, es en realidad una API para WPCs en nuestro punto de

vista.

3.8.5.3. Un acercamiento a SOAP y WSDL

Para mostrar la relación entre Web services y XML, vamos a ver un ejemplo de SOAP y WSDL. Al

igual que en otros ejemplos, el objetivo no es observar los detalles de estas especificaciones, sino

mostrar y explicar ejemplos para acercarnos al concepto.

Continuamos con el ejemplo del catalogo de DVD, pero esta vez no extendemos el ejemplo, sino

que preparamos futuros pasos a tomar al observar un ejemplo de un servicio existente, como ser

que se utiliza para acceder a la información de Amazon E-Commerce (ECS). Dicha información

puede ser utilizada en nuestro ejemplo para aumentar la información de nuestra fuente local de

datos e incluirla en el catalogo posteriormente. Esta API puede ser llamada de forma gratuita y es

muy popular (en efecto, el sitio ProgrammableWeb indica que la API es utilizada para más de 260

mashups (104))

En base a las consideraciones previas, consideramos que la esta Api da soporte a WPCs

únicamente y no a la visión completa de los Web services, pero si utiliza SOAP y WSDL. Es

importante destacar que también se puede acceder al servicio a través de su interfaz en base a

REST, pero no haremos hincapié en esto ya que hablaremos de este paradigma más adelante.

3.8.5.4. WSDL

En la URL http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl

encontramos la descripción WSDL de ECS. Por supuesto este archivo de formato XML es

considerablemente largo, por lo que analizaremos solo una pequeña porción: existen 18

operaciones especificadas en este WSDL, pero nosotros solo analizaremos una de estas.

Utilizaremos solo la operación llamada ItemLookup que devuelve ítems en base a un ID.

A continuación el código relevante a la operación que nos interesa. Vale aclarar que tampoco

incluimos el contenido del elemento <types> ya que la definición de tipos es muy prolongada y no

es necesaria para el objetivo de nuestro análisis.


<definitions

xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:tns="http://webservices.amazon.com/AWSECommerceService/2006-11-14"

targetNamespace="http://webservices.amazon.com/AWSECommerceService/2006-11-14">

<types>

<xs:schema

targetNamespace="http://webservices.amazon.com/AWSECommerceService/2006-11-

14"

46

Podemos encontrar información sobre la API discontinuada en code.google.com/apis/soapsearch/ e

información sobre la nueva API basada en Ajax en code.google.com/apis/ajaxsearch.

http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl


121



elementFormDefault="qualified"/>

<!—DEFINICIONES DE TIPOS OMITIDAS -->

</types>

<message name="ItemLookupRequestMsg">

<part name="body" element="tns:ItemLookup"/>

</message>

<message name="ItemLookupResponseMsg">

<part name="body" element="tns:ItemLookupResponse"/>

</message>

<portType name="AWSECommerceServicePortType">

<operation name="ItemLookup">

<input message="tns:ItemLookupRequestMsg"/>

<output message="tns:ItemLookupResponseMsg"/>

</operation>

</portType>

<binding

name="AWSECommerceServiceBinding"

type="tns:AWSECommerceServicePortType">

<soap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="ItemLookup">

<soap:operation soapAction="http://soap.amazon.com"/>

<input>

<soap:body use="literal"/>

</input>

<output>

<soap:body use="literal"/>

</output>

</operation>

</binding>

<service name="AWSECommerceService">

<port

name="AWSECommerceServicePort"

binding="tns:AWSECommerceServiceBinding">

<soap:address

location="http://soap.amazon.com/onca/soap?Service=AWSECommerceService"

/>

</port>

</service>

</definitions>

Podemos notar que es básicamente un archivo XML con muchos elementos anidados en el primer

nivel dentro de definitions. El anidamiento puede ocurrir entre definiciones de tipos, pero estos

han sido omitidos. Antes de ver los elementos anidados, analizaremos los atributos del elemento

definitions.

3.8.5.5. Namespaces

El atributo xmlns define el nombre de dominio o “namespace” de XML, que representa el

mecanismo XML que asegura que ocurran conflictos de interpretación o de significado entre

ítems con el mismo nombre. El valor del namespace es una URI que puede (pero no

necesariamente debe) contener un link valido (en nuestro ejemplo si es un link valido). El


122

vocabulario de un namespace puede ser definido utilizando un XML Schema o un archivo DTD,

pero no es requerido.

El namespace definido por el atributo xmlns es utilizado cuando un elemento en el documento no

define explícitamente su namespace. En este caso ninguno de los elementos vinculados en

definitions hace esta definición, por lo que todos pertenecen al namespace

http://schemas.xmlsoap.org/wsdl/.

El atributo targetNamespace denota cual namespace define esta documento. El valor de este

identificador nos indica que este es en efecto el ECS de Amaxon.com. Como veremos a

continuación, los mensajes SOAP enviados al servicio definido este documento WSDL deben

referenciar a este namespace.

3.8.5.6. Estructura de un WSDL

Anidados en definitions tenemos a los elementos types, message, portType, binding y service, que

se referencian entre ellos a través de atributos contenidos en los sub elementos que podemos ver

en la imagen.

Un service agrupa bindings, y a través de estos operations. Service y binding son frecuentemente

llamados el pegamento de un documento WSDL porque definen la locación y el protocolo vincular

del servicio. Aquí, service nos indica que su interfaz SOAP puede ser encontrada en la URL

http://soap.amazon.com/onca/soap?Service=AWSECommerceService, mientras que binding nos

indica que el servicio utiliza HTTP para

transporte al referenciar el namespace de

HTML (por ejemplo,

http://schemas.xmlsoap.org/soap/http).

Binding referencia a portType, que puede

ser considerado como un método de

interfaz. Aquí podemos ver que la

operación ItemLookup tiene

ItemLookupRequestMsg como su

mensaje de input y

ItemLookupResponseMsg como su

output. Encontramos también un tercer

tipo de mensaje llamado fault que

especifica el mensaje en caso de un error.

Los elementos de mensaje que son

referenciados por portType especifican

cual tipo de message utilizan. Para input y

output vemos tipos tns:ItemLookup y

tns:ItemLookupResponse, y ambos son

parte del vocabulario definido en

targetnamespace, y así ambos son tipos

que pueden ser encontrados en el elemento

Calificación de namespace

implícita

Referencia

Ilustración 51: Relaciones en un archivo WSDL.

http://schemas.xmlsoap.org/wsdl/

http://soap.amazon.com/onca/soap?Service=AWSECommerceService

http://schemas.xmlsoap.org/soap/http


123

types, el primer subelemento de definitions.

El elemento types define tipos utilizando XML Schema. Esto puede ser observado en el

namespace de xs:schamea, el único elemento en types que hemos mantenido del documento

original. Esto indica que es válido como archivo XML Schema al estar anidado en este documento

WSDL, especificando los tipos especiales necesitados para la operación ItemLookup y para otras

operaciones del documento. Podemos notar que el XML Schema podría también ser referenciado

en los elementos types. Obtendremos un pantallazo de lo que el schema especifica para la

operación ItemLookup cuando veamos los mensajes SOAP que pueden ser enviados.

Como podemos observar de esta explicación, WSDL es un lenguaje complejo que tiene el

potencial de describir interfaces a servicios y sus invocaciones. Es común que los Web services

provean acceso a su funcionalidad preexistente, por lo que es usualmente posible generar

automáticamente la mayor parte de un archivo WSDL que puede entonces necesitar solo algunas

configuraciones adicionales para funcionar. A través de esto, un usuario de un WSDL puede

utilizarlo para generar un stub del servicio consumidor que este escribiendo.

3.8.5.7. SOAP

Analicemos un mensaje SOAP que puede ser enviado a ECS, apuntado a la operación ItemLookup.

Como fue especificado en el archivo WSDL el mensaje será enviado sobre HTTP y al puerto SOAP

mencionado en dicho archivo.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"



xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>

<tns:ItemLookup

xmlns:tns="http://webservices.amazon.com/AWSECommerceService/2006-11-14">

<tns:MarketplaceDomain/>

<tns:AWSAccessKeyId>MY_ACCESSKEY</tns:AWSAccessKeyId>

<tns:Request>

<tns:IdType>ASIN</tns:IdType>

<tns:ItemId>B0000CABBW</tns:ItemId>

<tns:ResponseGroup>Small</tns:ResponseGroup>

</tns:Request>

</tns:ItemLookup>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Esto muestra un fuerte uso de namespaces, referenciando a namespaces específicos de SOAP

para el mensaje en sí, namespaces de XML Schema (que en este caso no es utilizado) y el

namespace de ECS definido en el documento WSDL.


124

Los namespaces de SOAP definen la estructura del mensaje SOAP, que

básicamente es un sobre que contiene una cabecera (opcional) y un

cuerpo. Ambos elementos pueden contener múltiples bloques, llamados

bloques header y body respectivamente. El cuerpo contiene la carga útil

del mensaje, y la cabecera información que puede ser procesada por

intermediarios. Estos pueden necesitar esta información para realizar

acciones propias, como por ejemplo realizar el seguimiento de una

conversación. Como en 6M, por no incluir una cabecera.

El cuerpo de nuestro ejemplo contiene tan solo un elemento

(ItemLookup) en base al documento WSDL de ECS. Los elementos

contenidos en este lo convierten en un elemento ItemLookup valido, que puede ser validado en

base a los schemas para el vocabulario utilizado. La información que enviamos contiene el

elemento vacio MarketplaceDomain y AWSAccessKeyId, la clave de identificación del autor del

mensaje sin la cual nuestra petición no sería procesada. Además contiene nuestra petición actual,

en la cual buscamos conocer el contenido correspondiente al identificador ASIN (en este caso

como ItemType, que como comentamos antes, el es identificador único asignado por Amazon a

sus productos, entre ellos DVDs) con el valor B000CABBW (ItemID). ResponseGroup solicita solo la

versión corta de los resultados.

Para completar el ejemplo, colocamos a continuación la respuesta generada por ECS. En este caso

tampoco se utiliza cabecera y el cuerpo contiene el elemento ItemLookupResponde.


<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>

<ItemLookupResponse

xmlns="http://webservices.amazon.com/AWSECommerceService/2006-11-14">

<OperationRequest>

<HTTPHeaders>

<Header Name="UserAgent" Value="SQLData Client/3.02"/>

</HTTPHeaders>

<RequestId>MY_ACCESSKEY</RequestId>

<Arguments>

<Argument Name="Service" Value="AWSECommerceService"/>

</Arguments>

<RequestProcessingTime>0.0265100002288818</RequestProcessingTime>

</OperationRequest>

<Items>

<Request>

<IsValid>True</IsValid>

<ItemLookupRequest>

<IdType>ASIN</IdType>

<ItemId>B0000CABBW</ItemId>

<ResponseGroup>Small</ResponseGroup>

</ItemLookupRequest>

</Request>

Sobre SOAP

Cabecera SOAP

Cuerpo SOAP

Block de

cabecera

Block de cuerpo

Ilustración 52: Estructura de un mensaje SOAP.

125

<Item>

<ASIN>B0000CABBW</ASIN>

<DetailPageURL>

http://www.amazon.com/gp/redirect.html%3FASIN=B0000CABBW%26tag=ws%2

6lcode=sp1%26cID=2025%26ccmID=165953%26location=/o/ASIN/B0000CABBW%2

53FSubscriptionId=1RPF28QJYKDDFEDRT902</DetailPageURL>

<ItemAttributes>

<Actor>Keisha Castle-Hughes</Actor>

<Actor>Rawiri Paratene</Actor>

<Actor>Vicky Haughton</Actor>



<Director>Niki Caro/Director>

<Manufacturer>Sony Pictures</Manufacturer>

<ProductGroup>DVD</ProductGroup>

<Title>Whale Rider</Title>

</ItemAttributes>

</Item>

</Items>

</ItemLookupResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Luego de cierta información operacional (como ser cuanto tiempo demoro ECS en generar la

respuesta) el mensaje contiene la respuesta que esperábamos. El elemento ítem contiene la URL

de la pagina donde se encuentra la información del producto, los actores (de los cuales hemos

omitido muchos), el director, el fabricante, el grupo de productos, y finalmente el titulo.

3.8.6. Formatos de Web feeds

Una segunda aplicación del XML que mencionamos marco un cambio en la forma en que se

accede a la información en Internet: la sindicación de contenidos, que fue analizada en forma

breve y funcional anteriormente.

Básicamente, los productores de contenidos pueden sindicar estos a través de “Web feeds” 47, a

los cuales los usuarios pueden subscribirse para recibir las actualizaciones. Podemos destacar que

los Web feeds son de gran valor tanto para el creador de contenidos como para el consumidor de

contenidos. Desde el punto de vista del subscriptor, los Web feeds simplifican el proceso de

recibir actualizaciones de una o múltiples fuentes. Y desde el punto de vista del proveedor, los

Web feeds mejoran su propia presentación en Internet ya que permite que los consumidores

utilicen fácilmente sus contenidos a través de distintos canales.

Los principales formatos en el cual estos feeds se especifican son los estándares RSS (2.0 y 1.0) y

Atom ambos basados en XML. Si bien tienen especificaciones distintas, comparten

aproximadamente la misma estructura. Los elementos XML que ellos comprenden pueden ser

divididos en dos categorías. La primera agrupa los elementos del canal (o feed) que incluye la

información genera de un feed. Los contenedores están compuestos por algunos ítems, conocidos

como entradas y cada una tiene adjunto un conjunto de metadatos extensibles, con los que sus

subelementos forman una segunda categoría de elementos.

47

Como en otros casos nuestro análisis tendrá el objetivo de acercarnos al concepto.


126

RSS 2.0 RSS 1.0 ATOM

Contenedor de feed channel channel Feed

Titulo de feed Title title Title

URL de feed link link Link

Descripción de feed description description (subtitle)

Autor webMaster/managingEditor Dc:creator Author

Ultima actualización lastBuildDate Dc:date Updated

Identificador único - - Id

Entradas de feed item item Entry

Lista de contenidos - items - Tabla 7: Nombres y descripciones de elementos contenedores en formatos de feeds.

RSS 2.0 RSS 1.0 ATOM

Titulo de entrada title title title

URL de entrada (link) link link

Identificador único guid - id

Descripción de entrada description (description) (summary)

Fecha de publicación pubDate dc:date updated Tabla 8: Nombres y descripciones de elementos de entradas en formatos de feeds.

Podemos ver una descripción general de aquellos elementos XML que son necesarios en las

diferentes versiones. Los elementos en paréntesis son opcionales, aunque existen otros

elementos que no han sido incluidos en las tablas ya que son opcionales en todos los formatos

analizados. En la primera fila de la primera tabla tenemos el elemento “Contenedor de feed”

indica el nombre del elemento que tiene el contenido del feed, y es interesante notar que los otros

elementos de esta tabla son todos subelementos de este.

Otra cosa destacable es ver como elementos que no están en la especificación de RSS 1.0 son

tratados por esta: “author” y “time of last update” no son considerados por el estándar, y es por

esto que son substituidos con elementos del Dublin Core Element Set48 denotados por el prefijo

“dc:”. Además, el elemento “Lista de contenidos” solo es utilizado en RSS 1.0, donde la referencia

XML es utilizada para referenciar elementos item. Esto es porque a diferencia de otros formatos

el elemento item no es un subelemento del elemento channel en RSS 1.0

Utilizamos estas tablas para mostrar que todos los formatos están construidos aproximadamente

de manera similar, pero es insuficiente para la interpretación de lo que exactamente debe

contener cada elemento. Por ejemplo, en el caso del elemento description de las entradas RSS 2.0

no es claro si debe contener un breve resumen o si debe contener todo el artículo. Por tanto,

desde el punto de vista técnico es algo complicado tener que ladear con las diferentes versiones

ya que son incompatibles entre sí.

48

El Dublin Core Element Set es un estándar ISO para metadatos en Internet. Podemos ver más sobre esto

en (140)


127

Para continuar con el ejemplo del

catalogo, creamos un blog donde

colocar opiniones de DVD en

Blogger (mencionado cuando

analizamos este social media) que

entre otras prestaciones permite

utilizar la sindicación de

contenidos. Con esto tendremos la

información necesaria para dar

contenido a los elementos de canal

que hemos mencionado

anteriormente.

Una vez en el blog creamos una

entrada. Al crear esta entrada, se

ha creado automáticamente

también un Web feed (tanto en RSS

2.0 como en Atom) y se ha

insertado un vinculo hacia este en

el blog. En base a estos podemos

analizar cada uno de los casos.

3.8.6.2. ATOM

A continuación incluimos el código generado por Blogger para el feed en Atom del blog en

http://misopinionesdvd.blogspot.com/atom.xml, donde podemos notar específicos del blog

creado (resaltados) y otros que fueron generados por el mismo sistema, notando que existen

muchos otros elementos que han quedado fuera de la discusión previa sobre elementos del

formato. Esto es debido a que por una parte junto a los elementos vienen atributos, y por otra

parte porque Blogger realiza agregados para generar el feed.

<?xml version='1.0' encoding='UTF-8'?>

<?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?>

<feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-

/spec/opensearchrss/1.0/'>

<id>tag:blogger.com,1999:blog-4392197541148508107</id>

<updated>2008-11-20T06:33:08.266-08:00</updated>

<title type='text'>Opiniones sobre DVD</title>

<subtitle type='html'></subtitle>

<link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml'

href='http://misopinionesdvd.blogspot.com/feeds/posts/default'/>

<link rel='self' type='application/atom+xml'

href='http://misopinionesdvd.blogspot.com/feeds/posts/default'/>

<link rel='alternate' type='text/html'

href='http://misopinionesdvd.blogspot.com/'/>

<author>

<name>Juan Ortiz</name>

<uri>http://www.blogger.com/profile/15260917426736429062</uri>

<email>[email protected]</email>

</author>

Ilustración 53: Creación de post en Blogger.

Creamos una entrada de blog, creándose automáticamente un Web feed.

http://misopinionesdvd.blogspot.com/atom.xml


128

<generator version='7.00' uri='http://www.blogger.com'>Blogger</generator>

<openSearch:totalResults>1</openSearch:totalResults>

<openSearch:startIndex>1</openSearch:startIndex>

<openSearch:itemsPerPage>25</openSearch:itemsPerPage>

<entry>

<id>tag:blogger.com,1999:blog-4392197541148508107.post-

4305271701793689325</id>

<published>2008-11-20T06:25:00.000-08:00</published>

<updated>2008-11-20T06:31:01.796-08:00</updated>

<app:edited xmlns:app='http://purl.org/atom/app#'>2008-11-

20T06:31:01.796-08:00</app:edited>

<title type='text'>Le Fabuleux destin d'Amélie Poulain</title>

<content type='html'>Lorem ipsum dolor sit amet, consectetur adipiscing

elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad

minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea

commodi consequat.</content>

<link rel='replies' type='application/atom+xml'

href='http://misopinionesdvd.blogspot.com/feeds/4305271701793689325/comments/defa

ult' title='Enviar comentarios'/>

<link rel='replies' type='text/html'

href='https://www.blogger.com/comment.g?blogID=4392197541148508107&postID=430

5271701793689325' title='0 comentarios'/>

<link rel='edit' type='application/atom+xml'

href='http://www.blogger.com/feeds/4392197541148508107/posts/default/430527170179

3689325?v=2'/>

<link rel='self' type='application/atom+xml'

href='http://misopinionesdvd.blogspot.com/feeds/posts/default/4305271701793689325

'/>

<link rel='alternate' type='text/html'

href='http://misopinionesdvd.blogspot.com/2008/11/le-fabuleux-destin-

damlie-poulain.html' title='Le Fabuleux destin d'Amélie Poulain'/>

<author><name>Juan Ortiz</name>

<uri>http://www.blogger.com/profile/15260917426736429062</uri>

<email>[email protected]</email>

</author>

<thr:total

xmlns:thr='http://purl.org/syndication/thread/1.0'>0</thr:total>

</entry>

</feed>

Analizamos ahora algunos de los elementos adicionales que encontramos. Notamos tres

elementos link en los elementos e nivel de canal (todos con diferentes atributos rel que describen

el significado de cada vinculo).

El link http://schemas.google.com/g/2005#feed es específico de Blogger y los links con relaciones

altérnate y self son especificados en el estándar de Atom. El primero apunta a la versión HTML

del feed y el último apunta a la dirección original del feed, y con esta última información es

posible encontrar la fuente de un feed. Encontramos estas mismas relaciones en la entrada que se

presenta. En ese caso, los links no apuntan a todo el feed, sino que apuntan al post en particular

que se está incluyendo. El elemento generator muestra que el feed fue creado con el servicio de

Blogger.

http://schemas.google.com/g/2005#feed


129

Hay tres elementos (totalResults, startIndex, itemsPerPage) del namespace openSearch.

OpenSearch 49 es una especificación para agregar metadatos a búsquedas y resultados de

búsquedas, y su especificación indica que “Los clientes de búsqueda utilizan los documentos de

descripción OpenSearch para aprender sobre la interface pública de un motor de búsqueda. Estos

documentos de descripción contienen templates de ULR parametrizados que indican como el

cliente de búsqueda debería realizar las peticiones de búsqueda. Los motores de búsqueda pueden

usar los elementos de respuesta de OpenSearch para agregar estos metadatos a los resultados en

una gran variedad de formatos de contenidos.”

Los tres elementos contenidos en nuestro feed pertenecen a la parte de respuesta de la

especificación, por ejemplo elementos que son incluidos en resultados de búsqueda.

Como el elemento content de una entrada es opcional, no lo hemos visto en las tablas

presentadas inicialmente, pero es este el elemento que tiene el contenido de la entrada, en el

caso en que el contenido es texto y no una referencia a un archivo como ser de video o audio

disponible en otro lugar.

3.8.6.3. RSS 2.0

El código incluido en http://misopinionesdvd.blogspot.com/rss.xml es similar al de Atom como

era esperado. Es interesante notar que el feed RSS contiene los elementos id y updated del

estándar Atom, ya que namepsace de Atom ha sido incluido en el elemento rss (ver línea 3). Estos

elementos son utilizados como solución para estos elementos u otros equivalentes que no están

presentes en la especificación RSS, pero que blogger necesita en este caso.

<?xml version='1.0' encoding='UTF-8'?>

<rss xmlns:atom='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-

/spec/opensearchrss/1.0/' version='2.0'>

<channel>

<atom:id>tag:blogger.com,1999:blog-4392197541148508107</atom:id>

<lastBuildDate>Thu, 20 Nov 2008 14:33:08 +0000</lastBuildDate>

<title>Opiniones sobre DVD</title>

<description></description>

<link>http://misopinionesdvd.blogspot.com/</link>

<managingEditor>[email protected] (Juan Ortiz)</managingEditor>

<generator>Blogger</generator>

<openSearch:totalResults>1</openSearch:totalResults>

<openSearch:startIndex>1</openSearch:startIndex>

<openSearch:itemsPerPage>25</openSearch:itemsPerPage>

<item>

<guid isPermaLink='false'>tag:blogger.com,1999:blog-

4392197541148508107.post-4305271701793689325</guid>

<pubDate>Thu, 20 Nov 2008 14:25:00 +0000</pubDate>

<atom:updated>2008-11-20T06:31:01.796-08:00</atom:updated>

<title>Le Fabuleux destin d'Amélie Poulain</title>

<description>Lorem ipsum dolor sit amet, consectetur adipiscing elit,

sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim

veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi

consequat.</description>

49

Podemos encontrar más información sobre el estándar OpenSearch en (141).

http://misopinionesdvd.blogspot.com/rss.xml


130

<link>http://misopinionesdvd.blogspot.com/2008/11/le-fabuleux-destin-

damlie-poulain.html</link>

<author>[email protected] (Juan Ortiz)</author>

<thr:total

xmlns:thr='http://purl.org/syndication/thread/1.0'>0</thr:total>

</item>

</channel>

</rss>

3.8.6.4. Publicando feeds

Como hemos visto es muy sencillo generar un

blog que también produce de manera automática

web feeds. Y desde el punto de vista de un

generador de contenidos, es también muy fácil

integrar Web feeds a programas en muchos

contextos para poder recibir los beneficios

mencionados de la sindicación de contenidos y

para esto es necesario que los usuarios puedan

acceder a los feeds.

En los archivos mostrados notamos referencias a

un archivo CSS. Esto combinado con las

versiones actuales de los navegadores populares

permite que al ser abierto en un navegador se dé

una interface para que el usuario pueda agregar

el feed en su agregador de preferencia.

Para que esto suceda se debe poner a disposición del usuario el archivo XML. Una forma es

publicar un link como los mencionados anteriormente de forma directa, y otra es la habilitación

del auto-descubrimiento colocando un tag en la cabecera del código HTML referenciando al

archivo, como el siguiente:

<link rel="alternate" type="application/rss+xml” title="RSS 2.0" href="rss.xml"

/>

En este caso el tag está basado en XHML, conteniendo al menos tres atributos rel, type, y href que

hemos visto en los elementos link de los Web feeds mostrados anteriormente. Efectivamente, la

función del elemento es la inversa a la del elemento link con la relación altérnate en el feed. Los

programas que dan soporte al auto-descubrimiento notifican al usuario cuando ingresan a una

página que existe un feed disponible.

3.8.7. Aplicaciones de Internet enriquecidas.

Continuando con el análisis realizado el considerar HTML, XML, CSS y scripting de servidor y

cliente, la tendencia actual es generar contenidos e interfaces cada vez más dinámicas para el

usuario. Esto fue analizado en el patrón de diseño Web 2.0 “Experiencias de usuario ricas” donde

realizamos una aproximación a las tendencias actuales hacia la generación de experiencias

rápidas y simples combinando lo mejor de los paradigmas web y de escritorio. Como se comento

al terminar el análisis de scripting, el siguiente paso es el estudio de las técnicas basadas en Ajax.

Ilustración 54: Web Feeds en Firefox.

Al abrir el archivo XML en el navegador Firefox el usuario

obtiene una interfaz que le permite agregar el feed.


131

El uso de Ajax y la disponibilidad generalizada de acceso a Internet analizada previamente

permite la creación de sitios que puede hacer mucho más que presentar páginas y conectarlas vía

hipervínculos. Ahora es posible ejecutar programas completos en un navegador, como ser clientes

de mail, programas de chat o incluso herramientas tan potentes como el Google Docs ya

mencionado. A su vez, los usuarios no tienen que preocuparse por instalaciones o actualizaciones

ya que el concepto es utilizar a Internet como una plataforma completa.

Para evitar que una página se recargue al requerir información del servidor y de esta forma

acercarnos mas al la rapidez y sensación que genera una aplicación de escritorio, la vista de una

página debe ser generada y manipulada en el navegador del cliente, utilizando la conexión

cliente-servidor solo para intercambio de datos. Esto apunta a generar interfaces con respuestas

más rápidas, y por lo tanto es necesario depender de la velocidad de conexión a Internet y sobre

todo optimizar el uso de esta ya que en general impone fuertes limitaciones. Existen diversas

aproximaciones técnicas para esto, como ser Java Applers, Flash de Adobe, y el mencionado Ajax.

En aplicaciones con este tipo de aproximaciones el servidor es el responsable de manejar los

datos y la generación del entrono grafico, mientras que el cliente muestra dicho entorno y maneja

las acciones de los usuarios.

Las aplicaciones enriquecidas han existido por muchos años, y en efecto cada programa de

escritorio da soporte a un amplio set de funcionalidades que están dirigidas a mejorar la

interactividad en base a patrones, como ser menús, ventanas, cajas de dialogo, arrastrar y soltar,

y respuestas inmediatas. Esto ha alcanzado niveles excelentes de interacción, presente en muchos

casos pero principalmente ha sido una característica de los programas offline. Por tanto, el

desafío es llegar a esto en la plataforma de Internet.

Podemos decir entonces que una aplicación es mas “rica” en este sentido relacionado el término

con su funcionalidad, y el nombre Rich Internet Applications50 (RIAs) puede ser clasificado como

orientado a la funcionalidad, a diferencia de los mashups que como veremos más adelante,

podemos decir que son orientados a los datos.

Como hemos notado en el análisis realizado hasta ahora el desarrollo de Internet ha sido

evolutivo, no revolucionario. RIAs son otro ejemplo claro de esto. Podemos encontrar una gran

variedad de estos en Internet, y son en general una aplicación de la idea del software como

servicio, algo que analizaremos más adelante pero que hemos anteriormente al estudiar los

patrones de diseño Web 2.0.

Por tanto, a continuación buscaremos aproximarnos al desarrollo de páginas aun más dinámicas,

en base a Ajax.

3.8.7.2. Ajax

Como se explico anteriormente, el modelo cliente-servidor se caracteriza por su funcionamiento

sincrónico, y esto se aplica al modelo de Internet y las páginas web: En general la actividad en el

cliente da como resultado peticiones de páginas al servidor, quien procesa estos pedido y da

50

El término fue desarrollado en (142) al hacerse referencia al entorno Flash y sus capacidades.


132

como resultado paginas HTML. Por

tanto, el cliente debe realizar esperas y

la información es manejada de forma

ineficiente porque los resultados son

siempre transmitidos como páginas

enteras, es decir, generando una

recarga de toda la página, por tanto

existiendo el envío de mucha

información redundante mientras que

solo se genera un cambio quizás

pequeño en el contenido (por ejemplo,

datos de una lista desplegable de un

formulario).

El objetivo principal de Ajax es acelerar

estas interacciones entre el usuario y

una aplicación web al hacerlas

asincrónicas y omitir la transmisión

redundante de datos. Podemos ver la nueva secuencia de interacciones en la siguiente figura.

En este nuevo modelo Ajax, el input del usuario es manejado por el motor Ajax cargado en

navegador del cliente luego de la primera interacción con el sitio web. De ahora en más, es

posible realizar muchas tareas sin necesidad de pedir datos al servidor. Solo cuando es necesario

se realiza una petición al servidor, y esta es transmitida y procesada de forma asincrónica, por

tanto la actividad del usuario no se interrumpe. La respuesta del servidor puede ser construida de

tal forma que solo contiene información nueva y relevante, por lo que se reduce drásticamente la

cantidad de datos transmitidos.

Aunque los detalles pueden variar,

todo escenario Ajax consiste de

pasos similares. Cuando el usuario

realiza un evento, el motor Ajax (o

más bien la función Javascript

responsable del evento) debe

manejarlo de una manera

apropiada. Si hace falta

información adicional del servidor

para llevar a cabo la tarea, se

realiza la petición asincrónica.

El motor descripto en la siguiente

figura no es una entidad

independiente, sino que representa

la interacción de las tecnologías

web que hemos analizado

anteriormente, en conjunto con el

Cliente Servidor

Actividad del

usuario

Actividad del

usuario

Actividad del

usuario

Procesamiento

del sistema.

Procesamiento

del sistema.

Transmisión

de datos

Transmisión

de datos

Transmisión

de datos

Transmisión

de datos

Tiempo

Cliente Servidor

Procesamiento

del sistema.

Procesamiento

del sistema.

Transmisión

de datos

Transmisión

de datos

Transmisión

de datos

Transmisión

de datos

Tiempo

Motor Ajax Navegador

Mostrar

Mostrar

Mostrar

Input

Input

Input

Actividad

del

usuario

Procec.

Del

sistema

Ilustración 55: Solicitudes sincrónicas y recargas de pagina.

Ilustración 56: Recargas asincrónicas de pagina utilizando AJAX.


133

objeto XMLHttpRequest.

El proceso general de una llamada Ajax puede ser resumida en los siguientes pasos:

1. Se crea el objeto XMLHttpRequest. La sentencia Javascript puede ser algo como resObject =

new XMLHttpRequest().

2. Para manejar la respuesta, es necesario definir una función de callback. La sentencia sería

algo similar a resObject.onreadystatechange = handleResponse, siendo handleResponse el

nombre del manejador de callback. Esta función es llamada cuando el estado de resObject

cambia. El campo resObject.readystate indica el estado en el que está el objeto

XMLHttpRequest. Cuando toma el valor de Loaded, la transmisión finaliza, y depende del

manejador de callback reaccionar apropiadamente al cambio de estado.

3. Al llamar a open en el objeto XMLHttpRequest se abre la conexión HTTP al servidor, y open

espera tres argumentos: el tipo de solicitud HTTP, la URL objetivo en la aplicación de servidor,

y un flag indicando si la transmisión debería ser asincrónica o no. Por ejemplo, una petición

asincrónica con el método GET tendría la siguiente forma:

resObject.open(‘get’,’targetURL’,true).

4. Para comenzar la solicitud, el método send del objeto XMLHttpRequest es llamado con un

argumento que contiene el mensaje en caso de una solicitud en la que se utiliza un tipo de

solicitud POST. Si se elige el método GET, los parámetros del mensaje son codificados en la

dirección objetivo y por tanto se envía null como argumento.

5. Una vez que el manejador de callback es llamado y el estado es COMPLETED la información

requerida puede ser accedida mediante los campos responseText y respondeXML del objeto

XMLHttpRequest. El primero contiene el mensaje en texto plano y el segundo en formato

XML.

El motor ajax puede ahora utilizar la información para completar sus tareas y presentar los

resultados, por ejemplo reemplazando ciertas porciones de la página utilizando DHTML.

Ilustración 57: Interacción cliente-servidor con AJAX.


134

Podemos encontrar información más detallada sobre Ajax en (105).

El siguiente ejemplo tiene el objetivo de simplemente explicar la función de XMLHttpRequest, y

ciertamente no es posible considerarla como una RIA.

3.8.7.3. Servidor WPC

Para poder mostrar cómo podemos extender nuestro catalogo de DVD con la funcionalidad de

XMLHttpRequest, necesitamos un proveedor de datos como ser un servidor WPC (Web

procedure call server) o un proveedor de Web service que procese las solicitudes generadas en

nuestra página de ejemplo.

Para esto realizaremos un cambio en nuestro script de PHP, que podría generar el catalogo

completo. Ahora en lugar de generar la página completa, el script en base a solicitudes devolverá

datos específicos correspondientes a una película, como ser los nombres de directores y actores.

Utilizaremos a su vez la misma fuente de datos principal, es decir, el archivo XML con datos de

DVDs.

La siguiente imagen muestra que componentes son parte del ejemplo. El cliente ejecuta código

Javascript para realizar las solicitudes Ajax al servidor WPC. El servidor corre PHP para generar las

peticiones a la base de dato, que en este caso implica acceder al archivo XML vía XPath. Luego

toma el resultado para producir el output para el cliente y se lo envía. El cliente utiliza

nuevamente código Javascript para manipular su DOM.

A continuación podemos ver el código para el servidor WPC:

<?

$asin = $_GET['ASIN'];

$dom = new DomDocument();

$dom->load('catalogo.xml');

$xp = new domxpath($dom);

$dvds = $xp->query('/DVDCatalog/DVD[ASIN="'.$asin.'"]');

foreach ($dvds as $node) {

$director = getFullNamesOfPersons($node->getElementsByTagName('Director')-

>item(0));

Generación del catalogo con Ajax


135

$actors = getFullNamesOfPersons($node->getElementsByTagName('Actors')-

>item(0));

returnDVDCode($director, $actors);

}

function returnDVDCode($director, $actors){

echo 'Director: '.$director.'<br>'."\n".'Actores: '.$actors;

}

function getFullNamesOfPersons($personList) {

$persons = $personList->getElementsByTagName('Person');

$i = 0;

foreach ($persons as $person) {

$fullNames[$i] .= getSubNodeContent($person, 'Firstname').'

'.getSubNodeContent($person, 'Lastname');

$i++;

}

return implode(", ", $fullNames);

}

function getSubNodeContent($node, $subNodeName) {

return $node->getElementsByTagName($subNodeName)->item(0)->nodeValue;

}

?>

Este servidor WPC tiene exactamente las mismas funciones getSubNodeContent y

getFullNamesOfPersons que el script de creación que vimos en el ejemplo de scripting de

servidor. Las funciones printDocumentFoot y prontDocumentHead han sido borradas del código

mostrado, ya que no son necesarias porque nuestro script ahora funcionara como una forma para

que un script cliente acceda a la información de nuestra base de datos de catalogo de DVD. Por

tanto no es necesario crear una página entera ya que sería redundante. En lugar de esto, nuestro

script utiliza la función returnDVDCode para entregar solo el contenido que no está todavía

disponible en el lado del cliente.

El script anterior devolvía todos los DVDs del catalogo, lo cual ya no hacemos. Para evitar esto

realizamos un pequeño cambio en el objeto $dvds, que ahora tiene la siguiente forma:

$xp->query('/DVDCatalog/DVD[ASIN="'.$asin.'"]').

El código indicado entre [ ] es un selector especial de XPath, que verifica que el elemento ASIN

(que es un subelemento de DVD) tiene el mismo valor que la variable $asin, y solo aquellos nodos

que cumplan esta condición son seleccionados y guardados en $dvds. Como podemos ver en la

línea 2 del script, la variable $asin tiene el valor de $_GET*‘ASIN’+, es decir que contiene el valor

ASIN si un valor con tal nombre ha sido previamente entregado al script a través del meto GET de

HTTP. Los parámetros GET son agregados en la URL del script invocado luego de un signo “?”, por

ejemplo:

http://www.juanortiz.com.ar/wpcserver.php?ASIN=B0000CABBW

La solicitud anterior llama al server WPC con un parámetro ASIN de valor B0000CABBW, que

contiene la película Le Fabuleux destin d'Amélie Poulain. El script devolverá entonces el siguiente

resultado:

Director: Jean-Pierre Jeunet <br>




136

Ya que no hemos agregado funciones que reciben y manejan números ASIN erróneos, en ese caso

el script devolverá un arreglo vacio.

3.8.7.4. Cliente WPC

Comenzaremos también con la base que teníamos en el ejemplo de scripting de cliente

previamente mostrado, donde podíamos esconder los detalles a través de un click en el titulo del

DVD. Como veremos a continuación con algunos pequeños cambios podemos adaptar el script a

nuestros objetivos actuales.

Primero, podemos notar que la página ya no contiene la información del director y de los actores,

sino que el div correspondiente esta vacio y con el número ASIN del DVD como Id, y funcionara

ahora como un contenedor para los datos que obtendremos del servidor. El resto del cuerpo no

contiene cambios.



<html>

<head>





function toggleDVDDisplay(id){

var http = new XMLHttpRequest();

http.onreadystatechange = function() {

if(http.readyState == 4 && http.status == 200) {


contentElement.innerHTML = http.responseText;



}

}

http.open("GET","http://localhost/ch3/sample_01_server.php?ASIN="+id,

true);

http.send(null);

}

</script>

</head>

<body>


<h1>Catalogo de DVD</h1>

<div class="DVD">


onClick="toggleDVDDisplay('B0000CABBW')">



</div>

<div class="DVDContent" id="B0000CABBW">

</div>

</div>

<div class="DVD">


onClick="toggleDVDDisplay('B00005U515')">


137


The Lord of the Rings: The Fellowship of the Ring</a></h2> (2001)

</div>

<div class="DVDContent" id="B00005U515">

</div>

</div>

</div>

</body>

</html>

El cambio más importante es la nueva versión de la función toggleDVDDisplay, que ahora sigue el

proceso de llamadas Ajax que mencionamos anteriormente. Primero se instancia un objeto

XMLHttpRequest y luego se define que la función onreadystatechange de XMLHttpRequest debe

manejar el resultado de la llamada WPC. A continuación la función open configura los parámetros

de la llamada WPC y send abre la conexión. Cuando el resultado regresa desde el servidor y su

estado es el correcto (es decir, que el estado de http.readyState es 4 y http.status es 200) se

ejecuta el código que se encarga de insertar el nuevo contenido. La función responseText

devuelve el resultado en texto plano que es insertado en el div vacio que funciona como

contenedor en el cuerpo de la página, con su selección funcionado de la misma forma que el

ejemplo original de scripting de cliente. Esta inserción se realiza sobrescribiendo el contenido del

div a través de la propiedad innerHTML.

Hay que notar que la función toggleDVDDisplay es tan simple que hace llamadas repetitivas al

servidor si se hace click repetidamente. Esto por supuesto no es un comportamiento deseable ya

que la idea de usar Ajax es reducir la cantidad de datos que son transmitidos y estos serian datos

redundantes, pero esto es debido a que se busca mantener la simpleza del ejemplo.

Para dar una pista de que mas es posible, potemos observar a las posibilidades que tenemos con

este objeto. Hasta ahora solo hemos utilizado el estado 4 (cargado) del XMLHttpRequest, que es

usado para informar al script que se ha completado el envío de datos. Podemos ampliar la

información diciendo que tiene los posibles estados:

0: sin inicializar.

1: abierto.

2: enviado.

3: recibido.

4: cargado.

El estado 1 indica que la función open ha sido llamada de manera exitosa, el estado 2 indica que la

petición ha sido recibida, el estado 3 indica que todas las cabeceras HTTP han sido recibidas y que

el cuerpo del mensaje está a punto de ser recibido. Estas funciones pueden ser utilizadas para

informar al cliente el estado de su solicitud. En nuestro ejemplo no hicimos esto debido a que la

cantidad de datos considerada es siempre pequeña, pero en caso de necesitar cargar mayores

cantidades de datos estas funciones serian una buena manera para mejorar la comunicación

entre el cliente y el servidor.

Si las respuestas de datos del servido no solo contuvieran contenidos de nueva información, sino

que también en forma de nuevos scripts podemos imaginar que es posible aumentar y modificar


138

las acciones que se realizan en la página. Las posibilidades que esto brinda son muy amplias,

dejando de lado el concepto estático que se presentaba previamente a la incorporación de Ajax,

alcanzando un nuevo nivel de páginas dinámicas.

Es importante considerar que esto sirve para nuestro pequeño ejemplo, pero cuando se habla de

proyectos de tamaño considerable es necesario utilizar herramientas que agregan capas a la

programación y que manejan con abstracción el concepto de Ajax.

3.8.8. Mashups y el diseño para la reutilización

Los mashups (concepto que hemos considerado en el análisis de social medias) representan un

cambio radical frente a las posibilidades que existían previamente en Internet. Antiguamente la

única forma de acceder a la información de un sitio web era a través justamente del sitio web,

siendo el “page scraping” una práctica necesaria para quien requería obtener información con el

objetivo de reutilizarla.

Existen diversas maneras de ejecutar este tipo de extracción de datos. Podemos explicarla de

forma breve indicando que consiste en extraer de forma automática contenidos de partes de

páginas publicadas a través de un robot o “spider” que recorre los sitios de los cuales se desea

extraer información, analizando los códigos HTML presentados y en base a patrones y palabras

claves identifica y extrae los contenidos, para luego procesarlos y presentarlos. Es una práctica

claramente ineficiente, dependiente de los patrones del diseño y con una gran tendencia al error,

pero ampliamente utilizada debido a que en muchos casos los sitios no permiten otra forma de

acceder a los datos presentados. Hoy en día continua siendo una práctica común para la

obtención de datos en Internet, pero requiere técnicas avanzadas y en general se utiliza para

cuestiones o tipos de información muy especificas, es decir, no es algo utilizable por el usuario

común de Internet.

Y aunque en ciertos escenarios esto puede funcionar, lo importante es el cambio que se presenta

en la actitud por parte de quien publica contenidos: Como mencionamos en la práctica de

“diseñar para la reutilización” del patrón “innovación en el ensamblaje”, en el concepto Web 2.0

los contenidos digitales se generan de tal forma que puedan ser desarmados y reutilizados. Esto

se logra en base a la publicación de contenidos de diversas maneras, manteniendo la tradicional

publicación de páginas web pero colocando a disposición del usuario de internet otras formas de

acceder a los contenidos, como ser a través de Web feeds y APIs y. Es decir, diseñar y generar

sitios web que además de ser legibles por los usuarios, pueden ser fácilmente leídos por otras

aplicaciones.

En base a estas maneras alternativas, es posible reutilizar los contenidos y servicios de diversas

fuentes combinadlos para crear e innovar, generando así posibilidades ilimitadas.

Antony Mayfield indica que “la combinación de dos o más unidades de contenidos (o software, o

sitios web) es uno de los fenómenos de los social media que hacen a estos tan excitantes,

dinámicos e incluso en ocasiones desconcertantes. Los Mashups son posibles debido a la apertura

de los social media, ya que muchos sitios web y desarrolladores de software alientan a la gente a

jugar con sus servicios y reintentarlos.” (10)


139

Analizamos a continuación las dos formas mencionadas para generar esta apertura: Web Feeds y

APIs.

3.8.8.2. Sindicación de contenidos con Web feeds

Hemos mencionado anteriormente el concepto de sindicación de contenidos, mencionado que se

presenta como una herramienta en los social media. A su vez, hemos profundizado en la

tecnología detrás de los Web feeds a través del análisis de los estándares RSS 2.0 y ATOM.

Podemos decir que la sindicación de contenidos en el contexto de Internet es una recombinación

de contenidos orientados a documentos.

Esto tiene un potencial virtualmente ilimitado en cuanto a las maneras que puede aprovecharse, y

podemos mencionar un par de casos para acercarnos al concepto.

Volviendo al caso mencionado del page scraping, podemos decir que esta técnica es parte de un

proceso de recolección, análisis, procesamiento y presentación de información. Podemos llevar

esto más allá de la tecnología, al caso de análisis de medios que se realiza en marketing o

ambientes corporativos, para obtener por ejemplo un resumen de diferentes revistas, periódicos

y publicaciones sobre un tema en particular con el objetivo de obtener reportes de información

agregada que es relevante al negocio. El punto fuerte de este tipo de análisis es que concentran

los esfuerzos de seleccionar y procesar estos puntos relevantes y entregarlos al nivel de toma de

decisiones, dando así información valiosa y acotada. Podemos notar diferentes pasos en este

proceso: obtener información (conseguir las fuentes en cuanto estas son publicadas), integrarla

(tomar copias de lo que se considera relevante), transformarla (puede no ser necesaria, pero

quizás se deba al menos acotar su largo para mostrar solo una parte de la información ya que

puede ser muy extensa) y entregarla (enviar por correo electrónico por ejemplo).

Ahora supongamos que aplicamos el concepto de Web feeds al caso analizado, siendo que las

fuentes de información están provistas como un Web feeds en alguno de los formatos

mencionados. En este escenario adquirir implica realizar las subscripciones a las fuentes de datos.

Integrar es realizado a través de un agregador de Web feeds, la transformación en caso de ser

necesaria se realiza internamente si es que los feeds están provistos en diferentes formatos, lo

cual solo implica una transformación en base a XML o incluso más simple aun, en la mantera en

que el contenido es presentado (por ejemplo, podemos mostrar tan solo las primeras 500

palabras de un articulo, dando la posibilidad de ir a la fuente original si se desea leer todo el

contenido). El último paso de entrega es realizado cuando se selecciona los contenidos relevantes

y el agregador funciona como un proveedor de Web feeds que son consumidos por otros usuarios

en sus agregadores.

Podemos llevar esto a un ejemplo práctico, demostrando esto al utilizar el servicio de Google para

Web feeds llamado Google Reader. Este servicio ofrece la opción de redistribuir contenidos

mediante la opción de “shared ítems”. Al agregar un feed a este grupo, se genera de forma

automática un nuevo feed que queda disponible para las personas que deseemos (o incluso es

posible hacerlo publico). Por tanto, volviendo al ejemplo mencionado una persona que quiera

redistribuir contenido solo debe primero seleccionar las fuentes que desea, y luego seleccionar

los artículos de estas fuentes que deben ser redistribuidas. La aplicación que funciona como


140

agregador en este caso se encarga de

todos los otros pasos del proceso.

Esto da la posibilidad de que

prácticamente cualquier usuario

pueda convertirse en un agregador y

redistribuidor de contenidos.

Al publicarse esto en una URL

particular, es claro que hemos

generado un mashup que contiene

diversas fuentes de datos de una

manera rápida y en base a Web feeds.

Este tipo de procesos de distribución

y redistribución basado en Web feeds

demuestra un gran potencial para el

consumidor de contenidos. Ahora

podemos observar esto desde el

punto de vista de los proveedores de contenidos.

La provisión de Web feeds

disminuye los esfuerzos de

integración en el cliente de tal

forma que el proveedor puede

esperar una amplia difusión de su

trabajo, pero para que esto le

beneficie es esencial la atribución

de la fuente. En los formatos de

Web feeds esto está asegurado por

defecto, y podemos notarlo al ver el

campo requerido de “channel level”

en un documento XML, y el campo

opcional “entry level”. Es decir, se

asegura que quede disponible la

fuente e incluso de manera

opcional el articulo original (algo

que comúnmente se mantiene).

A demás de la correcta atribución de autoría, el proveedor de contenidos puede estar interesado

en incrementar el tráfico de su sitio en base a la distribución de los Web feeds, y esto es algo que

el link incluido en el documento XML también provee. De tal manera es posible encontrar

información adicional sobre el tema del feed, y obtención de beneficios de acuerdo al modelo de

negocio del sitio (por ejemplo, anuncios publicitarios, productos o servicios que el proveedor

ofrezca, etc.) Una motivación común para que el lector del feed se dirija a la fuente original es

para leer los comentarios que han sido incluidos en el artículo, ya que en muchos casos estos

Ilustración 59: Pagina personal pública de Google Reader.

Una vez que tenemos contenido seleccionado, este puede ser accedido

de manera pública en una URL especifica permitiendo incuso que otra

gente se subscriba a esta información en formato de feed, o puede ser

redistribuido a un listado acotado de personas.

Ilustración 58: Captura de pantalla de Google Reader.

Google Reader nos da la posibilidad de generar nuestra propia

redistribución de feeds. Solo es necesario tener diversas fuentes

seleccionadas, y marcar los artículos que queramos redistribuir como

“shared”.


141

agregan información útil (y estos incluso pueden ser agregados como un feed individual en

muchos casos).

Diferenciamos entonces dos tipos de links: el link que apunta al sitio principal (channel level) y el

que apunta al artículo en particular (entry level). Este ultimo link es el que permite muchos de los

efectos de la Web 2.0 y que hemos analizado en la práctica “Direccionamiento granular de

contenidos” del patrón “innovación en el ensamblaje”. Este tipo de vínculo debería mantenerse

invariable para permitir al contenido ser encontrado siempre luego de su publicación, y es por

esto que estas URLs son denominadas permalinks.

3.8.8.3. Mashups basados en WPCs.

Mientras que los Web feeds funcionan bien para los contenidos orientados a documentos, solo

proveen un enfoque muy básico en cuanto a la combinación de contenidos orientados a datos.

Veremos a continuación como los WPCs y las APIs son una solución para este tipo de contenidos.

Como su nombre lo indica, los WPC (Web Procedure Calls) pueden ser utilizados para

implementar cualquier tipo de llamada a procesos de Internet. Es posible al crear una aplicación

definir que se puede llamar, con que parámetros y en base a qué métodos de acceso.

Analizaremos más adelante un ejemplo de mashups en base a Google Maps para acercarnos al

concepto.

Analizamos ahora brevemente como los WPCs son parametrizados. Existen alternativas que

definen como un WPC interactúa con un cliente y cuan extensible es. Volviendo al ejemplo

analizado previamente, hemos utilizado el GET de HTTP para llamar a la función PHP que devuelve

información adicional de un DVD, utilizando:


Este método GET podría ser también usado para enviar solicitudes al servidor, pero esta

cambiaria su estado y por tanto se consideraría un mal uso. Podemos decir que este método es

“seguro”, en el sentido de que solo debe ser usado para recibir información. La mejor forma de

enviar información a un servidor es mediante el método POST, que incluye los parámetros no en

la URL sino en el cuerpo de la solicitud.

Cuando hablamos de SOAP como una forma natural de mejorar la formalización de los datos que

se envían, ya que se utilizan sobres basados en XML para dar formatos a los mensajes. La

definición de interfaces de los servicios se realiza mediante XML Schemas (como ser el ya

mencionado WSDL). Finalmente, SOAP funciona como base natural para otros estándares si se

considera una estructura de capas y consecuentemente incremente la formalización, pero sin

cambiar la imagen general de los WPCs.

Debido a la forma en que hemos utilizado los procedimientos hasta ahora, la semántica de los

métodos GET y POST no han quedado del todo claras: Estas dependen del uso de los parámetros

en el script que ha sido accedido. Cuando las semánticas de GET y POST y otros métodos HTTP son

definidos y utilizados de forma rígida obtenemos como resultado un estilo de arquitectura como



142

ser la del caso de REST (Representatonal State Transfer)51, que describe como las aplicaciones

Web deben ser diseñadas. A saber, como “una red de páginas Web (una maquina de estado

virtual) donde el usuario progresa a través de una aplicación al seleccionar links (transiciones de

estado) que dan como resultado la siguiente pagina (representado el siguiente estado de la

aplicación) siendo transferido al usuario y presentados para su uso”. Toda funcionalidad y estado

de la aplicación son considerados recursos. Estos son direccionados de forma única típicamente a

través de URIs. Tomando nuevamente el ejemplo del DVD, las siguientes URIs apuntan a recursos.

http:// www.juanortiz.com.ar/DVD/

http:// www.juanortiz.com.ar/DVD/FindDVD

http:// www.juanortiz.com.ar/DVD/B0000CABBW

http:// www.juanortiz.com.ar/DVD/B00005U515

La primer alinea apunta a un recurso que contiene todos los DVDs, la secunda ofrece la

posibilidad de buscar DVD, y la tercera y cuarta a DVDs específicos. Los métodos que pueden ser

usados en los recursos son GET, POST, PUT y DELETE únicamente, y estos corresponden a los

métodos HTTP de iguales nombres. Hemos explicado ya GET y POSTS, y podemos decir que PT

agrega un recurso y los parámetros son dados en el cuerpo de la solicitud, y DELETE remueve una

dirección dada. Cuando se utiliza GET en un recurso, una representación del recurso de baja al

cliente, y la forma en que esta representación luce depende de la decisión del cliente y el servidor

ya que no hay un mecanismo formal para expresar la interfaz de un servidor. Por ejemplo,

observemos una página cargada en un navegador: La representación e la página es devuelta al

cliente debido a que ha sido llamado el método GET. Esta representación podría tomar la forma

de paginas HTML, imágenes o documentos PDF por mencionar algunos casos. Cuando se devuelve

una representación con links como ser el caso de paginas HTML, los usuarios pueden moverse en

la aplicación seleccionando los links y desplazándose en los distintos estados de la aplicación.

Hemos visto dos implementaciones distintas de los WPCs: orientados a procedimientos y

orientados a recursos. Ambos estilos son comunes en la Web y cada uno es el más adecuado

dependiendo de las características de la aplicación donde sean utilizados. La elección es sencilla

solo cuando una aplicación debe ser integrada a una arquitectura de Web services, que depende

fuertemente en estandartes de Web services. En dicho caso, la ventaja de utilizar SOAP es clara. Y

para proyectos más simples REST puede ser una opción ya que la simplicidad es su punto fuerte:

solo cuenta con cuatro métodos aplicados a recursos que son identificados con URIs.

Para analizar un ejemplo, la API de Google Maps permite integración de los servicios de mapas en

otros sitios web. El uso de la API implica registrarse al servicio para obtener una clave de

desarrolladores (una práctica muy común en los servicios de APIs) y el uso de un archivo

Javascript provisto por Google. En realidad esto último no es estrictamente necesario ya que uno

puede construir las llamadas necesarias en cualquier lenguaje, pero la documentación de la API

provee solo soporte para esta clase de Javascript. Solicitudes a la API son procesadas cuando se

utiliza la clave provista, habiendo sido relacionada esta con el sitio desde donde se realiza la

petición. La librería de la API consiste en un conjunto de objetos y escuchadores de Javascript. Los

51

El término fue definido en (143)


143

objetos por ejemplo representan un mapa, un marcador o un control. Los escuchadores permiten

reaccionar a eventos específicos inicializados por objetos o por el usuario.

Cada mapa es representado como una instancia de la clase GMap2. El constructor de un mapa

recibe la locación en el documento HTML que es definida mediante el uso de un elemento div

como argumento. Es posible agregar al mapa botones de control para manejar la locación y

niveles de zoom aunque GMap2 ofrece interfaces y clases que pueden sobrescribir el

comportamiento por defecto.

La API ofrece un conjunto rico de funcionalidades para controlar los aspectos visuales del mapa.

Para marcar lugares específicos se pueden incluir elementos GMarker en el mapa. Las locaciones

son representadas mediante el objeto GLatng que contiene las latitudes y longitudes respectivas.

Una instancia de GmMarker se miestra como un icono (GIcon) en el mapa, y es posible definir

diversos iconos para representar diferentes objetos. Los Gmarker pueden contener un

GInfoWindow que aparece al hacer click en el marcador o en otros eventos. Además se pueden

utilizar líneas o polígonos que pueden ser utilizados por ejemplo para mostrar el camino para

llegar de un punto a otro.

Podemos ver a continuación como utilizando la se crea un mapa centrado en latitud -31.432975 y

longitud -64.276317, y agregamos como agregar controles y un marcador con el texto “IUA” que

se mostrara cuando hagamos click en el marcador.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="content-type" content="text/html; charset=utf-8"/>

<title>Ejemplo de Google Maps :: IUA</title>

<script

src="http://maps.google.com/maps?file=api&v=2&key=ABQIAAAAW210_oqepJQ3TYK

PtSmmzBQuV8JmhhAn8NQ9CV189HfU10cb5BQCcdUXLm6LW5gDngABsWOOjSkrXg"

type="text/javascript"></script>


function load() {

if (GBrowserIsCompatible()) {

var map = new GMap2(document.getElementById("map"));

var point = new GLatLng(-31.432975, -64.276317);

map.setCenter(point, 16, G_HYBRID_MAP);

map.addControl(new GLargeMapControl());

map.addControl(new GMapTypeControl());

map.addControl(new GScaleControl());

var marker = new GMarker(point);

var html = "IUA";

GEvent.addListener(marker, 'click', function() {

marker.openInfoWindowHtml(html, 100);

});

map.addOverlay(marker);

}

}

</script>

</head>


144

<body onload="load()"

onunload="GUnload()">

<div id="map" style="width:

500px; height: 300px"></div>

</body>

</html>

La API de Google Maps también

permite posibilidades de simplificar la

comunicación asincrónica con un

servidor propio y el manejo de datos

XML. Por ejemplo, la función

FDownloadURL encapsula diferentes

implementaciones del objeto

XMLHttpRequest y reduce por tanto

la carga de codificación. Los métodos

GXml y GXslt permiten el análisis de archivos XML en su representación DOM y por tanto permitir

con el DOM resultante vía XSLT.

Como podemos ver es muy sencillo incluir mapas en un sitio Web, y seria increíblemente costoso

y complicado diseñar una aplicación propia que tuviera algún tipo de funcionalidad similar. Y

podemos imaginar el potencial de esto al generar el Javascript con scripts de servidor, en base a

diferentes configuraciones de mapas tomando por ejemplo las longitudes y latitudes de centros

comerciales en una ciudad desde una base de datos, junto a otros datos interesantes como ser

una imagen del frente de los locales, sus teléfonos y páginas web.

En el lado técnico, el desarrollo de nuevos mashups requiere que un servidor pueda trabajar junto

a los datos de mapas provistos por Google Maps, y para esto el servidor debe proveer acceso a

fuentes de datos adicionales sean locales o remotas. Parta esto los WPCs puede ser de la forma

en que hemos visto en el ejemplo de Ajax, y esto permite que los límites solo queden en la

imaginación de los desarrolladores.

En los análisis realizados en el despliegue del patrón de diseño “innovación en el ensamblaje”

hemos mencionado que una práctica Web 2.0 es la de ofrecer este tipo de APIs y a su vez ser los

propios consumidores de estas. Es por ello que hoy en día es de suma importancia poder tener un

panorama claro de las APIs existentes para poder basarnos en estas para por ejemplo, para el

caso planteado de mapas o para cargar videos en nuestro sitio utilizando posiblemente la API de

YouTube.

Hoy en día muchos mashups son creados por individuos de manera privada y sin objetivos

comerciales, aunque el número de empresas que crea mashups también está creciendo

rápidamente. Estas organizaciones se enfrentan al problema de basar sus servicios en los

servicios de otros, y por tanto se vuelven dependientes de estos. Claramente la dependencia de

proveedores no es algo nuevo ni deseable, y en estos casos es algo muy directo: si las APIs

cambian de interfaces sin previo aviso el mashup probablemente presente errores, y si las APIs

dejan de proveer servicios el mashup dejara de funcionar.

Ilustración 60: Ejemplo de Google Maps.

A través de la API de Google Maps podemos insertar mapas en base a

parámetros que definimos.


145

En general los términos y condiciones en base a los que las APIs son provistas incluyen el derecho

del proveedor de discontinuar el servicio o de deshabilitar las solicitudes de algún sitio en

particular en caso de algún tipo de uso que vaya en contra de estos términos y condiciones. Más

aun, cuando los mashups se vuelven populares se encuentran con el problema de que el

proveedor de la API puede considerar que se ha generado un nicho de mercado interesante y

desarrollar una manera para proveer el mismo servicio que el mashup, y en este caso por ejemplo

se vuelve muy importante el patrón de diseño de “Los datos son el próximo “Intel Inside””, y

generar en la operación del mashup el enriquecimiento de datos que provienen de una API, y no

simplemente reutilizar los contenidos de los servicios.

3.8.9. Tagging

Como mencionamos antes, los motores de búsqueda antes de la tendencia marcada por Google

se basaban fuertemente en los metadatos o meta-tags incluidos en la cabecera de un documento

HTML: para definir la temática de la página el autor puede incluir el titulo, palabras claves y

descripción en forma de metadatos. Ya que esto puede ser claramente manipulable, la

consideración de estos metadatos fue drásticamente reducida al momento de generar un ranking

de resultados. El método de Google fue la utilización de PageRank y el análisis de estructuras de

vínculos en los sitios como meta-información, lo que dio como resultado un ranking mucho más

natural.

Estos metadatos creados de forma manual han tomado una nueva forma y gracias a estos se

están convirtiendo en la nueva base para mejores búsquedas y resultados: El concepto de llama

tagging, y en este los usuarios (y ya no solo los autores de un sitio) agregan adjuntan o aplican

palabras claves a sitios u objetos de estos, es decir, sitios completos, imágenes, videos o links, con

el objetivo de clasificarlos y simplificar su posterior búsqueda. Este concepto es uno de los pilares

de la Web 2.0 y se presenta fuertemente en comunidades de contenidos, redes sociales, blogs y

otros social media. A su vez, los tags pueden ser públicos de tal manera que otros usuarios

puedan verlos y utilizarlos para sus búsquedas. Este proceso es el mecanismo de creación básico

para las llamadas folksonomias52: sistemas abiertos de etiquetas creadas de forma colaborativa.

Este término hace contraste las taxonomías, que en general se basan en directorios rígidos de

categorías.

El publicar y compartir tags es un paso importante en lo que a socialización de los contenidos

generados por usuarios en Internet respecta; y aunque la definición de tagging es tan simple

como hemos visto, las consecuencias de esta práctica son muy poderosas y significativas.

Podemos mencionar algunas dimensiones que definen las maneras en que los tags son creados y

utilizados (aunque no todas son independientes del resto), detallando características referidas a

los usuarios y al sistema para determinar la manera en que se comporta un sistema de tagging:

Tipo de Objeto: Cualquier objeto que puede ser representado puede ser taggeado. Sin

embargo, es esperado que el uso de los tags varíe mucho dependiendo de la naturaleza

del los objetos.

52

El término fue desarrollado por Thomas Vander Wal en 2004 (144).


146

Fuente del material: Cuando los objetos están disponibles en un sistema, puede ser

provistos por los usuarios o por el mismo sistema. Una alternativa es el caso de recursos

fuera del sistema (por ej. en otros sitios) que son taggeados.

Derechos de tagging: La decisión de quien puede (o incluso quien es alentado) a agregar,

editar o borrar tags afecta directamente a los tags que pueden surgir y a los patrones de

su surgimiento.

Soporte al tagging: Los usuarios pueden recibir ayuda al momento de aplicar tags. Por

ejemplo, en el caso de que los derechos de tagging permitan que muchos usuarios

puedan aplicar tags a un objeto, al momento de aplicar un tag se puede mostrar las

contribuciones de otros al usuario que este por realizar la acción dándole la opción de

aplicar quizás los mismos tags ya aplicados previamente.

Modelo de agregación: En esta dimensión podemos distinguir dos tipos básicamente: en

un caso se permite aplicar un tag a un objeto una única vez (set-based), y en otro caso los

tags pueden ser agregados más de una vez (bag-based), lo que permite que se realicen

evaluaciones de su frecuencia de uso para obtener análisis.

Conectividad de recursos: Los recursos pueden estar conectados de otras maneras

además de los tags, estando agrupados o vinculados entre sí. Es de esperarse que los

objetos interconectados compartan tags similares.

Conectividad social: Esta dimensión hace referencia a las conexiones entre los usuarios de

un sistema, y estos aspectos son similares a los que se presentan en las conectividades de

los recursos.

También es posible analizar las motivaciones de los usuarios para la aplicación de tags,

encontrando dos tipos principales: los tags organizativos y los tags sociales. La primera categoría

puede ser dividida en formas de organización personal e interpersonal: Los usuarios desean

organizar y encontrar sus propios ítems, para poder utilizarlos en el futuro y quizás compartirlos y

así permitir que otros usuarios puedan utilizar el mismo esquema de organización. Por otra parte,

las motivaciones sociales para la aplicación de tags incluyen la atracción de atención, la

presentación propia, la expresión de opiniones, y la creación de tags como un subproducto para

jugar y competir.

En esta parte del marco teórico notaremos repetidas instancias de las dimensiones y

motivaciones que mencionamos, al analizar primero el caso de las comunidades de contenidos

Flickr y Delicious, dos de los principales exponentes y pioneros en la generación de folksonomias.

3.8.9.2. Tagging en Flickr

Al analizar los social media y en particular las comunidades de contenidos, mencionamos el caso

de Flickr que habiendo nacido en el 2004 se convirtió en una de las comunidades más grandes

donde los usuarios pueden organizar y compartir imágenes, y que alcanzo este éxito gracias a

prácticas innovadoras. Uno de los pillares de este éxito ha sido el tagging.

Las imágenes pueden ser subidas al sitio mediante una interfaz web enriquecida o enviadas por

correo electrónico a una cuenta de Flickr. A su vez, existen aplicaciones de terceros basadas en las

APIs de Flickr que brindan un abanico más amplio de posibilidades. Una vez que han sido subidas,

las imágenes pueden ser incluidas en grupos. Flcikr también permite como mencionamos


147

anteriormente que el usuario defina si una imagen ser pública o privada y también aplicar

licencias de tipo Creative Commons a ellas, y siempre las imágenes se mantienen como propiedad

del usuario. Para proveer más información sobre las imágenes, es posible agregar una descripción

y aplicar tags (estos solo pueden ser aplicados por el autor). Analizaremos entonces a

continuación esta aplicación de tags.

Podemos ver aquí un típico

ejemplo de una imagen

subida a Flickr, y de los

elementos mencionados

previamente: descripción,

titulo, y tags.

A su vez se presentan

otros elementos, como ser

el usuario propietario de la

imagen, los grupos a los

que pertenece, los

comentarios que ha

recibido y algunos datos

adicionales como ser el

lugar donde fue tomada, la

cámara que se utilizo,

fecha, cantidad de

personas que la incluyeron

en su lista de favoritas y las

visualizaciones.

Volviendo a los tags, existen muchos aspectos que los hacen especiales. Primero, son tratados de

una forma distinta en la búsqueda: cuando se ingresan términos en la búsqueda de Flickr, es

posible que se realice la búsqueda en todos los campos existentes, pero también es posible

especificar que solo se haga en base a los tags. Y para entender porque esto es útil, debemos

recordar las razones por las que los usuarios utilizan tags y para que los utilizan. Una de las

motivaciones es el interés organizacional de encontrar o compartir contenidos con otros.

Si observamos los tags utilizados en este ejemplo, encontramos algunas categorías: donde

(Córdoba, Argentina), que (arco, piedra, ruta, torres) y quien (mherrero). Si bien estas categorías

no están especificadas de ninguna manera y por tanto no podrían ser interpretados como tales

por una maquina, son obvias para un usuario humano. Al leer estos tags el contenido que puede

encontrarse en la imagen se hace claro. En contraste, el titulo no llega a ser del todo descriptivo a

pesar de ser apropiado. La descripción en el ejemplo es clara, pero contiene información que

quizás no es completamente relevante a la descripción de la imagen.

Existen técnicas de inteligencia artificial, como ser el procesamiento del lenguaje natural, que

intentan entender el lenguaje humano en base a las cuales quizás sería posible extraer una

descripción igualmente apropiada del contenido de la imagen al analizar el titulo, la descripción y

Ilustración 61: Muestra de Imagen en Flickr.

Típica presentación de una imagen en Flickr con sus elementos.


148

quizás también los comentarios de otros usuarios obteniendo así los beneficios provistos por los

tags. Sin embargo, esto implicaría un procesamiento complejo para lograr manejar la ambigüedad

que se presenta en los lenguajes naturales al considerar el significado de las palabras, la sintaxis, y

las intenciones en las frases.

Los tags por otra parte, son mucho más simples de comprender. Dos tags son iguales solo si

tienen la misma representación de cadena de texto (aunque vale aclarar que esto no es

completamente cierto, ya que los espacios en blanco y caracteres especiales son quitados al

realizar búsquedas en muchos casos). Esto hace la búsqueda en base a tags una práctica más

trivial, pero también logra que la razón de porque una imagen es mostrada como el resultado de

una búsqueda sea totalmente clara. Sin embargo, el impacto más dramático se presenta en el

comportamiento de los usuarios frente a los tags: Ellos son intuitivamente consientes de la forma

en que los tags pueden utilizarse y por tanto los utilizan de la forma apropiada.

Por último, es importante destacar que los tags en aplicados de forma especial en las URIs de

flickr. Esto sigue los principios de REST y permite la navegación del sitio de manera sencilla.

Podemos observar algunas de las principales direcciones de la estructura de URIs en base a los

links que se presentan en la interfaz previamente mostrada:

Explorar: http://flickr.com/explore/

Grupos: http://flickr.com/groups/

Fotos: http://flickr.com/photos/

Explorar contiene imágenes que

han sido seleccionadas y

marcadas como “interesantes”

por un algoritmo de Flickr

explicado en

www.flickr.com/explore/interesti

ng/ de la siguiente manera: “Hay

muchas cosas que hacen que algo

sea 'interesante' (o no) en Flickr.

De dónde provienen los clics;

quién hace un comentario sobre él

y cuándo; quién lo marca como

favorito; sus etiquetas y muchas

cosas más que cambian

constantemente. Lo

interesantísimo cambia con el

tiempo, a medida que se agregan

más y más contenidos e historias

fantásticas a Flickr.” Es decir que

Flickr está utilizando los datos agregados por los usuarios de manera colaborativa para agregar

valor a las imágenes que almacena: hay que recordar que si bien las imágenes siguen

Ilustración 62: Nubes de tags en Flickr.

Las Nubes de tags en Flickr facilitan la exploración del usuario.


149

perteneciendo al usuario, Flickr es dueño de la información que se agrega a los objetos y de esta

manera crea valor.

Grupos son una forma de dar apoyo a la interacción social en el sitio. Estos son controlados pro

administradores que pueden hacerlos privados, públicos o por invitación. Los usuarios pueden

asignar sus imágenes a estos grupos, y los miembros de los grupos pueden utilizar foros de

discusión para su comunicación.

La URI de Fotos por su parte es el camino a todos los recursos de imágenes de Flickr, y las

subcarpetas que se presentan en photos/tags es una forma en que puede estructurarse el acceso

a estos recursos mediante los tags. Sobre esto podemos analizar el caso de la pagina de nube de

tags, donde es posible encontrar los más populares de todos los tiempos, del último día o de la

última semana, con el tamaño del vinculo indicando la frecuencia de su uso (esto aplica la práctica

de “Facilitar la aparición de los contenidos” del patrón “Aprovechar la inteligencia colectiva”).

Siguiendo estos vínculos los usuarios pueden explorar los tags y las imágenes que tiene aplicados

dichos tags. Este tipo de exploración es necesaria ya que existen en el sistema miles de tags y

por lo tanto sería complicado y poco práctico mostrar la lista completa. Esto permite que los

usuarios exploren en los recursos disponibles de una manera intuitiva y encontrando contenidos

inesperados pero adecuados a su intención. Al hacer click en alguno de los tags, la URI objetivo

tendrá la siguiente forma:

http://flickr.com/photos/tags/<nombre del tag>

Existen otros mecanismos para navegar a través de los tags presentes en Flickr además de la nube

de tags, tanto provistos por Flickr como por terceros, pero nos limitamos a esta para limitar la

extensión del marco teórico.

3.8.9.3. Delicious y los marcadores sociales

El software social introduce una nueva dimensión a la búsqueda y otras aplicaciones de Internet,

como ser permitir a los usuarios agregar lógica personal a algoritmos de computadoras. Al

analizar las comunidades de contenidos como parte de los social media mencionamos los casos

de Delicious y Digg como comunidades para compartir vínculos y noticias respectivamente.

Ambas son parte del fenómeno de marcadores sociales. Analizaremos el caso de Delicious para

acercarnos al concepto.

Como mencionamos anteriormente, en este servicio los usuarios pueden guardar los marcadores

que consideran interesantes o útiles y clasificarlos en base a una serie de tags. Los algoritmos de

búsqueda tradicionales (que no utilizan metadatos generados por usuarios como un factor de su

búsqueda) basan sus resultados en la masa anónima de usuarios de Internet y proveedores de

contenidos. En contraste a esto, al basar una búsqueda en metadatos explícitamente creados y en

relaciones presentes en las comunidades de servicios marcadores sociales como Delicious es

posible conseguir resultados guiados en base al juicio o criterio de los contactos sociales del

usuario.


150

En la información de su sitio el servicio indica que “Delicious es un servicio de marcadores sociales

que permite a los usuarios aplicar tags, guardar, administrar y compartir páginas web desde una

fuente centralizada. Con énfasis en el poder de la comunidad, Delicious mejora ampliamente la

manera en que la gente descubre, recuerda y comparte en Internet”. El servicio está abierto al uso

de cualquier persona para realizar búsquedas, pero sin embargo para poder crear marcadores es

necesario hacerlo mediante una cuenta de usuario.

La funcionalidad que Delicious ofrece gira en

torno exclusivamente a marcadores, y si

reducimos a sus conceptos de base ninguno

es revolucionario, pero la combinación de

estos fue una gran novedad al momento de

su desarrollo. Podemos hablar de dos

elementos genéricos: marcadores y

metadatos.

Los metadatos pueden ser clasificados en

creados por el usuario y los de sistema. En el

nivel más bajo, los metadatos del usuario

relacionados a un marcador abarcan

meramente tres aspectos: descripción, notas

y tags. Estos junto a los metadatos sistémicos

(como por ejemplo la cantidad de otros

usuarios que han agregado un determinado

marcador y la fecha en la que el usuario

guardo el marcador) son mostrados como la

representación de un marcador.

Al igual que en el caso mencionado de Flickr, los metadatos de descripción y titulo son

informativos y podrían ser utilizables para búsquedas, pero nuevamente se repite el caso

explicado de los tags. Primero, al agregar un marcador los tags son muy fáciles de utilizar ya que

se ingresan las palabras separadas por espacios, en una interfaz enriquecida que mediante el

análisis de contexto sugiere tags en base al comportamiento del usuario y de otros usuarios

respecto al mismo marcador. Segundo, los tags son los elementos más importantes a la hora de

manejar un marcador, y para esto los tags son organizados en paquetes (o “bundles”)

permitiendo así que los usuarios agregar composición lógica a la composición de sus tags. Por

último, los tags son el elemento crucial para la búsqueda de marcadores.

La página principal de Delicious y otras de sus subpáginas proveen formas de búsqueda y

exploración con diversas formas que aprovechan la inteligencia colectiva del servicio. Evitamos

mencionar detalles para acotar la extensión, pero podemos analizar algunos que hacen un

aprovechamiento interesante de los tags.

Entre otras, la opción de “links for you” incluye aquellos marcadores que han sido seleccionados

por otros usuarios para un determinado usuario. Esto se logra mediante la aplicación de tags

estructurados. En este caso es el tag “for:NOMBRE_DE_USUARIO”.

Ilustración 63: Ejemplo de página personal en Delicious.

Representación de los marcadores de un usuario de Delicious.


151

A su vez el concepto de la búsqueda en base a nombres de usuarios se refleja también en la

estructura del las URLs del sitio, que en caso de referirse a los marcadores creados por un usuario

determinado utilizando un tag específico tendría la forma:

http://delicious.com/<nombre de usuario>/<nombre de tag>

En la misma estructura, al incluir otros nombres de usuario podremos ver los marcadores

realizados por otras personas (siempre y cuando sean marcadores públicos), permitiendo conocer

quien está viendo que cosa y quien está interesado en determinados términos, la calidad de sus

datos y la conectividad de su comunidad.

3.8.9.4. Folksonomias

En general se entiende por clasificación al resultado de clasificar en un sistema jerárquico y

predefinido, lo cual está en desacuerdo con la aproximación no jerárquica y no exclusiva de una

folksonomia. Esta es la razón por la cual el uso del término en este contexto puede ser algo

controversial. El neologismo también es definido como “una clasificación generada por el usuario,

emergente del consenso ‘de-arriba-hacia-abajo’” (106) y es destacado por sus “namespaces

típicamente llanos y creados socialmente” (107).

En base a estas definiciones es claro que las folksonomias son sobre todo una forma de

clasificación, y por tanto se basan en metadatos. En general existen tres tipos de metadatos que

pueden ser diferenciados: los metadatos creados de manera profesional (por ejemplo, un

catalogo compilado por un grupo de profesionales), los metadatos creados por autores en sus

propios documentos y por último los metadatos creados por el usuario aplicados a un documento

de su interés y compartidos mediante una comunidad. Una folksonomia utiliza este tercer tipo,

admitiendo un vocabulario irrestricto para aplicar tags a objetos.

Más aun, se le atribuye a las folksonomias un conceso “de-arriba-hacia-abajo’” y ser creadas de

manera social debido a su “enfoque democrático (…) (evitando) muchos de las preocupaciones

éticas y políticas de los sistemas centralizados y ‘de arriba-hacia-abajo’” (108). Estas caracterizan

un consenso que es obtenido a través de la observación de que a pesar del uso de un vocabulario

sin control, un sistema de términos en gran medida en común evoluciona del tagging

colaborativo, que coexiste junto a categorías de minorías o incluso personales.

Finalmente, un namespace llano es otra característica de una folksonomia, causando el desarrollo

hacia una colección de tags no jerárquica y no exclusiva. Este concepto explota la percepción

general de que las jerarquías están son subjetivas en su estructura y costosas en términos de que

es necesario crearlas y mantenerlas. Un artículo referido a “Linux para PCs” por ejemplo seria

clasificado por ejemplo como PC en una capeta Linux por una persona, mientras que para otra

podría ser clasificado como Linux dentro de un contexto de PC. Consecuentemente, la idea es

despojar a las etiquetas de su interrelación lógica y asignarlas en un único nivel.

Notamos que las folksonomias, a pesar de haber sido caracterizadas como de-abajo-hacia-arriba,

creadas de manera social y no jerárquicas presentan igualmente varias limitaciones. En general,

estas pueden ser agrupadas en base a tres construcciones lingüísticas de homónimos, polisemias,

y homónimos.

http://delicious.com/%3cnombre


152

De manera similar a la que una palabra puede tener diferentes significados también puede

suceder con un tag. Los tags homónimos (por ejemplo, aquellos que son iguales sentacticamente

con distintos significados) afectan directamente los resultados de búsqueda, asi como también no

filtran correctamente pero combinan los resultados relevantes a un grupo de diferentes

connotaciones. Por ejemplo el tag “apple” devuelve resultados referidos a la empresa Apple

Computer, Apple Records o incluso sino de la fruta. Pasa algo similar con los acrónimos (por

ejemplo, el temino SOAP para referise a Simple Object Access PRotocol) corren el riesgo de

referise a ideas totalmente distintas (como ser en este caso, un jabon). Estas ambigüedades

pueden reducirse al agregar tags adicionales e univocos al realizar la búsqueda. Polisemias sin

embargo (describir teminos con significados diferentes pero ligeramente relacionados) presentan

un mayor desafio. Los sinónimos por otra parte (se refieren a diferentes términos con significados

iguales) manipulan los resultados de las búsquedas al acotarlas de manera artificial.

Volviendo al ejemplo de apple, al realizar una búsqueda sobre el término en el contexto de

computadoras privara a los usuarios de otros tipos de resultados en los que otra gente se haya

referido a por ejemplo mac o Macintosh. El ejemplo de apple muestra problemas que surgen de

las formas singulares y plurales de los sustantivos. Cuestiones relacionadas con mayúsculas o

minúsculas al manejar teminos que consisten de muchas palabras complementa la imagen de

desafíos que enfrentan las folksonomias debido a su característica de no tener un vocabulario

controlado.

Las folksonomias representan un desarrollo importante para la creación de un entendimiento

común y quizás incluso la confianza en las comunidades de internet. Son formadas de una

manera de “abajo-hacia-arriba” y es difícil saber de antemano la forma que tomara una

folksonomia en particular.

3.8.10. Desarrollo de proyectos Web 2.0

En base a lo estudiado previamente en cuanto a patrones de diseño Web 2.0 y un esbozo del

entorno de tecnologías y estándares de desarrollo analizado, es el momento de acercarnos al

proceso de desarrollo de proyectos Web 2.0

Para esto podemos analizaremos metodologías que son posiblemente aplicables, así como

también las plataformas y librerías que agregan simplicidad y abstracción al desarrollo. Por

último, analizamos la posibilidad del uso de software ya existente como base de nuevos

proyectos.

3.8.10.2. Metodologías de desarrollo tradicionales

Una distinción común en las tareas de diseño (por ejemplo, el diseño de bases de datos, de

sistemas de información, de procesos) es entre un modelo (como ser el diagrama entidad-

relación, diagramas de UML, diagramas de estado) y una metodología para su aplicación.

Sobre esa última, podemos decir que existe una distinción entre el diseño arriba-hacia-abajo (de

lo general a lo particular) y el diseño abajo-hacia-arriba (de lo particular a lo general). Las

metodologías en general usan diversos modelos para estructurar los resultados de los diversos


153

pasos que se llevan a cabo, y favorecen ciertos tipos de modelos frente a otros. Por ejemplo, la

metodología iterativa Proceso Unificado depende fuertemente en modelos UML.

Un ejemplo claro de una

metodología arriba-hacia-

abajo es la metodología de

cascada clásica, que comienza

con un análisis de

requerimientos donde se

identifica las necesidades del

cliente que marca el

desarrollo de las tareas del

proyecto. Una vez disponibles

estos requerimientos es

posible hacer una detallada

descripción de lo que se supone que el software debe hacer.

Cuando un sistema interactúa con otros sistemas, es importante que la definición de interfaces

sea solida y que permanezca estable, para que los sistemas relacionados puedan generar

componentes y conexiones exitosas. Al momento de trabajar sobre como una especificación se

transforma en un sistema vivo, una arquitectura de software define la estructura principal del

software, y esto incluye la definición de capas y escenarios. La implementación luego toma la

arquitectura y la transforma en código, completando detalles que no han sido definidos en la

arquitectura. Luego de que el código ha sido desarrollado, debe ser probado de diferentes

maneras, y en base a los resultados de estas pruebas se realiza el despliegue del sistema para dar

lugar al uso y mantenimiento de este.

En base a esta estructura se han desarrollado otras metodologías que aplicaron el concepto de

iteración, manteniendo este flujo de trabajo de forma constante a través de la aplicación de ciclos

iterativos, constantemente repitiendo el análisis, diseño, implementación prueba e

implementación del software. El mencionado Proceso Unificado es un claro ejemplo de esto, que

además rompe la secuencia de los pasos del proceso al proponer que se puedan realizar en forma

paralela, trabajando en base a hitos que distinguen los distintos pasos capturando el estado del

proceso de desarrollo.

3.8.10.3. Desarrollo ágil de software

El desarrollo de software en base a metodologías tradicionales y sus variaciones han sido

criticados por algunas características que afectan directamente a un proyecto. Es inherente en

todos los casos que la documentación debe ser creada de tal manera que contiene los outputs de

los diferentes pasos (por ejemplo, especificaciones escritas o en diagramas) que al mismo tiempo

son el input para los pasos siguientes. Sucede a menudo que no es necesario en proyectos de

software que no necesariamente un programa entero puede ser pre especificado por el cliente, ya

que sus demandas se adaptan a la maduración del proyecto.

Ilustración 64: Metodologías tradicionales de desarrollo de software.


154

Un nuevo enfoque fue el surgimiento del concepto de desarrollo ágil de software. Este nombre

fue dado por un grupo de figuras conocidas en la comunidad del desarrollo al publicar el

“Manifiesto para el desarrollo ágil de software” (109) que se basa en los siguientes valores:

Individuos e interacciones sobre procesos y herramientas.

Software funcionando sobre documentación comprensiva.

Colaboración de los clientes sobre negociación de contratos.

Responder al cambio sobre seguir un plan.

Podemos ver que los elementos de la derecha en cada frase son puntos fuertes de las

metodologías tradicionales. Sin embargo, el manifestó no descarta completamente a estos

valores, sino que también los considera pero siempre danto prioridad a los elementos de la

izquierda.

Además, el manifiesto indica el seguimiento de los siguientes principios:

Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.

Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.

Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.

Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.

Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.

La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.

El software que funciona es la principal medida del progreso. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,

desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida. La atención continua a la excelencia técnica enaltece la agilidad. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-

organizan. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su

conducta en consecuencia.

Los métodos agiles consisten de elementos individuales llamados practicas. Las prácticas incluyen

el uso de control de versiones, establecimiento de estándares de codificación y dar muestras de

avances a los interesados. Si bien la mayoría de las practicas han existido durante muchos años,

los métodos agiles realizan una combinación única de estas, acentuando las partes que dan

soporte a la filosofía ágil descartando al resto e integrando algunas ideas nuevas. El resultado es

un paquete poderoso, solido y auto reforzado.

3.8.10.4. Extreme Programming

Consecuentemente se han creado metodologías de desarrollo que intentan eludir los problemas

de las metodologías clásicas, tratando de ser más livianas en lo que es necesario generar al


155

comienzo y durante el desarrollo. Un ejemplo es Extreme Programming (XP) 53, que centra sus

valores alrededor de la simplicidad, la comunicación, retroalimentación y coraje con principios

relevantes.

Una de las más sorprendentes

premisas de XP es que es posible

eliminar fases de requerimientos,

diseño y prueba al igual que los

documentos formales que las

acompañan, aunque sin embargo no se

descartan los requerimientos, diseños y

pruebas ya que se trabaja sobre todas

estas cada día del proyecto. Esta

consigna resulta muy extraña debido a

que los desarrolladores de software

siempre han aplicado formas

tradicionales para el desarrollo, y si bien es algo complicado de aplicar es posible gracias a la base

de la colaboración cara a cara con el objetivo de eliminar demoras en la comunicación y

malentendidos de tal forma en que el equipo no necesita distinguir estas fases, por lo que es

posible trabajar en todas las actividades cada día con fases simultaneas.

Si bien este enfoque no implica que el equipo será más productivo, si da como consecuencia que

se recibirá retroalimentación de una manera mucho más frecuente. Como resultado de esto, el

equipo de desarrollo puede conectar rápidamente los éxitos y fracasos a sus causas. La cantidad

de trabajo sin probar es muy poca, por lo que el equipo puede corregir errores en el desarrollo

como ser cuando el código presenta algún error de diseño o cuando una opinión u acción de un

cliente demuestra que una interfaz es algo confusa.

Este apretado ciclo de retroalimentación también permite que equipos aplicando XP puedan

refinar sus planes rápidamente. Es mucho más sencillo que un cliente refina idea si puede dar su

opinión y obtener un prototipo funcionando en pocos días. Este mismo principio se aplica para la

prueba, diseño y políticas de equipo. Si surge algún defecto de diseño en la programación o la

prueba, es posible utilizar ese conocimiento cuando se analizan continuamente los

requerimientos y el diseño del sistema en las siguientes iteraciones.

Los equipos que aplican XP realizan prácticamente cada actividad del desarrollo de software de

manera simultánea: Análisis, diseño, codificación, prueba y despliegue ocurren con una rápida

frecuencia. Si bien es mucho para realizar de manera simultánea, XP logra esto al trabajar en

iteraciones cortas, como ser de una semana. En esta semana el equipo hace un poco de cada

actividad, focalizando su trabajo en “stories”: pequeños requerimientos o partes de

requerimientos que son considerados relevantes, tratando de abarcar por ejemplo entre cuatro y

diez de estas stories cada semana.

53

Podemos encontrar más información sobre metodologías agiles y Extreme Programming en el libro “The

Art of Agile Development” (145).

Ilustración 65: Metodología ágil de desarrollo de software.


156

A continuación podemos ver como las actividades tradicionales basadas en fases se corresponden

con una iteración de XP:

Planificación: Cada equipo de XP incluye varios expertos en el negocio (los clientes on-site)

que son responsables de tomar decisiones de negocios. Estos apuntan al proyecto en la

dirección correcta al clarificar la visión, crear historias, construyendo un plan de liberación del

proyecto y manejando riesgos. Los programadores proveen de estimaciones y sugerencias a

estos expertos, que son combinados con las prioridades de los clientes en un proceso llamado

“El juego de la planificación”. De esta forma y trabajando como esquipo pueden lograr

liberaciones pequeñas y frecuentes que maximizan el valor.

El esfuerzo de planificación es más intenso durante las primeras semanas del proyecto.

Durante las siguientes semanas los clientes continúan revisando y mejorando la visión y el

plan de liberación en base a nuevas oportunidades y eventos inesperados.

Además del plan general de liberación, el equipo crea un plan detallado para la siguiente

semana al comenzar cada iteración. Mediante reuniones diarias y un lugar de trabajo

compartido se mantiene a todo el equipo actualizado respecto al estado del proyecto.

Análisis: En lugar de utilizar una fase de análisis para definir requerimientos, los clientes on-

site trabajan a la par del resto del equipo todo el tiempo. Estos pueden o no ser clientes

reales dependiendo del tipo de proyecto, pero son los mejores calificados para determinar

que debería hacer el software.

Los clientes on-site son responsables de definir los requerimientos, y para hacerlo utilizan la

combinación de su conocimiento como clientes combinado con técnicas tradicionales de

recolección de requerimientos. Cuando los programadores necesitan información,

simplemente la preguntan. Los clientes son los responsables de organizar su trabajo de forma

tal de estar listos cuando los programadores pidan la información. Definen requerimientos

generales para las stories antes de que los programadores lo necesiten y los requerimientos

detallados antes de que los programadores los implementen.

Algunos requerimientos son complicados de entender, por lo que estos clientes deben

formalizarlos con la asistencia de probadores creando así “pruebas de clientes “o customer

tests: ejemplos detallados y ya probados. Los clientes y los probadores crean estos customer

tests para una story casi al mismo tiempo que los programadores implementan la story. Para

asistirlos en la comunicación, los programadores utilizan un lenguaje general en su código y

diseño.

El look and feel de la interfaz del usuario no se benefician de estas pruebas, sino que para

trabajar sobre las interfaces los clientes trabajan con el equipo para generar bocetos de las

pantallas de la aplicación. En algunos casos, trabajan junto a los programadores mientras

estos utilizan un software para la creación de las interfaces. Por último, algunos equipos

incluyen un diseñador de interacciones que es responsable de la interfaz de la aplicación.

Diseño y codificación: XP utiliza diseño y arquitectura incrementales para crear de manera

continua y mejorar el diseño en pasos pequeños. Este trabajo es manejado por un desarrollo


157

en base a pruebas o test-driven development (TDD), una actividad que combina pruebas,

programación, diseño y arquitectura. Para dar soporte a este proceso, los programadores

trabajan en pares, lo que incrementa la atención y creatividad para manejar cada tarea, y se

asegura que una persona en cada par tenga tiempo de pensar en cuestiones de diseño a

mayor escala.

Los programadores también son responsables de administrar su entorno de desarrollo. Ellos

usan un sistema de control de versión para configurar la administración. Integran sus códigos

en intervalos de horas y se aseguran de que cada integración es capaz de generar un

despliegue.

Para dar soporte a este esfuerzo, los programadores también siguen estándares de

programación y comparten la propiedad del código. El equipo mantiene una estética

compartida del código, y todos deben poder corregir problemas de código sin importar quien

haya sido el autor original.

Prueba: XP incluye un sofisticado conjunto de prácticas de prueba. Cada miembro del equipo

(programadores, clientes y probadores) realiza su propio aporte a la calidad del software.

Equipos que aplican XP de buena manera producen solo unos pocos bugs por mes en trabajos

completados.

Los programadores proveen la primera línea de defensa con TDD, que produce pruebas

automáticas de integración y unidad. En algunos casos, los programadores pueden crear

pruebas más completas o end-to-end, que ayudan a asegurar que el software hace lo que

ellos pretendían.

Igualmente, las pruebas de clientes ayudan a asegurar que los programadores puedan

alcanzar las expectativas de los clientes. Estos revisan el trabajo en el proceso para asegurar

que las interfaces funcionan de la forma en que ellos esperan, y generan ejemplos para los

programadores para reglas de negocio complicadas.

Finalmente, los probadores ayudan a que el equipo entienda si sus esfuerzos están

consiguiendo generar código de alta calidad. Utilizan pruebas exploratorias para buscar

sorpresas y errores en el software. Cuando encuentran un error, el equipo conduce un

análisis de raíz o root-analysis y considera como puede mejorar su proceso para prevenir bugs

similares en el futuro. Los probadores a su vez exploran las características no funcionales del

software, como ser la estabilidad y la performance. Los clientes usan esta información para

decidir si es necesario crear stories adicionales.

El equipo no realiza ninguna prueba manual de regresión. Las pruebas TDD y de clientes llevan

a un sofisticado conjunto de pruebas de regresión automáticas. Cuando se encuentran bugs,

los programadores generan pruebas automáticas que muestran que estos errores han sido

solucionados. Cada vez que los programadores integran (cada algunas horas) hacen correr el

conjunto de pruebas de regresión para comprobar si algo se ha roto en el cambio.


158

El equipo a su vez da soporte a sus esfuerzos de calidad a través de la programación de a

pares, trabajo energizado e iteraciones con holgura. Estas prácticas potencian las capacidades

que cada miembro del equipo posee para crear software de alta calidad.

Despliegue: Los equipos de XP mantienen su software listo para ser desplegado al final de

cada iteración. Realizan despliegues para interesados internos cada semana en preparación

para una demo de iteración semanal. El despliegue para clientes reales se organiza en base a

las necesidades del negocio.

Mientras el equipo se mantenga activo, provee de mantenimiento al software que ha

liberado. Dependiendo de la organización, el quipo puede también dar soporte a su propio

software y en otros casos se tiene un equipo separado para dar soporte a este. De forma

similar, cuando el proyecto finaliza el equipo puede dar las tareas de mantenimiento a otro

equipo. En este caso el equipo genera una documentación y provee el entrenamiento

necesario para el equipo entrante.

Practicas XP Planificación Análisis Diseño y codificación Prueba Despliegue

Thinking

Pair Programming ✓ ✓

Energized Work ✓ ✓ ✓ ✓ ✓

Informative Workspace ✓

Root-Cause Analysis ✓ ✓

Retrospectives ✓ ✓

Collaborating

Trust ✓ ✓ ✓ ✓ ✓

Sit Together ✓ ✓ ✓ ✓

Real Customer Involvement ✓

Ubiquitous Language ✓

Stand-Up Meetings ✓

Coding Standards ✓

Iteration Demo ✓

Reporting ✓ ✓ ✓ ✓ ✓

Releasing

“Done Done” ✓ ✓

No Bugs ✓ ✓

Version Control ✓

Ten-Minute Build ✓ ✓

Continuous Integration ✓ ✓

CollectiveCode Ownership ✓

Documentation ✓

Planning

Vision ✓ ✓

Release Planning ✓ ✓

The Planning Game ✓ ✓


159

Risk Management ✓

Iteration Planning ✓

Slack ✓ ✓

Stories ✓ ✓ ✓

Estimating ✓

Developing

Incremental Requirements ✓ ✓

Customer Tests ✓ ✓

Test-Driven Development ✓ ✓

Refactoring ✓

Simple Design ✓

Incremental Design and Architecture

✓

Spike Solutions ✓

Performance Optimization ✓

Exploratory Testing ✓

Tabla 9: Practicas y etapas de Extreme Programing

Esta breve introducción nos da una idea de cómo se desarrolla un proyecto de software en base a

la metodología ágil XP. Sin embargo, como toda metodología innovadora es complicada de

implementar, siendo que su funcionamiento depende enteramente del equipo que la lleve a cabo,

por lo que para su aplicación se realizan sesiones de entrenamiento y adaptación, realizando

consideraciones sobre el equipo como un todo y sus actores como individuos: clientes on-site,

administrador general, expertos en el negocio, diseñadores de interacción, analistas del negocio,

programadores, diseñadores y arquitectos, técnicos especialistas, probadores, entrenadores entre

otros.

Es un proceso complejo que bien aplicado puede alcanzar su mayor objetivo, que es la simpleza.

Claramente no es una metodología que se pueda aplicar para todo tipo de proyecto, sino que se

adecua mejor a determinadas situaciones, características y equipos de personas, pero

definitivamente como hemos comprobado en base al análisis de los patrones de diseño Web 2.0

este tipo de metodología bien aplicada es la base para el desarrollo de software Web 2.0.

3.8.11. El desarrollo Web

En el libro “Web Engineering: The Discipline of Systematic Development of Web Applications”

(110) se muestra como diferentes tipos de metodologías incluyendo las tradicionales pueden ser

aplicadas al caso especial del desarrollo Web. Podemos decir que las RIAs son solo un caso

especial de las aplicaciones web, y por tanto metodologías y sus modelos como ser diagramas de

casos de uso, diagramas de clases e interacciones y otros pueden ser aplicados, aunque existe

también una fuerte tendencia a la aplicación de modelos agiles debido a sus características.

La aplicación de metodologías agiles se convierte en una necesidad en los proyectos Web 2.0, ya

que permiten aprovechar los patrones de diseño y generar ventajas competitivas debido a la

velocidad de reacción y adaptación a las necesidades de los usuarios a la hora de crear un

proyecto.


160

En este punto debemos hacer referencia a dos patrones de diseño Web 2.0: beta perpetuo y

Modelos ligeros y escalabilidad costo-efectiva y. Podemos ver que las prácticas de estos patrones

se ajustan a lo planteado por el manifiesto del desarrollo ágil de software en general.

Si tomamos algunas de las prácticas del patrón beta perpetuo como ser “liberar temprano y

rápido”, “hacer participar a los usuarios como co-desarrolladores y probadores en tiempo real” e

“instrumentar los productos” podemos ve como claramente apuntan al valor de “colaboración de

los clientes” planteada por el manifiesto.

En el caso de la mayoría de los proyectos Web 2.0, inicialmente no existe una base de usuarios al

comienzo, por lo que la implementación de este valor tiene conlleva algunas consideraciones. Las

prácticas mencionadas funcionan juntas para generar una base de clientes que utilicen el

producto. Los clientes subsecuentemente dan retroalimentación sobre el servicio permitiendo

que los desarrolladores mejoren el producto, en forma de comentarios y como hemos

mencionamos antes en base al uso real de los usuarios del sistema en base a monitorear sus

acciones.

En base a esta información se genera un “datawarehouse de las acciones de los usuarios” que

puede ser explotado en futuros desarrollos. Uno de los ejemplos que hemos mencionado ya es el

caso de Flickr, con su generación ágil de nuevas versiones de su servicio.

La implementación de este patrón guía el desarrollo de nuevas características, pero al mismo

tiempo evita el desarrollo de funcionalidades que no son necesarias que quitan velocidad para

entrar al mercado y pueden incrementar el riesgo de fracaso. Aquí es donde notamos que puede

existir una contradicción entre este concepto de “no sobre-desarrollar” y la aplicación de

metodologías tradicionales, ya que estas buscan definir los requerimientos desde un primero

momento y pueden no tener la habilidad para adaptarse a cambios, y generar esfuerzos

innecesarios al detectar las nuevas necesidades tarde. Es importante aclarar que la prevención de

este sobre-desarrollo no debe atentar a la creatividad, ya que esta es la base de los proyectos y

empresas Web 2.0 en general.

El segundo patrón mencionado “Modelos ligeros y escalabilidad costo-efectiva” se relaciona

claramente al valor de “responder al cambio”. Algunas de las mejores prácticas que analizamos en

este caso son “escalar en base a la demanda”, “escalar los modelos de precios e ingresos” y

“sindicar los modelos de negocio”. Las prácticas de este patrón apuntan al cambio: cambio en la

demanda del propio servicio, cambio en las posibilidades de sacar rédito económico a un servicio,

y cambio en el ensamblaje del servicio a través del uso de la sindicación de contenidos y APIs.

La ultima practica mencionada es una clara representante de los modelos ligueros, al tercerizar

los servicios cuando es práctico y por tanto basarse en los modelos de negocios ya probados para

maximizar las posibilidades de aprovechar la idea de negocio del proyecto.

Podemos reconocer que en el caso del desarrollo de software para Internet en el contexto de

proyectos con forma Web 2.0 las metodologías y modelos tradicionales en general traen una

sobrecarga de trabajo innecesario que quita velocidad y adaptabilidad al proceso y que por tanto

los métodos agiles parecen aplicarse de mejor forma.


161

3.8.11.2. Model-Driven Web Engineering con UWE UML

La ingeniería Web basada en UML (UWE)54 surgió a finales de los 90s con la idea de encontrar una

forma estandarizada de construir modelos de análisis y diseño de sistemas Web en base a los

métodos ya existentes en esa época, con el objetivo de utilizar un lenguaje común o al menos

definir un mapeos basados en meta-modelos entre los lenguajes existentes. El Unified Modeling

Languague (UML) era al parecer el lenguaje a ser elegido por su amplio uso como lenguaje base

para modelos orientados a objetos.

Una de las características de UML es que provee un conjunto de ayudas para la definición de

lenguajes para modelados de dominios específicos (DSL), a modo de mecanismos de expansión.

En base a dichos mecanismos se genera UWE principalmente como una expansión de UML,

aunque también es compatible con otras metodologías y lenguajes.

El desarrollo de UWE es continuado hoy en día en búsqueda de asimilar nuevas capacidades de

las aplicaciones Web, como ser transacciones, personalizaciones y aplicaciones asincrónicas.

Sucede que el desarrollo de sistemas Web está en constante cambio como es notable en el

desarrollo teórico de Web 2.0.

UWE está dirigido por la separación de modelos de distintos asuntos describiendo las diferentes

etapas de ingeniería de requerimientos, análisis, diseño e implementación del proceso de

desarrollo con el objetivo de obtener diferentes vistas de la misma aplicación Web

correspondientes a dichas etapas o asuntos. El modelo de contenidos es utilidad para especificar

los conceptos que son relevantes al dominio de la aplicación y las relaciones entre dichos

conceptos. La estructura de navegación es modelada de manera separada del contenido (aunque

claramente se deriva de este último) y representa los diversos caminos de navegación del sistema.

El modelo de presentación apunta a mostrar la representación y los aspectos de comunicación

usuario-maquina mediante un esbozo de las interfaces.

UWE propone al menos un tipo de diagrama UML para la visualización de dichos modelos

buscando representar los aspectos estructurales de las diversas vistas. A su vez se utilizan

frecuentemente diagramas de interacción o de estado para representar aspectos de

comportamiento del sistema Web. Podemos decir que se realiza una separación considerando

etapas de desarrollo, vistas del sistema y aspectos como ser la estructura y el comportamiento.

Este tipo de separación provee ventajas a la hora de realizar mantenimientos y reingenierías de

sistemas web, y también en la generación de sistemas Web para distintos contextos y

plataformas.

El enfoque del desarrollo dirigido por modelos (MDD) no solo indica el uso de modelos para el

desarrollo, sino que también enfatiza en la necesidad de transformaciones en todas las fases del

desarrollo. Dichas transformaciones proveen una cadena que permite la implementación

automatizada de un sistema en pasos sucesivos desde los diferentes modelos. El desarrollo de

sistemas Web es un campo que se presta para la aplicación de MDD.

54

Podemos encontrar más información sobre UWE UML en http://uwe.pst.ifi.lmu.de/index.html

http://uwe.pst.ifi.lmu.de/index.html


162

Podemos encontrar una ampliación a esta introducción en el capítulo 7 del libro “Web

Engineering: Modelling and Implementing Web Applications” (111).

A continuación se realiza un breve desarrollo teórico para lograr acercarnos a los aspectos

prácticos del modelado mediante UWE en base a presentaciones realizadas por los autores de

UWE (112) y ejemplos que pueden ser encontrados en el sitio oficial de UWE (113). Se

presuponen conocimientos básicos de UML, ya que tiene el objetivo de ampliar dichos

conocimientos agregando el perfil propuesto por UWE, sin profundizar en el tema de base.

3.8.11.3. Ejemplo de modelado de análisis y diseño en UWE UML

El primer paso hacia el desarrollo de un sistema Web es la identificación de los requerimientos de

una aplicación, y estos pueden ser especificados en UWE mediante un modelo de requerimientos

contando con los actores del sistema, y una descripción a manera de esbozo de las

funcionalidades como parte de los requerimientos.

Posteriormente se realiza el análisis de tales requerimientos mediante el uso de:

Casos de uso y sus descripciones.

Diagrama de casos de uso.

Análisis de flujos mediante diagramas de actividades para la especificación de los

requerimientos funcionales (opcional en caso de considerarse necesario).

Por otra parte para los desarrollo del diseño se propone el uso de:

modelos de contenido para los aspectos de información.

modelos de navegación para la estructura de hipertextos y funcionalidades de

navegación.

modelos de presentación para el esquema de presentación

Modelos de proceso y diagramas de proceso para las funcionalidades.

Desarrollamos ahora una explicación sobre estos modelos y herramientas UML, acompañando

dicho desarrollo con un ejemplo práctico: Una agenda de contactos con actualizaciones de

contenidos55. A pesar de ser un caso muy sencillo el portal planteado nos servirá para ver con más

claridad lo propuesto por UWE UML. Ya que el objetivo es mostrar los diferentes modelos de UWE

IML, no incluimos la totalidad del modelo, sino que desarrollamos al menos un ejemplo de cada

diagrama. El modelo completo puede ser observado en la referencia mencionada.

En este caso se define como actor genérico al usuario de Internet que accede al sitio, bajo el

nombre de “user”. A modo de esbozo de requerimientos, el portal constará con las siguientes

características:

Cada contacto tiene un nombre, dos números de teléfono, dos direcciones, y un correo

electrónico.

El usuario puede agregar, actualizar o borrar contactos.

55

Es una adaptación de http://uwe.pst.ifi.lmu.de/exampleAddressBookWithContentUpdates.html

http://uwe.pst.ifi.lmu.de/exampleAddressBookWithContentUpdates.html


163

Después de la creación exitosa de un contacto, este debe ser mostrado.

En caso de error, debe mostrarse un mensaje indicándolo.

Es posible realizar búsquedas de contactos.

Se realiza una visualización grafica mediante el uso de diagramas de caso de uso de UML para

modelar las funcionalidades requeridas. Adicionalmente se pude agregar un listado de los casos

de uso y una descripción de cada uno con el nivel de detalle que sea necesario para el proyecto.

Ilustración 66: Diagrama de Casos de Uso del ejemplo de UWE UML.

Modelo de Contenidos

Se utiliza el modelo de contenidos en base a un modelo de dominio de UML utilizando un

diagrama de clases sin necesidad de aplicar semánticas adicionales, con el objetivo de

representar los requerimientos de datos del sistema propuesto, modelando los datos

persistentes.

Ilustración 67: Modelo de Contenidos del ejemplo de UWE UML.


164

Modelo de Navegación

El modelo de navegación tiene como objetivo representar nodos y vínculos de la estructura de

hipertextos, diseñar los caminos de navegación y evitar desorientación y cognitive overload. Este

modelo es representado mediante el uso de diagramas de clase UML, utilizando semánticas

adicionales para modelar elementos del contexto Web.

Por una parte el modelo de navegación representa la estructura de información estática de una

aplicación Web accesible a un usuario, especificando las funcionalidades de navegación a través

de los siguientes estereotipos.

<<navigationClass> especifica un nodo de hipertexto visitado por un usuario a través de

la navegación, y está relacionado a una clase de contenido.

<<navigationLink>> especifica un hipervínculo o link utilizado para acceder a un objeto de

navegación objetivo desde el objeto de navegación origen.

Los nodos de estereotipo <<navigationClass>> cuentan con otros adicionales semánticos

utilizados con el objetivo de modelar la estructura de navegación de forma más completa y clara:

<<index>> para indicar los vínculos de navegación que tienen una multiplicidad mayor a 1

en la asociación direccionada

<<menú>> para todas las clases de navegación que tienen más de una asociación de

salida. Los menús son utilizados para estructurar los vínculos salientes de un nodo,

generalmente asociados a una clase de navegación mediante composición, consistiendo

en un grupo de vínculos a elementos heterogéneos como ser index, queries, instancias de

clases de navegación u otros menús.

<< query>> para la selección de instancias de una clase de navegación.

{isHome} como una etiqueta en una determinada clase de navegación para indicar el

nodo inicial de una aplicación.

{isLandmark} como una etiqueta en una determinada clase de navegación para indicar

que el nodo es alcanzable desde cualquier lugar en la aplicación, y que por tanto todos los

otros nodos contienen un vinculo a dicho nodo.

Por otra parte, es necesario también considerar por tanto el modelo de procesos, que

representara los aspectos dinámicos de una aplicación Web, especificando funcionalidades como

ser transacciones y otras actividades. Es necesaria entonces la definición de clases de proceso e

integración de dichas clases de proceso en el modelo de navegación de nodos

<<navigationClass>>, para lo cual se utilizan los siguientes agregados semánticos:

<<processClass>> representa un proceso a través del cual un usuario será guiado. En

casos de procesos complejos es posible realizar un modelo de procesos adicional.

<<processLink>> es utilizado para modelar la asociación entre un nodo de estereotipo

<<navigationClass>> y un nodo de estereotipo <<processClass>>.


165

Ilustración 68: Modelo de navegación del ejemplo de UWE UML.

Modelo de Estructura de Procesos y Flujo de Procesos

El modelo de estructura de procesos contiene un grupo de clases de procesos que describen a los

procesos correspondientes, mencionados previamente en el modelo de navegación. Estos

apuntan a mostrar mayormente la funcionalidad de los procesos necesarios.

Ilustración 69: Modelo de Estructura de Procesos del ejemplo de UWE UML.


166

Con el objetivo de definir el comportamiento de un proceso en particular se utilizan además

diagramas de actividades UML asociados a una <<processClass>> del modelo de navegación,

posiblemente en base al refinamiento de diagramas de actividades utilizados para modelar las

especificaciones de requerimientos, pudiéndose utilizar opcionalmente diagramas de actividad

anidados.

El flujo de un proceso consiste de la representación mediante nodos de actividad conectado

mediante vínculos de actividad, nodos de control que proveen el control del flujo como ser

decisiones y sincronizaciones y nodos objeto que representan el flujo de datos a través del flujo

de actividades

Ilustración 70: Ejemplo de Flujo de Procesos del ejemplo de UWE UML.


167

Modelo de Presentación

Este modelo funciona como alternativa a la clásica construcción de prototipos, y tiene como

objetivo la representación abstracta del la distribución de elementos de interfaz para la los

modelos de navegación y procesos desarrollados previamente. Decimos que es una

representación abstracta en el sentido de que una representación concreta definiría a su vez

detalles como colores, tamaños, y otros detalles definitivos de una interfaz, los cuales no se

incluyen en este modelo para lograr una mayor claridad de diseño.

Se utiliza un diagrama de clases UML para estructurar la presentación, utilizando notaciones de

contenedores UML, contando con el uso de diagramas de secuencia o interacción UML para

modelar el comportamiento de las clases de presentación.

Podemos considerar los siguientes elementos semánticos agregados al modelo de clases:

<<presentationClass>> son estereotipos estructurales utilizados para representar páginas

Web o porciones de páginas Web, contando con una composición jerárquica de

elementos de interfaz de usuario

<<presentationGroup>> es otro elemento estructural de presentación, y este estereotipo

contiene un grupo de elementos <<presentacionClass>>.

<<presentacionPage>> es el elemento de presentación de mayor jerarquía, indicando una

ventana de un navegador y por tanto conteniendo diversos <<presetationClass>> y

<<presentationGroup>>.

Como dijimos, estos estereotipos sirven para agrupar elementos de interface de usuario.

Podemos mencionar los siguientes:

<<anchor>>

<<button>>

<<text>>

<<image>>

<<texinput>>

<<selection>>

<<form>>

Etc.


168

Ilustración 71: Modelo de Presentación del ejemplo de UWE UML.

Como podemos ver UWE provee una solida y flexible expansión para el modelado UML de un

sistema Web, permitiendo capturar en diversos grados de detalle los modelos de análisis y diseño.


169

3.8.11.4. Plataformas y librerías de desarrollo de cliente y servidor

Si bien hemos analizado y comprendido algunas de las tecnologías y estándares que son pilares

del desarrollo de software para Internet (como ser HTML, XML, CSS, scripting de servidor y

scripting de cliente, Web services, Web feeds, y Ajax), es importante reconocer que el desarrollo

de proyectos no se realiza de la manera en que hemos analizado los ejemplos, sino que se

agregan niveles de abstracción en cada caso generalmente mediante la utilización de librerías y

plataformas de desarrollo, ya que en caso de proyectos de complejidad considerable sería muy

difícil generar resultados que mantengan la simpleza.

En este marco teórico no se profundiza sobre estos, sino que se hace un breve recorrido por

algunas de las opciones que el mercado propone. Existe una gran cantidad de plataformas y

librerías que apuntan tanto a trabajar sobre el cliente como sobre el servidor, e incluso hay

muchas que cubren ambas partes, apuntando a aprovechar los diversos lenguajes de

programación para la generación de sitios dinámicos.

2Por ejemplo existe una gran cantidad de plataformas que pueden ser consideradas a la hora de

aplicar Ajax para el desarrollo. En el libro “Ajax Design Patterns” (114) donde el autor cubre

diversos patrones de tecnologías de base, programación, funcionalidad, usabilidad y desarrollo

para diseñar aplicaciones con Ajax, indica que “una explosión de librerías y plataformas ha sido

una de las afortunadas consecuencias del fenómeno Ajax. Estas se presentan en todos los

tamaños, formas y licencias. A través del análisis de patrones de Ajax se enfatiza la importancia de

la utilización de librerías y plataformas conociendo los detalles de bajo nivel pero sin necesidad de

implementar todo desde 0”. El autor de este libro presenta un listado de estas en el libro y a su

vez lo mantiene actualizado su sitio web (115) en base a una wiki.

Estos manejan diversas necesidades, como ser la comunicación de red incluyendo el

XMLHttpRequest, los efectos visuales, integraciones con otras tecnologías y XML. Las plataformas

apuntadas a servidor cubren lenguajes como ser C++, Coldfusion, .net, Java, Lisp, Perl, PHP, Pyton

y Ruby. Algunos de los proyectos más grandes cubren muchos de estos elementos, permitiendo

así que los programadores puedan depender de estos y trabajar más en la aplicación del modelo

de negocio.

Podemos mencionar el caso de Script.aculo.us56, una plataforma con excelentes capacidades

visuales basado en la librería Javascript Prototype57 que originalmente surgió de la mano de Ruby

on Rails58, otra plataforma de Ajax muy utilizada. También está el caso de la librería Zend para

PHP, que es utilizada fuertemente para el desarrollo de las APIs de los diversos productos de

Google en base a su clase Gdata59.

56 Más información sobre Script.aculo.us en http://script.aculo.us.

57 Más información sobre Prototype en http:// prototype.conio.net.

58 Más información sobre Ruby on Rails en http://www.rubyonrails.org/.

59 Más información sobre Zend y Gdata en http://framework.zend.com/download/gdata.


170

Por otra parte, es importante reconocer que no todo desarrollo Web 2.0 de RIAs se basa en la

aplicación de Ajax, ya que una porción del mercado es manejado al ya mencionado Flash de

Adobe, existiendo también plataformas para trabajar con este en el desarrollo de aplicaciones,

como ser el caso de OpenLazlo60, que incluso a partir de su versión 4 también da soporte Ajax.

Incluimos a continuación un breve listado con algunas las opciones disponibles presentadas en el

libro mencionado (y podemos encontrar otro listado de plataformas para proyectos web en la

Wikipedia (116)). Recordamos que no profundizaremos en el desarrollo en base a estas para

acotar el alcance del marco teórico, pero podemos mencionar que existen en internet diversas

comunidades y fuentes de información donde es posible indagar sobre cada una de las

plataformas y librerías mencionadas:

Grupo Plataformas / librerías Javascript Multipurpose Prototype , AjaxFace , Bindows , DOJO, Framework for RESTful JavaScript,

Mochikit, OpenRico, Script.aculo.us, Zimbra AjaxTK.

Javascript Remoting Ajax Toolbox, AjaxCaller, Juice Lib, LibXMLHttpRequest, UniAjax, Dervish, AjaxGear, vcXMLRPC, AJFORM.

Javascript Graphics and Effects

Script.aculo.us, Bitjuice, InfiView, Open-jACOB Draw2D, Interface, Run Universal JavaScript Animation Framework.

Javascript Flash AMFPHP, Flash JavaScript Integration Kit, Stream.

Javascript Logging log4javascript, JSLog, Lumberjack, Log4Js, jsTracer, fvlogger.

Javascript XML Google AJAXSLT, Sarissa.

Javascript Json JSON classic ASP Utilities, JSONER, JKL.ParseXML.

Javascript Specialised InfiView, CAPXOUS, GSV, Drag-Drop.

C++ Ajax Wt.

Coldfusion Ajax AjaxCFC, JSMX, mxAjax.

.Net Ajax Atlas, Bitkraft, MonoRail, ajaxed, Ajaxium, FastPage , JSON ASP, Visual WebGUI, zumiPage, ComfortASP.NET

Java Ajax AjaxAnywhere, Apache Struts 2, BACKBASE, BindowsFaces, SweetDEV, ADF Faces, AJAX JSP Tag Library, BZByte EZAjax Echo 2, Flexjson, Guise, Google Web Toolkit, IBM JSF Widget Library, Jaxcent, ItsNat, Light Portal, Java2Script Pacemaker, jMaki, Jayjax, ZK, Restlet, IFW2.

Lisp Ajax SymbolicWeb, CL-Ajax.

Multi-Language Ajax ZKAjax/XUL Web Framework, SAJAX, Rialto, JSRS, CPAINT.

Perl Ajax CGI::Ajax, HTML::Prototype.

PHP Ajax AjaxAc, AJASON, AjaxCore, NanoAjax, Simplicity PHP Framework, Zend, SimpleJax, Sybrain, PHPWebBuilder, phpAjaxTags, CrossBrowserAjax.

Python Ajax Django, Turbo Gears, Nevow, Pyjamas, Web2Py, Porcupine.

Ruby Ajax Ruby On Rails

Smalltalk Ajax Aida/Web, Seaside.

Tcl Ajax Aejaks. Tabla 10: Plataformas y librerías de Ajax y Javascript.

3.8.11.5. Proyectos existentes como base.

Existen distintas aplicaciones que ya han alcanzado un alto nivel de desarrollo y que son las bases

de muchos sitios Web 2.0 muy populares, siendo una clara opción al momento de encarar el

desarrollo de un sitio Web 2.0.

60

Más información sobre OpenLazlo en http://www.openlaszlo.org/


171

Por ejemplo en el momento de generar un blog, si se quisiera construir una aplicación desde cero

utilizando incluso excelentes prácticas de software, estándares y metodologías sería muy costoso

y complicado llegar a construir un software como es el caso del mencionado Wordpress. A su vez,

algunas de estas aplicaciones pueden ser modificadas ya que en su mayoría son de código abierto,

a demás de contar con APIs y posibilidades de generar plugins en base a ciertos estándares que

plantean (es decir, son en sí plataformas).

A su vez existe el caso de los gestores de contenidos o Content Management Systems (CMS) que

si bien originalmente pueden entrar en una clasificación solo de publicación, las versiones

actuales de los más populares poseen ciertas características que los hacen en cierta forma Web

2.0, como la posibilidad de realizar comentarios sobre artículos.

Si extendernos demasiado en estos para acotar el alcance del marco teórico, podemos mencionar

algunos de los casos más llamativos y utilizados en algunos de los grupos de social media

analizados anteriormente.

Bologs: Wordpress, Blogger.

Foros: phpBB, vBulettin.

Wikis: MediaWiki, TikiWiki, PhpWiki.

CMS: Drupal, Joomla.

Podemos decir que en los social media a los que pertenecen estos proyectos el software de base

ha pasado a ser de tipo commodity, siendo más importante preocuparse por el modelo de

negocio, los contenidos y presentación de estos. En el caso de otros social media como ser

microboggin, comunidades de contenidos y redes sociales se presentan casos de programación

demasiado específicos debido a modelos de negocio innovadores que no son posibles de

generalizar, como ser los casos de Facebook, Flickr y Youtube. Pero a su vez en estos últimos

social media mencionados, se da la posibilidad de su uso a través de sus APIs utilizando las

fortalezas de sus servicios como base para modelos de negocio propios como hemos analizado

previamente en los patrones de diseño Web 2.0

Por tanto, es también una opción el utilizar como base un proyecto de software existente y

desarrollarlo una solución Web 2.0 en base a este, ya sea utilizándolo de la forma genérica, o

reutilizando su código y arquitectura para generar nuevos proyectos.


172

3.9. Conclusión

Es posible considerar que el desarrollo efectuado en el presente marco teórico logra abarcar los

siguientes objetivos específicos:





implementación.


proyectos Web 2.0.

El desarrollo del marco teórico ha sido un proceso largo pero sumamente interesante. Llega

entonces el momento de aplicar el conocimiento obtenido para desarrollar el modelo teórico del

proyecto.

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Modelo Teórico

173

4. Modelo teórico

4.1. Introducción

En base al desarrollo del marco teórico hemos logrado comprender los elementos que componen

al concepto ambiguo de Web 2.0, entendiendo sus formas y tecnologías. Buscando alcanzar el

objetivo del trabajo final de grado buscaremos ahora generar un modelo teórico que permita

generar un impacto en el contexto de “criticas de productos”, siendo la base para la

implementación de un sitio web que genere un espacio de diálogo entre consumidores y

empresas.

En esta sección buscaremos cumplimentar los siguientes objetivos específicos:






Desarrollamos entonces un modelo teórico en busca de la solución de la solución del problema

planteado. De acuerdo a lo indicado en el campo de acción, desarrollaremos dicho modelo en

base a los siguientes patrones de diseño:






Aunque como se vio en el marco teórico, todos los patrones de diseño están interrelacionados y

por tanto, si bien no se hará un fuerte enfoque en los patrones que quedan fuera del alcance, sí se

los mencionara o se hará referencia a estos.


174

4.2. Planificación

Las actividades que se consideran a continuación serán realizadas por el autor del trabajo, no

siendo necesaria por tanto una división de tareas.

4.2.1. Etapas, actividades y duración.

Etapa Actividad Duración

Introducción Definición de la situación problemática 1 día

Definición del problema 1 día

Declaración de objeto de estudio y campo de acción 1 día

Definición de objetivos 1 día

Definición de alcance y limites 1 día

Descripción de aporte teórico y practico 1 día

Descripción de metodología 1 día

Marco contextual Descripción del entorno de objeto de estudio 1 día

Definición de la relación entre tesista y el objeto de estudio 1 día

Descripción de análisis de problemas observados 1 día

Marco teórico Investigación y desarrollo del marco teórico 82 días

Desarrollo del diagnostico 6 días

Modelo teórico Planificación 3 días

Requerimientos -

Definición de actores de negocio 1 día

Análisis de necesidades genéricas del negocio 1 día

Definición de actores de sistema 1 día

Aplicación de patrones de diseño Web 2.0 10 días

Identificación de requerimientos 4 días

Análisis del sistema -

Desarrollo de casos de uso 3 días

Desarrollo de diagrama de casos de uso 2 días

Diseño del sistema -

Desarrollo de modelo de contenidos 3 días

Desarrollo de modelo de navegación 6 días

Desarrollo de modelo de presentación 10 días

Desarrollo de modelo de procesos 10 días

Consideraciones adicionales 2 días

Concreción del modelo

Implementación del prototipo -

Adaptaciñon de phpBB y AjaxCORE 14 días

Adaptación de APIs YouTube y Picasa 6 días

Generación de interfaces web 15 días

Revisión del sistema 8 días

Descripción de puesta en marcha 6 días

Revisión Revisión de la documentación 14 días

Redacción de conclusiones 2 días

Corrección final de la documentación 9 días

Tabla 11: Etapas, actividades y duración del proyecto.


175

4.2.2. Diagrama Gantt

Ilustración 72: Diagrama Gant del Proyecto.


176

4.3. Requerimientos

4.3.1. Definición de actores de negocio

En base a lo planteado en el caso hipotético considerado en la introducción y en los posteriores

análisis sobre los usuarios de internet como consumidores y las empresas en el marco teórico de

este trabajo, podemos definir como actores de negocio a los usuarios de Internet, que pueden

estar cumpliendo el rol de consumidores o de empresa.

En el primer caso trataremos de forma genérica al grupo de usuarios que podría considerarse

como consumidores, teniendo en mente que dicho grupo plantea una enorme heterogeneidad si

consideramos diferentes grupos de edades, capacidades económicas, lugares de residencia, y

otros factores de segmentación.

Respecto al segundo grupo, es claro que hablamos de un conjunto mucho mas segmentado pero

que mantiene la característica de heterogeneidad si consideramos por un lado el abanico de tipos

de empresas existentes de variados rubros y mercados, y por otro lado y con un enfoque en el

interior de las empresas, los diferentes roles que posiblemente se relacionan con la imagen de la

empresa, la atención a los clientes, los desarrollos de productos o servicios, las estrategias de

mercadeo u otros de los posibles puntos en los cual el contacto con Internet resulta valioso, pero

para simplificar el análisis hablaremos de la empresa como una caja negra, sin identificar áreas o

roles.

Si aplicaremos una limitación geográfica a ambos grupos, acotando el alcance solo a usuarios de

Internet argentinos, debido a que el proyecto apunta a crear una solución solo a nivel país y no

una global. Por tanto, tenemos a grandes rasgos dos actores identificables que se relacionaran

con el proyecto

Clientes

Empresas

4.3.2. Necesidades genéricas detectadas en los actores de negocio

Clientes:

Realizar observaciones o reclamos respecto a empresas (y sus productos y servicios) de

las cuales han recibido un servicio defectuoso y no han obtenido una respuesta

satisfactoria ante el reclamo directo.

Tener la posibilidad de llegar a oídos de dichas empresas con sus reclamos mediante

mensajes persistentes en el tiempo en un espacio neutral que permita la opinión libre.

Poder valerse de información de otros consumidores para aportar a sus procesos de toma

de descripción frente a consumir determinados productos o servicios.

Encontrar y vincularse con otros consumidores que presenten problemas similares para

compartir opiniones y colaborar para llegar a posibles soluciones.

Estar atentos a posibles fallas en productos o servicios que ya posean, aunque no hayan

presentado problemas aun.


177

Empresas:

Obtener un nuevo canal de comunicación con sus clientes y posibles clientes, donde

fortalecer su relación con estos.

Realizar un seguimiento de la opinión de la gente sobre sus productos o servicios.

4.3.3. Definición de los actores de sistema

Si bien para el desarrollo del modelo de negocio y el análisis de necesidades es necesario separar

empresas y consumidores, al considerar el uso del sitio inicialmente solo se consideraran los

usuarios de internet de manera genérica, pudiendo separarse principalmente los usuarios que

están registrados en el sistema y los que no. El comportamiento de empresas y consumidores

indica las mismas necesidades genéricas, ya que se consideran mayormente la carga de

contenidos y la consulta de estos.

Por tanto, no se realizara una distinción inicial de empresas y consumidores. En etapas futuras del

desarrollo del proyecto podrían buscarse funcionalidades específicas para cada grupo.

Utilizaremos la distinción entre usuario y usuario registrado para describir las funcionalidades del

sistema.

4.3.4. Aplicación de los patrones de diseño al contexto del proyecto.

Con las necesidades genéricas que hemos considerado y lo analizado en el marco teórico en

mente, recorreremos los patrones de diseño y las practicas recomendadas en busca de los

requerimientos que el sistema deberá cumplir.

Recordamos que según lo definido en el alcance del proyecto, buscaremos aplicar los siguientes

patrones y prácticas, planteando cada uno de estos puntos sobre el contexto del problema que

analiza este trabajo.


178

Patrón Practicas

Aprovechar la

inteligencia colectiva. Pagar al usuario primero. Activar los efectos de red por defecto.



Confiar en los usuarios.

Diseñar software que es mejor a medida que más gente lo usa. Facilitar la emergencia de los contenidos

Los datos son el próximo

"Intel Inside”. Buscar poseer fuentes de datos únicas y difíciles de recrear. Mejorar los datos básicos.

Los usuarios controlan sus propios datos.

Algunos derechos reservados, no todos.

Definir una estrategia de pila de datos. Ser dueño del índice o del formato.

Diseñar los datos para su reutilización.

Tercerizar o proveer administración al acceso de datos.

Innovación en el

ensamblaje. Ofrecer APIs de los servicios.

Diseñar para la reutilización. Aplicar las mejores prácticas en APIs.

Usar los estándares existentes.



Ser cliente de su propia plataforma. Direccionamiento granular de contenidos.



Experiencias de usuario

ricas. Combinar lo mejor de las experiencias de escritorio y online.

Usabilidad y simplicidad primero. Alcanzar los requerimientos de los usuarios.

Priorizar la búsqueda sobre la estructura.

Mantener el direccionamiento de los contenidos.


Aprovechar la larga

cola. Construir en base a las fortalezas de la larga cola. Usar administración de datos algorítmica para que oferta y demanda se igualen.


Aprovechar el auto servicio de los clientes para alcanzar toda la red de manera costo-efectiva.


Tabla 12: Patrones y prácticas de diseño que seran aplicados en el proyecto.

4.3.4.1. Aprovechar la inteligencia colectiva

Crear una arquitectura de participación que use los efectos de red y algoritmos para producir

software que mejore a medida que más gente lo utilice.

Pagar al usuario primero:

Sera necesario generar una interfaz de sistema que permita al usuario desenvolverse de

manera intuitiva, permitiendo al usuario alcanzar objetivos de segundo orden, pero sin que

estos dificulten los pasos para alcanzar los objetivos de primer orden. Podemos agruparlos a

groso modo mencionando algunos de la siguiente manera:

Primer orden: cargar un reclamo sobre una empresa o producto en particular, encontrar

reclamos sobre una empresa o producto en particular, recibir actualizaciones sobre los

reclamos de interés.


179

Segundo orden: participar en una comunidad de consumidores, opinar sobre los reclamos de

otros miembros, comunicarse con otros miembros.

Activar los efectos de red por defecto.

Sera necesario perseguir funcionalidades que faciliten y promuevan la cooperación y

participación de los usuarios. Se debe permitir que los usuarios puedan aportar a los reclamos

de otros usuarios, potenciándose así la información de base aprovechando los efectos de re.

Sera importante que por defecto toda información de reclamos sea pública, no siendo

necesario estar registrado para obtener beneficios del sistema en la mayoría de los casos.

Esto es necesario debido a la tendencia de bajo porcentaje de usuarios de una comunidad que

aporta contenidos. Sera importante sacar provecho de la tendencia por parte de los usuarios

a aceptar las opciones por defecto.


El aprovechamiento de las participaciones explicitas e implícitas de los usuarios debe ser

perseguido para potenciar la generación de contenidos, la mejora de contenidos, las

posibilidades de navegación y por tanto el éxito del sistema. Podemos considerar lo

siguiente:

Aprovechamiento de participaciones explicitas: la generación de un nuevo reclamo, la

valoración sobre un reclamo, el comentario o agregado de información a un reclamo, la

sugerencia de una nueva empres a o producto de una empresa.

Aprovechamiento de participaciones explicitas: considerar como valiosos los

comportamientos de los usuario y almacenando estos datos. Esto permitirá clasificar

contenidos y ordenarlos algorítmicamente según diversos criterios, como ser los reclamos

más vistos, los más comentados, los mejor y más valorados. A su vez sería posible seguir los

caminos de navegación realizados por los usuarios, indicando cuales son algunos de los

reclamos vistos antes y después de uno en particular.


Hay que tener en claro que el sistema no solo debe invitar a los usuarios a participar, sino que

debe constituir un contexto coherente y consistente que promueva la generación de

contenidos. A un nivel alto nos referimos a la temática o contexto de la comunidad. A nivel de

plataforma, nos referimos a incluir mecanismos para la identidad, reputación y relaciones

entre los usuarios. Como veremos en otros patrones y prácticas, el correcto diseño de URLs,

etiquetas y otros elementos serán necesarios para proveer una correcta identificación de los

datos. A su vez es importante la facilitación de mecanismo de búsqueda sobre datos de

reclamos y datos de usuarios. Es decir, el contexto debe considerar a los usuarios, a la

plataforma, y a los datos.


180

Confiar en los usuarios.

Con el objetivo de promover la participación de los usuarios, es necesario mantener una

apertura respecto a la generación de contenidos y aportes sobre los contenidos ya existentes.

A su vez, se debe dar gran valor a los resultados de dicha participación.

Una manera de lograr esto es cediendo parte del control a los usuarios, sin aplicar demasiadas

restricciones a sus aportes, permitiendo que estos sean publicados de manera directa sin

tener que ser supervisados por un moderador o administrador del sistema, ya que esto

generaría un paso más en la generación, así como también se volvería incomodo y costoso (en

recursos de tiempos) al sobrecargar las tareas de los moderadores o administradores frente a

un alto volumen de generación de contenidos.

Incluso una manera de contrarrestar los malos contenidos es delegar parte de la tarea de

moderación a los usuarios, permitiendo que estos reporten contenidos inadecuados a la

temática de la comunidad.

Diseñar software que es mejor a medida que más gente lo usa.

El sistema debe orientarse al aprovechamiento de los efectos de red. En nuestro caso cuanto

más usuarios participen en la comunidad, esta tendrá más peso a nivel social y se hará más

conocida, y por tanto más peso tendrán los reclamos y opiniones individuales de cada usuario.

A su vez, será más probable que al momento de querer realizar un reclamo el usuario

encuentra ya cargado en el sistema la empresa o producto al cual desea referirse

simplificando el proceso de carga. Incluso en este caso podrá verificar si no existen

situaciones similares a la suya, pudiendo quizás encontrar una solución a su problema o

sumar información a su proceso de toma de decisiones sobre el consumo de un producto o

servicio.

A medida que más miembros de la comunidad compartan sus reclamos y opiniones, mejor

lograra la comunidad sus objetivos.

Facilitar la emergencia de los contenidos:

Sera necesario definir medos flexibles de navegación para los contenidos, tratando de no

apegarse demasiado a estructuras jerárquicas y categorizadas, facilitando así la emergencia

de contenidos al permitir el surgimiento de formas inesperadas e innovadoras de mostrar

contenidos y realizar navegaciones.

4.3.4.2. Los datos son el próximo "Intel Inside”.

Usar fuentes de datos únicas y difíciles de recrear para convertirse en el siguiente "Intel Inside",

en esta época en la que la información se ha vuelto tan importante como la función.

Buscar poseer fuentes de datos únicas y difíciles de recrear.

El sistema debe perseguir la generación de una base de datos de opiniones genuinas sobre

empresas y productos, cuyo valor provendrá del aporte particular de cada usuario, tanto por


181

la generación de sus propios reclamos o del aporque te realice al agregar información o

valorar los de otros usuarios. Al ser generada por los usuarios, será única y difícil de recrear.

Dicha base de datos tendrá el potencial de volverse más y más valiosa a medida que se genere

su crecimiento manteniendo la calidad de los contenidos, ya que lograría cumplir los objetivos

planteados por este proyecto, como ser potenciar la voz individual de cada consumidor,

proveer a soluciones e información valiosa para los procesos de toma de decisiones sobre

consumos de los productos o servicios.

Mejorar los datos básicos.

Podemos considerar como datos básicos a una posible lista inicial de empresas y productos,

ya que son datos simples y de público conocimiento, y a los datos agregados que puedan

generar los usuarios. Esta debe ser la base para generar valor al aplicar las opiniones,

valoraciones y otros aportes de los consumidores miembros de la comunidad de contenidos.

Los usuarios controlan sus propios datos.

Es importante recordar que el valor real proviene del contexto y no de los datos básicos y que

por tanto las bases de datos cerradas no llegan a aprovechar las fortalezas de Internet. Para

lograr una apertura es necesario que los usuarios confíen en el sistema y en la comunidad, y

por tanto deben tener la capacidad de controlar sus propios datos.

El sistema debe proveer formas de agregar y quitar sus datos de usuario y su cuenta, así como

también controlar los contenidos que aporta.

Algunos derechos reservados, no todos.

Al ser una comunidad abierta que promueve la libre participación y cooperación, hay que

considerar que muchos efectos potenciales provendrán de efectos virales de distribución de

los contenidos, suponiendo casos hipotéticos en los cuales fuentes externas a la comunidad

podrían tomar reclamos que tengan alta relevancia y reproducirlas total o parcialmente en

otros medios de Internet e incluso en medios tradicionales.

Es importante considerar los derechos de autor de cada usuario haciéndolo propietario de sus

opiniones, pero buscar flexibilidad para que dichos derechos de propiedad intelectual no sean

un obstáculo para la distribución y difusión de la información, por lo que será necesario

aplicar mecanismos apropiados.

Definir una estrategia de pila de datos.

Esta práctica no tiene alta relevancia en el contexto de este proyecto ya que la base de datos

inicial seria un listado de empresas y productos, la cual se formaría en gran parte por el

aporte de los usuarios, aunque se podría considerar si a futuro se utiliza esta base de datos

como fuente de datos para otro proyecto.


182

En dicho caso es importante considerar los visto anteriormente sobre la generación de valor

agregado sobre los datos de base.

Ser dueño del índice o del formato.

Esta práctica debe ser perseguida, ya que si la base de datos toma un tamaño considerable

alcanzando los objetivos altos del proyecto, de tal forma que los contenidos de la comunidad

puedan influenciar a empresas y otros consumidores.

En tal caso la comunidad de contenidos apuntaría a ser el lugar por defecto donde se

planteen opiniones sobre productos y servicios.

Diseñar los datos para su reutilización.

Así como consideramos la importancia de los datos, es importante también considerar la

importancia de la reutilización de los datos, y que por tanto, el diseño de los datos debe estar

preparado para dicha distribución.

Esto se manifiesta en los mecanismos de acceso a los datos, y por tanto será necesario que el

sistema cuente con mecanismos flexibles para proveer la sindicación de contenidos y

redistribución de los datos.

Tercerizar o proveer administración al acceso de datos.

Sera necesario buscar formas de manejar los altos volúmenes de contenidos de la

comunidad, persiguiendo eficiencia y un bajo costo. Si bien cada día se vuelven más

accesibles los espacios de almacenamiento y capacidades de transferencia, los

recursos con los que cuenta el proyecto y el potencial crecimiento que podría tener

no muestra como una opción conveniente administrar todos los datos en un servidor

propio.

Por tanto, será necesario considerar servicios de terceros para los datos que

potencialmente pueden consumir muchos recursos, como ser los contenidos

multimedia de imagen y video de los reclamos y comentarios.

4.3.4.3. Innovación en el ensamblaje.

Construir plataformas para fomentar la innovación en el ensamblaje, donde la combinación e

interacción de datos y servicios crea nuevas oportunidades y mercados.

Ofrecer APIs de los servicios.

Es necesario pensar no solo en una estrategia de aplicación, sino también de plataforma. Para

esto es necesario plantear el desarrollo de una API del servicio ofrecido por el sistema,

permitiendo que terceros puedan tomar información de la base de datos de reclamos,

empresas y productos.


183

Si bien cada día se vuelve más sencillo la generación de dichas APIs y su distribución,

posiblemente deba ser relegado para una etapa futura del proyecto debido a la escasez de

recursos con los que se contara para un primer lanzamiento, buscando otras formas

alternativas de aprovechar los efectos de Web 2.0 como ser la sindicación de contenidos.

Diseñar para la reutilización.

El principio de generar contenidos que puedan ser analizados, desarmados y reutilizados debe

aplicarse en el planteamiento del sistema, algo que se había planteado en otras prácticas

anteriores, lo cual es posible alcanzarse mediante el desarrollo de APIs y la sindicación de

contenidos.

De esta forma se permitiría que terceros tomen los reclamos del sistema y los usen de base

para sus propios proyectos de maneras inesperadas y creativas, e indirectamente

potenciando el éxito de la comunidad d contenidos.

Aplicar las mejores prácticas en APIs.

Al considerar el desarrollo futuro de una API para este servicio es importante seguir los

estándares más utilizados, y por tanto será necesario profundizar en los conocimientos

específicos de las técnicas analizadas en el marco teórico, al momento de considerar el

desarrollo Web 2.0.

Es necesario también buscar el desarrollo de técnicas que potencien su uso y por tanto su

éxito. Estas podrían incluir la generación de tutoriales que fomenten su uso y el desarrollo de

comunidades de desarrolladores que utilicen dicha API, mediante diversas herramientas

como ser foros, wikis y blogs.

Usar los estándares existentes.

Sera necesario profundizar sobre los estándares más utilizados, como ser JSON, microformats,

SOAP, REST, y otros para la generación futura de la API.

Por otra parte, el análisis realizado en el marco teórico sobre sindicación de contenidos nos

llevo al conocimiento y entendimiento de estándares RSS y Atom, y estos serán las bases para

la aplicación la sindicación al sistema.

En ambos casos será necesario profundizar sobre los conocimientos teóricos, ya que el

trabajo realizado aquí no busca abarcar los temas en profundidad técnica.


En este trabajo se plantea un modelo de negocio que abarca a los usuarios y a su forma de

publicación de contenidos sobre empresas y productos aplicando consideraciones vistas en

otros proyectos Web 2.0. Dicho modelo es la esencia del proyecto y por tanto al momento de

generar una API será necesario buscar la aplicación del modelo de negocio sobre esta, sin

perder claridad de objetivos.


184

Esto permitirá conseguir contribuciones y distribuciones en sitios de terceros, potenciando así

el efecto generado por la comunidad de contenidos.


Al momento de diseñar la API no solo se debe aplicar el modelo de negocio, sino que se

deben considerar todos los patrones de diseño planteados en el desarrollo de la plataforma,

persiguiendo la aplicación de principios Web 2.0 como ser bajas barreras de adopción,

herramientas en base a efectos de red y técnicas para construir y dar soporte a un ecosistema

de colaboración.

Hemos considerado muchas formas de aplicar estos principios mediante herramientas y

servicios Web 2.0 de terceros, como ser la generación de wikis colaborativas, blogs y otras.

Ser cliente de su propia plataforma.

Una vez desarrollada la API en una etapa futura del proyecto, será recomendable que

el sitio principal de la comunidad internamente utilice los servicios de la API,

buscando así incrementar la calidad y reducir los costos a través de la reutilización.

Direccionamiento granular de contenidos.

Cara reclamo, empresa, producto, comentario, usuario y otros elementos que surjan deben

poder tener un direccionamiento único y claro, siendo necesaria la generación de URLs claras,

legibles y simples para el sitio, lo que potenciara luego la redistribución de contenidos

pudiendo realizarse referencias a elementos individuales de los datos que contenga el

servicio, aportando efectos positivos para los usuarios del sitio, desarrolladores de otros sitios

y motores de búsquedas.


En busca de apertura y confianza por parte de los usuarios, es necesario que así como

planteamos la posibilidad de agregar y eliminar sus datos a través del sistema, también

puedan hacerlo a través de una futura API.

Esto va de la mano con lo planteado sobre la aplicación del modelo de negocio usado en el

sitio sobre la API. De tal manera en un escenario futuro los usuarios podrían utilizar sus

opiniones sobre productos y servicios en servicios de terceros de forma libre y flexible.


Los usuarios reutilizaran los servicios de formas inesperadas y creativas ya sea mediante

sindicación de contenidos o mediante API, por tanto será importante mantener la atención

en las acciones de estos, ya que podrían encontrarse nuevos elementos para ser agregados al

propio modelo de negocio del sistema.


185

4.3.4.4. Experiencias de usuario ricas.

Ir más allá de los conceptos tradicionales de lo que es una página web, para entregar experiencias

al usuario mucho más ricas, combinando lo mejor del software online y de escritorio.

Combinar lo mejor de las experiencias de escritorio y online.

Debemos buscar una experiencia de usuario sin los límites planteados por Internet en los

años anteriores a la tendencia Web 2.0, acercándonos a las características de las mejores

interfaces de escritorio. Las tecnologías actuales como ser el caso analizado de AJAX permiten

generar interfaces de usuario en un navegado altamente interactivas y rápidas a través de la

aplicación de cambios dinámicos en una página. A su vez el aspecto de un sitio puede ser

mejorado tendiendo a una simpleza de diseño con la aplicación de estilos CSS sobre

estructuras de XHTML. Además, los crecientes anchos de banda, espacios de almacenamiento

y capacidades de servicios de terceros permiten obtener capacidades multimedia antes

impensadas.

Por su parte Internet provee características como ser la independencia de una plataforma o

sistema operativo, el acceso independiente del lugar y por tanto posibilidades de

colaboración.

Por tanto se debe buscar que en el lado del cliente se utilice una aplicación liviana con las

características mencionadas anteriormente y aprovechando las cualidades del concepto del

software como servicio, apuntando siempre a enriquecer la experiencia de los usuarios del

sistema y considerando esto como un requerimiento funcional, y no solo complemento.

Usabilidad y simplicidad primero.

Es importante no permitir que en busca de una innovación o aplicación de una tecnología se

pongan en riesgo la usabilidad y la simpleza, ya que estas son las características que necesita

el usuario. En este caso se deberán priorizar las mejoras en los procesos del sistema, como

ser las cargas de reclamos, comentarios, contenidos multimedia de estos últimos dos,

administración de cuentas de usuario y sobre todo la navegación del sistema, dejando de lado

quizás efectos gráficos que llamen la atención pero que puedan poner trabas a los primeros

puntos.

En el área de multimedia sería interesante buscar el servicio de terceros como ser el caso de

YouTube para los contenidos de video, ya que su servicio da seguridad sobre los aspectos de

usabilidad, simpleza y disponibilidad tanto en el proceso de carga de videos como en el

consumo de estos. A su vez los servicios que se utilicen de terceros deberán contar con las

características de ser fácilmente integrables como componentes del sistema.

El diseño de la interfaz debe basarse fuertemente en estilos CSS con la menor cantidad

posible de gráficos para lograr maximizar la velocidad de carga.


186

Buscar que el uso coincida con los requisitos.

La aplicación de tecnologías como ser Ajax, JavaScript, CSS y otras tecnologías brinda un

gigantesco abanico de posibilidades a la hora de plantear interfaces, por esto es importante

siempre buscar el objetivo planteado por el modelo de negocio del sistema, brindando un

servicio claro para administrar y acceder a reclamos y opiniones de los usuarios, y por tanto

hacer que el uso del sistema no se aleje de lo planteado en los requerimientos.

Búsqueda sobre la estructura.

Las formas de acceder a contenidos e incluso de crearlos pueden ser guiadas por algoritmos

internos del sistema, aprovechando la estructura y contenido del sistema para mejorar los

servicios y predecir algunos comportamientos del usuario, sobre todo considerando que a

medida que la naturaleza y estructura de contenidos se vuelve menos predefinida y emerge

de la dinámica de los comportamientos y participación de los usuarios, aumenta la necesidad

de algoritmos más inteligentes y poderosos.

Sera importante permitir este tipo de efectos, asegurando que sea posible realizar búsquedas

en base a términos, empresas y productos sobre los contenidos de la base de datos de

reclamos

A su vez, seria óptimo que en base al comportamiento de búsqueda de un usuario, se le

sugiera parte de los datos necesarios para cargar un nuevo contenido. Por ejemplo, en caso

de estar viendo contenidos referidos a un producto determinado, al elegir “cargar un nuevo

reclamo” debería salir como seleccionado dicho producto, ya que probablemente quiera

referiste a este mismo.

Preservar el direccionamiento de los contenidos.

No se debe poner en riesgo el direccionamiento de los contenidos en pro de minimizar el

numero de recargas del navegador o de simplificar la interfaz del usuario, ya que hemos

considerado anteriormente la importancia de poder acceder individualmente y de forma clara

y simple a cada contenido del sistema. Cada elemento debe ser equivalente a una URL.

Esto permitirá que los usuarios puedan encontrar los contenidos (agregándolos a marcadores,

recibiendo actualizaciones de sindicación de contenidos, etc.), así como también las maquinas

(buscadores, herramientas de terceros por mencionar ejemplos).


Hay que tener en mente al momento de desarrollar las aplicaciones componentes del sistema

que se debe generar un entorno que aprenda dinámicamente del comportamiento del

usuario, anticipando sus necesidades, recordando sus preferencias y adaptándose a medida

que es más y más utilizado.


187

Sera necesario generar interfaces con detalles específicos para cada usuario, con elementos

que brinden una sensación de personalización, recordando los datos de usuario y sus

comportamientos, como por ejemplo poniendo a su disposición sus últimas colaboraciones o

sugiriéndole empresas o productos que puedan ser de su interés en base a su interacción

histórica con contenidos del sistema.

4.3.4.5. Aprovechar la larga cola.

Capturar nichos de mercado rentables a través economías de bajo costo y alcance amplio

permitidas por la Internet.

Construir en base a las fortalezas de la larga cola.

La producción democratizada de contenidos será aprovechada en base a las capacidades de

libre opinión de los consumidores con el bajo costo de generación de contenidos tanto de

texto como multimedia que presentan los escenarios actuales.

La distribución democratizada y la conexión entre oferta y demanda serán aprovechada

debido a la gran variedad de empresas y productos que potencialmente se encontraran en la

base de datos del sistema, pudiendo cada uno de estos ser encontrado mediante besucadores

cuando los usuarios de internet busquen información sobre dichas empresas y productos.

A su vez, puede profundizarse más aun el nicho al sumar un problema determinado sobre una

empresa o producto en el proceso de búsqueda. De esta forma se alcanzara a cubrir

contantemente múltiples micro-mercados, ofreciendo en cada búsqueda elementos de valor

como lo son las opiniones reales de los consumidores de la comunidad. Así sin

necesariamente contener términos que sean altamente buscados de manera individual, la

suma de todas las búsquedas sobre los contenidos del sistema proveerá de un potencial

tráfico al sitio y por tanto se potenciara el éxito de la comunidad.

En particular se debe proveer medios de distribución aprovechando las características de la

sindicación de contenidos, para mantener actualizado a aquellos usuarios que ya han

encontrado al sitio como una fuente de información valiosa.

Usar administración de datos algorítmica para que oferta y demanda se igualen.

Sera necesario sugerir contenidos a los usuarios en base a consideraciones algorítmicas sobre

el comportamiento de otros usuarios del sistema, por ejemplo, indicando que reclamos

fueron visitados luego de visualizar un determinado reclamo que el usuario pueda estar

consultando. De esta forma buscaremos aprovechar la inteligencia colectiva sugiriendo

contenidos al usuario que probablemente sean de su interés utilizando algorítmicamente los

datos obtenidos previamente.


El aprovechamiento de los comportamientos de los usuarios y de la arquitectura de

participación del sistema puede buscar “la sabiduría de las multitudes”. Esto debe aportar


188

medios de filtrado de información, sugiriendo por ejemplo las informaciones más comentadas

o valoradas por los otros usuarios del sistema.

Aprovechar el auto servicio de los clientes para alcanzar toda la red de manera costo-

efectiva.

Sera necesario permitir la auto administración por parte de los usuarios para reducir costos

de soporte y tiempos de espera por parte del usuario, minimizando así las barreras para la

adopción del sistema y el crecimiento escalable.


Los costos de mantener a un sistema online han bajado considerablemente año a año, y

podemos considerar que se tendrá un costo marginal mínimo a medida que la comunidad

tome un tamaño mayor.

Sera necesario buscar un servicio de alojamiento web con buenas prestaciones de espacio en

disco, ancho de banda y capacidades de soporte para las tecnologías que el sistema utilizara,

como ser el lenguaje de programación y la base de datos que se elija.

4.3.5. Requerimientos del Sistema

Las consideraciones realizadas anteriormente aplicando los patrones de diseño Web 2.0 al

dominio planteado por este trabajo nos da una visión general sobre la forma que deberá tomar el

sistema para poder lograr el objetivo planteado.

Si bien es complicado sintetizar dichas necesidades, podemos realizar un listado de

requerimientos manteniendo en cuenta los análisis generales de los patrones en todo momento

al realizar los procesos de análisis, diseño e implementación de la aplicación.

Podemos considerar como requerimientos del sistema a los siguientes:

Los usuarios registrados deben poder cargar reclamos referidos a empresas o productos.

Los nuevos reclamos y comentarios deben publicarse de manera directa en el sitio, sin ser

supervisados.

Los reclamos y opiniones deben ser de acceso público (no deben requerir registración para

ser accedidos).

Los contenidos deben publicarse bajo algún tipo de licencia que por un lado preserve los

derechos de autoría, pero que a su vez permita una distribución y reutilización flexible.

Los usuarios registrados deben poder reportar reclamos o comentarios si los consideran

inapropiados, para que estos sean revisados por un administrador del sistema.

Los usuarios registrados deben poder sugerir nuevas empresas y productos, siendo estas

aprobadas por un administrador de sistema posteriormente.

Los usuarios registrados deben poder aportar información adicional, opiniones y valoraciones

sobre reclamos de otros usuarios.

Los usuarios deben poder enviar mensajes privados a otros usuarios.

Cada miembro de la comunidad debe poder generar una cuenta de usuario en el sistema.

Los usuarios registrados deben poder eliminar sus propios datos.


189

Los usuarios deben poder realizar búsquedas en el sistema sobre reclamos, empresas,

productos y usuarios.

Se debe sugerir contenidos a los usuarios de a cuerdo a sus acciones en el sistema.

Se debe ayudar a los usuarios en el proceso de carga de acuerdo a sus acciones en el sistema.

Los usuarios deben poder recibir actualizaciones sobre nuevos reclamos y comentarios sobre

empresas y productos.

El usuario debe poder realizar sus objetivos en la menor cantidad posible de pasos.

Se debe minimizar la cantidad de recargas del navegador al efectuar un proceso en el sistema,

sin poner en riesgo la simplicidad, los objetivos del usuario ni el direccionamiento de

contenidos.

Las interfaces deben diseñarse flexibles, livianas y con tiempos de carga bajos, pero

manteniendo un aspecto simple, intuitivo y agradable.

Se debe monitorear la manera en que los usuarios navegan el sistema, almacenando dichos

datos.

Se deben generar estadísticas y rankings en base al comportamiento de los usuarios

considerando diversos criterios.

Los usuarios deben contar con una métrica sobre su reputación en base a la opinión de otros

usuarios sobre sus colaboraciones en la comunidad (reclamos y comentarios).

Cada elemento de contenido del sistema debe tener un direccionamiento claro y simple

contando con URLs únicas, simples y legibles para cada reclamo, comentario, empresa,

producto y usuario.

El sistema debe permitir la emergencia de contenidos buscando formas alternativas e

inesperadas de navegación, por ejemplo mediante la generación de nubes de tags.

El sistema debe contar con mecanismos que permitan la redistribución y reutilización de

contenidos y servicios del sitio, como ser APIs o sindicación de contenidos.

El sistema debe facilitar a los usuarios el agregado de los contenidos a marcadores sociales.

El sistema debe aprovechar los servicios ofrecidos por terceros para reducir la utilización de

recursos cuando sea posible, como ser el caso de los contenidos multimedia de los reclamos y

comentarios.

Sera necesario contar con un servicio de alojamiento web con características suficientes para

ser la base del sistema.

El sistema deberá contar con un panel de control brinde a administradores capacidades para

editar, desactivar y eliminar reclamos y comentarios; agregar, editar y eliminar empresas y

productos; revisar empresas y productos sugeridos por los usuarios; agregar, editar,

suspender y eliminar usuarios; y realizar tareas pertinentes a la administración del sistema

como por ejemplo realizar respaldo de la base de datos.


190

4.4. Análisis y Diseño En base a la búsqueda de requerimientos realizada en la etapa anterior, desarrollaremos el

análisis y el diseño del sistema considerando como herramienta a lo planteado por UML UWE. No

se profundizara en la arquitectura interna ni en detalles de programación del sistema debido a

que ese no es el foco principal del trabajo, sumado al hecho de que tal enfoque ya ha sido

aplicado en el trabajo de pre grado realizado por el autor del proyecto.

Se desarrollara principalmente los aspectos del sistema orientados a los usuarios en general como

consumidores y su relación con empresas y productos61, dejando de lado las especificaciones

relacionadas al las tareas de administradores ya que podemos considerar a estas en su mayorías

como triviales siendo principalmente ABM de datos del sistema, y siendo otras intrínsecas al

sistema open source que se elija para ser la base del proyecto.

Para lograr una comprensión del análisis y diseño del sistema, utilizaremos las siguientes

herramientas:

Análisis

Listado de casos de uso.

Descripción de los casos de uso.

Diagrama de casos de uso.

Diseño

Modelo de Contenidos

Modelo de Navegación

Modelo de Presentación

Modelo de Estructura de Procesos.

Diagramas de Flujo de Procesos.

Decisiones de diseño de sistema.

61

Cuando usamos el término “productos” estamos hablando tanto de productos como de servicios.


191

4.4.1. Análisis del sistema

4.4.1.1. Listado de casos de uso de sistema

Podemos considerar los siguientes casos de uso del sistema en base a lo analizado previamente:

1. Ingresar al Sistema.

2. Recuperar Password.

3. Registrar Usuario.

4. Salir del Sistema.

5. Ver Cuenta de Usuario.

6. Editar Cuenta de Usuario.

7. Eliminar Cuenta de Usuario.

8. Ver Mensajes Privados.

9. Enviar Mensaje Privado a Usuario.

10. Ver Reclamo.

11. Ver Comentarios.

12. Otorgar Valoración.

13. Reportar.

14. Agregar Social Bookmark.

15. Cargar Reclamo.

16. Editar Reclamo.

17. Cargar Comentario.

18. Cargar Imagen.

19. Cargar Video.

20. Sugerir Empresa.

21. Sugerir Producto.

22. Buscar Reclamos.

23. Ver Últimos Reclamos.

24. Ver Ranking de Reclamos.

25. Ver Lista de Empresas.

26. Ver Reclamos de Empresa.

27. Ver Lista de Productos.

28. Ver Reclamos de Producto.

29. Ver Reclamos de Usuario.

30. Sindicación de Contenidos.

31. Tour Guiado


192

4.4.1.2. Descripción de casos de uso de sistema

C.U: Ingresar al Sistema Actor: Usuario Nº 1

Descripción:

El usuario puede ingresar al sistema utilizando su nombre de usuario o e-mail y su password. Si los datos que ingrese son validos, el usuario es ahora un usuario registrado.

C.U: Recuperar Password Actor: Usuario Nº 2

Descripción:

En caso de no recordar su password, el usuario puede ingresar su dirección de e-mail. Si es una dirección ya existente en el sistema, el usuario recibirá en su casilla de e-mail su nombre de usuario y su password.

C.U: Registrar Usuario Actor: Usuario Nº 3

Descripción:

El usuario puede ingresar sus datos como ser nombre, apellido, e-mail, password y ciudad para crear una cuenta de Usuario. Una vez realizado el proceso recibirá sus datos en su casilla de e-mail.

C.U: Salir del Sistema Actor: Usuario Registrado Nº 4

Descripción:

El usuario registrado puede seleccionar la opción “Salir” para salir del sistema, dejando de ser un Usuario Registrado.

C.U: Ver Cuenta de Usuario Actor: Usuario, Usuario Registrado Nº 5

Descripción:

Un usuario puede ver los datos de otro usuario y los propios en caso de ser un usuario registrado. Se visualizan los datos básicos del usuario y es posible acceder al listado de los reclamos realizados por este así como también los reclamos en los cuales ha realizado algún comentario. Si se es un usuario registrado también es posible enviar un mensaje privado al usuario, y en caso de ver los datos propios es posible acceder a los mensajes privados, editar los datos de usuario y borrar la cuenta de usuario.

C.U: Editar Cuenta de Usuario Actor: Usuario Registrado Nº 6

Descripción:

El usuario registrado puede modificar sus datos de usuario.

C.U: Eliminar Cuenta de Usuario Actor: Usuario Registrado Nº 7

Descripción:

El usuario registrado puede eliminar su cuenta de usuario del sistema. No se eliminaran sus reclamos ni comentarios, pero si todos sus datos privados.


193

C.U: Ver Mensajes Privados Actor: Usuario Registrado Nº 8

Descripción:

El usuario registrado puede ver un listado de mensajes privados que le han sido enviados por otros usuarios del sistema.

C.U: Enviar Mensaje Privado a Usuario Actor: Usuario Registrado Nº 9

Descripción:

El usuario registrado puede enviar un mensaje privado a otro usuario registrado del sistema, indicando un asunto y un contenido del mensaje.

C.U: Ver Reclamo Actor: Usuario, Usuario Registrado Nº 10

Descripción:

El usuario o usuario registrado visualiza un reclamo, conteniendo empresa, producto si tuviera, tags, fecha, titulo, texto, imágenes, videos, valoración general y datos del autor. A su vez visualiza el listado de comentarios realizados por otros usuarios. Visualiza las opciones de agregar el reclamo a marcadores sociales y de adherirse a la sindicación de contenidos de los comentarios del reclamo. En caso de ser un usuario registrado podrá realizar una valoración sobre el reclamo, enviar un mensaje privado al usuario autor, reportar el reclamo como inapropiado (en caso de haber sido reportado ya por otro usuario puede estar en espera indicando tal situación, y si ya fue aprobado no podrá ser reportado nuevamente.), realizar un comentario sobre el reclamo y cargar un nuevo reclamo o un nuevo reclamo sobre la misma empresa y producto (si tuviera el reclamo un producto).

C.U: Ver Comentarios Actor: Usuario, Usuario Registrado Nº 11

Descripción:

Al visualizar un reclamo el usuario o usuario registrado visualiza un listado de todos los comentarios realizados por usuarios en referencia a dicho reclamo, obteniendo fecha, texto, imágenes, videos, valoración general y datos del autor. En caso de ser un usuario registrado visualiza las opciones de enviar un mensaje privado al autor del comentario, realizar una valoración sobre el comentario y reportarlo como inapropiado (en caso de haber sido reportado ya por otro usuario puede estar en espera indicando tal situación, y si ya fue aprobado no podrá ser reportado nuevamente.).

C.U: Otorgar Valoración Actor: Usuario Registrado Nº 12

Descripción:

El usuario registrado realiza una valoración sobre un reclamo o un comentario, valuando su calidad en la escala del 1 al 5. Esto puede ser realizado una única vez por parte del usuario registrado sobre un mismo reclamo o comentario.

C.U: Reportar Actor: Usuario Registrado Nº 13

Descripción:

El usuario registrado puede reportar un reclamo o comentario para que sea revisado por un administrador, indicando el motivo por el cual lo considera inapropiado. El reclamo o comentario no podrá ser reportado por otros usuarios en caso de estar en espera (mostrando un texto que indique su situación) o en caso de ya haber sido reportado y habiendo luego sido aprobado por un administrador.


194

C.U: Agregar Social Bookmark Actor: Usuario, Usuario Registrado Nº 14

Descripción:

El usuario o usuario registrado podrá utilizar diversos links para agregar el reclamo a marcadores sociales, buscando facilitar y encaminar la tarea enviando el titulo y la url del reclamo a la ventana de carga del servicio de marcador social que se utilice (externo al sistema).

C.U: Cargar Reclamo Actor: Usuario Registrado Nº 15

Descripción:

El usuario registrado podrá cargar un reclamo seleccionando mediante una interfaz enriquecida la empresa (y si lo deseara, el producto) sobre la cual desea realizar un reclamo (estos datos podrían estar preseleccionados en algunos casos si el camino elegido para llegar a la carga del reclamo sugería tal cosa) También será posible realizar la sugerencia de una empresa y/o producto. A su vez el usuario registrado deberá ingresar un asunto y una descripción, pudiendo ingresar opcionalmente tags, imágenes y videos. Una vez completada la información se realizara la carga del reclamo. El usuario registrado visualizara en todo momento un texto con sugerencias sobre como redactar el reclamo con el objetivo de que este se ajuste a las normas de la comunidad.

C.U: Editar Reclamo Actor: Usuario Registrado Nº 16

Descripción:

El usuario registrado puede editar sus propios reclamos, pudiendo modificar todos sus datos, contando con una interfaz similar a la desarrollada para la carga de reclamo. Sin embargo se mantendrá una copia de las versiones anteriores del reclamo, pudiendo un administrador volver a colocar una copia anterior.

C.U: Cargar Comentario Actor: Usuario Registrado Nº 17

Descripción:

El usuario registrado puede cargar un comentario al visualizar un reclamo, incluyendo texto, imágenes y videos. El usuario registrado visualizara en todo momento un texto con sugerencias sobre como redactar el comentario con el objetivo de que este se ajuste a las normas de la comunidad.

C.U: Cargar Imagen Actor: Usuario Registrado Nº 18

Descripción:

Al visualizar la carga de un reclamo o comentario el usuario registrado puede seleccionar un archivo valido de imagen desde su disco duro o ingresando una URL de una imagen valida. Esta se cargara en un servicio de terceros. Una vez realizada la carga el usuario registrado podrá continuar la carga del reclamo o comentario, visualizando un thumbnail de la imagen cargada.

C.U: Cargar video Actor: Usuario Registrado Nº 19

Descripción:

Al visualizar la carga de un reclamo o comentario el usuario registrado puede seleccionar un archivo valido de video desde su disco duro o ingresando una URL de una video valida. Esta se cargara en un servicio de terceros. Una vez realizada la carga el usuario registrado podrá continuar la carga del reclamo o comentario, visualizando un thumbnail del video cargado.


195

C.U: Sugerir Empresa Actor: Usuario Registrado Nº 20

Descripción:

Al visualizar la carga o edición de un reclamo, el usuario registrado puede sugerir una nueva empresa en caso de no encontrar una de su interés en el sistema. El usuario registrado podrá realizar la carga sobre dicha empresa e incluso sugerir productos de la empresa, pero ésta marcada como “pendiente” hasta que sea aprobada por un administrador no pidiendo ser utilizada por otros usuarios hasta que se realice tal acción.

C.U: Sugerir Producto Actor: Usuario Registrado Nº 21

Descripción:

Al visualizar la carga o edición de un reclamo, el usuario registrado puede sugerir un nuevo producto dentro de una empresa en caso de no encontrar uno de su interés en el sistema. El usuario registrado podrá realizar la carga sobre dicho producto, pero éste será marcado como “pendiente” hasta que sea aprobado por un administrador no pidiendo ser utilizado por otros usuarios hasta que se realice tal acción.

C.U: Buscar Reclamos Actor: Usuario, Usuario Registrado Nº 22

Descripción:

El usuario o usuario registrado podrá realizar una búsqueda en el servicio ingresando palabras clave de su preferencia, y obteniendo visualizando posteriormente un listado de reclamos que se ajusten a dichas palabras claves. Contara con la opción de visualizar el detalle de un reclamo en particular y en caso de ser un usuario registrado podrá acceder a la carga de un nuevo reclamo.

C.U: Ver Últimos Reclamos Actor: Usuario, Usuario Registrado Nº 23

Descripción:

El usuario o usuario registrado visualizara una lista de los últimos reclamos ingresados al sistema. Contara con la opción de visualizar el detalle de un reclamo en particular y en caso de ser un usuario registrado podrá acceder a la carga de un nuevo reclamo.

C.U: Ver Ranking de Reclamos Actor: Usuario, Usuario Registrado Nº 24

Descripción:

El usuario o usuario registrado visualizara una lista de los reclamos con mejores valoraciones por parte de los usuarios del sistema y de los reclamos más comentados por los usuarios del sistema. Contara con la opción de visualizar el detalle de un reclamo en particular y en caso de ser un usuario registrado podrá acceder a la carga de un nuevo reclamo.

C.U: Ver Lista de Empresas Actor: Usuario, Usuario Registrado Nº 25

Descripción:

El usuario o usuario registrado podrá visualizar una “nube de tags” con los nombre de las empresas cargadas en el sistema, estando ordenadas alfabéticamente y con tamaños variables dependiendo de la cantidad de reclamos que las referencien. Cada elemento de la nube será un link que llevará al usuario a visualizar el listado de reclamos realizados sobre una empresa.


196

C.U: Ver Reclamos de Empresa Actor: Usuario, Usuario Registrado Nº 26

Descripción:

El usuario o usuario registrado visualizara una lista de los reclamos ingresados al sistema en referencia a una empresa en particular. Contara con la opción de visualizar el detalle de un reclamo en particular, subscribirse por sindicación de contenidos a los reclamos que se generen sobre la empresa y en caso de ser un usuario registrado podrá acceder a la carga de un nuevo reclamo sobre la misma empresa (mostrándose ya seleccionada esta empresa al iniciar el proceso de carga) o sobre otra empresa.

C.U: Ver Lista de Productos Actor: Usuario, Usuario Registrado Nº 27

Descripción:

El usuario o usuario registrado podrá visualizar una “nube de tags” con los nombre de los productos cargados en el sistema, estando ordenados alfabéticamente y con tamaños variables dependiendo de la cantidad de reclamos que los referencien. Cada elemento de la nube será un link que llevará al usuario a visualizar el listado de reclamos realizados sobre un producto de una empresa.

C.U: Ver Reclamos de Productos Actor: Usuario, Usuario Registrado Nº 28

Descripción:

El usuario o usuario registrado visualizara una lista de los reclamos ingresados al sistema en referencia a un producto de una empresa en particular. Contara con la opción de visualizar el detalle de un reclamo en particular, subscribirse por sindicación de contenidos a los reclamos que se generen sobre el producto y en caso de ser un usuario registrado podrá acceder a la carga de un nuevo reclamo sobre el mismo producto de la empresa (mostrándose ya seleccionada esta empresa y el producto al iniciar el proceso de carga), sobre otro producto de la misma empresa (mostrándose ya seleccionada esta empresa al iniciar el proceso de carga) o sobre otra empresa.

C.U: Ver Reclamos de Usuario Actor: Usuario, Usuario Registrado Nº 29

Descripción:

El usuario o usuario registrado visualizara una lista de los reclamos ingresados al sistema por un usuario en particular. Contara con la opción de visualizar el detalle de un reclamo en particular, subscribirse por sindicación de contenidos a los reclamos que realice el usuario y en caso de ser un usuario registrado podrá acceder a la carga de un nuevo reclamo.

C.U: Sindicación de Contenidos Actor: Usuario, Usuario Registrado Nº 30

Descripción:

El usuario o usuario registrado podrá realizar una subscripción a sindicación de contenidos de los reclamos referidos a una empresa en particular, un producto de una empresa en particular o aquellos realizados por un usuario en particular, así como también a los comentarios realizados sobre un reclamo en particular. Se proveerá una URL específica para cada uno de estos casos, para que el usuario o usuario registrado pueda ingresarla en su servicio de sindicación de contenidos de preferencia.

C.U: Tour Guiado Actor: Usuario Nº 31

Descripción:

El usuario es guiado a través de un tutorial con textos e imágenes que explica el concepto de la comunidad de contenidos y las acciones que puede realizar en el sistema.


197

4.4.1.3. Diagrama de casos de uso del sistema

Ilustración 73: Diagrama de casos de uso del sistema.


198

4.4.2. Diseño del sistema

4.4.2.1. Modelo de Contenidos

Ilustración 74: Modelo de Contenidos.

El modelo de contenidos permite esbozar la necesidad de datos persistentes en el sistema. El

modelo planteado anteriormente captura las necesidades básicas de datos para el modelo

planeado hasta el momento. Este modelo será de suma utilidad al avanzar sobre la

implementación del sistema y la adaptación de un proyecto open source al formato necesario

para generar la comunidad de contenidos.


199

4.4.2.2. Modelo de Navegación

Ilustración 75: Modelo de Navegación.


200

4.4.2.3. Modelo de Presentación

Incluimos los siguientes diagramas para generar el modelo de presentación:

1. Ventana principal.

2. Índices de reclamos, empresas y productos.

3. Visualización de un reclamo.

4. Agregar y modificar un reclamo.

5. Reportar reclamo y comentario.

6. Registrar Usuario, Ingresar al sistema y Recuperar password.

7. Visualización de datos del usuario.

8. Modificación de datos de usuario.

9. Mensajes privados de usuarios.

10. Carga de imágenes y videos.


201

Ventana principal

Ilustración 76: Modelo de Presentación - Ventana principal.

La presentationPage MainWindow modela la ventana del navegador en la cual se mostrara el

sistema. Esta contiene elementos genéricos para todo el sitio, considerando que HomeLink,

StatusMenu y MainContet se mantendrán disponibles para el usuario en todo momento.

Como podemos notar MainContent es de tipo presentationGroup, y será el contenedor donde se

realizaran la mayoría de las acciones sobre el sitio.

Por su parte NavMenu solo se mostrará en ciertos casos, permitiendo a MainContent una

expansión que ocupe el ancho total de MainWindow.


202

Índices de reclamos, empresas y productos.

Ilustración 77: Modelo de Presentación - Índices de reclamos, empresas y productos.

Los índices de reclamos serán el paso previo al acceso a un reclamo en particular como lo

denota el modelo de navegación. Estos contendrán un listado de reclamos y sus

principales datos en base a diversos filtros que se denotan de las consideraciones de

casos de uso del análisis.


203

Visualización de un reclamo

Ilustración 78: Modelo de Presentación - Visualización de un reclamo.


204

La interfaz considerada en Reclamo es una muestra de la simplicidad de diseño que se

busca en el sistema, integrando múltiples componentes de una manera intuitiva para el

usuario. Al visualizar un reclamo el usuario rápidamente tiene alcance a todos los

contenidos de este, como ser texto, imágenes, videos y comentarios. A su vez se le

presentan opciones de acción: reportar el reclamo como inapropiado, realizar una

valoración sobre este y subscribirse a actualizaciones de sus comentarios mediante

sindicación de contenidos.

Algo importante de destacar es la unión de interfaces para la visualización de un reclamo

y la carga de un comentario, eliminando pasos innecesarios para poder adjuntar una

opinión personal a un reclamo de otro usuario.


205

Agregar y modificar un reclamo

Ilustración 79: Modelo de Presentación - Agregar y modificar un reclamo.


206

La interfaz de carga requerirá el desarrollo de una iteración enriquecida con el usuario,

utilizando tecnología AJAX para facilitar el proceso de elección de empresa y producto al

cual se referirá un reclamo.

La elección de la empresa se desarrollara sugiriendo al usuario nombres de empresa a

medida que se escriben letras. Además, en caso de no encontrar la empresa deseada,

podrá sugerirla al ya haber escrito el nombre de la empresa.

Una vez seleccionada una empresa se llenara dinámicamente y sin recargar la pagina un

combo de opciones que contendrá los productos de la empresa. En caso de que la

empresa no tenga productos cargados o de que ninguno sea el elegido por el usuario, se

podrá realizar una sugerencia mediante un campo de texto.

La carga de imágenes y videos se abrirán en una ventana auxiliar, permitiendo desarrollar

los procesos de manera independiente sin impedir al usuario seguir trabajando sobre

otras partes del formulario. Una vez terminados los procesos el usuario vera un

thumbnail de los contenidos pudiendo incluso eliminar imágenes que haya agregado, por

lo que será necesario trabajar con Javascript en la ventana principal y las auxiliares para

poder lograr estos efectos.

Las acciones de valoración y agregado a marcadores sociales también ocurrirán en la

misma ventana, siendo el proceso de la primera desarrollado con AJAX.

Por su parte, la interfaz de modificación no presenta grandes diferencias, excepto que ya

traerá cargados los datos y se realizaran modificaciones sobre estos de forma similar a lo

explicado para la carga.


207

Reportar reclamo y comentario

Ilustración 80: Modelo de Presentación - Reportar reclamo y comentario.

Ambas interfaces son similares, y surgen tras elegir la opción de reportar ya sea al

visualizar un comentario o un reclamo. En estas el usuario debe seleccionar de un combo

una razón por defecto, y agregar algunos detalles que le parezcan necesarios.


208

Registrar Usuario, Ingresar al sistema y Recuperar password.

Ilustración 81: Modelo de Presentación - Registrar Usuario, Ingresar al sistema y Recuperar password.

El registro del usuario busca simpleza y rapidez, por lo que se incluyen los datos

indispensables para la creación de la cuenta.

El acceso al sistema también se realiza por una interfaz clásica y simple, permitiendo al

usuario acceder a la recuperación de su contraseña.


209

Visualización de datos del usuario

Ilustración 82: Modelo de Presentación - Visualización de datos del usuario.

Los datos de los usuarios, así como también el acceso a los mensajes de este están

vinculados por un mismo contenedor y un menú de opciones especifico.

Al visualizar los datos del usuario es posible acceder a los reclamos que el usuario ha

realizado previamente, así como también a los reclamos en los que el usuario ha realizado

comentarios.


210

Modificación de datos de usuario

Ilustración 83: Modelo de Presentación - Modificación de datos de usuario.

El usuario podrá acceder a la modificación simple y rápida de sus datos de cuenta. Existen

datos secundarios que no fueron necesarios al momento de crear la cuenta ya que no son

básicos para el funcionamiento del sistema, pero que si aportan la creación de la

comunidad de usuarios como ser la provincia y la edad.


211

Mensajes privados de usuarios

Ilustración 84: Modelo de Presentación - Mensajes privados de usuarios.

El sistema permite un sistema de mensajes interno entre usuarios, dando un soporte a la

vinculación entre estos y por lo tanto generando sensación de comunidad.


212

Carga de imágenes y videos

Ilustración 85: Modelo de Presentación - Carga de imágenes y videos.

Los procesos de carga de imágenes y videos actuaran sobre ventanas auxiliares, y no

sobre la principal donde se realiza todo el resto de despliegue de interfaces. Esto permite

una independencia de procesos pudiendo el usuario continuar sobre la carga del

formulario de reclamo o comentario

Primero el usuario deberá seleccionar un archivo de su disco duro o de otro sitio web.

Una vez hecho esto comenzara el proceso de carga que podría demorar una cantidad

variable de tiempo dependiendo del tamaño del archivo y de las características del

servicio de terceros.

Al finalizar la carga se realizara una modificación mediante Javascript en la ventana

principal, mostrando un thumbnail y opciones para el usuario.


213

4.4.2.4. Modelo de Procesos y Diagramas de flujo de proceso.

Hasta ahora hemos logrado modelar muchas características del sitio que plantea el

proyecto. Para agregar más detalles vamos a describir como serán las acciones de

las clases de proceso planteadas. El Modelo de Procesos abarca:

El Modelo de Estructura de Procesos: describimos las relaciones entre las clases

de procesos.

Diagramas de Flujo de Procesos: Especificamos las actividades conectadas con

cada clase de proceso. Se incluyen los siguientes diagramas:

1. Agregar reclamo.

2. Modificar Reclamo.

3. Elegir Empresa.

4. Elegir Producto.

5. Agregar Imagen.

6. Agregar Video.

7. Agregar Comentario.

8. Reportar Reclamo.

9. Reportar Comentario.

10. Valorar Reclamo.

11. Valorar Comentario.

12. Social Bookmarks.

13. Comentarios RSS.

14. Empresas RSS.

15. Productos RSS.

16. Registrar Usuario.

17. Modificar Usuario.

18. Eliminar Usuario..

19. Enviar Mensaje Usuario

20. Login.

21. Recuperar Password.

22. Logout.

.


214

Modelo de Estructura de Procesos

Ilustración 86: Modelo de Estructura de Procesos - 1.


215

Ilustración 87: Modelo de Estructura de Procesos - 2.


216

Diagramas de Flujo de Procesos

Agregar reclamo

Ilustración 88: Diagrama de Flujo de Proceso - Agregar reclamo.


217

Modificar Reclamo

Ilustración 89: Diagrama de Flujo de Proceso - Modificar Reclamo.


218

Elegir Empresa

Ilustración 90: Diagrama de Flujo de Proceso - Elegir Empresa.


219

Elegir Producto

Ilustración 91: Diagrama de Flujo de Proceso - Elegir Producto.


220

Agregar Imagen

Ilustración 92: Diagrama de Flujo de Proceso - Agregar Imagen.


221

Agregar Video

Ilustración 93: Diagrama de Flujo de Proceso - Agregar Video.


222

Agregar comentario

Ilustración 94: Diagrama de Flujo de Proceso - Agregar comentario.


223

Reportar Reclamo

Ilustración 95: Diagrama de Flujo de Proceso - Reportar Reclamo.

Reportar Comentario

Ilustración 96: Diagrama de Flujo de Proceso - Reportar Comentario.


224

Valorar Reclamo

Ilustración 97: Diagrama de Flujo de Proceso - Valorar Reclamo.

Valorar Comentario

Ilustración 98: Diagrama de Flujo de Proceso - Valorar Comentario.


225

Social Bookmarks

Ilustración 99: Diagrama de Flujo de Proceso - Social Bookmarks.

Comentarios RSS

Ilustración 100: Diagrama de Flujo de Proceso - Comentarios RSS.


226

Empresas RSS

Ilustración 101: Diagrama de Flujo de Proceso - Empresas RSS.

Productos RSS

Ilustración 102: Diagrama de Flujo de Proceso - Productos RSS.


227

Registrar Usuario

Ilustración 103: Diagrama de Flujo de Proceso - Registrar Usuario.

Modificar Usuario

Ilustración 104: Diagrama de Flujo de Proceso - Modificar Usuario.


228

Eliminar Usuario

Ilustración 105: Diagrama de Flujo de Proceso - Eliminar Usuario.

Enviar Mensaje Usuario

Ilustración 106: Diagrama de Flujo de Proceso - Enviar Mensaje Usuario.


229

Login

Ilustración 107: Diagrama de Flujo de Proceso - Login.

Recuperar Password

Ilustración 108: Diagrama de Flujo de Proceso - Recuperar Password.

Logout

Ilustración 109: Diagrama de Flujo de Proceso - Logout.


230

4.4.2.5. Decisiones de diseño del sistema

Para complementar la metodología propuesta por UWE UML, podemos añadir las siguientes

consideraciones de diseño. Recordamos que este trabajo no busca profundizar en los aspectos de

programación y arquitectura del sistema.

Modelo: Se elige el modelo cliente servidor ya que el sistema debe ser necesariamente un

sitio web de Internet. Sera necesario considerar los análisis realizados en el marco teórico

sobre tecnologías de scripting especificas para cada componente del modelo.

Tipo de social media: Se buscara construir una comunidad de contenidos que tomara

como foco las opiniones y experiencias de consumidores sobre empresas y productos. Se

elije el nombre de “MonoFurioso.com: La comunidad de reclamos sobre empresas,

productos y servicios”, con la intención de generar un ambiente relajado en la

comunidad. Como hemos visto en los ejemplos analizados en el marco teórico (Google,

Flickr, YouTube, etc.) muchos nombres “relajados” son utilizados sin afectar la “seriedad”

de un proyecto.

Plataforma base del sistema: Se utilizara como base del sistema al proyecto open source

phpBB2 mencionado en el marco teórico de este trabajo. Brevemente podemos decir que

se ajusta por su simpleza y eficiencia interna de programación. Desarrollado en el

lenguaje PHP y con librerías propias, esta optimizado para el manejo de foros y posts en

foros, contando con un sólido panel de control que permite la administración de usuarios

y la incorporación de módulos que potencialmente podrían adaptarse a necesidades

como ser la sindicación de contenidos. Si bien será necesario realizas numerosas

modificaciones internas y de interfaces, podemos considerarlo como una base solida para

el desarrollo del sistema.

Base de Datos: Se elige trabajar sobre una base de datos MySQL por su probada eficiencia

y eficacia en numerosos proyectos existentes en Internet. Es importante destacar que el

proyecto open source phpBB2 tiene una excelente adaptabilidad al uso de bases de datos

de este tipo.

Aplicaciones de interfaz AJAX: Al considerar opciones de plataformas y librerías para el

desarrollo de aplicaciones AJAX en cliente y servidor, se elige el proyecto AjaxCORE

debido a su flexibilidad y adaptabilidad con proyectos PHP, y a la experiencia previa del

autor de este trabajo práctico con la librería y su aplicación a desarrollos en base a

phpBB2.

Desarrollo de interfaces: Se realizaran interfaces XHTML con hojas de estilo CSS buscando

la menor cantidad posible de gráficos para lograr interfaces agradables, simples y rápidas.

Otras funcionalidades: además de múltiples modificaciones al código original de phpBB2

será necesario buscar MODs adicionales y realizar modificaciones sobre estos de tal

manera que faciliten la implementación de funcionalidades como ser la generación de

nube de tags, sindicación de contenidos y el agregado a marcadores sociales.

Direccionamiento de contenidos: Se generaran URLs únicas que permitan el

direccionamiento granular de los contenidos de la comunidad de contenidos. Estas

seguirán la siguiente estructura:


231

Elemento Estructura

Empresa {sitio}/{empresa}/

Producto {sitio}/{empresa}/{producto}/

Reclamo {sitio}/{empresa}/{producto}/{reclamo} Tabla 13: Estruturas de URLs de los elementos del sitio.

Administración de Imágenes: Se utilizara el servicio de Picasa a través de sus APIs de

desarrollo, ya que provee un soporte amplio, confiable y de costo nulo para la

administración de imágenes.

Administración de Videos: Se elige el servicio brindado por YouTube a través de sus APIs

de desarrolladores, siendo este uno de los exponentes en lo referido a videos en Internet.

El servicio resulta simple de usar e incorporar, sumado a que la gran mayoría de los

usuarios de Internet ya se encuentra familiarizada con su uso.

Servicio de Hosting: se utiliza inicialmente una cuenta de ASmallOrange.com, eligiendo un

plan que se adecue a las necesidades que se planteen en la etapa de implementación.

Blog: Se creara un blog de comunicación externa mediante Wordpress 2.7.1. Este no se

incluye en los modelos de diseño ya que no se realizaran modificaciones a sus

funcionalidades.

Integración con Delicious: Como se modelo en el diseño se facilita la publicación de

reclamos en cuentas de usuarios de Deliciuos, pudiendo estos aplicar tags a los

contenidos de la comunidad. Esto no implicara la creación de una cuenta en el servicio de

marcadores sociales.

Integración con Facebook: Como se modelo en el diseño se facilitará la publicación de

reclamos a las cuentas de usuarios de Facebook, funcionando esto como un marcador

social interno de dicha red social. Adicionalmente se creara una “Facebook Page”.

Integración con Twitter: Para aprovechar lo analizado sobre microbbloging se creara una

cuenta en Twitter, aprovechado a este social media también como medio de

comunicación externa.


232

4.5. Conclusión

Podemos considerar que hemos logrado cumplir los dos objetivos planteados para esta etapa del

proyecto:






El análisis teórico realizado anteriormente y la aplicación de los patrones de diseño Web 2.0 a la

situación problemática nos han brindado requerimientos para el desarrollo de una aplicación de

software que se ajuste al objetivo principal del trabajo.

Posteriormente el uso de UWE UML nos ha brindado una manera de expresar el sistema distinta

al uso de UML tradicional, de una manera que se ajusta mejor al enfoque que este trabajo

mantiene.

Podemos considerar que tenemos una claridad suficiente en lo que respecta al análisis del

sistema y las acciones que el usuario podrá realizar a través el análisis y descripción de casos de

uso.

Y por su parte la etapa de diseño brinda rápidamente una comprensión sobre las necesidades de

navegación sobre el sitio mediante el modelo de navegación y sobre cada una de las interfaces del

sistema mediante los modelos de presentación. Además., las decisiones tomadas y los detalles

brindados nos dan la base para el desarrollo de la última etapa del proyecto, donde abarcaremos

la concreción del modelo teórico.

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Concreción del modelo

233

5. Concreción del modelo

5.1. Introducción Llegamos a la parte final de trabajo final de grado, en la cual buscaremos lograr la ultima parte del

objetivo general concretando la implementación de un sitio web que genere un espacio de

diálogo entre consumidores y empresas, en base a lo desarrollado en el modelo teórico y el marco

teórico.

En esta sección buscaremos cumplimentar el siguiente objetivo específico:

Implementar el sitio en base a la aplicación de los patrones de diseño mencionados en

el campo de acción, utilizando como base desarrollos open source y APIs de terceros.

En busca de este objetivo analizaremos primero los desarrollos open source y servicios elegidos

para la base del desarrollo. Realizaremos una descripción de estos e indicaremos como obtener

una información más detallada de cada uno.

Posteriormente nos aproximaremos a la solución de software implementada, mapeando los

modelos desarrollados en el marco teórico a los archivos creados y/o modificados para obtener la

aplicación, y una descripción del modelo de despliegue necesario. Además podremos observar

interfaces actuales de la versión funcional del proyecto.

Por último, analizaremos la puesta en marcha considerando las necesidades técnicas que

presenta el modelo de despliegue elegido, así como también la capacitación de los usuarios y la

prefactibilidad del proyecto.


234

5.2. Implementación

5.2.1. Proyectos open source y servicios de base

5.2.1.1. phpBB 2.0.23

Este software es la base de muchos foros actualmente existentes en Internet. Experiencias

previas del autor de este trabajo con dicho software proveen un conocimiento suficiente para

realizar modificaciones que permiten que phpBB sea utilizado como base para la creación de una

comunidad de contenidos con un formato claramente diferente al de un foro, pero aprovechando

todas las funcionalidades y optimizaciones para interacciones sociales que brinda phpBB,

convirtiéndolo en una excelente plataforma para una solida construcción y posterior crecimiento

del proyecto. Sera necesario agregar capacidades adicionales mediante la busque da de módulos

existentes y la modificación de estos para adaptarlos al desarrollo de la comunidad.

Es importante destacar que si bien las funcionalidades de base servirán para lograr una

plataforma solida, será necesario modificar ampliamente el proyecto para lograr generar la

solución de social media que persigue este trabajo. El proyecto de base está desarrollado con PHP

y si bien puede asociarse a diversas bases de datos, cuenta con una comprobada compatibilidad

con MySQL, que es la base de datos elegida.

Sitio principal del proyecto: Http://www.phpbb.com

El código fuente puede ser obtenido en: http://sourceforge.net/projects/phpbb/

5.2.1.2. AjaxCORE 1.4

El proyecto open source AjaxCORE provee una librería flexible y simple que permite generar

interacciones AJAX con los usuarios del sitio, lo cual será necesario para generar las interfaces

enriquecidas. El proyecto contempla claramente la teoría analizada en el marco teórico sobre

AJAX.

El proyecto se ha desarrollado en PHP y se basa fuertemente en la librería Prototype de JavaScript

también mencionada previamente. Se manifiesta como una clase que contiene las

funcionalidades necesarias a la cual se debe extender generando las aplicaciones específicas.

Estas deberán ser incluidas en el proyecto de base phpBB 2.0.23.

Sitio principal del proyecto: http://www.ajaxcore.org/

El código fuente puede ser obtenido en: http://sourceforge.net/projects/ajaxcore/

5.2.1.3. YouTube – API PHP Gdata

La comunidad de contenidos YouTube analizada previamente provee una API que permitirá la

integración directa del proyecto con las capacidades que brinda el servicio de videos. Será

utilizada para permitir la carga directa de videos desde la carga de un reclamo o comentario, así

como también integrar los videos al visualizar videos o comentarios.

http://www.phpbb.com/

http://sourceforge.net/projects/phpbb/

http://www.ajaxcore.org/

http://sourceforge.net/projects/ajaxcore/


235

La API se encuentra disponible en diversos lenguajes de programación y entre ellos se encuentra

PHP. Las clases disponibles extienden a la librería Zend Framework de PHP mencionada en el

marco teórico, que permite el manejo de los recursos necesarios a través de la clase Gdata de

Google. Sera necesario integrar este servicio al proyecto de base para lograr las funcionalidades

planteadas en el modelo teórico.

Sitio principal del proyecto:

http://code.google.com/intl/es-ES/apis/youtube/developers_guide_php.html

El código puede ser obtenido en:

http://framework.zend.com/download/gdata/

5.2.1.4. Picasa – API PHP Gdata

La funcionalidad de imágenes del proyecto será basado en el servicio de Picasa, quien provee APIs

que permitirán la integración directa tanto para la carga de imágenes en reclamos y comentarios,

así como también para la visualización de estas en los reclamos y comentarios de la comunidad de

contenidos.

Al igual que la API de YouTube, esta API está disponible en diversos lenguajes de programación,

incluyendo a PHP. Y a su vez, también está basada en la mencionada librería Zend Framework y

Gdata. Sera necesario integrar las clases que la componen al proyecto de base para lograr los

recursos de imágenes planteados en el modelo teórico.

Sitio principal del proyecto:

http://code.google.com/intl/es/apis/picasaweb/developers_guide_php.html

El código puede ser obtenido en:

http://framework.zend.com/download/gdata

5.2.2. Esbozo de la arquitectura del sistema.

Al ser un proyecto basado en Internet utilizaremos el modelo cliente servidor mencionado en el

marco teórico. Es necesario utilizar los conceptos sobre tecnologías de scripting en cliente y

scripting en servidor que hemos desarrollado en dicho marco teórico.

El proyecto phpBB 2.0.023 sienta las bases de la arquitectura del sistema. Utiliza una estructura

típica de proyectos de ese tipo, basándose en archivos PHP, HTML, CSS, JS y base de datos.

En el lado del servidor se utiliza a grandes rasgos el procedimiento mostrado en el marco teórico,

con el agregado de separar generar una separación de funcionalidad y presentación no utilizando

HTML con PHP embebido, sino separando los archivos PHP para la funcionalidad y los archivos

HTML, CSS y JS para la presentación. Estos son unidos para generar la respuesta al cliente

utilizando la clase template incluida en el proyecto de base. 62

62

La clase template puede ser encontrada en el archivo includes/template.php.

http://code.google.com/intl/es-ES/apis/youtube/developers_guide_php.html

http://framework.zend.com/download/gdata/

http://code.google.com/intl/es/apis/picasaweb/developers_guide_php.html

http://framework.zend.com/download/gdata


236

La conexión a la base de datos se realiza de forma similar a la analizada en el ejemplo del marco

teórico, utilizando los mecanismos planteados por el proyecto de base.

Ante una respuesta del servidor el cliente recibirá un archivo HTML relacionado a un archivo de

estilo CSS para la presentación de los contenidos según lo analizado en el marco teórico al

respecto de la separación de estructura, presentación y contenidos. A su vez, contara con diversos

archivos de JavaScript necesarios para las funcionalidades del scripting en el cliente.

Se hace aprovechamiento a su vez de los conceptos desarrollados sobre Web Services y APIs de

servicios. En este caso utilizaremos las provistas por YouTube y Picasa para dar capacidades de

audio y video al sitio. El aprovechamiento de dichos servicios es lo que provee la calificación de

mashup al proyecto de tesis, al reutilizar fuertemente los servicios provistos por terceros

potenciando fuertemente el nuevo servicio planteado en la comunidad de contenidos.

La sindicación de contenidos por su parte es desarrollada mediante RSS 2.0 aprovechando

funcionalidades agregadas de componentes adicionales disponibles para el sistema de base, y

realizando modificaciones sobre dichos componentes para adaptarse a la forma del nuevo

servicio.

Las interfaces enriquecidas son generadas con aplicaciones AJAX, otro concepto analizado en el

marco teórico. AjaxCORE 1.4 es el proyecto que provee dichas capacidades siguiendo los

esquemas planteados al desarrollar el concepto.

De acuerdo a lo planteado en los objetivos de este proyecto y con el objetivo de mantener

acotada la longitud del presente trabajo, no explicaremos en detalle la arquitectura de la solución

de software ya que esto implicaría desarrollar documentación para explicar los productos y

servicios en los cuales se basa este. Dichos desarrollos pueden ser encontrados en las referencia

planteadas sobre cada uno anteriormente, por lo cual nos limitamos a indicar el mapeo de lo

modelado en la etapa de diseño mediante UWE UML sobre los archivos y tablas especificas que

han sido modificados y/o agregados para lograr el funcionamiento de la versión actual del

sistema.

Vale recordar que el código fuente y el modelo relacional estarán disponibles para la

consideración del proyecto al presentar la documentación final.

5.2.2.1. Dependencia de traza entre modelo relacional y modelo de contenidos

Se mantiene la estructura básica del proyecto phpBB 2.0.23, pero se modifican algunas tablas y se

agregan otras para acoplar el modelo de contenidos planteado en el desarrollo del modelo

teórico.

A continuación se muestran las dependencias de traza entre las clases planteadas en dicho

modelo de contenidos y la estructura del modelo relacional del sistema.


237

Ilustración 110: Dependencia de traza entre Modelo Relacional y Modelo de Contenidos.

5.2.2.2. Dependencia de traza entre archivos PHP y clases de procesos.

Las funcionalidades y procesos diseñados mediante el modelo de estructura de procesos y

diagramas de flujos de procesos en la etapa de diseño son implementados en archivos PHP. Se

reutilizan las funcionalidades existentes en el sistema de base cuando es posible, realizándose

modificaciones en los archivos necesarios y creándose nuevos archivos para ampliar la

funcionalidad hasta cubrir lo planteado en el diseño del sistema.

Si bien solo se mencionan los archivos indispensables, hay que considerar que el proyecto

mantiene una alta complejidad involucrando otros archivos que no son mencionados ya que no

tienen un mapeo directo con el modelo. Estos pueden ser analizados al observar el código fuente

que acompaña el proyecto.

A continuación se detalla la dependencia de traza entre las clases de proceso y los archivos PHP

que contemplan dichas funcionalidades.


238

Ilustración 111: Dependencia de traza entre archivos PHP y Clases de Procesos.


239

5.2.2.3. Dependencia de traza entre archivos HTML y clases de presentación.

El modelo de navegación y el modelo de presentación analizados en la etapa de diseño explican

en detalle el funcionamiento de la aplicación y su forma de relacionarse son el usuario. Se han

utilizado fuertemente las clases de presentación para lograr modelar las interfaces necesarias.

Todos los archivos HTML son utilizados por diversos archivos PHP para generar una respuesta al

pedido de un cliente. Estos están diagramados fuertemente mediante XHTML y se combinan con

un archivo de estilo CSS que contiene los detalles de presentación de los datos. A su vez, diversos

archivos JS son invocados dependiendo de las necesidades del sistema.

A continuación se detalla la dependencia de traza entre los archivos HTML y las clases de

presentación planteadas en la etapa de diseño.


240

Ilustración 112: Dependencia de traza entre archivos HTML y clases de presentación.


241

5.2.3. Modelo de despliegue

Como se menciono anteriormente se utiliza el modelo cliente servidor para este proyecto. Hemos

desarrollado este concepto previamente en el marco teórico, analizando el modelo con el detalle

suficiente para el desarrollo del proyecto al considerar tecnologías de scripting en ambas partes.

En el nodo servidor Web se encontrara la aplicación que implementa este proyecto de grado

conteniendo archivos PHP, HTML, CSS, JS y la base de datos. Este nodo se conectará con un

navegador del nodo cliente.

Los detalles y especificaciones técnicas de ambas partes serán comentados posteriormente en

este trabajo al desarrollar la puesta en marcha.

Adicionalmente, se utilizaran servicios de terceros pero no implicaran la generación o

modificación de código fuente, y se mantendrán externos a la aplicación y por tanto externos al

modelo de despliegue.

Ilustración 113: Modelo de despliegue.


242

5.2.4. Prototipos de Interfaces

Para acercar esta documentación al desarrollo obtenido, incluimos algunas capturas de pantalla

de de las interfaces principales diseñadas en el modelo teórico, sin llegar a cubrir toda la

implementación actual. Estas pertenecen a una versión funcional y publicada de manera online,

aunque se seguirán agregando elementos para aproximar del desarrollo aun más al modelo

planteado.

Home

Ilustración 114: Prototipo de Interfaz - Home.

La página principal contiene los elementos principales planteados en el diseño. Se ha buscado

generar un diseño CSS simple y claro como el observado en otros proyectos Web 2.0. Provee una

distribución intuitiva para el usuario, tanto para visualizar contenidos como para acceder a la

carga de estos.


243

Carga de Reclamo

Ilustración 115: Prototipo de Interfaz - Carga de Reclamo.

EL proceso de carga de un reclamo ha sido implementado de la manera diseñada en el modelo

teórico. Utiliza una interfaz enriquecida mediante la aplicación de AJAX para ayudar en la

selección de la empresa (1) y el producto (2). A su vez la carga de imágenes (3) y videos (4) se

realiza mediante las APIs de los servicios de Picasa y YouTube respectivamente.

Una vez ingresados todos los campos necesarios el usuario solo debe seleccionar la opción

“enviar” (5), logrando su objetivo de carga de reclamo en muy pocos pasos y de manera intuitiva.


244

Visualización de un reclamo y carga de comentario.

Ilustración 116: Prototipo de Interfaz - Visualización de un reclamo y carga de comentario.

La visualización de un reclamo ha sido implementada de la manera diseñada en el modelo teórico.

Es posible visualizar rápida y claramente los contenidos del reclamo, pudiendo realizarse acciones

como ser compartir en la red social Facebook, agregar a una cuenta marcadores sociales de

Delicious, valorar el reclamo, reportarlo, y acceder a la sindicación de contenidos de los

comentarios del reclamo.

En la misma interfaz se muestran los comentarios de otros usuarios, y se permite la carga de

nuevos comentarios incluyendo texto, imágenes y videos.


245

5.3. Puesta en Marcha

5.3.1. Infraestructura necesaria

Especificamos a continuación los requerimientos de infraestructura necesarios para los nodos

mencionados en el modelo de despliegue.

5.3.1.1. Tecnología y requerimientos del nodo Cliente.

El software desarrollado debe ser utilizable en cualquier entorno web que sea ampliamente

utilizado en la actualidad. Esto incluye diversos navegadores funcionales en una amplia variedad

de sistemas operativos y entornos de hardware. Incluimos entonces los navegadores en los que es

posible utilizar el sistema debido a que ha sido implementado cuidado su correcto

funcionamiento en ellos.

Microsoft Internet Explorer 6.0 o superior

Mozilla Firefox 2.0 0.1 o superior.

Opera 9.1 o superior.

Por tanto los requerimientos de sistemas operativos y hardware dependen directamente del

navegador que se utilice para acceder al servicio.

5.3.1.2. Tecnología y características del nodo Servidor.

Como se comento en las decisiones de diseño, se ha optado por tercerizar el servicio de hosting

Web. Se ha seleccionado el servicio provisto por la empresa “A Small Orange” eligiendo el servicio

“Small Shared Web Hosting”63, contando el servidor actual con las siguientes características:

Capacidad de almacenamiento en disco de 400 MB.

Transferencia (bandwith) mensual de 10 GB.

Soporte de PHP y MySQL.

Acceso FTP.

Servicios de POP3 y SMTP.

Garantía de disponibilidad del 99.5%.

Ante un eventual crecimiento de las necesidades del nodo servidor será posible cambiar

fácilmente por un servicio que se adecue a nuevos requerimientos.

Una primera versión del sitio ha sido implementada y puede ser encontrada en

http://www.monofurioso.com. A su vez, encontramos las siguientes funcionalidades mencionadas

en las decisiones de diseño:

Blog: http://blog.monofurioso.com

Facebook Page: http://www.facebook.com/pages/MonoFuriosocom/40177294497

Twitter: http://twitter.com/monofuriosocom

63 Podemos encontrar más detalles sobre el servicio en http://asmallorange.com/hosting/shared/

http://www.monofurioso.com/

http://blog.monofurioso.com/

http://www.facebook.com/pages/MonoFuriosocom/40177294497

http://twitter.com/monofuriosocom

http://asmallorange.com/hosting/shared/


246

5.3.2. Capacitación de los usuarios

La capacitación de los usuarios en el caso de este proyecto requiere métodos diferentes a los

utilizados en proyectos tradicionales de software. Como hemos visto uno de los pilares del

concepto Web 2.0 apunta a la usabilidad del software, y dentro de esta usabilidad se encuentra

implícita la necesidad de generar aplicaciones intuitivas.

Como hemos visto en el modelo teórico, se ha buscado simplificar al máximo las interfaces y

minimizar los pasos que el usuario necesita para lograr sus objetivos. Por tanto, es necesario

mantener el esfuerzo en dichos puntos, y aportar solo una ayuda general a los usuarios del

servicio.

Esto se logra generando el “tour guiado” que se ha definido como uno de requerimientos en el

modelo teórico. El desarrollo de dicha interfaz apunta a una comprensión de lo que es la

comunidad de contenidos, y del potencial uso que podrían dar los usuarios en su rol de empresas

o consumidores, y no tanto al uso especifico del software que se muestra. Es decir que para lograr

los objetivos del proyecto Web 2.0 es necesario que los usuarios comprendan el valor que la

comunidad de contenidos puede darles.

Se genera además un apoyo al tour guiado mediante el desarrollo de una serie de “preguntas

frecuentes”, y una explicación de los términos, condiciones y políticas de privacidad de datos.

Todos estos contenidos estarán disponibles de manera permanente en el sitio, tanto para

usuarios registrados como aquellos no registrados.

Por otra parte, no se abarca en el desarrollo de este trabajo las tareas administrativas del servicio,

que deberían ser llevadas a cabo en el backend por un usuario con perfil de administrador y

consecuentemente no se contempla la capacitación de dicho tipo de usuarios en esta

documentación.

Por tanto no será necesario generar formas de capacitaciones adicionales a las ya planteadas en la

etapa de diseño.


247

5.4. Prefactibilidad

El tesista considera que el desarrollo del tema propuesto es factible de ser llevado a cabo,

considerando los aspectos técnicos, operativos y económicos:

5.4.1. Prefactibilidad técnica

En base a la bibliografía disponible y los conocimientos previos adquiridos por el autor de este

trabajo, es posible considerar que el proyecto es factible en su aspecto técnico.

La mayor dificultad presentada por el tema elegido es lograr sintetizar la información disponible

en libros, artículos y blogs sobre la tendencia Web 2.0, para moldear el marco teórico de una

manera apropiada y comprensiva. En este punto la publicación de los patrones de diseño

mencionados ha simplificado considerablemente este desafío, por tanto es necesario lograr una

comprensión de estos y analizar los medios necesarios para su aplicación a proyectos.

En cuanto a la implementación de la solución online, se basa en desarrollos open source

existentes, así como también en los servicios provistos por terceros en base a APIs. La

documentación en estos elementos es amplia por lo que sumado a los conocimientos previos del

alumno será posible desarrollar la implementación de un primer prototipo funcional que busque

modelar la solución al problema.

5.4.2. Prefactibilidad operativa.

Como se menciono anteriormente, el proyecto será diseñado para lograr alcanzar a los usuarios

de Internet, encontrando entre estos los subgrupos comprendidos por empresas y consumidores

de sus servicios.

El sitio online que surge como resultado del desarrollo estará disponible de forma pública y será

difundido a pequeños grupos de usuarios inicialmente, esperando que los mismos efectos de red

permitan intensificar su uso rápidamente. En un principio se espera obtener la atención de los

usuarios de Internet como consumidores, para en base a los reclamos de estos alcanzar a los

usuarios de Internet empresas.

5.4.3. Prefactibilidad económica.

El proyecto es económicamente factible debido a que la investigación se realizará sobre fuentes

de información y publicaciones disponibles en bibliotecas, las cuales se efectúan mayormente de

manera online y se caracterizan por ser gratuitas.

La implementación de la solución de software será programada sobre entornos, proyectos y

servicios open source y gratuitos, provistos por terceros.

Software Costo de licencia

NetBeans PHP IDE Gratuita – open source

MagicDraw 1.51 Gratuito por licencia de estudiante

MagicUWE 1.2 Gratuita por licencia de estudiante

Microsoft Project 2003 Obtenida a travez de convenio con IUA

Microsoft Word 2007 Obtenida a travez de convenio con IUA Tabla 14: Costos de software


248

Proyecto / API Costo de licencia

phpBB 2.0.23 Gratuita – open source

AjaxCORE 1.4 Gratuita – open source

YouTube – API PHP Gdata Gratuita – open source

Picasa – API PHP Gdata Gratuita – open source Tabla 15: Costos de proyectos y APIs de base

En cuanto a costos de infraestructura se ha considerado el servicio “Small Shared Web Hosting”

de “A Small Orange” (más detalle de esto puede ser encontrado en el apartado “Tecnología y

características del nodo Servidor.”) que tiene un costo anual de USD$60, aunque este costo es

despreciable ya que el tesista ya cuenta con dicho servicio para otros proyectos personales.

A continuación consideramos los costos de recursos humanos por hora para la generación del

modelo teorico y la concreción del modelo. Las horas se calculan considerando 4 horas laborales

por día incluido en cada actividad, sin analizar en detalle las subactividades que incluyen64 y el

costo por hora del tipo de personal se basa en los honorarios publicacos por el Consejo

Profesional de Ciencias Informáticas de la Provincia de Córdoba (CPCIPC)65.

Actividad Tipo de personal Costo-hora horas Costo de la actividad

Planificación Jefe de Proyectos 85 12 1020

Análisis de requerimientos

Analista 55 68 3740

Análisis de sistema Analista 55 20 1100

Diseño de sistema Analista 55 124 6820

Implementación Programador de Páginas Web

45 172 7740

Costo total: 20420 Tabla 16: Costos de recursos humanos

Por tanto, si bien el proyecto no posee apoyo económico de terceros, la inversión principal será

de tiempo, y el costo principal será el costo oportunidad que presente la situación. Igualmente,

los resultados esperados del proyecto y sus posibles aplicaciones futuras presentan un justo

balance a esta inversión.

64 Las subactividades y sus duraciones pueden ser claramente apreciadas en el diagrama Gantt incluido en

la planificación del proyecto.

65 Los honorarios considerados por el CPCIPC pueden encontrarse en

http://www.cpcipc.org.ar/portal/index.php?option=com_content&task=view&id=17&Itemid=33


249

5.5. Conclusión

Al llegar al final de la etapa de concreción del modelo, es posible considerar que se ha alcanzado

el objetivo específico planteado:

Implementar el sitio en base a la aplicación de los patrones de diseño mencionados en

el campo de acción, utilizando como base desarrollos open source y APIs de terceros.

Este es el último de los objetivos específicos que este trabajo de grado persigue, por lo cual

podemos dar por finalizado el desarrollo de las etapas de documentación del proyecto.

Se ha alcanzado una implementación de software que debería ser la solución planteada al

problema analizado en un primer momento.

Es importante destacar que ésta implementación es solo parcial, ya que el software desarrollado

deberá ser mantenido y actualizado permanentemente, como plantea el patrón de diseño de beta

perpetuo.

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Conclusiones

250

6. Conclusiones

Se ha llegado a la conclusión de este trabajo final de grado. Es posible considerar que se han

alcanzado tanto el objetivo general como los objetivos particulares planteados en la introducción

del proyecto, destacándose los siguientes resultados:

Se tiene una solida base teórica sobre la tendencia Web 2.0, conociendo de manera

general los diferentes tipos de social media en los cuales se manifiesta dicha tendencia. A

su vez conocemos la forma en que los usuarios de Internet (tanto en su rol de

consumidores como de empresas) se relacionan actualmente con esta red, y las

tendencias futuras consideradas por diversas fuentes.

Para canalizar estos conocimientos, el autor de este trabajo ha analizado patrones de

diseño que surgen de la observación de diversos social media, obteniendo un

conocimiento más profundo de las prácticas que permiten aprovechar el potencial de

Internet como base para el desarrollo de soluciones a una gran variedad de situaciones.

Posteriormente, se han considerado los aspectos técnicos, tecnológicos y metodológicos

necesarios para llevar a cabo el desarrollo de dicho tipo de proyectos completando así la

investigación teórica del proyecto de grado, y contando el tesista con los conocimientos

necesarios para desarrollar una solución al problema planteado.

Como implementación practica se ha desarrollado un sitio online en base a un desarrollo

de requerimientos considerando la situación problemática a los ojos de los patrones de

diseño Web 2.0, y llevando a cabo el análisis y diseño de la aplicación mediante UWE

UML, y aprovechando servicios de terceros y proyectos open source para maximizar las

fortalezas del servicio.

La mencionada aplicación se encuentra funcional en la actualidad, con el compromiso del autor

del trabajo de dedicar esfuerzo personal en el desarrollo y crecimiento futuro de la comunidad de

contenidos que ha surgido del desarrollo del proyecto, ya que considera que genuinamente es la

base para un lugar de participación, abierto a la retroalimentación y generación de libre de

contenidos, que facilite la conversación de una comunidad de consumidores y empresas

aprovechando el factor de conectividad y alcance cada vez más amplio de Internet.

Este trabajo demuestra el potencial que se encuentra en Internet hoy en día habiendo pasado de

ser una revolución tecnológica a una revolución social al convertirse en un medio libre y

descentralizado de creación y distribución de contenidos, a medida que surgen más y más

ejemplos a nivel global y local de la realidad planteada en The Cluetrain Manifesto.

TFG: Análisis de la tendencia Web 2.0, y su aplicación a la relación cliente-empresa IUA Ingeniería de Sistemas – Bibliografía

251

7. Bibliografía

1. Ortiz de Zárate Tercero, Alberto. Manual de uso del blog en la empresa - Cómo prosperar en la

sociedad de la conversación. Barcelona : Zero Factory, S. L., 2008. 978-84-612-1535-5.

2. Arrington, Michael. TechCrunch. [En línea] 6 de Abril de 2008.

http://www.techcrunch.com/2008/04/06/comcast-twitter-and-the-chicken-trust-me-i-have-a-

point/.

3. Garfield, Bob. Comcast Must Die. [En línea] http://www.comcastmustdie.com.

4. McGregor, Jena. BusinessWeek. Consumer Vigilantes. [En línea]

http://www.businessweek.com/magazine/content/08_09/b4073038437662.htm.

5. BikeForums.net. [En línea] http://www.bikeforums.net/video/ .

6. CNNMoney.com. Kryptonite scrambles to find solution. Recall of flawed U-shaped locks could

cost firms tens of millions of dollars, experts say. [En línea] 17 de 10 de 2004.

http://money.cnn.com/2004/09/17/news/midcaps/kryptonite/.

7. Havenstein, Heather. COMPUTERWORLD. Customer Service 2.0: Clients become brand

managers. [En línea] 28 de 5 de 2008.

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=909039

8.

8. Pirulee y Albert, Pere. Manifesto Cluetrain en Español. [En línea]

http://tremendo.com/cluetrain/.

9. John Musser, Tim O’Reilly and the O’Reilly Radar Team. Web 2.0 Principles and Best Practices.

Sebastopol, CA, USA : O’Reilly Media, Inc., 2007. 0-596-52769-1.

10. Mayfield, Antony. What is Social Media? [En línea] 8 de Enero de 2008.

http://www.icrossing.co.uk/fileadmin/uploads/eBooks/What_is_Social_Media_iCrossing_ebook.p

df.

11. Tabak, Alan. Hundreds Register for New Facebook Website. The Harvard Crimson. [En línea] 9

de Febrero de 2004. http://www.thecrimson.com/article.aspx?ref=357292.

12. Facebook. Facebook Statistics. [En línea] [Citado el: 24 de Octubre de 2008.]

http://www.facebook.com/press/info.php?statistics.

13. It’s Official: Google + MySpace = OpenSocial. Mashable. [En línea] 1 de Noviembre de 2007.

http://mashable.com/2007/11/01/myspace-google-2/.

14. Orkut. Orkut Demografia. [En línea] [Citado el: 24 de Octubre de 2008.]

http://www.orkut.com/Main#MembersAll.aspx.


252

15. Riley, Duncan. Google Opens OpenSocial Site And Provides Orkut Support. TechCrunch. [En

línea] 2 de Noviembre de 2007. http://www.techcrunch.com/2007/11/02/google-opens-

opensocial-site-and-orkut-support/.

16. Nash, Adam. LinkedIn & Open Social. The LinkedIn Blog. [En línea] 31 de Octubre de 2007.

http://blog.linkedin.com/blog/2007/10/linkedin-open-s.html.

17. TARGET Nos vemos en la Web. Cannilla, Flavio y Garzón de la Rosa, Tomás. Edicion especial,

Buenos Aires : El Cronista Comercial S.A, 2008. ISSN 0328-6401.

18. Experian Integrated Marketing. Discussion paper - Social Networking in 2008. [En línea] Enero

de 2008.

http://www.experianim.com/download/the_impact_of_social_networking_white_paper_-

_final.pdf.

19. Blogger. [En línea] http://www.blogger.com.

20. Wordpress. [En línea] http://wordpress.com/.

21. Technorati. State of the Blogosphere 2008. [En línea] http://technorati.com/blogging/state-

of-the-blogosphere/.

22. Ebersbach, Anja, y otros. Wiki: Web Collaboration. s.l. : Springer, 2008. ISBN-10: 3540351507.

23. Cunningham, Ward y Leuf, Bo. The Wiki Way: Quick Collaboration on the Web. s.l. : Addison-

Wesley Professional, 2001. ISBN-10: 020171499X.

24. Wikipedia: About - Wikipedia, the free encyclopedia. [En línea] [Citado el: 27 de Octubre de

2008.] http://en.wikipedia.org/wiki/Wikipedia:About.

25. Giles, Jim. Internet encyclopaedias go head to head. Nature Publishing Group. [En línea] 15 de

Diciembre de 2005. http://www.nature.com/nature/journal/v438/n7070/full/438900a.html.

26. Javapedia. [En línea] http://wiki.java.net/bin/view/Javapedia/WebHome.

27. Clarin.com Podcast Informativos. [En línea]

http://www.clarin.com/shared/v8/podcasting.html.

28. Forum Discussion Search With BoardTracker.com. [En línea] http://v2.boardtracker.com/.

29. O'Keefe, Patrick. Managing Online Forums. New York, USA : Amacom, 2008. ISBN 978-0-8144-

0197-2.

30. phpBB - Creating Communities Worldwide. [En línea] http://www.phpbb.com/.

31. Flickr Services. [En línea] http://www.flickr.com/services/api/.

32. Schonfeld, Erick. The Flickrization of Yahoo! CNNMoney.com. [En línea] 1 de Diciembre de

2005. http://money.cnn.com/magazines/business2/business2_archive/2005/12/01/8364623/.


253

33. Ins and Outs: Does YouTube fit on the boob tube? Engadged. [En línea] 18 de Julio de 2007.

http://www.engadget.com/2007/07/18/ins-and-outs-does-youtube-fit-on-the-boob-tube/.

34. YouTube Developer APIs. [En línea] http://www.youtube.com/dev.

35. Google buys YouTube for $1.65bn. BBC News. [En línea] 10 de Octubre de 2006.

http://news.bbc.co.uk/1/hi/business/6034577.stm.

36. Digg - Overview. [En línea] http://digg.com/about/.

37. Menéame. [En línea] http://meneame.net/.

38. Twitter. [En línea] http://twitter.com/home.

39. Hopkins, Heather. Twitter Gaining Momentum But Still Niche. Hitwise. [En línea] 29 de Abril

de 2008. http://weblogs.hitwise.com/us-heather-

hopkins/2008/04/twitter_gaining_momentum_but_s_1.html.

40. Dougherty, Heather. Twitter growth continues despite outages. Hitwise. [En línea] 8 de Julio

de 2008. [Citado el: 23 de Octubre de 2008.] http://weblogs.hitwise.com/heather-

dougherty/2008/07/twitter_growth_continues_despi_1.html.

41. Tancer, Bill. Even Gen X is aTwitter. Time. [En línea] 20 de Agosto de 2008.

http://www.time.com/time/business/article/0,8599,1834131,00.html.

42. Hirsch, Adam. CNN Heavily Promoting Twitter On Air, Making Big Moves in Social Media.

Mashable. [En línea] 4 de Septiembre de 2008. http://mashable.com/2008/09/04/cnn-twitter/.

43. Laube, Natalia y Pacho, Mariana. El huracán Twitter. Clarin.com. [En línea] 31 de Agosto de

2007. http://www.clarin.com/diario/2007/08/31/conexiones/t-01488847.htm.

44. Musser, John. Twitter API Traffic is 10x Twitter’s Site. ProgrammableWeb. [En línea] 10 de

Septiembre de 2007. http://blog.programmableweb.com/2007/09/10/twitter-api-traffic-is-10x-

twitters-site/.

45. Twitter API wiki. [En línea] http://apiwiki.twitter.com/.

46. Bloglines - Stay up to-the-minute on all your favorites. [En línea] https://www.bloglines.com/.

47. Yee, Raymond. Pro Web 2.0 Mashups: Remixing Data and Web Services. Febrero : Apress,

2008. ISBN-10: 159059858X.

48. Grossman, Lev. Time. Time's Person of the Year: You. [En línea] 13 de 12 de 2006.

http://www.time.com/time/magazine/article/0,9171,1569514,00.html.

49. D’Alessio IROL. Internet en Argentina 2005-2006. [En línea]

http://www.digikol.com.ar/recursos/pdfs/internetargentina.pdf.

50. Price & Cooke. Perfil del Usuario de Internet en Argentina 2007. [En línea] Diciembre de 2007.

http://www.princecooke.com/estudios/usuario_internet_2007.asp.


254

51. International Telecomunication Union. Internet indicators: subscribers, users and broadband

subscribers. [En línea] http://www.itu.int/ITU-D/ICTEYE/Reports.aspx.

52. Carrier y Asoc. Internet es banda ancha. [En línea] 27 de Junio de 2008.

http://www.carrieryasoc.com/index.php?option=com_content&task=view&id=413.

53. The GSM Association. Worldwide cellular connections exceeds 2 billion. GSM World. [En línea]

15 de Septiembre de 2005. http://www.gsmworld.com/news/press_2005/press05_21.shtml.

54. BuddeComm. 2007 Latin America - Telecoms, Mobile and Broadband in Mercosur, Guyana,

Suriname, Venezuela. [En línea] 28 de Marzo de 2007.

http://www.budde.com.au/buddereports/4218/2007_Latin_America_-

_Telecoms_Mobile_and_Broadband_in_Mercosur_Guyana_Suriname_Venezuela.aspx?sub=EXEC

UTIVE.

55. Tedesco, Pablo. Mercado móvil en Argentina – 3G. Prince & Cooke. [En línea] Diciembre de

2007. http://www.spkrsbr.com/biblioteca/htm/telefonia_movil.PDF.

56. Rainie, Lee y Horrigan, John. Pew Internet & American Life Project. A decade of adoption:

How the internet has woven itself into American life. [En línea] 25 de Enero de 2005.

http://www.pewinternet.org/pdfs/Internet_Status_2005.pdf.

57. Sifry, David. The State of the Live Web, April 2007. Sifry's Alerts. [En línea] 5 de Abril de 2007.

http://www.sifry.com/alerts/archives/000493.html.

58. Gonsalves, Antone. InformationWeek. Social Networks Attract Nearly Half Of All Web Users.

[En línea] 12 de Mayo de 2006.

http://www.informationweek.com/news/internet/ebusiness/showArticle.jhtml?articleID=187202

878.

59. Carrier y Asoc. ArgenWeb 2.0. [En línea] 11 de Abril de 2008.

http://www.carrieryasoc.com/index.php?option=com_content&task=view&id=339&Itemid=1.

60. Dans, Enrique. La empresa y la Web 2.0, artículo en Harvard Deusto. El blog de Enrique Dans.

[En línea] 4 de Junio de 2007. http://www.enriquedans.com/2007/06/la-empresa-y-la-web-20-

articulo-en-harvard-deusto.html.

61. Celaya, Javier y Herrera, Pablo. Los blogs en la comunicación empresarial en España: Últimas

tendencias”. Madrid : Grupo BPMO Ediciones, 2006. ISBN-10: 84-611-0074-3.

62. TARGET Blogs, por ahora una ola verde. Valleboni, Cecilia. Edicion especial, Buenos Aires : El

Cronista Comercial S.A, 2008. ISSN 0328-6401.

63. Jarvis, Jeff. Dell Hell. BuzzMachine. [En línea] 2005.

http://www.buzzmachine.com/archives/cat_dell.html.

64. Dell. About. Ideastorm. [En línea]

http://www.ideastorm.com/ideaAbout?pt=About+IdeaStorm.


255

65. Zanoni, Leandro. Medios Sociales. eBlog. [En línea] 16 de Octubre de 2008.

http://eblog.com.ar/4916/medios-sociales/.

66. O'Reilly, Tim. What Is Web 2.0. Design Patterns and Business Models for the Next Generation

of Software. [En línea] 30 de Septiembre de 2005.

http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html.

67. Metcalfe, Bob. Metcalfe’s Law Recurses Down the Long Tail of Social Networking. [En línea]

[Citado el: 31 de Octubre de 2008.] http://vcmike.wordpress.com/2006/08/18/metcalfe-social-

networks/.

68. Reed, David P. That Sneaky Exponential—Beyond Metcalfe's Law to the Power of Community

Building. [En línea] [Citado el: 31 de Octubre de 2008.]

http://www.reed.com/gfn/docs/reedslaw.html.

69. Koman, Richard. Stewart Butterfield on Flickr. O'Reilly Media. [En línea] 2 de Abril de 2005.

http://www.oreillynet.com/pub/a/network/2005/02/04/sb_flckr.html.

70. Statistics . Wikipedia, the free encyclopedia. [En línea] [Citado el: 2 de Noviembre de 2008.]

http://en.wikipedia.org/wiki/Special:Statistics.

71. Stewart, Sharla A. Can behavioral economics save us from ourselves? Theuniversity of Chicago

Magazine. [En línea] Febrero de 2005.

http://magazine.uchicago.edu/0502/features/economics.shtml.

72. NAVTEQ. [En línea] http://www.navteq.com/.

73. Haughey, Matt. Flickr’s Creative Commons area back, grown way over a million images

licensed. Creative Commons. [En línea] 29 de Abril de 2005.

http://creativecommons.org/weblog/entry/5425.

74. Schutzberg, Adena. The Technology Behind Google Maps. Directions Magazine. [En línea] 19

de Febrero de 2005. http://www.directionsmag.com/article.php?article_id=760&trv=1.

75. deCarta. Telcontar Unveils Framework and Fluid Maps . Directions Magazine. [En línea] 8 de

Mayo de 2008.

http://www.directionsmag.com/press.releases/index.php?duty=Show&id=14216&trv=1.

76. Prescott, LeeAnn. PhotoBucket Leads Photo Sharing Sites; Flickr at #6. Hitwise Intelligence. [En

línea] 21 de Junio de 2006. http://weblogs.hitwise.com/leeann-

prescott/2006/06/photobucket_leads_photo_sharin.html.

77. Frommer, Dan. Your Tube, Whose Dime? Forbes. [En línea] 28 de Abril de 2006.

http://www.forbes.com/intelligentinfrastructure/2006/04/27/video-youtube-

myspace_cx_df_0428video.html.

78. Musser, John. eBay Opens Platform to 3rd Party Developers. ProgrammableWeb. [En línea] 16

de Junio de 2008. http://blog.programmableweb.com/2008/06/16/ebay-opens-platform-to-3rd-

party-developers/.


256

79. ProgrammableWeb. Flickr API Mashups. [En línea] [Citado el: 4 de Noviembre de 2008.]

http://www.programmableweb.com/api/flickr/mashups.

80. —. YouTube API Mashups. [En línea] [Citado el: 4 de Noviembre de 2008.]

http://www.programmableweb.com/api/youtube/mashups.

81. Musser, John. 1,000 Web APIs. ProgrammableWeb. [En línea] 3 de Noviembre de 2008.

http://blog.programmableweb.com/2008/11/03/1000-web-apis/.

82. Using JSON (JavaScript Object Notation) with Yahoo! Web Services. Yahoo! Developer

Network. [En línea] http://developer.yahoo.com/common/json.html.

83. Twitter Technology Blog. [En línea] http://dev.twitter.com/.

84. Eventful API and Services. [En línea] http://api.eventful.com/.

85. Yahoo! Tech. [En línea] http://tech.yahoo.com/.

86. Yahoo! Shopping Web Services. [En línea] http://developer.yahoo.com/shopping/.

87. Hardy, Quentin. Why Google Loves The Little Guys. Forbes. [En línea] 18 de Agosto de 2006.

http://www.forbes.com/business/2006/09/17/mashup-search-google-tech-

cz_qh_0918google.html.

88. TiVo - Most Popular: Actor, Directo and Show WishLists. [En línea] [Citado el: 7 de Noviembre

de 2008.] http://www3.tivo.com/tivo-tco/top25.do?show25=seasonpass.

89. Kincaid, Jason. Exclusive Look at Plazes for iPhone. TechCrunch. [En línea] 15 de Mayo de

2008. http://www.techcrunch.com/2008/05/15/exclusive-look-at-plazes-for-iphone/.

90. Biggs, John. ScanLife: Barcode Scanning for the 21st Century and Beyond. TechCrunch. [En

línea] 8 de Julio de 2008. http://www.techcrunch.com/2008/07/08/scanlife-barcode-scanning-

for-the-21st-century-and-beyond/.

91. Raymond, Eric S. The Cathedral & the Bazaar. s.l. : O'Reilly, 1999. ISBN 1-56592-724-9.

92. Fried, Jason. Web 2.0 Review: Don't forget there's another kind of scaling. 37signals. [En línea]

9 de Octubre de 2004. http://www.37signals.com/svn/archives/000881.php.

93. Anderson, Chris. The Long Tail : Why the Future of Business Is Selling Less of More. New York :

Hyperion, 2006. ISBN 1-4013-0237-8.

94. Hornik, David. Where's The Money In The Long Tail? VentureBlog. [En línea] 13 de Diciembre

de 2005. http://ventureblog.com/articles/2005/12/wheres_the_mone.php.

95. Surowiecki, James. The Wisdom of Crowds. s.l. : Anchor , 2004. ISBN-10: 0385721706.

96. Godin, Seth. Small is the new big. Seth Godin's Blog. [En línea] 5 de Junio de 2005.

http://sethgodin.typepad.com/seths_blog/2005/06/small_is_the_ne.html.


257

97. Stern, Allen. Future of Web Apps - Kevin Rose. CenterNetworks. [En línea] 13 de Septiembre

de 2006. http://www.centernetworks.com/future-of-web-apps-kevin-rose.

98. Amazon S3. [En línea] http://aws.amazon.com/s3/.

99. Cloud Computing For Web Applications - 3Tera. [En línea] http://www.3tera.com/.

100. Vossen, Gottfried y Hagemann, Stephan. Unleashing Web 2.0: From Concepts to Creativity.

s.l. : Morgan Kaufmann , 2007. ISBN-10: 0123740347.

101. Science, Nature International Weekly Journal of. The web is a bow tie . Vol. 405, página 113.

[En línea] 11 de Mayo de 200.

http://www.nature.com/nature/journal/v405/n6783/pdf/405113a0.pdf.

102. Levene, M. An Introduction to Search Engines and Web Navigation. s.l. : Addison Wesley

Publishing Compan, 2005. ISBN-10: 0321306775.

103. Page, Lawrence y Brin, Sergey. The Anatomy of a Large-Scale Hypertextual Web Search

Engine. [En línea] 1998. http://infolab.stanford.edu/~backrub/google.html.

104. Amazon eCommerce API. ProgrammableWeb. [En línea] [Citado el: 19 de Noviembre de

2008.] http://www.programmableweb.com/api/amazon-ecommerce.

105. Asleson, Ryan y Schutta, Nathaniel. Foundations of Ajax. s.l. : Apress, 2009. ISBN-10:

1590595823.

106. Wright, Alex. Folksonomy. Ale Wright.org. [En línea] 23 de Agosto de 2004.

http://www.alexwright.org/blog/archives/000900.html.

107. Shirky, Clay. Folksonomy. Many-to-Many. [En línea] 25 de Agosto de 2004.

many.corante.com/archives/2004/08/25/folksonomy.php.

108. Sturtz, David N. Communal Categorization: The Folksonomy. [En línea] 16 de Diciembre de

2004. http://davidsturtz.com/drexel/622/communal-categorization-the-folksonomy.html.

109. Manifesto for Agile Software Development. [En línea] 2001. http://www.agilemanifesto.org/.

110. Kappel, Gerti, y otros. Web Engineering: The Discipline of Systematic Development of Web

Applications. s.l. : Wiley, 2006. ISBN-10: 0470015543.

111. Rossi, Gustavo, y otros. Web Engineering: Modelling and Implementing Web Applications.

Londres : Springer, 2007. ISBN-10: 184628922X.

112. Koch, Nora. Model-Driven Web Engineering: UWE Approach. [En línea] 28 de Mayo de 2008.

http://www.pst.ifi.lmu.de/projekte/uwe/publications/MDWE-UWE_URJC_280508.pdf.

113. UWE – UML-based Web Engineering. Model Examples. [En línea]

http://www.pst.ifi.lmu.de/projekte/uwe/examples.html.


258

114. Mahemoff, Michael. Ajax Design Patterns. Sebastopol, CA : O'Reilly Media, Inc., 2006. ISBN:

0-596-10180-5.

115. Frameworks. Ajax Patterns. [En línea] [Citado el: 25 de Noviembre de 2008.]

http://ajaxpatterns.org/Ajax_Frameworks.

116. List of web application frameworks. Wikipedia. [En línea]

http://en.wikipedia.org/wiki/List_of_web_application_frameworks.

117. Locke, Christopher, Searls, Doc y Weinberger, David. The Cluetrain Manifesto. s.l. : Basic

Books, 6 de Enero del 2000. ISBN-13: 978-0738202440.

118. Hagemann, Stephan y Vossen, Gottfried. Unleashing Web 2.0: From Concepts to Creativity.

s.l. : Morgan Kaufmann, 2007. ISBN-10: 0123740347.

119. Locke, Christopher,Searls, Doc y Weinberger, David. The Cluetrain Manifesto. [En línea]

Abril de 1999. http://www.cluetrain.com/..

120. Arrington, Michael. TechCrunch. End Of Speculation: The Real Twitter Usage Numbers. [En

línea] 28 de Abril de 2008. http://www.techcrunch.com/2008/04/29/end-of-speculation-the-real-

twitter-usage-numbers/.

121. Wikipedia. List of social networking websites. [En línea]

http://en.wikipedia.org/wiki/List_of_social_networking_websites.

122. Facebook. Facebook Developers. [En línea] http://developers.facebook.com/.

123. Google Code. OpenSocial. [En línea] http://code.google.com/apis/opensocial/.

124. Plugin API WordPress Codex. [En línea] http://codex.wordpress.org/Plugin_API.

125. Blogger Data API. Google Code. [En línea] http://code.google.com/apis/blogger/.

126. GNU General Public License. Free Software Foundation (FSF). [En línea]

http://www.gnu.org/copyleft/gpl.html.

127. (FSF), Free Software Foundation. GNU General Public License. [En línea]

http://www.gnu.org/copyleft/gpl.html.

128. RSS 2.0 Specification. [En línea] http://www.rssboard.org/rss-specification.

129. Bennett, Keith, y otros. Service-Based Software: The Future for Flexible Software. [En línea]

1999. http://www.bds.ie/Pdf/ServiceOriented1.pdf.

130. Association, Software & Information Industry. Software as a Service: Strategic

Backgrounder. [En línea] Febrero de 200. http://www.siia.net/estore/ssb-01.pdf.

131. Prensky, Marc. Digital Natives, Digital Immigrants. On the Horizon - MCB University Press.

Octubre, 2001, Vol. 9, 5.

132. 3G. Wikipedia. [En línea] http://en.wikipedia.org/wiki/3G.


259

133. Bricklin, Dan. Cornucopia of the Commons: How to Get Volunteer Labor. [En línea]

http://www.bricklin.com/cornucopia.htm.

134. Meyer, Carl D. y Langville, Amy N. Google's PageRank and Beyond: The Science of Search

Engine Rankings. Princeton, New Yersey : Princeton University Press, 2006. IDBN-13: 978-0-691-

12202-1.

135. Musciano, Chuck y Kennedy, Bill. HTML & XHTML: The Definitive Guide. s.l. : O'Reilly Media,

Inc., 2006. ISBN-10: 0596527322.

136. Harold, Elliotte R. XML 1.1 Bible. Indiana : Wiley Publishing Inc., 2004. ISBN: 0-7645-4986-3.

137. W3C. XHTML 1.0 The Extensible HyperText Markup Language (Second Edition). [En línea] 26

de Enero de 2000. http://www.w3.org/TR/xhtml1/#dtds.

138. Meyer, Eric. CSS: The Definitive Guide. s.l. : O'Reilly Media, Inc., 2006. ISBN-10: 0596527330.

139. Melton, Jim y Buxton, Stephen. Querying XML, : XQuery, XPath, and SQL/XML in context. San

Francisco, California : Morgan Kaufmann, 2006. ISBN-10: 1558607110.

140. Dublin Core Metadata Element Set Version 1.1. [En línea] 14 de Enero de 2008.

http://dublincore.org/documents/dces/.

141. DeWitt, Clinton. Specifications - OpenSearch - 1.1 - Draft 3. [En línea]

http://www.opensearch.org/Specifications/OpenSearch/1.1.

142. Allaire, J. Flash MX - A Next Generation Rich Client. s.l. : Macromedia, 2002.

143. Fielding, Thomas. Architectural Styles and the Design of Network-based Software

Architectures. Irvine, CA : Ph.D. Thesis, University of California, 2000.

144. Vander Wal, Thomas. Folksonomy. VanderWal.net. [En línea] 2 de Febrero de 2007.

http://www.vanderwal.net/folksonomy.html.

145. Shore, James y Warden, Shane. The Art of Agile Development. s.l. : O'Reilly Media, Inc.,

2007. ISBN-10: 0596527675.

Tesis Ingenieria de Sistemas - Trabajo de Grado - Web 2.0

Documents

Transcript of Tesis Ingenieria de Sistemas - Trabajo de Grado - Web 2.0