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.
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:
|show 1 more comment|
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:
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.
Yes. I've had issues with a dev team who chose Primefaces as a toolkit - with our (usability team's) blessing - as long as it was totally customizable with CSS.
But it turns out that Primefaces is so difficult for them to customize that they are now refusing to do it - even though it won't comply with our standards or meet user needs.
What I don't understand is that they could easily use other tools along with Primefaces as a base (like JQuery) to do what we need them to do.
From what I understand, though, Primefaces is a toolkit you choose when you don't want to deal with a custom UI at all.
It's a real issue. Primefaces and a good user experience / solid usability don't seem to go well together.
I'm going to write an issue paper that says that Primefaces (out of the box) doesn't meet usability requirements. Hopefully they will either abandon it or use it as a base and supplement it with more robust technologies when it can't do what we need.
Depending on the business needs you might be able to do the same. Some of the technologies we use provide developers with:
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!