ginger-dev-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ginger-dev-list] Fwd: RE: [ginger-dev-list] [RFC] Porposal of group


From: Jan Schneider
Subject: Re: [Ginger-dev-list] Fwd: RE: [ginger-dev-list] [RFC] Porposal of grouping host management functionalities in UI menue tabs
Date: Tue, 20 Oct 2015 15:21:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

Hello Samuel,

my opinion according to the navigation and landing page:
My preferred choice is your option 2 (if the costs are moderate, else option 1). We should remember the latest selected second level item but not it's content/data.


Example sequence:

1) User selects first level item 'Host' for the first time. Second level item 'Dashboard' (which is the first and default) is selected and content loaded.

2) User selects second level item 'Network'. Second level item 'Network' is selected and loaded.

3) User selects first level item 'Virtualization' for the first time. Second level item 'xxx' (which is the first and default) is selected and content loaded.

4) User re-selects first level item 'Host'. Second level item 'Network' (which was the latest selected in Host context) is selected and content reloaded.


For the third level navigation I see the following requirements:
1) Quick navigation i.e. all third level items should be always visible.
2) Remember latest selection like second level.


I currently have no good idea how to consistently implement the third level navigation. Ideas are highly welcome.

Kind regards
Jan



On 10/20/2015 12:17 PM, Walter Niklaus wrote:



-------- Forwarded Message --------
Subject: RE: [ginger-dev-list] [RFC] Porposal of grouping host management functionalities in UI menue tabs
Date: Fri, 16 Oct 2015 14:07:16 +0000
From: Samuel Henrique De Oliveira Guimaraes <address@hidden>
To: Walter Niklaus <address@hidden>, Daniel Henrique Barboza <address@hidden>, address@hidden <address@hidden>


Hi, I've tried to answer via Ginger Dev-List but I had to subscribe using my gmail account first...

About the navigation and landing page, three options:
		1 - First item in the first level always redirects user to first item in the second level (we keep Dashboard link in the 2nd level and by clicking either Host or Dashboard, user will be redirected to the same page). 
		2 - First item in the first level acts just like regular tabs, keeping record of the selected item in the second level (keeping "Dashboard" link in the 2nd level. example: https://jsfiddle.net/bfsL0y7s/1/embedded/result/). I think this might bring some performance issues (if we want to keep the pages "preloaded" and it would require some code refactoring in the JSs files.
		3 - First item in the first level isn't listed in the second level (hide Dashboard link for instance). I don't like this and it will look odd in some cases such as when the second level only has two items. Assuming virtualization would have only Guests and Templates, then Virtualization tab link would redirect to Guests and the 2nd level nav would have a single link to Templates, leading user to confusion cause even if we add a visual clue, the user would see "Virtualization" and "Templates" active all the time.

About grouping panels:
	I believe we just can't use the same pattern for every panel and every page, we have to draw some mockups first. Dashboard will look odd with just the line charts and a single column with system information, we would have to increase font-size in the system info and display each data in columns instead of rows. I think I can mix something from Guests table layout into this page since we'll have more screen width and height.
	For pages that only have two panels, we use Accordions / Collapsible panels or an adjustable panel layout like this - http://www.jeasyui.com/demo/main/index.php?plugin=Layout - but adjusting panel height instead of width. Other pages we can go with mixed patterns. For instance, User Management and Debug Reports in Administration can go side by side, these panels won't have enough info to fill screen width and we can set a fixed height. If we split the screen in three columns I think we can group the panels in 6 different ways ( 1 x 1 x 1, 2 x 1, 1 x 2, 3x) but we would have to figure a way to fill the empty space when a new plugin is installed and appended into each page.

Regards,	
Samuel

-----Original Message-----
From: Walter Niklaus [mailto:address@hidden] 
Sent: sexta-feira, 16 de outubro de 2015 09:31
To: Daniel Henrique Barboza <address@hidden>; address@hidden; Samuel Henrique De Oliveira Guimaraes <address@hidden>
Subject: Re: [ginger-dev-list] [RFC] Porposal of grouping host management functionalities in UI menue tabs


On 15.10.2015 14:30, Daniel Henrique Barboza wrote:
>
>
> On 10/15/2015 09:05 AM, Walter Niklaus wrote:
>>
>>
>> On 15.10.2015 13:41, Paulo Ricardo Paz Vital wrote:
>>> Hello Walter.
>>>
>>> Correct me if I understood wrongly, but all these itens will be 
>>> under the Host (or Ginger) itens in menu, right?
>> True.
>>> If so, why is it necessary a Dashboard item? Why not, when clicking 
>>> in Host option, just open the System statistics and information page 
>>> in only one page?
>> You are addressing 2 aspects here:
>>    - what's the default selection when somebody is clicking on Host.  
>> And here I fully agree with you that "Dashboard" would be the right one.
>>    - how will the functions be presented in the selection ?
>>         - in one page ?  Makes most sense if it's fitting nicely.
>>         - as individual selections/sections ? Would address 
>> functionalities wich require a lot of space.
>>      You're right, we need to clarify these questions as well. But I 
>> would postpone this till we have agreed upon the grouping and can 
>> asess better how
>>      to present it.
>>
>> I guess we need the "Dashboard" selection even if it will be the 
>> default landing page when clicking on Host tab, because you may want 
>> to return to the Dashboard from inside another Host sub-menue and I'm 
>> not sure if everybody would expect to get there by re-clicking on the 
>> main Host Tab.
>
> I think this is a fair point. Samuel, what's your take in this? Is it 
> doable for 2.0?
Samuel, I have added a mockup to visualize the proposal discussed here.
And so far the discussion was only about grouping stuff but not about how to show and navigate between the various functionalities inside a group/tab. Suggestions from the experts/users are very welcome :-)
>
>>> But, in general, I really like your proposal. +1
>>>
>>> Best regards,
>>> Paulo Vital
>>>
>>> On Thu, 2015-10-15 at 11:12 +0200, Walter Niklaus wrote:
>>>> Based on our Scrum discussion from yesterday, where we talked about 
>>>> the requirement of quick navigation via menue tabs in Ginger, here 
>>>> a proposal to get the discussion started.
>>>> My thoughts when creating this grouping was based on the following 
>>>> goals which are contradictory to a certain degree and therefore may 
>>>> require discussions to get the right balancing:
>>>>      -  reduce the menue points/groups to a minimum in order to 
>>>> allow good placement also on smaller windows
>>>>      -  present crsip and meaningfull tab names of the groups in 
>>>> order to make the user understand where to look for a certain 
>>>> functionality
>>>>
>>>> Dashboard
>>>>       - System Statistics
>>>>       - System Information
>>>> Network
>>>>       - Interfaces
>>>>       - Open vSwitch
>>>> Storage
>>>>       - Volumes
>>>>       - Groups
>>>>       - Filesystems (local and remote)
>>>>       - SAN Adapters
>>>>       - Tape Devices (if arch=s390x)
>>>>       - Swap
>>>> Power (may not be active on all arch)
>>>>       - Settings
>>>>       - Sensors Monitor
>>>> Updates
>>>>       - Software Updates
>>>>       - Repositories
>>>>       - Firmware Updates (if arch=ppc64) Administration
>>>>       - User Management
>>>>       - Debug Reports
>>>>       - Configuration Backup
>>>>       - SEP Configuration (if arch=ppc64)
>>>>
>>>> I hope I dind't miss any functionality. Please let me know what you 
>>>> think.
>>>>
>>>> Thanks, Walter.
>>>>
>>
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]