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