Prefix your entries with your (first name) to facilitate further discussion.
This focus area includes standardizing page layout / markup conventions, improving readability, reducing CSS bloat and possibly making CiviCRM pages (especially public facing pages) inherit properties consistently from the surrounding CMS theme.
Usability Pain Points
Use this section to list pain points. Include the use case(s) / workflow(s) where it occurs and some idea of severity of problem (using 1 to 10 scale where 10 is the most urgent). Let's try to keep these sorted by severity.
[brian] Too much dead white space (inefficiency in the layout)
[brian] Inconsistent use of html tags for layout/data display (table tags vs. dl/dt/dd tags): makes it difficult to consistently style frontend pages
[brian] Inconsistent layout + white space causes fields to be awkwardly spread out, and more difficult to navigate (accessibility issue)
[brian] Frontend/backend share styles, with no way to differentiate (need a wrapper div to distinguish frontend/backend pages so styles specific to one or the other can be implemented)
[michael] - brian - is there an easy way to say what is a backend and front end pages in civi?
[brian] General css bloat (I'm seeing more and more css styles that accomplish minor tweaks for layout; need less tweak styles and more general use styles)
[brian] Creating a more "generic" theme. In addition to taking a look at whether improvements can be made so that Civi pages inherit properties from the parent CMS theme more effectively, I think we should modify the existing Civi theme to use more generic colors and styles. Nothing against baby blue -- I just don't have a lot of sites using that color as the dominant theme. The colors should be neutral -- greys, tans, etc. -- so that it can appeal to a wider cross section of users "out of the box" without the need for unnecessary style modifications.
[michael] summary tables look too much like selectors, and sometimes their functionality overlaps (see events summary and events selector) which is confusing
[michael] no standard rule / position for buttons at the top of start pages for each of the components. e.g. CiviEvent and has 'manage event' and new event as a button on the top right, Contribute has them on the right, mail has them on the top left. Not trying to be picky here - just saying that the inconsistency can be confusing for users and the more we can standardise layouts the easier the interface is to understand.
[michael] high signal to noise ratio in elements like the selectors. if we have alternating column colors then why also have diving lines? I think using both shading and lines isn't necessary.
[michael] scrollbars appear on quicksearch in firefox
[michael] contacts overlap right hand menu bar in Drupal when using ie7.
[michal] CRM-4351 - print view failing in firefox
Online contribution layout / workflow improvement (michael)
In the contribution/membership/event configuration pages, there is a check box to allow paying by cheque. For most orgs this is offered for 'accessability' reasons but they would much rather people paid online. But the way it is presented, it almost encourages people to click it. It would be better to have radio boxes so you knew what the other (preffered) method was, i.e. pay now online
When you click pay by cheque, it removes the paypal buttons / info to enter credit card details, but the way the form is laid out people often don't see that they have been removed. This is because they are currently seperated by a profile field. So why not put the pay by cheque/online option directly above the form to enter credit card details, and rather than removing the credit card option why not just disable it so people can enable it again if they realise that they do want to pay online.
Events layout / cleanup (michael)
We often collect email as a necessary field in event sign up. But it appears all on its own most of the time, just after the pay by cheque tick box, outside of the normal flow of the other collected profile fields. It would be much nice if these fields were all laid out in the same way. Also, if you have defined email in the profile, why have another box to put the email? Can we do a check to see if email is being collected in a profile field then we don't need to collect it again.
Use this section for ideas about general approaches - with rationales (how does this approach fix things, what pain points does it address, what use cases does it serve / serve better than the current approach).
- [brian] [too much dead white space...] Reduce padding for table cells.
- [brian] [inconsistent use...]
- The issue from a design/layout perspective is inconsistency. Within a single .tpl file you will find both table tags and dl/dt tags used for laying out the data. This makes it cumbersome to lay things out consistently.
- My understanding is that dl/dt/dd tags were introduced to improve accessibility. I don't think that's necessary, as the information displayed by CiviCRM is data (not page layout). And WCAG doesn't completely forbid tables for layout anyway (http://www.w3.org/TR/WCAG10-HTML-TECHS/).
- Table tags should be used for field layout. TH tags should be used for the label cell. Wherever possible, a single "master" table should be used for field layout, rather than multiple tables for each block of information (improves consistency). Subtables should have a distinguishing class tag.
(xavier): I'd suggest to adapt the class naming in the layout to the jquery ui standard, so we don't spend time reinventing the css wheel and we can easily let the users choose the theme they want, or add a new "brian super compact" one
[michael] come up with some explicit rules on what objects exist in Civi layouts (i.e. selectors, records, groups of fields) and some guidlines on when to use these objects (I guess these exist somewhere - perhaps it is time to review them).
[michael] work on simplfying the CSS for things like selectors. Some ideas to start:
- *selectors: *If we have different colours to differentiate rows, then why also have lines between them? Do we need vertical lines in our columns? if tables are shaded, should they also be outlined? Why use bold in headings if they are already differentiated by being on a different color? Can we make column headings stay at the top like drupal?
- field groups: do we use fieldsets or divs? if we have header at the start of field sets, why do we also need outlines?
[michael] work on other CSS guidelines like use of bold, capitalisation, color, etc, HR,
[michael] can we use color to suggest that a certain action is taking place? one for each of CRUD?
[michael] we should group together certain functions and style them similarly, for example, all the buttons, actions, etc. at the top of the Contact layout.
Use this section (or a separate page) for detailed specifications for the chosen solution(s).