Hi all,

As for Bootstrap, it is just a CSS and HTML library that has some widgets (with JS functionality) and components (plain html markup) with default styles ready to use. For the navigation bar I am styling the default navbar markup to match the mockups. This is the default Bootstrap markup: http://getbootstrap.com/components/#navbar

As you can see, it does support dropdown buttons that we could use for merging two plugins in one tab. In the following link, the accepted answer points that multi-level tabs should be avoided: http://ux.stackexchange.com/questions/21912/usability-of-multi-level-tabs-versus-dropdown-menu-for-navigation.

I wasn’t able to find any other worthy discussion or study that evaluates drop-down buttons/links in tabbed navigation usability but another good point in this link is that we should keep in mind low screen resolutions. Harshal proposed a mockup for the index page that features an off-canvas menu triggered by the hamburger icon and I’m considering using it if the navigation bar content doesn’t fit the screen width (applying some sort of responsive design technique, Bootstrap already has it by default for mobile navigation): http://www.jasny.net/bootstrap/examples/navmenu-push/

We also have to think about an use case scenario that the user only has access to these two merged tabs – in my opinion there’s no point in showing just one tab in a navbar in this case.

I think Aline idea to extend the plugins inside the page makes more sense than using two options in one tab.

I was actually going to ask if someone could guide me through the current tab implementation because in the new-ui mockups we see that all tabs appear in a disabled state in the login page if the user is not logged. I understand that in the current ui the tabs are rendered after user login and after the i18n translation strings are loaded so I was trying to run these functions (getI18n and buildTabs) before login but then I realized that some tabs should not be presented to users that don’t have the right privileges to access them.

I’ll definitely need some help on this because there are some features that would be interesting to add to tab-ext.xml for the new-ui and should be considered before we start splitting Ginger plugin and moving Hosts tab functionalities to Ginger.

For instance, in the current tab-ext.xml we have the following markup:

<tab>

<path>plugins/kimchi/host.html</path>

</tab>

In the mockups each tab has a different color, I can’t set this if I don’t add a class attribute to the list item that gets the <title> from this XML. I need a tag like <cssClass> for the new-ui. Another feature that we can see in the mockups and that maybe we should keep in mind is the guests/templates/storage/network items counter that appears right next to the tab title. This can be done by JavaScript though (otherwise we would have to rewrite and reload tabs-ext each time a new object is added in these pages).

Thanks,

Samuel

From: Archana Singh [mailto:archus@linux.vnet.ibm.com]
Sent: quarta-feira, 12 de agosto de 2015 08:20
To: Samuel Henrique De Oliveira Guimaraes <samuel.guimaraes@eldorado.org.br>
Cc: kimchi-devel@ovirt.org
Subject: Re: Fw: [Ginger-dev-list] [RFC] Inheriting Kimchi's Host tab

Please find my comment inline.

From: Aline Manera <alinefm@linux.vnet.ibm.com>
To: ginger-dev-list@nongnu.org
Date: 08/11/2015 08:12 PM
Subject: [Ginger-dev-list] [RFC] Inheriting Kimchi's Host tab
Sent by: ginger-dev-list-bounces+archanasingh=in.ibm.com@nongnu.org

Hi all,

As we have agreed on Kimchi mailing list, the Ginger community will be
responsible for the Host tab (today part of Kimchi) in a way of 2
different plugins: ginger-basic and ginger.
ginger-basic will provide host basic information, host statistics and
debug reports support. And among the current Ginger features, it will
also provide software updates and repositories management.

For Kimchi perspective, we need to transform part of the Host tab into
the ginger-basic plugin and add it as a Kimchi dependency.
To move the discussion as soon as possible to Ginger community, my
suggestion is to move the entire Host tab into ginger-basic plugin in
the first moment.
Once we do that, we can move software update and repositories management
APIs to Ginger.

Here is my proposal:

1) Create ginger-basic plugin which will launch the Host tab as it is today.
It will be done on Kimchi community.

2) Move software update and repositories management *APIs* from
ginger-basic to ginger.
Only the API will be updated. The UI will keep the same.

3) Add ginger-basic as a Ginger dependency.
In this step, Ginger standalone will launch 2 tabs: Host and
Administration.

All that can be done by the end of September.

Once we have the new UI widgets done, Samuel will start working on
merging those 2 tabs into one as we just need the update how UI is built.
The idea is to release Ginger as one single Host tab in the December

@Samuel: As I was looking into current UI implementation to understand how to merge two plugins into one tab. But now it does not make sense to spend time on understanding this in exiting UI, as the plan is to do this on new UI.
As I am not expert on bootstrap, is bootstrap already has some feature to merge two plugins into one tab?
If not, then do you think it is better to consider this point while implementing new UI, so that merging(two plugins into one tab) can be easier wherever required.
Or do you think still it make sense to spend some time to understand how can this be done in exiting UI?
I hope I make sense to you. Please let me know your input.

Or spending some time in current UI implementation on how to merge will be required?

release - in addition to wok and Kimchi as a plugin.

Let me know what you think about it.

Regards,
Aline Manera