8:19 a.m.
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....
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>
<access role="admin" mode="admin"/>
<access role="user" mode="none"/>
<title>Host</title>
<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(a)eldorado.org.br>
Cc: kimchi-devel(a)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><mailto:alinefm@linux.vnet.ibm.com>
To: ginger-dev-list@nongnu.org<mailto: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<mailto: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