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
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/
i
IUA Ingeniería de Sistemas – Dedicatoria
Dedicatoria
A Ana y Juan, mis padres.
ii
IUA Ingeniería de Sistemas – Agradecimientos
Agradecimientos
A mi familia.
A mis amistades.
iii
IUA Ingeniería de Sistemas – Abstract
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.
iv
IUA Ingeniería de Sistemas – Índice de figuras
Í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
5
IUA Ingeniería de Sistemas - Índice de contenidos
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
6
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
7
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
8
Í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
9
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
10
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
11
IUA Ingeniería de Sistemas – Índice de Tablas
Í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
12
IUA Ingeniería de Sistemas – Introducción
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).
13
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,
2
para lograr que su aplicación en base a patrones de diseño 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).
14
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.
15
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).
16
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.
17
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.
18
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.
19
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:
20
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
21
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.
22
IUA Ingeniería de Sistemas – Marco Contextual
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.
23
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):

24
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.
25
IUA Ingeniería de Sistemas – Marco Teórico
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.
26
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.
27
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)
28
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
29
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).
30
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).
31
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.
32
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 Ilustración 1: Edad y sexo de autores de blogs. Technorati 2008:
puedan ingresar al sitio.
9
Podemos encontrar información sobre las APIs de Wordpress en (124) y las APIs de Blogger en (125).
33
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 Technorati 10 (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
Ilustración 2: Bloggers personales, corporativos y profesionales.
los mismos blogs o en otros de su
misma autoría. Grupos no mutuamente excluyentes – Technorati 2008.
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
34
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.
Percepciones sobre blogs y medios tradicionales
Los blogs estan siendo considerados seriamente como

fuentes de información 71
Más gente recibira sus noticias y entretenimiento desde
blogs que de medios tradicionales en los proximos 5… 51
Los blogs son fuentes de información tan validos como
los medios tradicionales 49
Obtengo mas de mis noticias e informaciones desde
blogs y no tanto desde medios tradicionales 43
Los blogs estan frecuentemente escritos mejor que
articulos en medios tradicionales 37
Los periodicos no sobreviviran los proximos 10 años.
21
0 10 20 30 40 50 60 70 80
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”.
35
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.
36
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
14
Recorder), 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.
37
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).
38
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)
16
Las 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/.
39
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.
40
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 Ilustración 4: Estadísticas de HitWise sobre Twitter.
dicho numero representaba un Porcentaje de visitas a Twitter por parte de usuarios de Internet en
crecimiento del 60% respecto al Estados unidos, comparado con otros sitios de microblogging. Julio del
mes anterior (39). Y para Julio del 2008
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
41
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
Ilustración 5: Twitter de Barack Obama, candidato presidencial para
como recurso para obtener y Estados Unidos.
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.
42
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 Craiglist 20
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.
43
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.
44
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
45
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.
46
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.”
47
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

Banda ancha en hogares con
más común, lo que permite que los Internet en Argentina - %
usuarios estén conectados de forma 100 94
virtualmente permanente. En marzo del
80 72
2006 en Estados Unidos un 42% de la
población tenía acceso a Banda Ancha, 60 45
mostrando un crecimiento del 40% 40
22
sobre el año anterior. En el caso de 13
20
Argentina según el ITU (51) en el 2007
0
solo el 6.58% del total de la población
tiene acceso a Internet Banda Ancha 2004 2005 2006 2007 2008
creciendo ampliamente en comparación Ilustración 7: Banda ancha en hogares con Internet en Argentina.
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
48
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 Ilustración 8: Blogs indexados por Technorati - Marzo del 2003 a
las 10 redes sociales más Marzo del 2007.
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).
49
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

Contenidos subidos a Internet por usuarios
Asociados en base a un estudio realizado en
Argentinos - %
Noviembre del 2007 indica que en dicho país
100
“existen 5 millones de personas que participan 82
activamente de la Web 2.0 de los cuales 1,4 80
millón lo hacen con una frecuencia al menos 60
43
semanal (…) el principal contenido subido a la red 40
son fotos, compartidas por el 82% de los usuarios 15
20
2.0, lo que equivale a 4,1 millones de personas,
0
porcentaje que crece en la medida en que baja la
Fotos Textos Videos
edad. Luego, con un 43%, sigue el upload de
texto, aunque en este caso este valor crece a Ilustración 9: Contenidos subidos a Internet por
medida que sube la edad y aumenta la usuarios Argentinos.
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.
50
¿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 41% 48% 11%

odio).
Publico información o rumores que escucho sobre 31% 32% 37%
las empresas.
Publico sobre algunas de mis experiencias de la 34% 45% 21%
vida diaria en empresas y con atención al cliente.
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

Usuarios que consultan sitios para
comercial de Internet crece y se vuelve una informarse sobre productos y servicios
“vidriera gigante”: 9 millones de personas 1
consultan sobre productos y servicios para su
posterior consumo”. Además indica que para 13 Si
nueve de cada diez personas Internet le fue de No
utilidad en la decisión de una compra, la mitad de 86 No responde
las personas que utilizan Internet ya ha realizado
compras online, y que más del 60% realiza Ilustración 10: Usuarios que consultan sitios para
compras por canales tradicionales luego de haber informarse sobre productos y servicios.
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:
51
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 36
corriente/Tarje)
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
52
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) :
Corporativos
Externos Internos
Enfoque de ventas Enfoque relacional Enfoque conocimiento Enfoque de colaboración
Ilustración 11: Segmentación de blog corporativos.
53
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)
Son competencia de los medios tradicionales 3,6

(radio, tv, diarios) 3,9 R.R. P.P.
Son efectivos para que la sociedad publique Dir. de com.

6,6
sus inquietudes 6,7
Los blogs de periodistas son mas confiables 5,7
que los medios para los que trabajan 5,7
Son una buena forma de realizar 4,9
conmunicaciión institucional 4,8
Son fuente de información confiable 4,2

4,1
0 1 2 3 4 5 6 7 8
Ilustración 12: Opiniones de directores de comunicaciones y relacionistas públicos sobre blogs.

Opinión de Relacionistas públicos y directores de comunicación. - (1 al 10)
54
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). Ilustración 13: Captura de pantalla de IdeaStorm de Dell.
El caso de Dell demuestra la IdeaStorm de Dell es el lugar donde la empresa Dell interactúa
tendencia de interacción con clientes abiertamente con las opiniones y voces de sus clientes, buscando
sacar provecho de estas en lugar de ignorarlas o callarlas.
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
55
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.
56
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
57
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
Ilustración 14: Impacto de los efectos de red.
analizadas de redes sociales,
58
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.
59
Ilustración 15: Proceso de carga de imagen en Flickr.
Pagar al usuario primero- Con tan solo 4 clicks el usuario puede subir una imagen a su cuenta en Flickr.
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).
60
Ilustración 17: Porcentagenes de imagenes publicas y

privadas en Flickr.
Ilustración 17: Subida de imágenes en Flickr. 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.
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.
61
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.
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.
62
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. Ilustración 19: Nube de tags de Technorati.
Un ejemplo que surgió en los últimos años es la Nube de tags en base a los posts en blogs
indexados por Technorati del 3/11/2008, una día
nube de tags: podemos ver un ejemplo en antes de las elecciones presidenciales de Estados
Technorati que contiene una pequeña nube de tags Unidos.
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.
63
Aplicaciones de Escritorio Aplicaciones de Internet

Software propietario Uso de APIs (Microsoft y Uso de efectos de red y de software
Apple.) como servicio ( Google, Amazon y
EBay.)
Integración de Monitores, Placas madre, Linux, Apache, MySQL, y PHP.
componentes discos.
“
Formas de mantener a CPU (Intel, AMD) Datos (adWords, NAVTEQ)
usuarios cautivos
mediante código
propietario
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.
64
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

Ilustración 20: Uso de Creative Commons en Flickr.
encontrado que existen modelos flexibles y con
beneficios colaterales probados, como ser el de Los usuarios de Flickr pueden optar por diferentes tipos
los modelos de licencias GNU o las Creative de licencias Creative Commons para sus imágenes, lo
que potencia la reutilización y creación de nuevos
Commons que permiten que software, datos o
contenidos mientras mantiene los derechos de autor.
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
65
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 Ilustración 21: Niveles en la cadena de
proviene de poseer los datos, sino que a veces puede datos de mapas digitales.
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
66
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)
67
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 Ilustración 22: Categorias de APIs en
actualidad, pero no solo ellos han incursionado ProgrammableWeb.com
en esta estrategia de plataforma: Ya en Las APIs son parte de la estrategia Web 2.0 de gran
Noviembre del 2008 John Musser, uno de los variedad de servicios: 15 categorías principales al
autores de “Web 2.0 Principles and Best alcanzar las 1000 APIs registradas en el sitio
ProgrammableWeb.com
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.
68
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.
Ilustración 23: Uso de protocolos por APIs.
En el artículo previamente mencionado de
John Musser, encontramos un análisis de la Distribución del uso de protocolos en las más de 1000 APIs
indexadas por ProgrammableWeb.com.
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. Ilustración 24: Wiki sobre API de Twitter.
Twitter da soporte sobre sus APIs a su comunidad de

Esta práctica es realizada por
desarrolladores mediante el uso de una wiki, donde
prácticamente todos los ejemplos que potencia el efecto colaborativo de los usuarios.
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.
69
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.
70
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
71
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
Ilustración 25: Captura de pantalla de Google Docs.
escritorio. Y además, el modelo de
negocio ha cambiado, beneficiando a los Google Docs permite a los usuarios del servicio trabajar de
usuarios en un aspecto extra: el costo. Es forma colaborativa sobre documentos, tomando lo mejor de
las experiencias de escritorio y online, a través de interfaces
cada vez más común que se apliquen web enriquecidas.
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,
72
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.
73
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.
74
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
75
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 Ilustración 26: Captura de pantalla del sitio TiVo.com
con contenidos generados y compartidos
TiVo involucra a los usuarios creando rankings en base al
por los usuarios, rankings, feedbacks,
comportamiento de los consumidores en los dispositivos
perfiles de usuarios y listas de amigos. Un DVR de sus hogares, conectados al servicio online.
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)
76
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 Ilustración 27: Captura de pantalla del sitio eBay Mobile
notificación por SMS de ofertas en subastas eBay ha generado distintas maneras de integrar su modelo
del usuario, acceso vía equipos móviles de negocio a dispositivos móviles y manteniendo la
mediante una aplicación especifica e incluso tendencia Web 2.0.
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
Ilustración 28: Captura de pantalla del sitio TN y La Gente
cualquier momento o lugar y con muy
poco esfuerzo. Existen muchos servicios En Argentina el canal de noticias TN ha creado un servicio
online que buscan aprovechar este tipo de para que su audiencia pueda enviar imágenes desde sus
dispositivos móviles, siendo estas publicadas online.
capacidades.
77
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 Ilustración 29: Captura de pantalla del sitio ShoZu.
en el diseño de interfaces que optimicen la
En base a simplicidad de interfaz ShoZu hace de
habilidad de los usuarios para utilizar los intermediario entre dispositivos móviles y servicios
servicios en dichos dispositivos. como YouTube o Facebook.
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.
78
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.
79
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.
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. Ilustración 31: Ciclo de de desarrollo de beta perpetuo.
Esta plataforma de instrumentación Ciclo de de desarrollo de beta perpetu, incluyendo el

producto, aplicaciones de seguimiento y los requerimientos.
debe ser guiada por objetivos de
En base a la medición obtenida en las pruebas con usuario,
negocio y estar planificada y pensada se compara constantemente el cumplimiento de objetivos.
80
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!.
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.
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:
81
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.
82
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 Ilustración 33: Representación grafica de "la larga
cola".
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)
83
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 Constructores de herramientas Cámaras de video digitales, software
democratizada para la larga cola, productores. para la edición de música y video y el
blog como herramienta.
Distribución Agregación para la larga cola Bienes físicos: Amazon.com e eBay.
democratizada Bienes digitales: Google y Cragslist.
Información: Goolge y Wikipedia.
Comunidades: MySpace, Bloglines.
Conexión Filtros para la larga cola Google, blogs, recomendaciones en
entre oferta y base a algoritmos.
demanda
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 Ilustración 34: Modos de listar noticias de
tipo de filtros colaborativos se hace cada vez mas Clarin.com
critico. Clarin.com aprovecha “la sabiduría de las
multitudes” filtrando las noticias en base al
comportamiento de los usuarios.
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.
84
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.
85
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
86
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.
87
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
88
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 A favor En contra Ejemplos

Ingresos
Publicidad Los usuarios obtienen No siempre están Publicidad contextual
sindicada contenidos y servicios apuntados a mercados en base a texto de
gratuitos correctamente Google adSense.
Servicios de bajos precios No son apropiados
gratuitos motivan la adopción. para todos los
escenarios
Publicidad en Los usuarios obtienen No tan escalable desde Publicidades variantes
base a sponsors contenidos y servicios el punto de vista de la con relaciones directas
gratuitos larga cola entre publicitarios y
Servicios de bajos precios publicadores.
gratuitos motivan la adopción. TechCrunch
Las publicidades pueden ser
más apropiadas para los
contenidos y la audiencia.
Subscripciones Simplicidad Los costos disuaden a Los servicios de
Modelo de ingresos algunos usuarios. Salesforce.com.
recurrente Algunos usuarios Basecamp de 37signals.
Bajo costo o nulo inicial (como ser Muchos de los servicios
promueve la adopción. departamentos IT de Premium son ofrecidos
89
Opciones de costos fijos o empresas) prefieren como servicios de

variables (en base al uso) modelos más subscripción
tradicionales como ser escalables.
el de licencias.
Comisión por Atado directamente a las No aplicable para todos Los programas de
transacciones acciones de los clientes. los modelos de afiliados de
Permite que los usuarios (en negocios. Amozon.com y eBay.
este caso socios) compartan
las ganancias.
Servicios Opciones de mejoras Algunos clientes no Los servicios
Premium atractivas para los usuarios estarán interesados en adicionales de
gratitos o que consumen mejoras. impresión de
publicidades. fotografías de Flickr.
Microsoft Office Live
Licencias de El modelo más tradicional y Menos flexibilidad y Programas
productos por tanto familiar a los escalabilidad. tradicionales de
usuarios. No se aplica bien para escritorio como ser
el software como Microsoft office.
servicio. 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.
90
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 Ejemplos Practicas

relacionados
Aprovechar Arquitectura de Wikipedia Pagar al usuario primero.
la inteligencia participación Flickr Activar los efectos de red por defecto.
colectiva. Los usuarios Amazon Involucrar a los usuarios implícita y
agregan valor Delicious explícitamente.
Efectos de red Technorati Proveer un contexto significativo para la
Creacion creación.
colectiva Confiar en los usuarios.
Diseñar software que es mejor a medida que
más gente lo usa.
Los datos son Estrategia de Amazon Buscar poseer fuentes de datos únicas y
el próximo datos. eBay difíciles de recrear.
"Intel Creative NAVTEQ Mejorar los datos básicos.
Inside”. Commons Craigslist Los usuarios controlan sus propios datos.
YouTube Algunos derechos reservados, no todos.
Buscador de Definir una estrategia de pila de datos.
Google Ser dueño del índice o del formato.
Technorati Diseñar los datos para su reutilización.
LinkedIn Tercerizar o proveer administración al acceso
de datos.
Innovación en La Web como Google Maps Ofrecer APIs de los servicios.
el ensamblaje. plataforma. Twitter Diseñar para la reutilización.
Mashups. Amazon Aplicar las mejores prácticas en APIs.
Remezcla Facebook Usar los estándares existentes:
Pequeños Eventful Construir los modelos de negocios en las APIs.
pedazos Flickr Usar Web 2.0 para dar soporte a la plataforma.
débilmente HousingMaps Ser cliente de su propia plataforma.
acoplados. Direccionamiento granular de contenidos.
APIs Utilizar su plataforma para construir la
REST y SOAP. confianza y lealtad de los clientes.
Aprender de cómo los clientes reutilizan los
servicios.
Experiencias Aplicaciones de GMail Combinar lo mejor de las experiencias de
de usuario Internet Google Docs escritorio y online.
ricas. Enquiquecidas Google Usabilidad y simplicidad primero.
Ajax Analytics Alcanzar los requerimientos de los usuarios.
Google Maps Priorizar la búsqueda sobre la estructura.
YouTube Mantener el direccionamiento de los
contenidos.
Personalización profunda y adaptativa.
Software más Computación iTunes Diseñar desde un primer momento para
26
allá de un ubicua TiVo compartir datos entre dispositivos, servidores
solo eBay 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
91
dispositivo. SCANBUY Estar atentos a la locación.

TN y la Gente Extender la Web 2.0 a los dispositivos.
Shozu Usar el poder de las redes para hacer los
Intelisync 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 Fin del ciclo de Google Liberar temprano y rápido.
perpetuo. adopción de Flickr Hacer participar a los usuarios como co-
software Amazon desarrolladores y probadores en tiempo real.
Software como Basecamp Instrumentar los productos.
servicio Crear nuevos productos de manera
Desarrollo 2.0 incremental.
Extreme Hacer que las operaciones sean una habilidad
27
Proggraming principal.
Usar herramientas y lenguajes dinámicos.
Aprovechar Micro-mercados Amazon Construir en base a las fortalezas de la larga
la larga cola. Sabiduria de las eBay cola.
masas adWords Usar administración de datos algorítmica para
iTunes que oferta y demanda se igualen.
Office Live 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 Sofware y 37Signals Escalar en base a la demanda:
ligeros y hardware de tipo adSense Sindicar los modelos de negocio.
escalabilidad commodity. Digg Tercerizar cuando es práctico y posible.
costo-efectiva. Ecalabilidad Amazon S3 Proveer infraestructuras, funciones y
Flickr experiencia a terceros.
Photobucket Escalar los modelos de precios e ingresos.
Limelight 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.
92
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 Ilustración 36: Interacción entre cliente y servidor.
quiere un servicio como ser el acceso a una base
La interacción básica de Internet entre navegadores y
de datos, envía una petición al servidor servidores web está basada en el modelo de red cliente-
correspondiente. Este procesa la petición y servidor.
devuelve el resultado al cliente.
93
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.
94
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 Ilustración 37: Modelo simple de páginas y vínculos.
encontrara información más relevante o incluso
vínculos que lo lleven a otros lugares donde Podemos pensar a Internet como un conjunto de
nodos (páginas web) conectados (mediante los
encontrar dicha información. Sin embargo, los vínculos).
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).
95
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 Ilustración 38: Modelo tipo moño de páginas y vínculos.
usuario quizás no pueda encontrar un El grafico de Internet puede ser considerado en forma de moño,
camino entre dos páginas elegidas al contando con 4 grupos de páginas.
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
Ilustración 39: Motor de busqueda.
mediante un grupo de palabras,
observando luego una pequeña Un motor de búsqueda está compuesto típicamente por tres componentes:
un rastreador, un indexador y un servidor.
96
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.”
97
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/.
98
<!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:
Ilustración 40: Ejemplo de uso de HTML.
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.
99
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).
100
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 Existen diferentes componentes relacionados al XML. Aquí
lenguajes mencionados anteriormente. podemos ver algunos de estos.
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).
101
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>
102
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 XHTML 34 (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.
103
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).
104
}
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.
105
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 Ilustración 41: Ejemplo de uso de XML con CSS.
guardados en bases de datos., y en general no
Resultado al ejecutar el archivo XML con un estilo CSS
hace flat amostrar todos los datos que
asociado en un navegador
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 XQuery 37(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).
106
<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; Ilustración 42: Ejemplo de uso de HTML con CSS.
}
h2 { Resultado al ejecutar el archivo HTML con un estilo CSS
font: bold large sans-serif; asociado en un navegador.
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.
107
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
108
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>
109
<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.
110
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
Ilustración 43: Estructura DOM con DOM Inspector en
GetelementsByName, aunque se diferencian Firefox.
en que pueden devolver más de un elemento
Utilizando el DOM Inspector del navegador Firefox podemos
ya que los nombres pueden repetirse,
ver la estructura DOM de nuestro ejemplo.
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/
111
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 PHP 40 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).
CLIENTE SERVIDOR
SERVIDOR WEB
<html> Script PHP Fuente
<head> de datos
<title> externa
<?php echo $pageTitle;?>
URL + 1 </title>
datos de formulario </head>
<body>
2 3 4
<h1>
<?php echo $pageHeader;?>
</h1>
Procesador
<html> Salida del de PHP
<head> servidor web
<title>
6 Catalogo de DVD
5
</title>
</head>
<body>
<h1>
Catalogo de DVD
</h1>
Ilustración 44: Scripting de servidor con PHP.
40
Podemos encontrar más información sobre PHP en http://www.php.net/
112
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>
113
<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
114
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.
115
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.
116
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
Ilustración 46: El Paradigma de los Web services.
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.
117
Publicar, encontrar y vincular Web services

son actividades realizadas por solicitantes de Interacción del servicio:
WS-Choreography, WS-Coordination, WS-Transaction
servicios y proveedores que usan estándares
específicos. En la capa más baja utilizan Composición del servicio: WSFL, BPEL
transporte ordinario de redes, luego
encontramos el protocolo HTTP para datos de Publicación y descubrimiento del servicio: UDDI
Internet. Sobre esto se encuentra el estándar Descripción del servicio: WSDL

SOAP 41 basado en mensajes, luego WSDL 42
(Web Services Description languagues) es Mensajes basados en XML: SOAP
utilizado para la descripción de los servicios y

Red: HTML
finalmente encontramos al UDDI43 (Universal
Description, Discovery and Integration) para la Ilustración 47: Las capas de los estándares de Web services.
publicación y descubrimiento.44
En ocasiones es necesario agregar

Servicio Servicios de
más capas a la estructura, y para esto
Funcionalidad Propiedades nivel más alto
se construyen encima de UDDI en
base a lenguajes como ser WSFL y
BPEL que especifican procesos donde Servicio Servicio
los pasos en dichos procesos son Funcionalidad Propiedades Funcionalidad Propiedades
completados por Web services. Servicios de nivel más bajo
Finalmente, varios servicios en acción Ilustración 48: Vista de la orientación a servicios.
necesitan algún tipo de Solicitante del servicio Proveedor del servicio
coordinación o garantías Objeto Aplicación Objeto Aplicación
transaccionales, lo que es (Cliente) (Proveedor del servicio)
posible a través de estándares Stub Esqueleto
como WS-Coordintation y WS-
Transaction. Middleware Mensajes SOAP Middleware
basado en SOAP basado en SOAP
Mencionamos antes que la
orientación a servicios es en Mensajes SOAP Mensajes SOAP
(Para buscar servicios) (Para publicar la
efecto un paradigma
descripción de
fundamental en base a la idea Middleware basado en SOAP servicios)
de que una funcionalidad Registro UDDI
compleja puede ser separada
Descripciones de servicios
en una colección de servicios
Ilustración 49: La Infraestructura de Web services.
41
w3.org/TR/soap/
42
w3.org/TR/wsdl
43
www.uddi.org/
44
Vale 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.
118
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 WSDL del proveedor de servicio

services están basados en
estándares y utilizan el Compilador WSDL Compilador WSDL
esquema de repositorio. (Cliente) (Servidor)
Muchos otros tipos de servicios
Solicitante del servicio Proveedor del servicio
que se encuentran en Internet
Objeto Aplicación Objeto Aplicación
no tienen estas características, (Proveedor del servicio)
(Cliente)
pero representan formas Stub Esqueleto
modernas de las llamadas a
procedimientos remotos, pero Mensajes SOAP
Middleware Middleware
lo que los diferencia de los basado en SOAP basado en SOAP
Web services es el hecho de Ilustración 50: La Infraestructura de WPC.

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
119
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.
120
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
121
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 Calificación de namespace Referencia
implícita
que pueden ser encontrados en el elemento Ilustración 51: Relaciones en un archivo WSDL.
122
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.
123
Los namespaces de SOAP definen la estructura del mensaje SOAP, que Sobre SOAP
básicamente es un sobre que contiene una cabecera (opcional) y un Cabecera SOAP
cuerpo. Ambos elementos pueden contener múltiples bloques, llamados Block de
bloques header y body respectivamente. El cuerpo contiene la carga útil cabecera
del mensaje, y la cabecera información que puede ser procesada por
intermediarios. Estos pueden necesitar esta información para realizar Cuerpo SOAP
acciones propias, como por ejemplo realizar el seguimiento de una Block de cuerpo
conversación. Como en 6M, por no incluir una cabecera.
El cuerpo de nuestro ejemplo contiene tan solo un elemento Ilustración 52: Estructura
de un mensaje SOAP.
(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>
124
<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.
125
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)
126
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. Ilustración 53: Creación de post en Blogger.
3.8.6.2. ATOM Creamos una entrada de blog, creándose automáticamente un Web feed.
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>noreply@blogger.com</email>
</author>
127
<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>noreply@blogger.com</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.
128
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>noreply@blogger.com (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).
129
<link>http://misopinionesdvd.blogspot.com/2008/11/le-fabuleux-destin-
damlie-poulain.html</link>
<author>noreply@blogger.com (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é Ilustración 54: Web Feeds en Firefox.
una interface para que el usuario pueda agregar
Al abrir el archivo XML en el navegador Firefox el usuario
el feed en su agregador de preferencia.
obtiene una interfaz que le permite agregar el feed.
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.
130
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 Applications 50 (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.
131
como resultado paginas HTML. Por

tanto, el cliente debe realizar esperas y Cliente Servidor
la información es manejada de forma Actividad del
Transmisión
ineficiente porque los resultados son usuario
de datos
siempre transmitidos como páginas
Procesamiento
enteras, es decir, generando una Transmisión del sistema.
recarga de toda la página, por tanto de datos
existiendo el envío de mucha Actividad del
información redundante mientras que usuario Transmisión
de datos
solo se genera un cambio quizás
pequeño en el contenido (por ejemplo, Procesamiento
Transmisión del sistema.
datos de una lista desplegable de un de datos
formulario).
Actividad del
usuario
El objetivo principal de Ajax es acelerar
estas interacciones entre el usuario y Tiempo
una aplicación web al hacerlas
Ilustración 55: Solicitudes sincrónicas y recargas de pagina.
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,

Cliente Servidor
todo escenario Ajax consiste de
Navegador Motor Ajax
pasos similares. Cuando el usuario Transmisión
realiza un evento, el motor Ajax (o Input de datos
más bien la función Javascript Procesamiento
responsable del evento) debe Transmisión del sistema.
Mostrar de datos
manejarlo de una manera
apropiada. Si hace falta Input
Transmisión
información adicional del servidor
Mostrar de datos
para llevar a cabo la tarea, se
Input Procesamiento
realiza la petición asincrónica. Transmisión del sistema.
de datos
El motor descripto en la siguiente Mostrar
figura no es una entidad Actividad Procec.

del Del
independiente, sino que representa
usuario sistema
la interacción de las tecnologías Tiempo
web que hemos analizado Ilustración 56: Recargas asincrónicas de pagina utilizando AJAX.
anteriormente, en conjunto con el
132
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.

133
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.
Generación del catalogo con Ajax
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));
134
$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>

135
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')">
136
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
137
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)
138
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
139
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.
Ilustración 58: Captura de pantalla de Google Reader.
Este tipo de procesos de distribución
Google Reader nos da la posibilidad de generar nuestra propia
y redistribución basado en Web feeds
redistribución de feeds. Solo es necesario tener diversas fuentes
demuestra un gran potencial para el seleccionadas, y marcar los artículos que queramos redistribuir como
consumidor de contenidos. Ahora “shared”.
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
Ilustración 59: Pagina personal pública de Google Reader.
asegura que quede disponible la
fuente e incluso de manera Una vez que tenemos contenido seleccionado, este puede ser accedido
de manera pública en una URL especifica permitiendo incuso que otra
opcional el articulo original (algo
gente se subscriba a esta información en formato de feed, o puede ser
que comúnmente se mantiene). redistribuido a un listado acotado de personas.
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
140
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:
http://www.juanortiz.com.ar/wpcserver.php?ASIN=B0000CABBW
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
141
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)
142
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>
143
<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
Ilustración 60: Ejemplo de Google Maps.
implementaciones del objeto
XMLHttpRequest y reduce por tanto A través de la API de Google Maps podemos insertar mapas en base a
la carga de codificación. Los métodos parámetros que definimos.
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.
144
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).
145
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
146
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
Ilustración 61: Muestra de Imagen en Flickr.
en su lista de favoritas y las
visualizaciones. Típica presentación de una imagen en Flickr con sus elementos.
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
147
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
Ilustración 62: Nubes de tags en Flickr.
tiempo, a medida que se agregan
más y más contenidos e historias Las Nubes de tags en Flickr facilitan la exploración del usuario.
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
148
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.
149
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 Ilustración 63: Ejemplo de página personal en Delicious.
marcador y la fecha en la que el usuario
Representación de los marcadores de un usuario de Delicious.
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”.
150
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.
151
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
152
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 Ilustración 64: Metodologías tradicionales de desarrollo de software.
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.
153
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
154
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 Ilustración 65: Metodología ágil de desarrollo 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).
155
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
156
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.
157
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 ✓ ✓
158
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.
159
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.
160
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
161
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
162
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.
163
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>>.
164
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.
165
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.
166
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.
167
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.
168
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 Gdata 59.
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.
169
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 Script.aculo.us, Bitjuice, InfiView, Open-jACOB Draw2D, Interface, Run
Effects 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/
170
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.
171
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.
172
IUA Ingeniería de Sistemas – Modelo Teórico
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.
173
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 Implementación del prototipo -
modelo 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.
174
4.2.2. Diagrama Gantt
Ilustración 72: Diagrama Gant del Proyecto.
175
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.
176
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.
177
Patrón Practicas
Aprovechar la Pagar al usuario primero.
inteligencia colectiva. 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.
Facilitar la emergencia de los contenidos
Los datos son el próximo Buscar poseer fuentes de datos únicas y difíciles de recrear.
"Intel Inside”. 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 Ofrecer APIs de los servicios.
ensamblaje. 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 Combinar lo mejor de las experiencias de escritorio y online.
ricas. 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 Construir en base a las fortalezas de la larga cola.
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.
efectiva.
Aprovechar las ventajas del bajo costo de estar online.
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.
178
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.
Involucrar a los usuarios implícita y explícitamente.
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.
Proveer un contexto significativo para la creación.
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.
179
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
180
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.
181
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.
182
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.
Construir los modelos de negocios en las APIs.
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.
183
Esto permitirá conseguir contribuciones y distribuciones en sitios de terceros, potenciando así

el efecto generado por la comunidad de contenidos.
Usar Web 2.0 para dar soporte a la plataforma.
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.
Utilizar su plataforma para construir la confianza y lealtad de los clientes.
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.
Aprender de cómo los clientes reutilizan los servicios.
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.
184
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.
185
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.
186
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.
Utilizar una arquitectura de participación para que oferta y demanda se encuentren.
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
187
medios de filtrado de información, sugiriendo por ejemplo las informaciones más comentadas
o valoradas por los otros usuarios del sistema.
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.
Aprovechar las ventajas del bajo costo de estar online.
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.
188
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.
189
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.
190
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
191
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.
192
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.
193
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.
194
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.
195
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.
196
4.4.1.3. Diagrama de casos de uso del sistema
Ilustración 73: Diagrama de casos de uso del sistema.
197
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.
198
4.4.2.2. Modelo de Navegación
Ilustración 75: Modelo de Navegación.
199
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.
200
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.
201
Í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.
202
Visualización de un reclamo
Ilustración 78: Modelo de Presentación - Visualización de un reclamo.
203
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.
204
Agregar y modificar un reclamo
Ilustración 79: Modelo de Presentación - Agregar y modificar un reclamo.
205
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.
206
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.
207
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.
208
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.
209
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.
210
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.
211
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.
212
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.
213
Modelo de Estructura de Procesos
Ilustración 86: Modelo de Estructura de Procesos - 1.
214
Ilustración 87: Modelo de Estructura de Procesos - 2.
215
Diagramas de Flujo de Procesos
Agregar reclamo
Ilustración 88: Diagrama de Flujo de Proceso - Agregar reclamo.
216
Modificar Reclamo
Ilustración 89: Diagrama de Flujo de Proceso - Modificar Reclamo.
217
Elegir Empresa
Ilustración 90: Diagrama de Flujo de Proceso - Elegir Empresa.
218
Elegir Producto
Ilustración 91: Diagrama de Flujo de Proceso - Elegir Producto.
219
Agregar Imagen
Ilustración 92: Diagrama de Flujo de Proceso - Agregar Imagen.
220
Agregar Video
Ilustración 93: Diagrama de Flujo de Proceso - Agregar Video.
221
Agregar comentario
Ilustración 94: Diagrama de Flujo de Proceso - Agregar comentario.
222
Reportar Reclamo
Ilustración 95: Diagrama de Flujo de Proceso - Reportar Reclamo.
Reportar Comentario
Ilustración 96: Diagrama de Flujo de Proceso - Reportar Comentario.
223
Valorar Reclamo
Ilustración 97: Diagrama de Flujo de Proceso - Valorar Reclamo.
Valorar Comentario
Ilustración 98: Diagrama de Flujo de Proceso - Valorar Comentario.
224
Social Bookmarks
Ilustración 99: Diagrama de Flujo de Proceso - Social Bookmarks.
Comentarios RSS
Ilustración 100: Diagrama de Flujo de Proceso - Comentarios RSS.
225
Empresas RSS
Ilustración 101: Diagrama de Flujo de Proceso - Empresas RSS.
Productos RSS
Ilustración 102: Diagrama de Flujo de Proceso - Productos RSS.
226
Registrar Usuario
Ilustración 103: Diagrama de Flujo de Proceso - Registrar Usuario.
Modificar Usuario
Ilustración 104: Diagrama de Flujo de Proceso - Modificar Usuario.
227
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.
228
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.
229
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:
230
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.
231
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.
232
IUA Ingeniería de Sistemas – Concreción del modelo
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.
233
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.
234
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.
235
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.
236
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.
237
Ilustración 111: Dependencia de traza entre archivos PHP y Clases de Procesos.
238
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.
239
Ilustración 112: Dependencia de traza entre archivos HTML y clases de presentación.
240
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.
241
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.
242
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.
243
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.
244
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/
245
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.
246
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
247
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 Analista 55 68 3740
requerimientos
Análisis de sistema Analista 55 20 1100
Diseño de sistema Analista 55 124 6820
Implementación Programador de 45 172 7740
Páginas Web
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
248
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.
249
IUA Ingeniería de Sistemas – Conclusiones
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.
250
IUA Ingeniería de Sistemas – Bibliografía
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.
251
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/.
252
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.
253
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.
254
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/.
255
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.
256
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.
257
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.
258
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.
259

Tesis Ingenieria de Sistemas - Trabajo de Grado - Web 2.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tesis Ingenieria de Sistemas - Trabajo de Grado - Web 2.0

Uploaded by

Copyright:

Available Formats

Trabajo Final de Grado

Ingeniería de Sistemas - IUA

Juan Alberto Ortiz Fernandez

Declaración de Derechos de Autor

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

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

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

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

3.4.1.3. Orkut ......................................................................................................................................... 31

3.8.2.3. XML ......................................................................................................................................... 101

4.3.4.1. Aprovechar la inteligencia colectiva .......................................................................................... 178

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

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

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

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

1.2. Situación problemática

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

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

1.4. Objeto de estudio

Aprovechar la inteligencia colectiva.

1.5. Campo de acción

Aprovechar la inteligencia colectiva.

1.6.1. Objetivo general

1.6.2. Objetivos específicos

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

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

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

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

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

1.8. Delimitación del proyecto

Software más allá de un solo dispositivo.

1.9. Aporte practico

1.10. Aporte teórico

1.11. Métodos de investigación.

1.11.1. Métodos lógicos

1.11.2. Métodos empíricos

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

1.12. Enfoque metodológico.

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

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

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

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

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

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

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

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

2.2. Relación tesista y objeto de estudio

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

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

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

2.3. Análisis de los problemas observados

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

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

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

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

3.2. The Cluetrain Manifesto: los mercados son conversaciones.

1. Los mercados son conversaciones.

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

3.3. La Web 2.0

3.4. Social Media: los nuevos medios sociales.

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

3.4.1. Redes sociales

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

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