1)Tiki now (since Tiki13) uses bootstrap. Bootstrap has some ideas about buttons, see here. Tiki provides a default bootstrap theme, which is the default theme at installation and also the fallback if anything fails for theme settings, read more here .
2)Tiki's default icon set is now font-awesome, see here. Font-awesome also has some ideas about default icon size.
3) Tiki has some basic css rules that are always applied, no matter which theme is selected ("themes/base_files/css/tiki_base.css")
The question: should Tiki modify any default bootstrap/font-awesome styling (eg: font-size, paddings, margins) using tiki_base.css OR these stylings should be addressed for each theme.
gezzaz opinion: I think Tiki should provide bootstrap and fontawesome "as is", so without modification by default. Imho it is better to not modify default font-size, margins, paddings, etc with tiki_base.css, new users will have a hard time to explore why eg: "Default Bootstrap" theme does not deliver the default bootstrap look and why "Default fontawesome" icons dont look have the same size and padding, etc like on the font-awesome page. I agree, some modifications might be useful, but I think it is better to do it for each theme's css.
Proposed rule is to use 3 schemes based on result of pressing the icon/button:
- navigation (in-page, modal opening, remote destination, etc): always use Bootstrap's "btn-default" class
- insert/update to the database: always use Bootstrap's "btn-primary" class
- delete in the database: always use use Bootstrap's "btn-warning" class
There can be a difference based on where the icon/button is situated (eg: in a navbar, in a form as an action or as a feature, in a table listing items)
- navbar (eg: navigate to another screen): use button styling
- list (eg: open item, delete item, modify item, etc): use link styling
- form actions (eg: save, delete, cancel): use button styling
- item features (eg: print, wathc, translate, etc): use button styling
Bootstrap has button groups (http://getbootstrap.com/components/#btn-groups), the tricky thing is that in Tiki some navigation buttons might appear based on permission settings, so the btn group might break visually for users with lesser permissions. Maybe better to use standalone navigation buttons.
For examples see tiki-list_trackers and tiki-admin_newsletters
Using "tips" or "tikihelp" class on buttons/icons a boostrap popover gets triggered showing the content of "title" tag.
Do we want it to be general? If yes, there are two ways: popover with and without popover title.
If we dont want popover title, maybe we should use bootstrap's tooltip
Some places (eg: tiki-list_trackers) use buttons with icon and text, most places only use text (eg: tiki-admin_newsletters), there are also many example where only an icon is used.
Can we come up with a rule here? Eg:
1) to encourage content contribution, use icon with text for creating new items (eg: tracker item, article, forum post, etc), for import and maybe export.
2) For navigation between main screens, use text only
3) For item related features (eg: RSS, watch, translation), use icon.
Does this make sense?
Tiki offers several ways to create a button/icon, can we make a rule for this?
Code location: lib/smarty_tiki/function.button.php
Use this to create a button (<button>) element with icon, text or both. Default bootstrap classes: btn btn-default
Code location: lib/smarty_tiki/function.icon.php
Use this to show a plain icon or create an icon in a link (<a>) element. Default bootstrap classes: btn btn-link. This is probably ok, please add proposal if you want to change it.
Code location: lib/smarty_tiki/block.self_link.php
Use this to add a link (<a>) to the current page on a text.
4) html: for more complicated cases, eg: button dropdowns (http://getbootstrap.com/components/#btn-dropdowns) use HTML
1) "While button classes can be used on <a> and <button> elements, only <button> elements are supported within our nav and navbar components." and 2) "If the <a> elements are used to act as buttons – triggering in-page functionality, rather than navigating to another document or section within the current page – they should also be given an appropriate role="button"."
It is not consistent how mass actions for items listed in a table are presented. Usually there is some text below the table and a dropdown, but it takes too much space. It would be better to have a general solution that makes the screen less crowded using bootstrap's button dropdown.
Features for wiki page management is very demanding visually, could be simplified. Maybe this direction can be followed for item management of other object types (articles, blog posts, tracker items). Will be hard to agree on this.