La semana pasada tuvo lugar en Chicago el Ignite, una importante conferencia de Microsoft, en la que se presentaron las próximas novedades de la plataforma de productividad Office 365. Algunas de las novedades (como desarrolladores) nos afectan de cierto modo y, en los siguientes post, intentaré abordar alguna de ellas. Para empezar, en este post voy a hablaros sobre la desaparición de SharePoint Designer en la nueva versión y las consecuencias.

 ¿Qué función realizaba SharePoint Designer?

Cuando salió la primera versión Designer en 2007, éste se utilizaba para realizar los aspectos relativos al diseño. Podríamos decir que era como el Dreamweaver, se utilizaba para poder darle un poco de estilo a los portales. El inconveniente es que no se podía llevar un ciclo de vida de la solución. Esta parte de diseño no se podía paquetizar y, por lo tanto, el mantenimiento era un verdadero infierno. Desde mi punto de vista, este ha sido uno de los principales «fracasos» de la herramienta.

La siguiente versión, SharePoint 2010, facilitaba el despliegue de las características de diseño desde WSP generados con Visual Studio pero, sin embargo, la mayor parte de los desarrolladores continuaban utilizando Designer para aplicar el diseño.

Ya en la última versión, Designer tenía mucha menos funcionalidad. ¿Por qué? Se suprimió la vista de diseño y, por lo tanto, había que buscar otras alternativas para realizar todos los detalles para los que se utiliza la herramienta. Microsoft propuso que cada diseñador utilizara la que quisiera y después, mediante el Design Manager, se incorporase a SharePoint. Aunque en principio era una buena alternativa, en la practica no mejoraba mucho (principalmente el ciclo de vida de la solución).

¿Qué otras características tiene?

Aunque todo el mundo dice que su principal función es diseñar, en mi opinión su fuerte es la creación de Flujos de Trabajo. Se pueden crear Flujos de Trabajo de una forma muy intuitiva y visual. Hay determinadas soluciones en las que un usuario final (power-user) define el mismo sus flujos de acuerdo a sus necesidades y de esta forma sacarle mayor productividad a la plataforma. Por este motivo, la popularidad de herramientas como Nintex Workflow, que todavía simplifican más esta tarea.

En el Ignite, sin embargo, no se mostró ninguna herramienta para poder hacer Flujos de Trabajo (supongo que la mostrarán cuando se lance SharePoint 2016). Si al final los flujos de Trabajo hay que crearlos haciendo uso de Visual Studio, el usuario solo tendrá dos alternativas: buscar un producto similar a SharePoint o adquirir un producto comercial (cómo pueda ser Nintex WorkFlow, K2, etc).

Conclusión

En mi opinión, SharePoint Designer es una herramienta totalmente prescindible para cualquier desarrollador de SharePoint ya que nunca se ha utilizado para lo que realmente estaba implementada. Podemos hablar de su mal funcionamiento en determinadas circunstancias, pero más allá de estos fallos, el principal problema que tiene SharePoint Designer es su mal uso.

SharePoint Designer «facilita» no trabajar correctamente: posibilita modificar ficheros directamente en Producción, sin ningún tipo de control de código fuente. Aunque, esto también tiene su lado bueno… y es que podemos mostrarle los cambios más rápidos. ¡OJO! Hay que ser conscientes que estos cambios se han de replicar en nuestro código fuente.

Si eres de los que todavía utiliza Designer, ves buscando otras alternativas para trabajar bien en SharePoint y… no te coja desprovisto. ¡Estás avisado! 😉