Could be a good idea since different users have different use cases
and different priorities in accessing/navigating the screens.
a) In this context it would be even more desirable for us to lift some
submenu things to the highest level (and vice versa) (also in the mouse
context menu),
e.g. if I additionally look at Alert History (AH), Alert Definitions
(AD), Inventory Connection (IC), Monitoring Tables (MTa), Monitoring
Traits (MTr), Monitoring Availability (MA), Operation History (OH),
Monitoring Graphs (MG)
I would maybe like to have the following as 1st order tabs for my daily
work:
AH+, AD, MG, MA, IC, Config, Others*
+ the first tab should open as default, if I click on a resource (left
mouse) or open it from somewhere else
* other tabs could be in 2nd level or added to 1st level
b) It would be also nice to bind those tab orderings to the resource
type. E.g. the RHQ agent could open with the Configuration tab as
default for me where as other DB-plugin-specific resources would be nice
to open up with the MTr or MTa tab.
c) On the other hand sometimes another RHQ feature is very handy:
staying on the subtab when changing resources on a platform.
=>
d) Maybe some icon (like the "mark as favorite resource" one) would be
nice where one could choose to stay on the current tab when changing
resources or open with the default one
BUT it has to be said: All of this is low prio for us at the current
stage of RHQ. Alert management must be improved first as stated
somewhere else on this forum.
On 12/08/2010 03:47 PM, Joseph Marques wrote:
What if tab order were configurable (drag-reordering) whose
positions
were persisted in user preferences?
On 12/08/2010 09:35 AM, Andreas Dietrich wrote:
> Hi,
>
> my 2 cents ....
>
> first looking from the use cases ...
>
> 1. most often we like to have a look at a resource when it has alerts
> (history)
> 2a. we then would like to have a closer look at, acknowledge, delete,
> purge all of the alerts or
> 2b. adjust some alert conditions
> 3. sometimes it is useful to look at time-related data (availability,
> measurements, summary data, availability) to relate the alert
> 4. sometimes we would like to adjust some config (inventory connection
> of our plugin properties - e.g. Logreader settings - or the RHQ agent
> config)
> 5. sometimes it's necessary to restart some agent, restart it's plugin
> container, enable/disable debugging (e.g. after some changes have been
> made or some alert fired)
> (we do this as fast as possible by right-clicking on the agent and
> choosing the apropriate operation)
> 6. we don't use events/content stuff
>
> => thus I would vote for S,(A,M|A,M),I,Cf,O,(E,Ct|Ct,E)
>
> Kind regards
> Andreas :-)
>
>
> On 12/08/2010 02:57 PM, Heiko W.Rupp wrote:
>> Am 08.12.2010 um 14:49 schrieb John Mazzitelli:
>>> On 12/08/2010 08:20 AM, Heiko W.Rupp wrote:
>>>> Am 29.11.2010 um 20:33 schrieb John Mazzitelli:
>>>>> Summary, Inventory, Alert, Monitor, Events, Operations, Config,
Content
>>>> I especially mean the "M" part of it.
>>> Is the concern about the acronym MICA now having letters in a different
>>> order than what the tabs are now in?
>> No.
>> What I mean is that users are for a long time used to have the Monitor tab being
>> the leftmost. Then we put the "Summary" as leftmost and Monitoring next
to it. And
>> now Monitoring is "somewhere".
>>
>> I would rather put it back in 2nd place
>> - users are used to it
>> - users are most often using the monitoring tab of a resource's
functionality.
>>
>> Heiko
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel