User Experience vs. UI Javascript Component Libraries

Question

Anyone run into Agile Development teams that use UI Component Libraries (PrimeFaces and IceFaces) with horrible User Experiences ... who won't modify the code to support a better User Experience. Looking for responses on how to protect the Users Experience and convince upper management that the UI Component Libraries provide a bad user experience.

Answer 1

I hate to stereotype, but, well, it's somewhat valid in this case: JSF developers don't understand the presentation layer code nor user experience. I think it has to do with the evolution of JSF as a web development tool...most all of the front-end code is out of the hands of the developers. It's all generated automatically (and poorly) via the server side JSF tags. As such, JSF pretty much hides client-side code from JSF developers so they never have a need or motivation to care about a good UX client side.

Things like PrimeFaces are meant to help but, IMHO, they really don't.

The only 'cure' is to get the JSF to STOP MAKING CLIENT SIDE MARKUP. To do that, you likely need to change the entire architecture of the software so that you're leveraging things like JSON and AJAX to a bigger extent--allowing the data to be handled by JSF, but the actual rendering of the page to be handled by the front-end devs.

Be careful about stating 'UI component libraries provide a bad user experience' generically, as there are plenty of quality UI component libraries that provide a fairly decent UX (jQUery UI is one to consider).

So, alas, that's a lot of typing, but I'm not sure I have an answer for you...if anything, I think I have the exact same question!

Some arguments to consider:

• JSF comes from the server-side model of web development. It's a dated concept.
• JSF tends to produce a heavy client-side code base. That impacts UX.
• JSF libraries tend to be fairly rigid, reducing the ability of the UX team to tailor the experience for your customers
• There are plenty of modern up-to-date client-side libraries that are being used to a great extent and are much more forward-thinking both in UX and development philosophies.

Answer 2

To my mind, this isn't an issue specific to Agile development processes; this question gets at the issue of ensuring that UX is part of the development process, period. In one of the first comments on the question "At what point in the development process should UX come into play in an Agile work environment?", user Aaron McIver (rightly) says that "Agile accounts for anything that delivers end user value. If the Agile team you're working on is not accounting for UX, that is to do with the team, not the process."

Your situation seems to be that you/the UX team is not appropriately involved in the development process, developers who are part of the process are implementing UI without consultation with UX, and that UI is bad yet they then won't listen to recommendation to make it better.

This is sadly typical (regardless of software development methodology), and in my experience resolutions require UX buy-in a level or two above the "problem layer" so that responsibilities are made clear to everyone on the team(s). You can:

• Continue to provide good UX-based recommendations for UI
• Document everything that you recommend (obviously) but also immediately document what is actually done and very clearly state how the implementation is does not follow the recommendation
• Constantly communicate with the Project Manager that the UX portion of the project is being undermined by the implementation portion -- not in a mean way, but in quantifiable ways based on your documentation.
• Find a way (either you or through your manager, depending on the hierarchy at your place) to ensure that UX and Dev are working in coordination with each other throughout the product development lifecycle.
• Continue to do the best job that you can providing recommendations and documentation for good UX, and if you come to the realization that UX is not valued there/you can't change the setup, then decide how hard you want to continue to fight.

The key for me has always to make a pest of myself until people understand there's a fundamental process problem, then go back to the work that I/the UX team has done to show very simply that "A is good. B is bad. We recommended A. Devs implemented B. If they continue to implement B, here are the problems that will arise." At the end of the day, management will decide what they want to roll with; if the stakeholders sign off on something that UX doesn't support, that's unfortunate but it's what they do.

You'll note that I didn't take the tack in my answer that DA01 did, which is to address the component libraries themselves. That's because I see the greater issue being one of process and management; without UX embedded in the development process, the non-UX/UI-oriented developers are going to grab onto and use whatever they feel like/are comfortable using until someone stops them.

Answer 3

I feel your pain. Currently our company uses JSF 1.2; very old, very outdated, and sadly the newest application framework we can support. In order to get around JSF shortcoming we put together a user experience team which I currently work in. We have build a agnostic template/framework, custom JavaScript APIs and guidance to use other technologies where possible. We are still currently in our "beta" stage but development groups have been adopting our standard where possible.

Depending on the business needs you might be able to do the same. Some of the technologies we use provide developers with:

• jQuery and jQuery UI
• Modernizr
• jQuery DataTable Plugins
• jQuery Qtips Plugin
• Many custom developed plugins
• Custom CSS to help style around JSF structural deficiencies.

We then eat or own poison in that all the functionality and styling we provide is built on top of JSF 1.2. As the "application" provides no real application need it proves that the framework is somewhat solid. We also provide syntax highlighting showing how we implemented the style and functionality. In most cases developers on need to attach a class to a an element like a table and our client side data tables plugin will automatically style the feature accordingly.

Currently I can not provide a link to our UX Guidelines as we are still working on them and they have yet to be promoted to a public facing server. But its in our backlog.

Hope this helps!