new refresh button (?)

Charles Crouch ccrouch at redhat.com
Tue Mar 29 20:55:36 UTC 2011


Lets get the issues we know with different parts of the UI not refreshing into BZ so they can be triaged and fixed (it sounds like tree refreshes is a big one)
If it turns out we're still hitting these issues closer to a release, then we can look at adding a refresh option to the top menu for example, or even the refresh button, but I think adding a toplevel refresh button is premature right now.

This brings up a more general question about displaying data in the UI and how we should handle refreshing different data differently. Here is one way to split stuff out:

-Data Guaranteed to change: e.g. Last 8hrs of metric data. People may reasonably want to sit and watch this change over time. Should refresh automatically
-Data Expected to change: e.g. Contents of autodiscovery portlet, alert history. Ability to refresh is good: "i just turned my agent on, i want to see the platform appear", "i created an alert, I want to see if its firing now". Probably doesn't need to autorefresh by default but needs someway to trigger a refresh.
-Data Unlikely to change unless prodded: e.g. alert definitions. Adding or removing items requires human intervention, you see new items by revisiting the page.

Thoughts?

----- Original Message -----
> On 03/29/2011 01:20 PM, John Mazzitelli wrote:
> > So, yes, having this would be a band-aid in the case where the
> > product
> > is out in the field and it turns out we missed one of those cases
> > and
> > a person wants to refresh. F5 is too harsh a solution... see my
> > above
> > comment.
> 
> I understand this, but you're adding a prominent feature that's
> arguably
> redundant and increases the noise in the UI. Importantly, it's
> addressing an exception with a non-exceptional (i.e. non-edge case)
> solution. I don't know if I've stated my concern clearly or not.
> 
> Here's the other concern - Does an *application* focused refreshed
> (i.e.
> this) button give users the impression that it updates something other
> than the *client*? e.g. 'Does that button run server discovery?' 'Does
> it check resource availability?' 'Does it pull any agent info that
> isn't available on the server?'
> 
> > Sounds like another bug - at least a usability bug.
> > If you are referring to the popup, that's a question we need to
> > answer.
> > Do we want to keep the confirmation dialog when F5'ing, closing or
> > leaving the RHQ tab in the browser? I'm leaning towards getting rid
> > of it.
> 
> Again - my opinion - I dislike the 'leaving' popup. I've (probably)
> never hit f5 by accident. If I remember correctly, I hit that dialog
> everytime I try to navigate away. I don't think I'm unusual in this
> regard.
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list