In order to try a new approach for the development process, it was decided to implement a version of the admin in HTML/CSS/jQuery using Twitter Bootstrap. We do not expect this to be the final interface (both in terms of content and visual design) but want to verify how much of this client side can be used in the development.
The HTML was written using basically Bootstrap components. I tried to write as little CSS as possible (css/admin.css).
The code can be seen at: https://github.com/cardosogabriel/gatein-client
I want to make clear that this early version has the following problems:
- HTML is not valid because of the use of elements <rel="tooltip"> in tags <button> and <a>. This is a bootstrap's element to enable tooltip. So maybe we need to think in another way to enable the tooltips…
- I used an approach that fixes the sidebar. Although scrolling only the content to be a good strategy, we could have problems in displays with lower resolutions since the sidebar can grow with more portals or menu options. So I'll check if is better to put a scroll bar in the sidebar to (which reinforces the app aspect) or to make it not fixed (scroll with the content).
- I fixed the title / main actions. However, the fixed elements don't work well with the responsive design that comes with Bootstrap. So this approach requires some coding in the responsive CSS.
- The CSS was not written using LESS CSS. Need to learn about it.
- The page was just tested in modern browsers (FF 12 and Safari
- Some other elements are not being well displayed when the with is decreased. Need to check what is happening.
With this experiment I could conclude that Bootstrap offers nice UI elements and saves a considerable work. A negative point is that more elements in the HTML are necessary (to make their structure work) and some of them are not valid on W3C validator. A good point is that we could achieve a acceptable layout with not much CSS customization.
Considering that to have a little bit more code won't harm the accessibility, I believe it is an interesting approach to save time. Just remembering that we need to define better the how the top bar / sidebar are presented and to work on the visual design / transitions.
It does look great, there are details to figure out (such as adding permissions), but now I'm curious to see how that can translate into a JSF portlet eventually with the help of http://blog.bleathem.ca/2012/05/richfaces-bootstrap.html
I've just published a new version testing the implementation of a modal. It can be seen by clicking the buttons "Add Permission" or "Edit Permission".
A negative point is that this implementation forces to add the HTML of the modal in the same page HTML. This is not good for several reasons:
- It brings more content in the page even if the user doesn't want to add / edit permissions
- It is not modular. So if we use the same modal in different pages we would need to replicate the code in different pages.
I think it would be better to have the modal in a separate HTML page (like other modals do) and open it as a modal. It would be easier to maintain and more accessible. Maybe we could find out a way to do this way if you think that it's important.
I must say that I'm also not a fan of asterisk for mandatory field, I read the article mentionned by Stevan http://uxmovement.com/forms/always-mark-optional-form-fields-not-required-ones/ and I like the idea.
To make it useful we would need to have like what I've seen on some website:
The "Optional" text is greyed out.
When the field is clicked, it becomes even more greyed out but you can still tell that it's Optional (It's important as you may not remember if the field was optional).
The text is replaced in black color as the user enter the first letter.
For our case, it's true that we should improve the page by displaying "optional" over optionnal fields, instead of "a red asterisk + its legend" over each mandatory fields. It will remove some noise over the page.
For selectors, I think functionnal guys have to select which value is the most oftenly used.
If there is no good default value, as you said, it's probably that the meaning of the value, or the choice to do, is quite difficult. So, I think we should help the user by displaying a string and explaining what the field mean and which impacts the choice can have.
You are right, in that screen we should indicate the optional fields (since are more required) to remove some noise.
The question I see is that the solution proposed in the post works to input texts but not for selectors, checkboxes and radios.
Stévan's solution works in some cases (when we display a selected option and the user changes only if he wants) but that still means that the field is required (since some data was chosen).
The problem is that this solution doesn't work for the case when we don't offer a default and the field is not required. One example of this is a label "Gender" plus two radios "Male" and "Female". We cannot choose one by default and it might not be required as well. So how to make clear that it's an optional field? Stévan, sorry if the string is the text "optional"…
So I believe the solution proposed in this article (http://patternry.com/p=required-form-fields/) works for every cases. It suggests that we indicate required fields when we have more optional ones and indicate optional fields when we have more required ones. He also suggests that we write (optional) next to the label, what would solve the problem I cited
I'm totaly agree with you Gabriel ! "Optional" should be displayed !
Thomas' solution works better when the form only has textfields. But when you have selectors, checkboxes and radios, it's better to display "optional" near from the field.
About default values, I'm still thinking that, even for your case, functionnal guys should define which one is the most oftenly used. If you know that your users are more "Male" than "Female", I think you should decide to preselect "Male".
I oftenly see form where you have to select your title : Mr, Mrs and 'Mr' value is preselected.
Anyway, for this form, I think we should use "Optional" string and also provide some help to the user if our concepts are not very clear.