Liferay Portal

Liferay Portal / News: Recent posts

Marketplace, PACL, and Community Plugins

<img alt="" class="callout" src="http://www.liferay.com/documents/5912873/6394519/mkt.png/1300742f-bb80-4749-bdfd-ba3720efb2ac?t=1367489097041" style="width: 401.0px; height: 163.0px; margin: 8.0px; float: right;" />If you've been developing plugins for the <a href="http://www.liferay.com/marketplace" style="font-size: 12.0px; line-height: 1.5;">Liferay Marketplace</a>, you're undoubtedly aware of the issues surrounding the development and publication process for apps.  The main issues are around the required use of the <a href="http://www.liferay.com/documentation/liferay-portal/6.1/user-guide/-/ai/security-manager" style="font-size: 12.0px; line-height: 1.5;">Security Manager</a> (aka PACL), which has proven challenging to get right (or not even possible to make work, depending on the nature of the app, and the use of certain frameworks/libraries). This, plus other issues in the most recent release (such as <a href="http://issues.liferay.com/browse/LPS-29103" style="font-size: 12.0px; line-height: 1.5;">LPS-29103</a>) has meant that many of our most valued community members have been prevented from publishing to the Marketplace through no fault of their own, and they have not been shy about letting us know of their concerns (see <a href="http://www.rotterdam-cs.com/blogs/-/blogs/liferay-security-manager-or-how-to-raise-a-horde-of-angry-developers" style="font-size: 12.0px; line-height: 1.5;">here</a>, and <a href="http://www.liferay.com/community/forums/-/message_boards/view_message/18978400#_19_message_17554571">here</a>). I personally find it very encouraging to see such passion and constructive criticism from our community, and I'm happy to report that we're making significant changes to the Marketplace to address these concerns and make Marketplace the high quality, go-to place for Liferay apps.
<div>
Here's what the team is working on right now:</div>
<ul>
<li>
Remove the requirement for Security Manager (aka PACL) to be enabled
<li>
Improve the "Denial Reasons" given when apps are rejected (usually because they fail a test case)
<li>
Document the environments in which apps are tested and more clearly specify requirements for metadata
<li>
Improve the Security Manager developer experience
</ul>
<div>
The first item in particular is intended to bring back the kind of functionality we had in the legacy community plugins repository, but still ensure that the Marketplace contains quality apps that actually work as advertised (since apps will still be run through anti-virus checks and basic smoke tests). App developers will have a choice to publish their app with or without the use of PACL, and apps will be marked as such when viewed on the Marketplace. This will also make it less ambiguous for developers looking to enter the <a href="http://discover.liferay.com/Marketplace-App-Submission">Marketplace App Contest</a> with apps that otherwise work without PACL. PACL will still be required for apps offered for sale (once that feature is available). </div>
<div>
 </div>
<div>
The other items relate to improving the developer experience of developing for Marketplace. We now have hundreds of apps and registered developers (not including Liferay itself) who are publishing to the Marketplace, and it's critical that the development and publishing process be as smooth, intuitive, and informative as possible. This is foremost on the team's mind, and if you have any additional feedback (besides those mentioned above), don't hesitate to make yourself heard either in the comments below, or in the <a href="http://www.liferay.com/community/forums/-/message_boards/category/10919228">Marketplace Developer forums</a>.  We are hoping to implement these changes in the next couple of months, to resolve the difficulties with Marketplace development.</div>
<div>
 </div>
<div>
As far as the PACL experience, in the next Liferay releases (for both 6.1 and 6.2) will be a new PACL policy generator tool (<a href="http://issues.liferay.com/browse/LPS-32200">LPS-32200</a>) which will vastly simplify the creation of a PACL-enabled app. If you want to test-drive it now, go grab the <a href="http://www.liferay.com/community/wiki/-/wiki/Main/BugSquad+-+Liferay+Portal+6.2+CE+Milestone+5+Testing">6.2 Milestone 5</a> build - it's fully implemented and ready for you to try out (<a href="https://github.com/liferay/liferay-docs/blob/master/devGuide/en/chapters/13-plugin-security.markdown">here's how</a>).</div>
<div>
 </div>
<div>
Finally, I want to let you know that we (as a company) make every effort to listen and respond to the open source community. We don't always get everything perfect right out of the gate, and sometimes it takes a while to make a change, but please know that Liferay depends on its community to point out the good and the bad, and make corrections as necessary. This is another example of why open source and open development processes are vastly superior to the alternative.</div> link

Posted by 15 hours ago

Liferay Hamilton Office is Taking Shape

Over the past several years, our North American Sales and Customer Experience Management team has grown at a tremendous rate.  We have team members in New York, Illinois, California, Minnesota, Texas and Florida, but the majority of our team is based in the greater-Cincinnati area.  To that end, It has become increasingly important for us to have a central location to meet and work together.  

In October of 2012, we <a href="http://www.journal-news.com/news/news/new-company-coming-to-downtown-hamilton/nSgkM/" target="_blank">announced</a> that Liferay has chosen to open its North American Sales Office in Hamilton, Ohio.   Liferay makes a point to heavily invest in the areas and communities in which we do business, and as time goes on, I will write a series of posts which will serve to introduce you to the <a href="http://www.hamilton-city.org/Modules/ShowDocument.aspx?documentid=5262" target="_blank">many good things happening in Hamilton</a> along with the different ways Liferay will be partnering with the community.

That's not what this post is about, though.  This post is to answer the "How's the office coming?" question I keep getting from the community, Liferay team, partners and customers.

It's going well!  The office is under construction, and we will be located on the second floor of the <a href="http://buildingsofnote.blogspot.com/2013/03/dixon-globe-opera-house-robinson.html" target="_blank">Robinson-Schwenn Building</a> in the heart of downtown.  The Robinson-Schwenn Building was built in 1866 and has been everything from an opera house to a department store and now hosts an expansion of <a href="http://www.regionals.miamioh.edu" target="_blank">Miami University</a>, a <a href="http://truewestcoffee.com" target="_blank">coffee shop</a>, and a law library.  Be sure to visit <a href="http://buildingsofnote.blogspot.com/2013/03/dixon-globe-opera-house-robinson.html" target="_blank">Buildings of Note</a> for some beautiful photos of the building.

<img src="http://4.bp.blogspot.com/-CrWwsHWfa5g/UVi1uOp-YdI/AAAAAAAADJM/K-De4_nfw3w/s640/Globe+Theater+-+Hamilton+051+-+Copy+-+Copy.JPG" style="width: 400.0px; height: 338.0px;" /> 
(Photo from <a href="http://buildingsofnote.blogspot.com">http://buildingsofnote.blogspot.com</a>)

Opening an office an office is no small endeavor, and we have been blessed to work with Cindy and Michael Dingeldein from the Community Design Alliance.  They have created with the architectural and design components of our project and have helped ensure that our new space will be nothing less than beautiful and functional (much more on that in a future post).

So, how is the construction coming?  Quite well, and we expect to be moving in by the last week of May.  

 
 
<div>

<img alt="" src="http://www.liferay.com/documents/26073/24237383/IMG_2550.JPG/0d749010-2ae2-4801-bb49-134ebc34c9ac?t=1367426048000" style="width: 400.0px; height: 299.0px;" />

<img alt="" src="http://www.liferay.com/documents/26073/24237383/IMG_2548.JPG/02529b80-0f65-4d35-bf55-fff22a0509ce?t=1367426048000" style="width: 400.0px; height: 299.0px;" />

Our first Sales bootcamp in January.

<img alt="" src="http://www.liferay.com/documents/26073/24237383/IMG_2546.jpg/2160d59e-5f84-4245-8026-5d7d8e18dc9f?t=1367426049000" style="width: 400.0px; height: 535.0px;" />

Dinner with Hamilton City Leaders, Brandon Saurber and Jody Gunderson, at <a href="http://www.ryanstavern.com" target="_blank">Ryan's Tavern</a> -- an Irish pub conveniently located in the next building... <img alt="smiley" height="20" src="http://cdn.www.liferay.com/html/js/editor/ckeditor/plugins/smiley/images/regular_smile.gif" title="smiley" width="20" />

<img alt="" src="http://www.liferay.com/documents/26073/24237383/IMG_2543.JPG/cbdf471c-25f1-4ee8-a931-e2f1d83d9911?t=1367426049000" style="width: 400.0px; height: 299.0px;" />
</div>
<div>
Liferay's New York-based Senior Account Executive working out of the current Hamilton office -- my house.  Note that my dog, Nashville, will be joining us at the new office.</div>

 

 

<img alt="" src="http://www.liferay.com/documents/26073/24237383/IMG_2914.jpg/e1d1ec8f-b6ad-4ce1-a349-86774e5ad529?t=1367426045000" style="width: 400.0px; height: 299.0px;" />

My office and shared office.

<img alt="" src="http://www.liferay.com/documents/26073/24237383/IMG_2916.jpg/3cc60b85-5ad7-455f-b37a-37c7898e9b9d?t=1367426045000" style="width: 400.0px; height: 299.0px;" />

The large windows let in plenty of natural light.

<img alt="" src="http://www.liferay.com/documents/26073/24237383/IMG_2976.jpg/3886ff97-392f-4585-a272-072704610399?t=1367426046000" style="width: 400.0px; height: 299.0px;" />

Painting has begun.  Behind the blue wall will be the "Rumpus Room."

<img alt="" src="http://www.liferay.com/documents/26073/24237383/IMG_2978.jpg/a9c0369a-855b-4088-a7c2-f8f260fce0f2?t=1367426046000" style="width: 400.0px; height: 299.0px;" />

Door frames are getting ready to go in.

<img alt="" src="http://www.liferay.com/documents/26073/24237383/IMG_2980.jpg/6d2eddbe-a7c7-4853-8fe7-c0218eaf58ae?t=1367426047000" style="width: 400.0px; height: 299.0px;" />

Conference rooms, offices and a large shared work area.

 

So, that is where things stand now.  The carpet will be going in this week, and we are planning an official grand opening celebration at the end of the month.  Stay tuned for more news, updates and photos.

If you'd like to learn more about Hamilton,<a href="http://youtu.be/RuRTrWNZgbA" target="_blank"> check out the 2012 State of the City Address</a>.  The Liferay announcement occurs at 31:50.

 

  link

Posted by 1 day ago

Liferay + TIBCO!

<a href="http://www.cmswire.com/cms/information-management/enterprise-portal-liferay-partners-with-tibco-software-for-lower-cost-backend-integration-020698.php">Enterprise Portal Liferay Partners with TIBCO Software for Lower Cost Back-End Integration</a> link

Posted by 2 days ago

Desencuentros entre un irreverente icono y una reflexiva etiqueta

En Liferay nos encontramos inmersos en la redefinición de algunos conceptos UX, y ello nos ha permitido comprobar de primera mano, la controversia que aún se mantiene latente, entre los lenguajes fundamentales (imagen y escritura).

Llevamos varios meses trabajando en nuevos patrones de interacción, en un nuevo rediseño visual, y en la utilización de nuevas metodologías asociadas a la forma en la que exploramos y descubrimos cómo mejorar la Experiencia de Usuario (UX) en Liferay. Por ello, Jorge Ferrer (VP Engineering), Nate Cavanaugh (Director UI) y yo como Diseñador UX estuvimos discutiendo (los 3 teníamos el mismo criterio) sobre cual era la mejor forma de afrontar una parte importante del futuro rediseño (los iconos).

<img alt="" src="http://www.liferay.com/documents/15796801/0/suns3.png/4f999401-e360-40be-ac1c-a6909e696b84?t=1366093635887" style="line-height: 1.5; width: 665.0px; height: 267.0px;" />

Esto fue motivo de búsqueda de información, de estudios y mockups Así llegamos a un post de <a href="http://bokardo.com/archives/labels-always-win/">Joshua Porter</a> (@bokardo) y sus respuestas a artículos de otros cracks (<a href="http://layervault.tumblr.com/post/42361566927/progressive-reduction">Layervault</a>). Estas lecturas son realmente interesantes, y os recomiendo su lectura, como prefacio a este artículo. Este texto no trata de dar luz a una serie de políticas de comportamiento, sino más bien encontrar una raíz histórica a la que poder adherir las métricas resultantes de nuestros tests, desde un punto de vista muy personal. 

 

Icono versus Etiqueta: Una discusión con miles de años.

Cuando diseñamos GUI, a menudo nos encontramos en una encrucijada que nos lastra desde tiempos inmemoriales. Y cuando me refiero a “tiempos inmemoriales”, no hago referencia a cuando Sir Tim Berners Lee inventó “The Web”, quiero decir a varios cientos y miles de años atrás. 

 

Existen indicios de que el hombre empezó la representación de formas hace como unos 40.000 años de antigüedad, es decir, durante la última glaciación. Sin embargo, los primeros sistema de escritura se originaron a finales del 4.000 a.C. Dichos orígenes se basan en sistemas de protoescrituras, los cuales tardaron varios cientos de años más en consolidarse como “hacedores” de contexto. Esta diferencia temporal nos la define magistralmente el genial Joan Costa “....hay pues una considerable distancia temporal entre el nacimiento de la imagen fija y el pensamiento escrito”.

 

Desde los 2.000 caracteres de la escritura pictográfica Suméria a los 22 signos del alfabeto fenicio, se han dado pasos hacia una aceptación generalizada de la imagen sobre el signo. No debemos olvidar que el sentimiento de placer e incluso de puro disfrute visual, es la sensación que mejor describe lo que percibimos cuando visualizamos una imagen. Algo totalmente distinto al instinto evocador o decodificador de la unión casi subliminal de caracteres que generan un recuerdo, en favor del pensamiento y un todo más figurativo. 

 

Ya en el siglo XX (1970) fueron diseñados los primeros iconos, desarrollados por Xerox PARC, inicialmente se diseñaron con la esperanza de que a los usuarios les resultase más fácil el uso de los ordenadores. Pero fue David Canfield Smith (empleado de Xerox) quien definió el término icono cuando se referían a ese tipo de grafismos. 

 

Posteriormente los sistemas operativos de empresas como Microsoft o Apple, popularizaron y estandarizaron el uso de los iconos en las GUI. 

<img alt="" src="http://www.liferay.com/documents/15796801/0/image00.png/6cdcf8ae-321e-48b2-b8ec-0b8551fcf5ff?t=1366094091747" style="width: 720.0px; height: 600.0px;" />

La relación asociativa entre la formula de texto o imagen, o texto+imagen, se fundamenta en las diferencias históricas entre los lenguajes gráficos fundamentales (la imagen y lo escrito). Siempre hemos estudiado y disfrutado de la relación de dependencia antagonista del Arte y la Literatura, ilustración o pintura y escritura. A fin de cuentas siempre ha existido esa especial “rivalidad” entre lo estrictamente asociado a las percepciones asociadas a las imágenes o la transformación subliminal o decodificación de una sucesión de caracteres que de por sí carecen de significado y que en conjunto se ligan a recuerdos, sensaciones y percepciones o conceptos. 

 

Durante mucho tiempo la relación entre lo icónico y lo escrito ha sido competencia de grafistas y tiene su representación en el término funcional, Lenguaje Bimedia (imagen-texto). El diseño gráfico, no es sino la representación lingüística y funcional de la fusión de la creatividad, interacciones, sensaciones y asociaciones entre los lenguajes fundamentales (la imagen y lo escrito). 

 

Ahora mismo nos encontramos inmersos en una época en la que predominan los componentes visuales a los textuales. Estudiamos análisis basados en comportamientos, interacciones con la conducta de los usuarios, sus necesidades e incluso el ambiguo valor de lo creíble e incluso respetable. La utilización del grafismo icónico, lastrando el importante papel que conjuga la escritura, quiebra el falso “Status Quo” que equilibra la necesidad real de los usuarios y lo que nosotros como diseñadores queremos diseñar. No, no caigamos en la tentación de indicar, que el usuario, ya aprenderá, ya se enterara, o que cuando sepa utilizar la herramienta dentro de un tiempo, entenderá el significado de ese icono o acción. Partamos de la base que un icono solo se ve, no puede explicar ni argumentar cuál es su cometido, es inherente de su contexto, y es huérfano de nacimiento por ausencia de mensaje. 

 

Seguro que a estas alturas, ya hay gente que está buscando en su memoria retrospectiva algunos casos que amparen estas líneas, sino reflexiones sobre iconos con los que está acostumbrado a trabajar, GMAIL? genial, son muy muy buenos, pero antes de que alguien diga tres veces Nielsen, Nielsen, Nielsen......., reflexionemos desde un punto de vista basado en procedimiento teóricos, o mejor dicho en procedimientos histórico-teóricos, que suena como más rimbombante. 

 

Nos olvidamos en demasía de algunos de los criterios que nos definieron en nuestra autodidacta enseñanza al principio de los tiempos: credibilidad y el menor tiempo posible de aprendizaje. Dicha curva de aprendizaje de un producto, es directamente proporcional a la facilidad de uso de un producto, mientras mayor sea la curva de aprendizaje, menor será el indicativo de experiencia positiva en el. Es cierto que la curva de aprendizaje siempre aparece como indicativo cuando procedemos a estudios de UX en comportamientos de relaciones con interfaces, pero es algo que solemos obviar cuando se trata de algunos de nuestros proyectos como UX Designers, pero que requerimos hasta la saciedad cuando criticamos (perdón, “analizamos”) los productos en los que otros profesionales han trabajado. 

 

Hablando de GOOGLE

A finales de 2011, Gmail decidió darle una vuelta de tuerca a su interfaz. Apostó por iconos en lugar de información textual. Eso generó un aluvión de de opiniones de lo más variado, abanderados de la usabilidad que veían como se traspasaba la delgada línea entre lo icónico y textual a lo icónico y casi abstracto. A decir verdad, existen algunos iconos que a primera vista (pasado bastante tiempo de su cambio) me chocaron frontalmente, sobre mis ideas preconcebidas (hábitos de uso, que podría llamarse). 

 

En la siguiente imagen se aprecia la barra de iconos activa, tras las selección de un mail. podemos apreciar como el tooltip que se genera, se integra perfectamente en el diseño, y a mi modo de ver no genera demasiado ruido. Sin embargo la cantidad de opiniones en contra, motivo a Google a poner una opción de conmutar “Icons or Text”.

 

<img alt="" src="http://www.liferay.com/documents/15796801/0/image02.png/1d0f99c0-f594-4c49-acee-83a164a6ad78?t=1366094323707" style="width: 591.0px; height: 575.0px;" />

Fue una buena decisión? a mi modo de ver, No. Personalmente y por encima de cualquier tipo de comentario basado en simples conjeturas, creo que hubiera sido más acertado otorgar la posibilidad al usuario de conmutar entre: “Icons, Icon with Text and Text”. 

 

Clasificaciones

Los iconos han sido utilizados desde el principio de la creación de los ordenadores (Xerox PARC), para identificar abstractamente determinadas acciones, para minimizar el peso, para reducir la necesidad de lectura, necesitan menos espacio, en incluso consiguen algo realmente necesario en el caos actual de convenciones asociadas a las diferentes terminologías de cada idioma: hace los interfaces más internacionales. 

 

Por ejemplo: “Borrar” debería ser igual aquí en Madrid, que en Nairobi, que en Los Angeles, o al menos deberia ser asi......

Para poder estandarizar un icono, primero deberíamos poderlos clasificar. Según (Blattner 1989) podemos catalogarlos o clasificarlos en Representativos, Abstractos y Semi - Abstractos.
<ul>
<li>
Representativos: Objetos simples y operaciones muy familiares y habituales a los usuarios. Por ejemplo: el icono de una goma de borrar, esta constituido como estandar de Facto de Borrar, implicando una acción común.
<li>
Abstracto: Figuras geométricas o símbolos gráficos. Por ejemplo: La utilización del carácter “?” implica asociación con preguntas, ayuda, faqs, etc.... 
<li>
Semi-abstracto: Es la clasificación entre la representación pictórica y el símbolo abstracto. Por ejemplo: el icono con un signo (+), que implica creación o adición de un nuevo documento. 
</ul>

 

Leclerc y los estudios experimentales

El conocimiento de este “folleto” y sus consideraciones me permitió transformar dicha prueba en una buena herramienta evaluativa para iconos y etiquetas. Si un usuario o un target de usuarios podian conseguir métricas considerables en este experimento, me daba un buen zurrón de motivos para documentar la política a implementar.

 

Recuerdo que la primera vez que utilice dicha prueba fue a raíz de un proyecto para un software de enseñanza. Los iconos con los que el cliente quería que trabajasemos, poseían una legibilidad penosa, por ello quisimos asegurarnos que los usuarios comprendian el significado de todos ellos. La utilización de esa familia de iconos llevaba como restricción que no debiamos añadirle ninguna etiqueta textual. 

 

Preparé una serie de pruebas, basadas sobre una muestra real de 100 usuarios (divididos en 4 grupos de 25 para cada tira), a los que les mostraba una serie de iconos sobre los que albergábamos algunas dudas, con reducciones de entre un 30% a un 60% del tamaño original, y al último grupo le daba las mismas reducciones pero agregandole las etiquetas (1 sola palabra) y su correspondiente reducción.<img alt="" src="http://www.liferay.com/documents/15796801/0/iconos.gif/3f024010-a1b0-447d-8d0d-d24d9302bc01?t=1366362164183" style="width: 510.0px; height: 518.0px;" /> 

* En esta imagen se utiliza glyphicons.com para representar los iconos motivo de las pruebas. Los iconos (contexto) aquí representados si son los originales y los valores Yes y No indican los resultados de las personas que identificaron correctamente el signficado del icono en todas su variantes. Para que el estudio tuviese una dimensión real, decidimos dividir los 100 usuarios en 4 grupos de 25 cada uno, y requerirles su opinión sobre ellos. 

 

¿Que descubrimos? 

Si nos fijamos en la última línea (imagen anterior) podemos apreciar cómo a pesar del reducido tamaño del icono, y el seccionamiento de la etiqueta, se produjeron las métricas más altas y positivas de toda la prueba.
<ul>
<li>
El usuario adivina más que lee.  
 Vislumbra el significado de una palabra con solo leer la parte superior de una palabra, es una lectura rápida basada en una fijación y en su correspondiente decodificación de caracteres. La observación de los patrones de visualización de los usuarios (no disponiamos de infraestructura para test de Eyetracking), nos indicó que en determinados usuarios las fijaciones se sucedían entre el icono (parte de él) y el texto. También llegamos a la conclusión al igual que comprobamos en otros estudios, teorías y libros sobre el tema (Joan Costa), que en caso de no poder descifrar un carácter en una palabra, el usuario la obvia y utiliza la cadena anterior y la posterior para descubrirla (adivinarla). 
<li>
Icono mejor con etiqueta 
La suma de etiqueta e icono consigue valores cercanos 100% de resultados positivos. 
<li>
El tamaño es importante, muy importante para los usuarios. 
La reducción de un icono sin etiqueta implica una relación directamente proporcional de reconocimiento negativo al tamaño original. 
<li>
Incorrecta Clasificación 
Nos equivocamos en como pensábamos que debíamos clasificar algunos de los iconos con los que experimentabamos. Algo universal que el tiempo me ha regalado, es que las preclasificaciones con las que venimos de serie (enseñanza), generalmente o mejor dicho raramente se corresponde con la realidad diaria. <a href="http://portfolio.educ.kent.edu/daltone/cmc2/articles/jp_use%20of%20icon%20labels_wiedenbeck.pdf">Reference</a>
</ul>

En etapas iniciales de uso de un interfaz los iconos sin etiquetas funcionan realmente mal.

 

Gran finale.....

Generalmente los iconos generalmente se reconocen con mayor rapidez, a pesar del anterior experimento Leclerc. La utilización de iconos genera que el usuario necesita prestar menos atención a dicha tarea y pueda concentrarse cognitivamente en la tarea que realmente espera conseguir en ese paso del interfaz (tarea principal).

 

La razón es que tal y como sumarizamos anteriormente, la acción cognitiva del desciframiento de caracteres (lectura de la escritura) es a priori tediosa, y aunque nos pueda producir cierto sentimiento de placer, este sentimiento se acrecienta cuando hablamos de imágenes, pictos..... 

 

Por supuesto siempre y cuando el icono o imagen no necesiten de una resolución de su significado que impliquen altas dosis de desciframiento cognitivo. 

Los iconos pueden generar un efecto (con la utilización) de creación de estándar de facto en el usuario, que le ayuden a minimizar la curva de aprendizaje y les genere una serie de “apuntes” en su memoria a largo plazo. 

Existen otras interpretaciones y discusiones bizantinas que podrían dar más “madera” a estos puntos..... 
<ul>
<li>
Los iconos necesitan de un menor espacio a la hora de representar una acción. En innumerables ocasiones la acción escrita puede contener varias palabras. .
<li>
En etapas iniciales de uso de un interfaz los iconos sin etiquetas funcionan realmente mal.
<li>
Los usuarios que no están acostumbrados a utilizar un producto, suelen tener más predisposición a necesitar icono+etiqueta. 
<li>
Si bien en determinados productos se utiliza un componente de “escalabilidad” o “Progressive reduction”, me inclino a pensar que solo podemos llevar a cabo esta acción cuando se trata de iconos establecidos como estándar.
<li>
Los usuarios cada vez están más familiarizados con la utilización de interfaces gráficas, y sobre todo eliminando toda indicación textual. Esto no significa que se establezca como un mandamiento, pero si es cierto que el tiempo invertido en descifrar iconos de una determinada APP, será proporcionalmente inversa a la posterior carga cognitiva necesaria para descifrar un icono similar cuando cambie a otra aplicación similar. 
</ul>

 

References

* BEHAVIOUR & INFORMATION TECHNOLOGY, 1999, VOL. 18, NO. 2, 68 ± 82 The use of icons and labels SUSAN WIEDENBECK Faculty of Computer Science, Dalhousie University, Halifax, Nova Scotia, Canada B3J 2X4

* Diseñar para los ojos I.S.B.N. 978-84-611-8137-7 JOAN COSTA link

Posted by 7 days ago

Disagreements between a disrespectful icon and a reflexive label

In Liferay we are engaged in redefining some UX concepts, and this has allowed us to experience at first hand, the controversy that is still latent, between the fundamental languages (image and writing).

We are working several months on new patterns of interaction, a new visual redesign, and the use of new methodologies associated with the way in which we explore and discover how to improve user experience (UX) in Liferay. For that reason, Jorge Ferrer (VP Engineering), Nate Cavanaugh (Director UI) and I as UX Designer, were discussing (all 3 had the same criteria) about what was the best way to tackle an important part of the future redesign (icons). 

<img alt="" src="http://www.liferay.com/documents/15796801/0/suns3.png/4f999401-e360-40be-ac1c-a6909e696b84?t=1366093635887" style="line-height: 1.5; width: 665.0px; height: 267.0px;" />

This motivated the search for information, studies and mockups. And we arrived to a post of my idolized <a href="http://bokardo.com/archives/labels-always-win/">Joshua Porter</a> (@bokardo) and its response to an article of other cracks such as (<a href="http://layervault.tumblr.com/post/42361566927/progressive-reduction">Layervault</a>). These readings are really interesting, and I recommend reading it, as a preface to this article. This text is not about to release to a set of behavior policies, but rather to find historical roots that can adhere to the resulting metrics of our tests, from a very personal perspective. 

 

Icon versus Tag: A discussion with thousands of years.

When we design GUI, we often find ourselves at a crossroads that hampers us from time immemorial. And when I refer to "time immemorial", I am not referring to when Sir Tim Berners Lee invented "The Web", I mean hundreds and thousands of years ago.

 

There are indications that the man began representing forms 40,000 years ago, that is, during the last glaciation. However, the first writing system originated in late 4.000 BC.These origins are based on protoescrituras systems, which still take several hundred of years to establish itself as "makers" of context. The great Joan Costa defines us this temporary difference brilliantly ".... there is thus a considerable temporal distance between the birth of the fixed image and written thought". 

 

Since the 2,000 characters of Sumerian pictographic writing to the 22 signs of the Phoenician alphabet, have taken steps toward widespread acceptance of the image on the sign. We must not forget that the feeling of pleasure and even pure visual enjoyment, is the feeling that best describes what we perceive when viewing an image. Something completely different to the evocative or decoder instinct of the almost subliminal union of characters that generate a memory, for thought and a whole more figurative. 

 

Already in the 20TH century (1970) the first icons were designed, developed by Xerox PARC, initially designed in the hope that users could more easily use computers. But it was David Canfield Smith (employee of Xerox) who defined the term icon when they referred to this type of graphics. 

 

Later operating systems from companies like Microsoft or Apple, popularized and standardized the use of icons in the GUI. 

<img alt="" src="http://www.liferay.com/documents/15796801/0/image00.png/6cdcf8ae-321e-48b2-b8ec-0b8551fcf5ff?t=1366094091747" style="width: 720.0px; height: 600.0px;" />

The associative relationship between the formula text or image, or text + image, is based on the historical differences between the fundamental graphical languages (the image and the written). We have always enjoyed and studied the antagonistic relationship of Art and Literature, illustration or painting and writing. After all, there has always been that special "rivalry" between what is associated with the perceptions associated with the images or the subliminal processing or decoding of a succession of characters which themselves are meaningless and that together are linked to memories, sensations and perceptions or concepts. 

 

For a long time the relationship between the iconic and the written has been responsability of the graphic artists and is represented in the functional term language bi-media (image-text). Graphic design is not but the linguistic and functional representation of the fusion of creativity, interactions, sensations and associations between fundamental languages (the image and the written). 

 

Right now we find ourselves in an era dominated by the textual visual components. We study analyses based on behaviors, interactions of the users, their needs and even the ambiguous value of credible and even respectable. The use of iconic graphics, burdening the important role that combines writing, bankruptcy false “Status Quo” that balances the need and what we want to design. No, do not fall into the temptation to indicate that the user,will learn already, already know, or that when you know to use the tool within a time, understood the meaning of that icon or action. We assume that an icon is just for seeing, can not explain or argue what is its mission, is inherent in its context, and is an orphan of birth for lack of message. 

 

Sure there are already people are looking for in their retrospective memory some cases that protect these lines, reflections on icons that are used to working, GMAIL? great, are very very good, but until someone says three times Nielsen, Nielsen, Nielsen..., reflect from a point of view based on theoretical procedure, or rather historical-theoretical procedures, which sounds as more bombastic. 

 

We forget too much of some of the criteria we defined in our self-taught teaching at the beginning of time: credibility and the shortest possible learning time. The learning curve of a product, is directly proportional to the ease of use of a product, the greater the learning curve, the lesser will be the indicative of positive experience in the. It is true that learning always curve as indicative as we proceed to UX studies on behaviors of relationships with interfaces, but is something we tend to ignore when it comes to some of our projects as a UX Designer, but need over and over again when we criticize (sorry, "Analyze") products in which other professionals have worked. 

 

Talking about GOOGLE and its UX.

At the end of 2011, Google decided to give another turn of the screw to its interface. They laid for icons instead of textual information. That generated plenty of opinions in a very different way, Representatives of the usability thought about trespassing the thin line between the iconic and textual to the iconic and almost abstract. In my opinion, there are some icons in a first view (it is a long time ago from this change) that shock my preconceived ideas frontally (habits of use, we could call them).

 

In the following image, we could appreciate the icons’ bar active, after selecting a mail. We can appreciate how the tooltip generated, is integrated in the design perfectly, and in my point of view, it does not generate too much noise. However, the opinions against this, made Google to add an option to change “Icons or Text”. 

 

In the following image, we could appreciate the icons’ bar active, after selecting a mail. We can appreciate how the tooltip generated, is integrated in the design perfectly, and in my point of view, it does not generate too much noise. However, the opinions against this, made Google to add an option to change “Icons or Text”. 

<img alt="" src="http://www.liferay.com/documents/15796801/0/image02.png/1d0f99c0-f594-4c49-acee-83a164a6ad78?t=1366094323707" style="width: 591.0px; height: 575.0px;" />

Was it a good decision? No, in my opinion. Personally and over any type of comment based on conjectures, I think it was more accurate offer the possibility to the user to change between “Icons, Icon with Text and Text”. 

 

Classifications

The icons have been used from the beginning of the computers’ creation (Xerox PARC), to identify different actions abstractly, to minimize the weight, to reduce the need to read, they need less space, and they get something really needed in the actual chaos of associated conventions to the different terminologies of each language: they do more international the interfaces.

 

For instance: “Erase” must be the same here in Madrid, than in Nairobi, in Los Angeles, or at least it must be so... In order to standard an icon, first of all, we should permit their classification. According to Blattner 1989, we can list or classify them in Representatives, Abstracts and Semi-Abstracts.

 
<ul>
<li>
Representatives: Simple objects and very familiar and habitual operations to the users. For instance, the rubber icon, is constituted as a standard de facto for erasing, implying an usual action. 
<li>
Abstract: Geometric figures or graphic symbols. For instance: the use of “?” symbol implies association with questions, help, faqs, etc... 
<li>
Semi-abstract: It is the classification between the pictorial representation and the abstract symbol. For instance: the icon with a sign (+), implies the creation or addition for a new document. 
</ul>

 

A bit of History and research: Leclerc and the experimental studies.

Leclerc realized around mid 19th century, a leaflet in which he shows with some guidelines how to reduce the costs in the documents’ print, for that he gave some indications based in the way to read the words. He argued saying the users can read and give sense to a word only reading its upper level, he told it could be reduced shorten the word in its base in percentage over 50%. This generated a reduction in paper and ink, and its saving in the statal money. The knowledge of this “leaflet” and its considerations allowed me to transform that prove in a good evaluative tool for icons and labels. If an user or target of users could get considerable metrics in this experiment, it gave me a lot of motives to document the policy to implement. 

 

I remember the first time I used this test: It was due to a project for a learning software. The customer wanted to work with icons with an awful readability, for that we wanted to assure the users understood the meaning of all of them. The use of that family of icons carried as restriction that we must not add any textual label.

 

I prepared some tests, based in a real test for 100 users (divided in 4 groups with 25 for every test), and we showed them a list of icons over which we had some doubts, with reductions between 30% and 60% of the original size, and to the last group I gave them the same reductions but adding the labels (only one word) and its appropriate reduction.<img alt="" src="http://www.liferay.com/documents/15796801/0/iconos.gif/3f024010-a1b0-447d-8d0d-d24d9302bc01?t=1366362164183" style="width: 510.0px; height: 518.0px;" /> 

* In this image is used glyphicons.com to represent the icons for the tests. The icons (context) here represented are the original and the values Yes and No show the results for the people that identify in a right way the meaning of the icon in all the variants. To give the study a real dimension, we decided to divide 100 users in 4 groups with 25 each one, and require their opinions about them.

 

What do we discover? 

If we pay attention to the last line (previous image), we can appreciate how despite the small size of the icon, and the section of the label, they brought the higher and more positive metrics in the test. 
<ul>
<li>
The user guess more than he reads.  
He glimpses the meaning of a word only reading the upper side of it. It is a fast read based on a fixation and its correspondent characters’ decodification. The observation of the patterns of visualization of the users (we didn’t have the infrastructure for tests of Eyetracking), showed us that in certain users the fixations happened between the icon (part of i) and the text. We also conclude as we prove in other studies, theories and books about this theme (Joan Costa), that in the case of not decoding a character in a word, the user obviates it and uses the previous and posterior chain to discover it (guess it).
<li>
Best an Icon with label  
The add of label and icon gets values close to 100% in positive results.
<li>
The size is important, very important for the users.  
The same icon a bit smaller and unlabeled proportionality generates a negative acknowledgment to the small size.
<li>
Incorrect Classification  
We failed in how we thought we must classify some of the test’s icons. Something universal the time has given me, is that the preclassifcations we come in our owns (learning), generally or, best said, strangely correspond with the daily reality. 
<a href="http://portfolio.educ.kent.edu/daltone/cmc2/articles/jp_use%20of%20icon%20labels_wiedenbeck.pdf">Reference</a> 
</ul>

 

Gran finale..... 

Usually, the icons are recognized faster, despite previous experiment by Leclerc. The use of the icons generates the user needs to pay less attention to that task and can concentrate cognitively in the task that really hopes to get in that interface over (main task). 

 

The reason is that, as we argued previously, the cognitive action of decoding the characters (reading the writing) is firstly boring, and although it could provoke us a pleasure feeling, this feeling increases when we talk about images, pictos, … 

 

Of course, if the icon or image does not need a resolution of its meaning implying important parts of cognitive decoding.

The icons can generate an effect (with the use) of creation of standard in fact in the user, that helps him to minimize the learning curve and generates a list of “notes” in his memory in a long term. 

Other interpretations and byzantine discussions exist, that could bring “more wood” to these points...
<ul>
<li>
The icons need less space to represent an action. In several times, the writing action can contain different words. 
<li>
In early stages of an interface using icons without labels work really bad.
<li>
The users not accustomed to use a product, use to be predisposed to need icon + label.
<li>
Although in some products is used a component of “scalability” or “Progressive reduction”, I tend to think that we can only carry out this action when we use icons established as standard.
<li>
Increasingly, the users are more familiarized with the use of graphics interfaces, and overall, deleting any textual indication. This does not mean to establish like a commandment, but it is true that time invested in decoding icons in a certain APP, will be proportionally inverse to the later cognitive charge need to decode a similar icon when he changes to a similar application.
</ul>

 

References

* BEHAVIOUR & INFORMATION TECHNOLOGY, 1999, VOL. 18, NO. 2, 68 ± 82 The use of icons and labels SUSAN WIEDENBECK Faculty of Computer Science, Dalhousie University, Halifax, Nova Scotia, Canada B3J 2X4

* Diseñar para los ojos I.S.B.N. 978-84-611-8137-7 JOAN COSTA link

Posted by 7 days ago

Using Gist in Liferay blog

All credit goes to <a href="http://www.liferay.com/c/my_sites/view?groupId=5912873&privateLayout=0">James Falkner</a><img alt="smiley" height="20" src="http://cdn.www.liferay.com/html/js/editor/ckeditor/plugins/smiley/images/regular_smile.gif" title="smiley" width="20" />

Steps given by James:


<div class="portlet-msg-info">
Note 1: The Gist is not viewable in "Preview".</div>
<div class="portlet-msg-info">
Note 2: The CSS on Liferay site ates all the indents in Gist because of the following:</div>



To fix the indents, simply insert the following CSS in your blog entry in "Source" view:

 link

Posted by 2013-04-24

Using Gist in Liferay Community Blogs

All credit goes to <a href="http://www.liferay.com/c/my_sites/view?groupId=5912873&privateLayout=0">James Falkner</a><img alt="smiley" height="20" src="http://cdn.www.liferay.com/html/js/editor/ckeditor/plugins/smiley/images/regular_smile.gif" title="smiley" width="20" />

Steps given by James:


<div class="portlet-msg-info">
Note 1: The Gist is not viewable in "Preview".</div>
<div class="portlet-msg-info">
Note 2: The CSS on Liferay site ate all the indents in Gist because of the following in Liferay CSS:</div>



To fix the indents, simply insert the following CSS in your blog entry in "Source" view:

 link

Posted by 2013-04-24

Make Video Page Look Like Youtube Using Structure and template

Hello Guys 

For That We have To make two structure abnd template 

One For Add Video And Another is for Display Video

1) addVideo Strucutre and template

open Youtube and copy video url which you want to add and paste in textbox in structure then publish

Structure for add video

<img alt="" src="http://www.liferay.com/documents/11857173/0/strcuture.PNG/7febfe51-a7ec-475d-a55c-553baf0d1a60?t=1366718297786" style="width: 727.0px; height: 201.0px;" />

Template Code For add Video

 
<div>
#set($foo=$Video-URL.getData())</div>
<div>
#set($n=$foo.split("v=").get(1))</div>
<div>
<div id="web-video"></div>
<div>
<iframe width="500" height="300" src="http://www.youtube.com/embed/$n?feature=player_detailpage" frameborder="0" allowfullscreen></iframe></div>
<div>
</div></div>
<div>
<div id="video-discription"></div>
<div>
$Discription.getData()</div>
<div>
</div></div>
<div>
 </div>
<div>
2)  Display all Video using company id</div>
<div>
 </div>
<div>
Only Template is require to display video ,so used blank structure .</div>
<div>
 </div>
<div>
Template code:</div>
<div>
 </div>
<div>
<div>
#set ($journalArticleLocalService = $serviceLocator.findService('com.liferay.portlet.journal.service.JournalArticleLocalService'))</div>
<div>
#set ($UserLocalService = $serviceLocator.findService('com.liferay.portal.service.UserLocalService'))</div>
<div>
#set ($companyId = $getterUtil.getLong($request.theme-display.company-id))</div>
<div>
 </div>
<div>
#set ($curArticle = $journalArticleLocalService.getCompanyArticles($companyId,0,-1,-1))</div>
<div>
#set($arc=$journalArticleLocalService.getCompanyArticlesCount($companyId,0))</div>
<div>
#set ($ExpandoValueService= $serviceLocator.findService("com.liferay.portlet.expando.service.ExpandoValueLocalService"))</div>
<div>
#set ($targetPortletID = "56")</div>
<div>
 <div  class="video-list"></div>
<div>
<ul></div>
<div>
#set ($counter = 0)</div>
<div>
#set($by=10)</div>
<div>
#foreach ($article in $curArticle)</div>
<div>
#set($arc = $arc - 1)</div>
<div>
#set($article=$curArticle.get($arc))</div>
<div>
#if($journalArticleLocalService.isLatestVersion($article.getGroupId(),$article.articleId,$article.getVersion()))</div>
<div>
#set ($articleUrl = "/widget/videos/-/journal_content/" + $targetPortletID + "/" + $article.groupId +  "/" + $article.articleId)</div>
<div>
#set ($document = $saxReaderUtil.read($article.getContent()))</div>
<div>
#set ($title = $document.valueOf("//dynamic-element[@name='Video-URL']/dynamic-content/text()"))</div>
<div>
#if($title!="")</div>
<div>
 </div>
<div>
#set($n=$title.split("v=").get(1))</div>
<div>
#set($userx = $UserLocalService.getUser($article.getUserId()))  </div>
<div>
#set($Degree=$ExpandoValueService.getValue($companyId,"com.liferay.portal.model.User","CUSTOM_FIELDS","Degree",$article.getUserId()))</div>
<div>
#set($Specialty=$ExpandoValueService.getValue($companyId,"com.liferay.portal.model.User","CUSTOM_FIELDS","Specialty",$article.getUserId()))</div>
<div>
#set($Prefix=$ExpandoValueService.getValue($companyId,"com.liferay.portal.model.User","CUSTOM_FIELDS","Prefix",$article.getUserId()))</div>
<div>
 <li class="videoli" style="list-style: none;width:330px;border-bottom: 1px solid #DDD;min-height:150px;">   </div>
<div>
 <a href="${articleUrl}" target="video"><img src="http://img.youtube.com/vi/$n/default.jpg" style="float: left;</div>
<div>
padding-right: 20px;</div>
<div>
width:140px;"></a></div>
<div>
     <h4> $article.getUrlTitle() </h4></div>
<div>
     <a href = "/web/$userx.getScreenName()"></div>
<div>
     $userx.getFirstName() $userx.getLastName()  </a> </div>
<div>
     $Degree.getData() </div>
<div>
     $Specialty.getData()</div>
<div>
     </div>
<div>
  </li> </div>
<div>
#set ($counter = $counter + 1)</div>
<div>
#if($counter==$by)</div>
<div>
  #if($by>50)</div>
<div>
   #break</div>
<div>
  #end</div>
<div>
  @page_break@</div>
<div>
#set($by=$counter+2)</div>
<div>
#end</div>
<div>
#end</div>
<div>
#end</div>
<div>
#end</div>
<div>
</ul></div>
<div>
 </div>
<div>
I implemented this code at <a href="http://liferay.medicalassociation.in/videos" style="line-height: 1.5;">http://liferay.medicalassociation.in/videos</a>  Visit For Better Understanding .</div>
<div>
 </div>
<div>
 </div>
</div>
<div>
 </div>
<div>
 </div>
<div>
 </div> link

Posted by 2013-04-23

Vaadin Liferay Development...

NOTE: The following blog post is about Vaadin 6 and Liferay.  I'll be doing future posts on Vaadin 7, but for now I recommend sticking with Vaadin 6 in Liferay.

 
<h2>
Introduction</h2>

About two years ago, I noticed the Liferay IDE allowed for the creation of a new type of portlet based on Vaadin.  Curious, I did some research and found I could create Liferay portlets based upon the <a href="http://www.vaadin.com">Vaadin Framework</a>.

According to the Vaadin FAQ, Vaadin ("Vaadin" sounds like vuh-din, emphasis on first syllable, the long 'a':s sound like the 'a' in "ago") is a Java web application framework. It is designed for creating rich and interactive applications that run in the browser, without any plugins. A server-driven architecture together with reusable component model is used to simplify programming of applications and for better web application security. No HTML, XML or JavaScript necessary and all Java libraries and tools are at your disposal.

Translation is that it's a framework that you do most of your development in Java and, since it is based on the GWT, runs mostly in the client browser and uses lots of AJAX to communicate with the backend.

It's not a flashy framework in that it's not really designed to support lots of browser eye-candy.  It is, however, very well suited for enterprise development where you want to support forms, tables, and other basic widgets to create real and responsive enterprise applications.
<h2>
Unfortunately, the wizard in the Liferay IDE was the only info I found on creating Vaadin portlets.  I couldn't find a real developer guide, didn't understand some of the requirements from the Vaadin website, and I basically struggled through the development of an initial Vaadin portlet.</h2>

So this blog post is going to help explain Vaadin in Liferay and what you'll need to use to become an effective Vaadin portlet developer.
<h2>
Terminology</h2>
<h4>
Widgets</h4>

These are the UI elements that are rendered in the browser.  Vaadin includes support for a basic set of UI widgets and include buttons, checkboxes, option groups, tables, trees, labels, text fields, etc.

Widgets have two aspects: the server side code and the client side code.  The server side widget is referred to as a Component.  Components are instantiated, configured, and added to define what the client side will represent.  The client side code is in Javascript and is generated using GWT to compile the Java code for the components into the javascript version for the client side.
<h4>
Widgetset</h4>

A widgetset is the set of compiled javascript for all of the widgets that are used in the Vaadin application.

Widgetsets have names.  The widgetset name is a Java class-like name complete with a package path, i.e. com.vaadin.portal.gwt.PortalDefaultWidgetSet.  There's actually a corresponding file in the classpath at the location defined by the widgetset name with the extension ".gwt.xml", and this file defines the widgetset and all included modules.  The com/vaadin/portal/gwt/PortalDefaultWidgetSet.gwt.xml file is read by the GWT compiler to compile the widgetset used on the client side.

A Vaadin application requires a correctly compiled widgetset for the Vaadin version used in the application to render the client side correctly.
<h4>
Theme</h4>

Vaadin widgets are rendered in the browser using a theme.  Vaadin ships with a number of themes out of the box, including a theme named "liferay" which is based on the standard Liferay classic theme in blue.

Custom themes are created by writing CSS.  Sounds pretty simple, but can be quite complex.  Every widget has it's own classes automatically added to them, and the components can have classes added to them in the Java code (components have an addStyleName() method to add a CSS class to the component, yes I know it's misnamed, but I think they were trying to avoid confusion with Java classes).
<h4>
Add-Ons</h4>

Vaadin Add-Ons are supplemental widgets that can be added to a Vaadin application to add new widgets that can be used in the application.  For example, there are Add-Ons to provide integration with charting packages, new layouts, extended core widgets that provide additional functionality, etc.

When an Add-On is added to a Vaadin application, the widgetset must be recompiled to create the complete widgetset for the application.  If the widgetset is not recompiled, the server side will have the code for the component (so you the developer can create, configure, and add the component), but the client side will not be able to render the widget.

Add-Ons can be found in the <a href="http://vaadin.com/directory">Vaadin Add-On Directory</a>.
<h2>
Vaadin in Liferay</h2>

The Vaadin website covers Vaadin as servlets in great detail, and touches on Vaadin portlets somewhat, but there are some things about using Vaadin in Liferay that are important to keep in mind...
<h4>
The Widgetset</h4>

Vaadin portlets use a single, shared widgetset.  This widgetset is normally com.vaadin.portal.gwt.PortalDefaultWidgetSet, but it can be changed by setting the "vaadin.widgetset" property in portal-ext.properties.

The single widgetset is used by all Vaadin portlets deployed in the portal, so the widgetset must contain all of the Add-Ons used by any single Vaadin portlet.  Have a single Vaadin portlet that uses, say, the Refresher Add-On?  It must be in the widgetset for all portlets.
<h4>
The Theme</h4>

Vaadin portlets will, by default, use a single, shared theme.  This is actually a good thing because it will make your Vaadin portlets look consistent across the portal.

The default portal theme is "liferay", but it can be changed by setting the "vaadin.theme" property in portal-ext.properties.
<h4>
The Add-Ons</h4>

Add-Ons must be deployed into Liferay's WEB-INF/lib directory.  This is the only directory that will be used to compile the widgetset (details coming shortly), so this is where they must go. Vaadin portlets that use the Add-On(s) will use the liferay-plugin-package.properties file to define a dependency on the portal's jar.
<h4>
The Resources</h4>

The compiled widgetset and the theme files represent all of the static files (resources) that Vaadin portlets will be using.  These files are always part of the Liferay ROOT web application, and will normally be available as /html/VAADIN/...  Vaadin will automatically be looking for the VAADIN directory to get the static resources, and this directory is found in the "/html" path, but this can be changed by setting the "vaadin.resources.path" property in portal-ext.properties.  NOTE: The resources path must be part of the ROOT application and must be in an accessible path for the client browser, as the browser will be submitting HTTP requests to get the static resources.
<h2>
Vaadin Control Panel</h2>

All Liferay instances that will be using Vaadin in their portlets must add the Vaadin Control Panel.  It's not included in Liferay by default, but your ability to leverage Vaadin in the portal will be severely limited without it.

There are two key functions that the Vaadin Control Panel provides:
<ul>
<li>
The ability to change Vaadin versions on the fly.
<li>
The ability to compile the portal's single, shared widgetset.
</ul>

The Vaadin Control Panel for Liferay is a portlet that provides a new control panel for Vaadin.  It can be downloaded from the Add-On directory <a href="https://vaadin.com/directory#addon/vaadin-control-panel-for-liferay:vaadin">here</a>.

Download the portlet and drop it into the deploy directory, and Liferay should deploy it.  Note that the control panel portlet does not adhere to Liferay's packaging requirements (it's missing the crucial liferay-plugin-package.properties file), so it may complain about it during deployment, but should still be functional.  You may or may not need to restart your application container post-deployment (I have seen it deploy successfully and be available, but also have seen cases where a restart is necessary).

When you go to the control panel, you'll have a new entry at the bottom of the Portal section named "Vaadin".

The interface is rather simplistic:

<img alt="Vaadin 6 Control Panel" src="http://www.liferay.com/documents/26528/0/vaadin-control-panel2.png/b16a7399-dd46-4f04-bdfe-4ac33c8fbc07?t=1366484442348" style="width: 726.0px; height: 597.0px;" />

The first thing to notice is the "Change Version" link at the top of the file.  Liferay by default comes with a fairly old version of Vaadin.  You're going to want to change your version of Vaadin in the portal to the latest version as soon as possible.

The next thing to notice is the "Select Add-ons" checkboxes.  When you download an Add-On, you'll have a jar file that contains the Add-On code.  The jar file must be put into Liferay's WEB-INF/lib directory.  You can see the path where the jar file must go in the filesystem.

The checkboxes here allow you to select and deselect Add-Ons that will be included in the widgetset compile.

The last thing to notice is the "Compile Widget Set" button.  When you change the Vaadin version or when you enable/disable Vaadin Add-Ons, you MUST recompile the widgetset using this button.  Failure to do so will result in errors on the client side.

When you hit the "Compile Widget Set" button, a bunch of stuff will scroll in the "Output Console" section of the window.  This is the output of the GWT widgetset compiler.  In most cases you should get a successful result at the end of the compile.  If you get errors in the window, I would search the Vaadin forums for a match or try posting to the Vaadin or Liferay forums.
<h2>
Issues Upgrading Vaadin in Liferay</h2>

The Vaadin Control Panel makes changing Vaadin versions really easy, but it does not handle the upgrade completely...

The Vaadin Control Panel only changes the version of the vaadin.jar in Liferay, but does not deal with the Vaadin themes.  Vaadin themes are released for each Vaadin release, and the themes contain bug fixes also.

Vaadin provides a special download for Liferay users, the Vaadin 6 Liferay Update Package.  This download will include the precompiled widgetsets (that you won't use since you're compiling your widgetset using the Vaadin Control Panel) and the updated themes.  You'll want to extract the themes directory from the download and copy it up to the Vaadin resources directory (default would be ROOT/html/VAADIN directory).  I actually deploy this locally using a JSP hook plugin (create a JSP hook plugin, put the new themes directory in the hook plugin, build and deploy to let Liferay handle the updating of the ROOT webapp).
<h2>
Conclusion</h2>

Well, that about covers administrating Vaadin in Liferay.  My next blog post will cover developing Vaadin portlets...

  link

Posted by 2013-04-20

Service Builder Presentation Info

So I received bunch of emails on Service Builder after my webinar last month...  Thought I'd write up a blog entry that will end up in the search engines and hopefully lead folks here to get to the details...

Anyway, the recorded presentation is available on the <a href="http://www.liferay.com/events/web-events">Liferay LIVE Web Events page</a>.  You can listen to the whole presentation and watch as my demo fails during the presentation...  <img alt="wink" height="20" src="http://cdn.www.liferay.com/html/js/editor/ckeditor/plugins/smiley/images/wink_smile.gif" title="wink" width="20" />

All of the projects used for demo are actually available in <a href="http://www.liferay.com/community/forums/-/message_boards/message/22561833">this forum post</a> in the second message of the thread.

Now for the keywords that will get you here...

The presentation covers how to do some basic Service Builder functions, but also features:
<ul>
<li>
one-to-many relationship handling.
<li>
many-to-many relationship handling.
<li>
accessing an external (non-Liferay) database.
<li>
using 'fake' (non-database-backed entities) to build shared code modules using Service Builder.
<li>
Vaadin and Service Builder integration.
</ul>

  link

Posted by 2013-04-20

<< Older Entries