note: this is post four in my ATG CSC and why I hate it series:
ATG CSC has a new UI
While the old Commerce Assist UI was pretty bare-bones, pretty simple, and not super “smart” it generally worked. It was pretty easy to figure out how to do what you wanted to do, and get it done. I don’t think I ever had to consult the user docs to figure out how to accomplish some task.
The new ATG CSC has a whole new front end with AJAX driven panels and actions.
While AJAX and more dynamic user interfaces can increase a web application’s ease of use and make you more productive, unfortunately the CSC’s new UI seems to do the opposite.
The AJAX “loading” dialog shows up after clicks for longer than the old Commerce Assist took to load a whole new page the old fashion way. God help you if you try to use the back button. The whole thing feels sluggish. Nothing awful, like 10 second page loads, but in general everyone who’s used it has mentioned how slow it feels overall.
Also with the UI being built in such a complex manner (as mention in earlier posts) from two web apps, database UI Framework data, dynamic JSP includes, dsp includes, panels, panes, includes, and AJAX, it’s very difficult to actually diagnose the cause of various slowness, much less fix it.
The UI is more cluttered and much of it is hard to figure out. You can view a user or order, but that’s different than putting a user or order into context. Depending if you’re viewing or have something in context, the available editing actions are different. The information displayed is different. There’s odd expandable panes, that vanish when collapsed, and show the same information you get on other main panels. If you put an order into context, the screen you get then is different than the screen you get if you click on the order number on the top nav. Sometimes you can’t find your way back to the main screen, and you have to search for the order all over again, just to get the main order screen.
Aside from the navigation and information display issues, actions are more complicated as well. Adding a price adjustment to an order isn’t a two step process any longer. It’s sort of buried, and you have to go through this whole faux checkout flow with ~7 steps just to make an adjustment on the order. If you don’t make it through the whole flow and click Save, it looks like your adjustment is on the order, but when you logout it goes away.
Everything you do is wrapped under this concept of Tickets. Which is great if your CSRs aren’t already using another Ticketing system. If they are, then it’s a giant pain. It interferes with your actions, clutters up the UI, and you end up with a ton of open Tickets in the system, that you don’t want or care about.
It’s Error Prone
In some cases errors and stack traces are displayed to the CSR agent in the UI, but aren’t logged out to the logs, which makes tracking down issues reported by CSRs impossible.
Seemingly harmless errors show up in the CSC logs all the time. Window ids missing, session conf mismatch issues (this was so bad we had to turn it off for the CSC entirely), and many others. And this is an OOTB CSC setup.
Lots of stuff just doesn’t work in seemly random ways. Sometimes we see Order out of date errors (seems like Orders aren’t being handled correctly somewhere in the guts of CSC), sometimes actions just fail and work if you click the submit button again. Sometimes AJAX calls say they fail with 500 errors even if nothing shows up in the logs. All in all it feels un-tested across the board.
The new CSC seems to be more complex, slower, and more error prone than it’s predecessor. I hope it matures in the next version, as I see a lot of potential in a more helpful “smart” application interface, but currently it just doesn’t feel like an upgrade.
Translated into Romanian by Irina Vasilescu
Leave a Reply