RHQ GUI: how to deal with user clicking to navigate to view X and then clicking to navigate to view Y before X has finished loading

John Mazzitelli mazz at redhat.com
Fri Aug 12 19:20:14 UTC 2011


On 08/12/2011 03:02 PM, Michael Foley wrote:
> Yes, I think we need to attend to this....
>
> I understand how "quick clicking" and addressing sporadic UI issues can
> appear minor and less important than new feature development. But it is
> creating a bit of a quality perception and is "fighting above its weight".
>
> The analogy is a customer picks up a box at Walmart and gives it a shake
> ... here's a bit of a rattle ... and starts to form a perception about
> quality. That is what is happening with these sporadic UI issues.

Understood. From the grand scheme of things, how important is it when 
weighing how long it will take to fix and looking at what other work we 
have to do.

I read in Ian's post a minimum of 200 man hours, a maximum of 600 man hours.

Based on our collective (poor) ability last year to estimate how long it 
would take to get rid of most of the portal-war for gwt (which was 
supposed to be "just a couple months" and lasted about a year), I will 
take the prerogative and multiple that estimate by pi - thus making it 
roughly 600 to 1800 man hours to yet again refactor our UI.

My question - that's a lot of man hours to dedicate to what is 
essentially a single issue of wanting to be able to rapidly click around 
the app.

Is it that important? As compared to drift, performance improvements, 
continuing to build out the GWT app (graphs, removing portal-war and 
structs - yes we still have to finish our original two refactorings of 
the UI  :), fixing BZs, customer support patching, cloud initiatives, 
etc, etc, etc.



More information about the rhq-devel mailing list