It's all about the answers!

Ask a question

Does anyone actually use the web client?


Evan Leonard (4667) | asked Jan 28 '13, 4:30 p.m.
edited Jan 28 '13, 4:34 p.m.
 More and more our users are becoming frustrated with the web client.
  • It load plans very slow
  • It is tough to drag and drop to prioritize - usually miss the target and make something a child instead of a peer.
  • there is no conflict resolution support so you're always at risk of having to refresh to throw away your work
  • there are lots of random error messages that show up in the UI 
    • We had a great one "X - Status 200:  more details"  And when you clicked more details it said "Status 200" - And the irony is that 200 is the HTTP status code for a successful request!
  • Saving is slow too.

During a planning meeting with 7 people in the room all of these things add up to create an unbearable experience, and strong distaste toward RTC. At this point I am beginning to direct more an more of our users to the eclipse client, which is in the opposite direction of the focus of RTC development.

I'm wondering at this point, if any other customers have actually successfully rolled out the web client to a large development group?

Evan

P.S. we're on 4.0.1

6 answers



permanent link
Guido Schneider (3.4k1380103) | answered Jan 29 '13, 3:40 a.m.

We are using now 4.0.1 with 1200 Users worldwide. We use exclusivly the WebUI. Also for most administrative tasks. Eclipse UI is only used for some Admintasks which cannot be done in Web.

We are using Firefox 10ESR. IE is more or less unusable, specially in V8.

For far away locations with 200ms or more round trip we have a Citrix terminalserver infrastructure beside the Jazzserver with Firefox on it.

Our plans are often 1000+ workitems. Specially Release Plans and Product Backlogs.

I fired many workitems against planing to improve the stability. With V.4.0.1 we are now at a quite stable release and also the performance is acceptable. With V.3.0.1 nd V.4.0 I often asked myself, why did I decided to rollout only the Web client.

Drag and Drop in a Workbreakdown view is very dangerous. We recommend to select the workitem(s) you want to move, go to the target and use the Move above/below/into menu instead of drag and drop. Also the new autoscroll function is not improving this. Specially in a Ranking View with Workbreakdown structure it's absolutly dangerous to use drag and drop. Drag and drop should only be possible within the siblings in a ranking view.

The new function to select all children with the <Alt> key and the new select all function within groups helps also in this area. But it's not understandable when you select a parent, why are not all children also selected per default. Most user forget to press the <Alt> key when the select the parent.


permanent link
sam detweiler (12.4k6180201) | answered Jan 28 '13, 5:14 p.m.
is this RTC3?  the plan views are very slow.. make sure to use Firefox or Chrome.. IE is a dog as plan is all javascript..

no performance improvments in 3.x  everything is in 4.x and forward.. we've been told by IBM that plans should be small <200 workitems) for 'best' performance..  course release and backlogs are much larger..

yep, a dead UI (no threads polling for changes) will experience those concurrent update problems more often than Eclipse for example..

drag/drop in the web UI I don't use much.. its painful as u mention

permanent link
Daniel Toczala (88211414) | answered Jan 29 '13, 10:11 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Evan,

  More of what Sam and Guido have already stated here.

  When a user requests a plan, the request is sent to the Jazz server and the usual authentication, permission, and context setting is done.  The Jazz server will then generate a series of SQL requests to the database to retrieve all of the work items that need to be displayed for a plan.  Once the data sets have been returned, all of this data is returned to the client.  If the client is a web browser, a Javascript routine is then run, which will properly display and render the plan for the end user.  The use of Javascript on the web client to do this work is because plans are active elements, and users can interactively modify multiple work items when doing drag and drop operations and other modifications while looking at a plan.

  Since the JavaScript being executed for plans is fairly complex, the performance of the JavaScript engine in the browser has a direct impact on the perceived end user performance.  Curious users might want to measure the performance differences between the various different web browsers using a tool like Firebug or HttpWatch.

  Since a plan retrieves data for multiple work items, it is like a large query in the way that it requests data and gets large collections of data returned to it.  The main difference is that this data is not just returned to the end user in the form of rows of data.  Instead the plan display must do some amount of JavaScript processing in the web browser to render the final plan display for the user, similar to the way that the reporting engine will need to use the data returned to it to render a diagram for the report.

  Plans can be slow when they become very large, due to the large amounts of data that need to be returned from the database, and the subsequent JavaScript processing in the web browser.  At the present time it is an accepted best practice to limit plans to less than 250 plan items.  Larger plans can take a long time to display, and most of the time a user cannot conceptually grasp more than a few dozen plan items at a time.


permanent link
sam detweiler (12.4k6180201) | answered Jan 29 '13, 10:33 a.m.
In addition to the commentary above.. all the data is NOT processed in one batch in the web UI.

the list of workitems may be returned in one blob, but the rest of the plan data is retrieved in a per workitem loop.

our measurements show about a 5 to 1 web service calls per workitem.. so this web UI is VERY chatty.
and every step along the implementation path contributes..  a few ms on a database look on every workitem makes a difference when i hit 500 or a 1000 workitems. ( we had one fun time a few months ago when someone unrelated was doing a 4 hour ftp download across the same phone line, completely consuming the capacity, and elongating normal response time from 20ms to 90ms..  4.5 times longer.. and it showed.. the scrum meeting had to be canceled)

we measured for 500 workitems at over 3,000 web service calls.  this is old school (early 90's) client server design which works great for small data.(I helped design and write some of them with the same problem back then) and takes lots of thought on how to minimize these kinds of design side effects with larger data..

I think IBM understands the issue, but its gonna be really hard and slow to resolve.. (incremental change over time)

Comments
Daniel Toczala commented Jan 29 '13, 10:52 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

Thanks Sam.


Evan Leonard commented Jan 29 '13, 4:59 p.m. | edited Jun 27 '13, 2:30 a.m.

 Thank you everyone. Its good to hear about your experiences. I didn't realized that IE was so poor in performance compared to FF or Chrome. That's at least one thing I can inform our users about.


Kai-Uwe Maetzel commented Jan 30 '13, 3:14 p.m.
JAZZ DEVELOPER

Hey Sam, can you share your traces with us in a work item? Our traces show that there are 113 calls the browser makes to the server to open a plan with around 4100 work items on it. An empty plan takes 65 requests. The minority of these calls are web service calls. Thanks!


Guido Schneider commented Feb 07 '13, 12:53 p.m.

In addition I would like to know the number of network roundtrips you measured from Client to http Server and back. You only mention the webservice calls in the Server. My concerns are more the roundtrips over lines with 200+ms latency.


sam detweiler commented Jun 27 '13, 7:35 a.m.

sorry, I didn't see this set if replies til today.. I no longer work for the company with the experience I mentioned, and do not have access to the logs. This was recorded with  httpwatch.


permanent link
Michael Walker (99213197157) | answered Jan 29 '13, 7:36 p.m.
We support over 9000 users across many repositories and the majority of our users use the Web Client.  While I agree the Eclipse Client can be easier for Planning purposes, it still works well in the Web Client with Firefox and a lot of our users would prefer not to use the Eclipse client if they can help it. 

permanent link
sam detweiler (12.4k6180201) | answered Jan 30 '13, 5:47 p.m.
and a lot of the planning functions are and will only be available in the web UI.. (starting with 3.0, IBM has started doing web only implementations of new function)..



Comments
Ralph Schoon commented Feb 07 '13, 1:14 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

And as far as I can tell, a lot of customers don't want to use the Eclipse Client for planning and that drives using the Web UI instead.

Your answer


Register or to post your answer.