Message Boards

Processes around UX at Liferay

Lee Jordan, modified 5 Years ago.

Processes around UX at Liferay

Expert Posts: 449 Join Date: 5/26/15 Recent Posts
I'm curious to know what kind of activity the UX team engage in with users of Liferay (not developers implementing Liferay). I'm in a unique sort of position between development and users, working in an organization that uses Liferay. The impression that comes through is that there is a disconnect that Liferay don't know how users use the product and are unaware of users needs.

I think of Alloy Editor not being able to align text, not really being that great of a tool for creating creative content. I think of the developers who are most likley very proud of what they make and users who simply want to throw a brick at the content editing field. The user seems to be a mythical creature, but to me when I explain situtations it's because I've litterally got someone a real person on the other end of an issue that just can't interact with the editor or create content without the product getting in their way.

So I'm curious, how much do UX at Liferay reach out to the ordinary real life users instead of the personas? Do UX mix in with developers do developers ask UX questions? What sort of collaboration occurs? For me it's kinda easy, I do both, I develop and fix issues and sit with or at least collaborate with site admins so I have all that information that informs what I develop.
thumbnail
David H Nebinger, modified 5 Years ago.

RE: Processes around UX at Liferay

Liferay Legend Posts: 14914 Join Date: 9/2/06 Recent Posts
Actually the adoption of Lexicon/Clay kind of disproves your notions. Lexicon defines an abstract language around user interaction, not just a random collection of UI elements. In many ways Clay is Liferay's version of Material Design.

Liferay does a lot of research internally and externally to build the UI for OOTB tools. Many of the UI things you see represent current trends in UI, and this can sometimes be disconcerting.

Liferay always does a beta period for the community to get involved with finding bugs and reporting UI issues. In 7.1 for example, the initial design for managing pages was separated from navigation. Research combined with previously reported usability issues w/ the old way of managing pages vs navigation drove the separation of the two concerns and a new UI for managing it. For those participating in the beta program, however, the new UI suffered from severe usability problems when page counts were high. The beta voluteers raised the issues and Liferay ended up making changes to the UI.

The beta program is open to all, but regardless how much we might encourage users to participate and raise concerns and report issues, unfortunately only a small fraction of the community actually does participate.

But, as a result, after the fact we will frequently get posts like this pointing towards UI concerns and sometimes just outright complaining about things. But it is often long past the point where even the most helpful feedback could be used to influence the release.

Finally, yes the folks who did the Alloy Editor are proud of the work they have done. I think your mistake, though, is believing that it is what it is. The Alloy Editor is truly extensible and can be easily augmented to add the functionality you need: https://dev.liferay.com/en/develop/tutorials/-/knowledge_base/7-0/alloyeditor

The challenge is typically trying to balance the needs of the content creators. Some content creators want to control aspects of the presentation (such as centering text) and look for buttons like the ones you need. But in controlling the presentation, you prevent allowing the theme to enforce consistency and control presentation correctly. By providing these kinds of buttons, you are surrendering presentation control to the content creators.

Granted lines like this are never completely clear; content creators are often the same folks who are responsible for presentation, so a forced separation that Liferay uses by default is at odds to the way they work.

But I hope you can understand why it is not in there by default.
Lee Jordan, modified 5 Years ago.

RE: Processes around UX at Liferay

Expert Posts: 449 Join Date: 5/26/15 Recent Posts
I guess there are a few aspects to what I was originally thinking in phrasing the question.

1) How often are users able to demonstrate how they use the product
2) How user centric is the design process and are personas based on knowledge or asumptions on how the product is used
3) How can users be alerted to a change before it's too late so that they can suggest how the change would impact them to inform the design

The navigation issue clearly indicates a disconnect between the owners of the product and the users. If users were asked if it was ok to make their navigation expereince worse ... I don't think users would be raising a glass and suggesting that it was ok to proceed and sure this will be great. Which does tie in to the feedback coming at the end of the process rather than the begining. When modern site building was demonstrated it didn't adequately suggest that the "navigation" menu was going to be removed and moved to the totally wrong place in the "build menu".

Or put another way I want to run cat5 cables around the house, I did it and then showed my wife that look Netflix is soooo much better now and everything is ok. It turns out it wasn't ok and now it's done it can't be undone we just move forward and fix the hole in the celing I made when trampling around the attic and enjoy signal stability. Splitting edit web content in the display portlet into two menus ... again users not taken along with the change and suprise 6 months later the ripples of that earthquake go into a fixpack and have to be re-worked to fix new problems.

Alloy is a completly different thing, that's tool dictation. That's design process stating that users don't need what they need and that to get what they need they need to fix it themselves which is the opposite of being user centric.
thumbnail
David H Nebinger, modified 5 Years ago.

RE: Processes around UX at Liferay

Liferay Legend Posts: 14914 Join Date: 9/2/06 Recent Posts
I don't know how to answer the questions, I don't have the direct details.  I do personally believe that parts of the UI were driven by UI trends over actual usability testing; its the only way I can see someone saying the floating + add button in the bottom right corner of the browser made sense emoticon

I wouldn't say there was a disconnect between owners and users; it is actually more of a disconnect between admins of different sizes of pages.

The miller columns work great if you have a smaller number of pages w/ a shallow (like 3) depth of navigation. And the miller colunns are harder to use if you have a significant number of pages and/or a complex depth of navigation.

Liferay knows about the groups of different sizes and tries to make the best decision for the largest number of admins.

The disconnect, in my opinion, was that the latter group of admins found it so hard to use, harder than what was expected.

All of that said, the tree perspective that is prevalent in 7.0 and earlier, that too had problems with large page count or navigation depth; trying to drag/drop pages around the tree caused folks a lot of pain too. Liferay tried to fix the issues with that UI and maybe didn't get the right UI that everyone needed.

Liferay faces significant challenges for UI development and testing since it is used in many different ways.  I like to point out that Sesame Street used to run on Liferay, as well as the USMC. Such a completely different user base in both cases, it would be impossible to create a UI to make everyone happy.

So for the OOTB portlets, Liferay tries to deliver UIs which make sense, conform to current web standards (so you don't have to learn special UIs), and that seem to be obvious.

What is seen as a problem for you can be the absolute right solutions for 9 other organizations at different experience levels. It's just hard to make everyone happy.
​​​​​​​
thumbnail
Victor Valle, modified 5 Years ago.

RE: Processes around UX at Liferay

New Member Posts: 8 Join Date: 8/17/16 Recent Posts
Hi Lee!

I'm going to go over your comments and try to provide you with answers.

I want to start with a little bit of overview.

Everyday Liferay runs more user tests. Liferay was a pure developers company and from some years the company started hiring UX Designers gradually. The product is improving it uxer experience along the time. But this is not an easy or immediate change. The change comes gradually as every year we are more designers.

The first version of Lexicon (1.0), it was applied to Liferay Portal 7.0. Since then, Lexicon Team in members considerably. From 7.0 launch, we increased the number of UX Designers for Liferay DXP x6.

There are a lot of things to fix, and a lot of things to be applied, and we aware of it. We always appreciate the feedback from our community and help us to improve. Our product is complex, we have many user types, but believe when I'm saying that we are reducing the complexity and we expect this to be appreciated in each release.

There are different cases you mention in this post. There are many things around like performance, technical limitations, among others, that do not help to create the best experience possible. There are changes that come motivated for these reasons. We understand your concerns Lee, but as David said there is a context around some changes that you are missing and we are not communicating. But believe we don't change things because we just want to make them more fancy or trendy. There are reasons for them.

How much do UX at Liferay reach out to the ordinary real life users instead of the personas?
Reaching out real-life users of any type is complex, but every day we are closer to making it happen more often. We are in continuous contact with our partners and clients to validate our product hypothesis, to transform our product into a better product.

Do UX mix in with developers do developers ask UX questions? What sort of collaboration occurs?
Liferay has multidisciplinary teams, so every team has front-ends, back-ends, ux, product manager, project manager, testers and documentalist. The number of member per team varies. So we are always in contact and direct communication.

How often are users able to demonstrate how they use the product?
We know this is an issue and we are working toward making our product accessible to everyone.

How user centric is the design process and are personas based on knowledge or asumptions on how the product is used?
We build our product with a special focus on the users. As commented above, we talk to clients and users to know the problems they have and make improvements in our product towards a successful experience. We know there are things to fix, and we are improving the product.

How can users be alerted to a change before it's too late so that they can suggest how the change would impact them to inform the design.
Also aforementioned, we check our solutions with some of clients and users. It is not possible to do this task with every client as you can understand.

As always when issues occur, we are open to listening to you. One of the ways is through tickets. We review them and provide solutions.

As you might have seen, sometimes we open tests, questionnaires and surveys to the community to help us improve.

Every day the way we develop our products is more efficient and the quality is increasing.
Lee Jordan, modified 4 Years ago.

RE: Processes around UX at Liferay

Expert Posts: 449 Join Date: 5/26/15 Recent Posts
What is seen as a problem for you can be the absolute right solutions for 9 other organizations at different experience levels. It's just hard to make everyone happy.

That's a valid point David and what I see Liferay doing is a one size fits all rather than allowing sites that work with a tree to keep the tree. Regardless, if it did or didn't work, site admins now cannot easily navigate their sites and that's a bigger problem than dragging pages to reorder them (which co-incidentally is worse in miller columns than it was in trees). The tree was used in two ways, navigation and management. Only the management UI was re-provided. The navigation is still missing. So the product has lost the ability of navigation, to which providing a simple site map would fix this issue for site admins, but a page search was given instead. While a search is nice, it offers no context as to the structure of the site ... which again miller columns makes it harder to understand the page structure of a site.

The feature seems to have been lead by a discussion of a "pool of unstructured pages" that you then structure yourself using navigation menus. So in that situation yes it would work, but upgrading a site that had been built previous to miller, there's no way it could be compatible with miller and so a tree should have been there as an "option". Freedom and choice. Not removing the tree would have made this complaint irrelevant. It was removed in whole, no votes, no phasing out, no option to turn it back on as a menu without drag and drop. Just ripped out and we were forced to use miller.

Maybe some sort of setup wizard that allows simple sites to use Miller columns and complex multisite portals to use tree management, that could be a way to go. Features are being duplicated, but not entirely. So if you want the best of widgets in content pages ... sorry you can't have it and won't have it. So now we'll get users using the wrong page mode for their need.



The break up of the product into tiers of complexity seems to make more and more sense by the day. There's also the issue for 7.0 users who patch ... we're getting code leaks backported that affect us. The edit web content menu is a clear case where UX said don't do it, engineers did it anyway creating 100 other new issues and the change that was supposed to apply to 7.1+ got back-ported to 7.0!!
Q: How often are users able to demonstrate how they use the product?
> A: We know this is an issue and we are working toward making our product accessible to everyone.
But working mostly in isolation from users?!

UX is getting worse. How can it be that you're adding UX resources but putting out features that in the words of the product designers are "calculated risks, in adding more clicks and we think users will get used to it"? Existing customers are being screwed and new customers are getting a product that is even more complex as time goes on.


If you're not hearing the complaints of how much harder Liferay is getting to use, I think you're on a path to irrelevance in the market. UX must be at the forefront of these changes. Perhaps it's the right time now to go beyond Liferay's own solutions and embrace communities like uservoice.com. And listen. And review feature requests properly and with urgency because that's what users want from the product, the clues are there in the feature requests.


Breaking up Liferay does seem to be the only solution though ...


Right now I don't feel like users of portals are being taken into consideration. The product is shifting into two areas, commerce and simple publication (or marketing publication to support commerce). That's fine but taking the product that way leaves behind intranet and extranet portals and those customers may have to find alternative solutions and leave Liferay. Document management for example, while getting the ability to share within the platform, that has been the only real progress made. Some users are gaining significant progress and others are being left behind.




On the UX side of things, things are getting better in some areas, like we are getting new features but there's so much change happening that oversight is occurring. Old features are being forgotten about or worse removed (why?). Why remove features to evolve the product, why not break up the product into use tiers? Look bookmarks might not be relevant to a commerce site, but to a community focused portal can be a shared resource.
But again maybe this is the time to break up the product and listen to the wise words of the people who are calling for Liferay Lite (not by removing features but by providing a simple UX where needed in a Lite bundle and a more complex one where appropriate in a Full bundle). OSGi was supposed to give you that modularity ... yet the reason we are being told for example that blogs can't be patched independent of message boards is because the product is too integrated.

And when features are being released, they are "not yet done", or are "being worked on" and 80%  done at best. So I have to question that if the switch to modern site pages is going to take 4 years over 4 iterations ... why encourage customers to upgrade to software that is in constant Beta. And when we do get features, they're almost like so close to solving a problem, yet seem to cause 10's of new problems we didn't have before. Miller columns is an example of that.

And training site admins? This is going to kill us post upgrade. Not only are we taking features away from them by doing an upgrade and that decision was made by our vendor not us (so all we can do is shrug and seem powerless to complaints) ... things have changed so much that our training needs updating and that puts a strain on us. Then say we get users trying to use the new features, the features that are not quite done yet or are harder to use because users will get used to it? UX is critical to the perception of a product.

The takeaway though is that Liferay is getting harder to use, I don't know how else to describe it but the product designers need to listen to the UX people and reduce the number of clicks it takes to do things. Maybe spin up 7.0 while not perfect, managing content in particular is actually a lot easier 4 years ago than it is today.
Lee Jordan, modified 3 Years ago.

RE: Processes around UX at Liferay

Expert Posts: 449 Join Date: 5/26/15 Recent Posts

Ok so it's 2 years later after posting this. Things that worked in 7.2 were removed in 7.3. One example of many (I don't wanna get bogged down by examples) ... The portlet toppers in the page editor. Firstly consider the browser tab and how you can drag and drop to reorder browser tabs, on the whole you can select any part of the tab and it's a draggable zone.

7.2 had this. 7.3 ... They made it so that to drag the portlet topper you could only use the drag icon to the left. On a widget page the topper remained hot-zonable across the entire topper (as it should be).

If there was a UX process around that, that the content page editor went through UX review before being release dto the community, something like that could have been picked up. Liferay is paying staff to do this and it seems like they aren't making these checks. The Liferay community doesn't get paid to do UX testing and there are very few constant contributors to beta testing.

Community members aren't end users

So here is one big problem I see with relying on the community to plug the UX gap. On the whole community members aren't end users. We are implementing the product, we have some insight as to what the site admin faces and we can relay that on. BUT we in the Liferay community are technically capable of learning any system and we would find it easier to learn to fly the space shuttle than anyone else. We don't use Liferay, we implement it.

Nobody can escape the fact that Liferay is getting harder to use and rather than change direction, the direction seems to be on doubling down on making it even more complicated to use for the end user.

Find actual end users

Usability studies can only be done with real users. Some of us, particulary front end dev focused contributors can point out certain things, but perhaps the best way forward is to screenshare with real users directly. We have DevCon why not have UXCon?