User Interface issueshttps://lab.civicrm.org/dev/user-interface/-/issues2024-03-07T13:51:41Zhttps://lab.civicrm.org/dev/user-interface/-/issues/70Test & resolve final accordion markup pattern rewrite: CRMDashlet (pattern 2)2024-03-07T13:51:41ZnicolTest & resolve final accordion markup pattern rewrite: CRMDashlet (pattern 2)The accordion issue #60 has just one pattern left remaining, which appears in one part of CiviCRM, the dashboard. This is more complex than other accordions as the summary bar needs to be drag-and-drop, as well as have function buttons f...The accordion issue #60 has just one pattern left remaining, which appears in one part of CiviCRM, the dashboard. This is more complex than other accordions as the summary bar needs to be drag-and-drop, as well as have function buttons for refresh, close, and expand-to-modal.
There's a WIP PR for it here: https://github.com/civicrm/civicrm-core/pull/29613 – which has two outstanding issues:
- the expand-to-modal duplicates the title.
- the refresh js in `crmDashlet.component.js` needs to be updated
In addition, testing needs to confirm on several CMS the following still work:
- [ ] drag,
- [ ] drop,
- [ ] expand fullscreen,
- [ ] expand/collapse accordion,
- [ ] refresh,
- [ ] remove dashlet
- [ ] inactive dashlet state (when clicking 'available dashlet')Improve Civi's front-endhttps://lab.civicrm.org/dev/user-interface/-/issues/69Fix Additional Payment div tag issue in Accordion2024-03-07T13:40:03ZshaneonabikeFix Additional Payment div tag issue in AccordionBased on this discussion [here on pull 29448](https://github.com/civicrm/civicrm-core/pull/29448) we need to modify the divs to ensure that the Check is placed inside the Payment Details (rather than outside).
This problem existed in pr...Based on this discussion [here on pull 29448](https://github.com/civicrm/civicrm-core/pull/29448) we need to modify the divs to ensure that the Check is placed inside the Payment Details (rather than outside).
This problem existed in previous versions before. The issue lies in ```templates/CRM/Contribute/Form/AdditionalPayment.tpl``` and can be seen below.
![paymentdetails](/uploads/aea5250221b5177befc50ba34d82df5a/paymentdetails.png)
@nicol comments:
> This closing div closes the crm-accordion-body too soon so the check field is outside the border. This </div> should be removed, and the one below (line 106) brought back.
cc @nicol @noah @herbdoolhttps://lab.civicrm.org/dev/user-interface/-/issues/68Do these really need to be accordions?2024-03-07T13:35:48ZshaneonabikeDo these really need to be accordions?During the work in #67 there was some discussion that the following accordions should perhaps be removed since they aren't that useful (they could be set back to something else).
* [ ] This shouldn't be accordion - Financial/Form/Financ...During the work in #67 there was some discussion that the following accordions should perhaps be removed since they aren't that useful (they could be set back to something else).
* [ ] This shouldn't be accordion - Financial/Form/FinancialAccount.tpl - civicrm/admin/financial/financialAccount?reset=1 + add
* [ ] Does this need to be an accordion? - Case/Form/CaseFilter.tpl - civicrm/case
* [ ] Does this need to be an accordion? - Contribute/Form/ContributionPage/Premium.tpl - civicrm/admin/contribute/custom?action=update&reset=1&id=1&selectedChild=premium
* [ ] Does this need to be an accordion? - SMS/Form/Group.tpl - civicrm/sms/send?reset=1 (install & config SMS dummy ext)
* [ ] Does this need to be an accordion? - SMS/Form/Schedule.tpl - civicrm/sms/send?reset=1
cc @nicol @noah @herbdoolhttps://lab.civicrm.org/dev/user-interface/-/issues/67Tracker for making CiviCRM's accordions accessible2024-03-06T20:54:20ZnicolTracker for making CiviCRM's accordions accessibleIn #60 at least eight accordion markup patterns were identified, demonstrated in ThemeTest. This issue is to track progress on updating all Civi accordion markup to being accessible.
The table below tracks the progress of all of these p...In #60 at least eight accordion markup patterns were identified, demonstrated in ThemeTest. This issue is to track progress on updating all Civi accordion markup to being accessible.
The table below tracks the progress of all of these patterns: bundling pattern 1 and 8 which use the same JS, then there's just three patterns left to make accessible (four, if another instance of an accordion fieldset can be found).
Statuses are either:
- Recommended - a new/agreed pattern, themes should support
- Supported - old pattern but it's still being used, so themes need to support
- Deprecated - old pattern, not being used, so themes can drop support
| Pattern | Status | Initial PR | Current PR |
|---------|--------|------------|------------|
| 1\. crm-accordion-wrapper & crm-accordion-master-wrapper | Supported | [28415](https://github.com/civicrm/civicrm-core/pull/28415) | 64 instances - [29448](https://github.com/civicrm/civicrm-core/pull/29448) |
| 2\. crm-dashlet | Supported | [29613](https://github.com/civicrm/civicrm-core/pull/29613) | (only instance, so same) |
| 3\. crm-collapsible | Supported | [28430](https://github.com/civicrm/civicrm-core/pull/28430) | 9 instances - 8 fixed in [29533](https://github.com/civicrm/civicrm-core/pull/29533) |
| 4\. fieldset | Deprecated (?) | [28441](https://github.com/civicrm/civicrm-core/pull/28441) | That PR might have been only instance |
| 5\. Extensions table | Deprecated | [28473](https://github.com/civicrm/civicrm-core/pull/28473) | Was only instance |
| 6\. Angular directive | Deprecated | [28467](https://github.com/civicrm/civicrm-core/pull/28467) | Was only instance |
| 7\. FormBuilder generated accordion | Deprecated | [28449](https://github.com/civicrm/civicrm-core/pull/28449) | Was only instance |
| 8\. crm-accordion-master-wrapper | Supported | [28421](https://github.com/civicrm/civicrm-core/pull/28421) | Bundled with pattern 1 |
Testing of new patterns should be on all CMSs with their default admin theme (e.g. Claro on Drupal 9+) and Civi's Greenwich (default) theme.
### Testing [29533](https://github.com/civicrm/civicrm-core/pull/29533)
| File | Testing URL | UI works? | likely related JS? | status | notes |
|------|-------------|-----------|--------------------|--------|-------|
| templates/CRM/Admin/Form/ScheduleReminders.tpl | civicrm/admin/scheduleReminders?reset=1 & click 'add reminder' | yes: d7+d10+sa+wp | none | functional | tested with and without an sms provider enabled |
| templates/CRM/Admin/Page/APIExplorer.tpl | civicrm/api3 & then select an Entity, such as ACLRole | breaks: d7+d10+sa+wp | yes, [APIExplorer.js](https://github.com/civicrm/civicrm-core/blob/735b4e27d76f8cc9f0da3c573217eb35a6250720/templates/CRM/Admin/Page/APIExplorer.js), broken | broken | documentation tab content appears below explorer tab content; entity dropdowns don't have intended behavior |
| templates/CRM/Case/Form/ActivityTab.tpl | civicrm/contact/view/case?reset=1 under Activities/SearchFilters | yes: d7 | none that controls the accordion | functional | some extra borders appear around the details |
### Testing [29448](https://github.com/civicrm/civicrm-core/pull/29448)
Would remove all instances of pattern 1 and pattern 8 (the majority of Civi's accordions).
- [x] CRMAccordionToggle - Contact/Import/Form/Preview.tpl - civicrm/import/contact \> page 3
- [x] CRMAccordionToggle - Financial/Form/BatchTransaction.tpl - civicrm/batchtransaction?reset=1&bid=1 (after creating a batch)
- [x] Contact dashboard issues - Contact/Form/Contact.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/Address.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/CommunicationPreferences.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/CustomData.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/Demographics.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/Notes.tpl
- [x] Contact dashboard issues - Contact/Form/Edit/TagsAndGroups.tpl
- [x] Doesn't open on validation error - Activity/Form/FollowUp.tpl - civicrm/activity?reset=1&action=add&context=standalone
- [x] Doesn't open on validation error - Core/Form/RecurringEntity.tpl - civicrm/activity?reset=1&action=add&context=standalone
- [x] Doesn't open on validation error - Form/attachment.tpl - civicrm/activity?reset=1&action=add&context=standalone, civicrm/activity/email/add
- [x] Other issue - common/fatal.tpl - make an error, ie civicrm/payment
- [x] Other markup issue - Contribute/Form/AdditionalPayment.tpl - civicrm/payment?action=add&reset=1&id=1
- [x] Other markup issue - Custom/Page/CustomDataView.tpl - tested by @shaneonabike and requesting feedback (seems ok)
- [x] Other markup issue - Contribute/Form/Contribution.tpl - civicrm/contribute/add
- [x] Other UX issue - Case/Form/Activity.tpl - civicrm/contact/view/case (add activity modal)
- [x] Other tiny issue - Pledge/Form/Search.tpl - civicrm/pledge/search?reset=1 - tested by @shaneonabike and requesting feedback (seems ok)
- [x] Ajax issue - Contact/Page/View/GroupContact.tpl - civicrm/contact/view -\> Groups
- [x] Ajax issue - Pledge/Form/Pledge.tpl - civicrm/pledge/add?reset=1&action=add&context=standalone
- [x] Remove from PR - Case/Form/ActivityTab.tpl - civicrm/contact/view/case
- [ ] ~~This shouldn't be accordion - Financial/Form/FinancialAccount.tpl - civicrm/admin/financial/financialAccount?reset=1 + add~~ see #68
- [ ] ~~Does this need to be an accordion? - Case/Form/CaseFilter.tpl - civicrm/case~~ see #68
- [ ] ~~Does this need to be an accordion? - Contribute/Form/ContributionPage/Premium.tpl - civicrm/admin/contribute/custom?action=update&reset=1&id=1&selectedChild=premium~~ see #68
- [ ] ~~Does this need to be an accordion? - SMS/Form/Group.tpl - civicrm/sms/send?reset=1 (install & config SMS dummy ext)~~ see #68
- [ ] ~~Does this need to be an accordion? - SMS/Form/Schedule.tpl - civicrm/sms/send?reset=1~~ see #68
- [x] Custom/Form/Search.tpl (e.g. civicrm/activity/search?reset=1)
- [ ] ~~Cannot find to test - Mailing/Form/Approve.tpl~~ (there is a path but class isn't called anywhere, does it do anything? New issue https://lab.civicrm.org/dev/core/-/issues/5055)
- [x] Create membership, and then click Edit/View and see the Related Contributions - Member/Form/Membership.tpl
- [x] Create report, click a report like Constituent Summary, and view Custom fields in Field selection- Report/Form/Tabs/FieldSelection.tpl
- [x] Create report, click a report like Constituent Summary, and view fields in Filter - Report/Form/Tabs/Filters.tpl
Edit: moved review summary to a comment.
#### Related class issues
These files are not affected by [29448](https://github.com/civicrm/civicrm-core/pull/29448) but have references to `.crm-accordion-wrapper`, `.crm-accordion-header` or `.crm-master-accordion-header` and need attention to eliminate those classes.
- Activity/Form/Search.tpl
- Case/Form/CaseView.js
- Campaign/Form/Gotv.tpl
- Contact/Form/Search/AdvancedCriteria.tpl
- Contact/Page/View/CustomDataView.tpl
- Contact/Page/View/Summary.js
- Dashlet/Page/Blog.tpl
- Financial/Form/FinancialAccount.tpl - see above
We will need to merge [29563](https://github.com/civicrm/civicrm-core/pull/29563) as well for theming issue fix.Improve Civi's front-endnicolnicolhttps://lab.civicrm.org/dev/user-interface/-/issues/66Add a resets file / section to core CSS. List necessary resets here2024-03-01T23:42:31ZnicolAdd a resets file / section to core CSS. List necessary resets hereOpening this as an issue rather than PR in order to gather sufficient number of resets needed before creating a single place in the CSS folder to put them.
CMS admin themes sometimes clash with Civi's CSS. For e.g. Claro (default admin...Opening this as an issue rather than PR in order to gather sufficient number of resets needed before creating a single place in the CSS folder to put them.
CMS admin themes sometimes clash with Civi's CSS. For e.g. Claro (default admin theme in D9+) does this:
```
td {
height: 4rem;
}
```
which makes Civi tables look like this:
![image](/uploads/b38c89de3e97838a2fc94dd3314dd4d2/image.png)
Instead of
![image](/uploads/d44351e711abbe61b08279ed9f5b73cf/image.png)
(reset with `.crm-container td {height: inherit;}`). These resets will be needed in core and any Civi themes.
Some things are smaller, e.g. the new SearchKit UI on Claro looks like this:
![image](/uploads/b6f81108f635fd89300f1b5be10cde75/image.png)
because of the following non-namespaced CSS that ships in Claro:
```
.panel {
margin-block: 1em 3em;
…
```
which can be reset with putting at the top of Civi's css:
```
.crm-container .panel {
margin-block: 0;
…
```https://lab.civicrm.org/dev/user-interface/-/issues/63Drop support for Bootstrap 3 (EOL'd) and upgrade to the latest Bootstrap version2023-11-08T20:39:35Zjustinfreeman (Agileware)Drop support for Bootstrap 3 (EOL'd) and upgrade to the latest Bootstrap versionDrop support for Bootstrap 3 and upgrade to the latest Bootstrap version.
Because Bootstrap 3 was released 10 years ago. CiviCRM should not be shipping with known out of date software libraries.
Bootstrap 3 is End-of-life as of 2019-07...Drop support for Bootstrap 3 and upgrade to the latest Bootstrap version.
Because Bootstrap 3 was released 10 years ago. CiviCRM should not be shipping with known out of date software libraries.
Bootstrap 3 is End-of-life as of 2019-07-24, reference https://github.com/twbs/release#release-schedulehttps://lab.civicrm.org/dev/user-interface/-/issues/62Contact tabs counts: separate the count of active vs inactive entities2023-11-02T15:23:28ZbgmContact tabs counts: separate the count of active vs inactive entitiesContact tabs can be inconsistent when displaying a number:
- If a contact does not have any active memberships or relationships, it displays zero and is grey
- If a contact has closed cases, it displays the number in blue
I would like ...Contact tabs can be inconsistent when displaying a number:
- If a contact does not have any active memberships or relationships, it displays zero and is grey
- If a contact has closed cases, it displays the number in blue
I would like propose that we show the number of inactive/closed entities separately. Something like this:
![image](/uploads/dd7c103334c073950c3b87bbdd3c374a/image.png)
Perhaps `3 / 5` is not the best visual representation, because to most people it will read as "3 out of 5". Maybe a pill or something else would be more clear, where the inactive count would be grey, and the active would be blue (or whatever the theme uses, because it's just CSS).
To be honest, I rarely have had users complain about this, but personally I find it very confusing, especially for memberships. Say I have duplicate records, and I want to find the one who had a membership, it's an additional click to view memberships. Conversely, it's also annoying for cases, where we aim to work towards 0 (i.e. getting cases resolved).
Previous discussion: https://chat.civicrm.org/civicrm/pl/53twa5xhffguzbqffdh15b3xwr (user-interface channel)https://lab.civicrm.org/dev/user-interface/-/issues/61Modals: move from Jquery UI Dialog to something else?2024-02-20T00:52:26ZnicolModals: move from Jquery UI Dialog to something else?At present Civi's modals (aka popups) are generated using [JQuery UI Dialog](https://jqueryui.com/dialog/). This inserts the modal's markup just above the bottom `</body>` closing tag, which is outside of `#crm-container` and `#bootstrap...At present Civi's modals (aka popups) are generated using [JQuery UI Dialog](https://jqueryui.com/dialog/). This inserts the modal's markup just above the bottom `</body>` closing tag, which is outside of `#crm-container` and `#bootstrap-theme` divs. This is perhaps related to [an issue where](https://chat.civicrm.org/civicrm/pl/fywkz1tcetdp5ms6s39zqfxcbw) modals can't render Bootstrap elements from Form Builder output.
![image](/uploads/71aee3e41f4455dfe65476ab6e821fd9/image.png)
JQuery UI dates back to 2007, is tricky to theme, and doesn't include modern accessibility Aria labels. What are the other options?:
1. replace with [Bootstrap 3's modal component](https://getbootstrap.com/docs/3.4/javascript/#modals) that ships with Civi. Upside is it's more accessibile, reduces code, is easier to retheme or share styles with the base theme.
Downside is there's no grabber to resize the modal, and you can't have multiple modals open at the same time, which Civi likes to do at present. Multiple modals is [considered bad UX](https://app.uxcel.com/courses/ui-components-n-patterns/modals--dialogs-best-practices-166) - Bootstrap5 offers [toggling between multiple modals](https://getbootstrap.com/docs/5.3/components/modal/#toggle-between-modals). There's also scripts that extend Bootstrap Modal to support multiple, ie https://codepen.io/neni9/pen/dJVwqr.
![image](/uploads/4dee863b5b5bd40d0d8a0d95084a0c7b/image.png)
2. use an Angular modal method (e.g. https://jasonwatmore.com/post/2016/07/13/angularjs-custom-modal-example-tutorial)
3. use another modal library
4. use the html element `<dialog>` (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog). Accessible by default, requires no javascript library (can use the native [showModal](https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/showModal) method), widely supported, should never grow old/need replacing, easy to theme… (am writing the upsides in the hope someone replies below with the downsides).
5. change nothing, just ensure that #bootstrap-theme can be applied to the contents of a modal.Improve Civi's front-endhttps://lab.civicrm.org/dev/user-interface/-/issues/60Accordions: Eight patterns in Civi markup – reduce & make more accessible?2024-03-06T20:20:40ZnicolAccordions: Eight patterns in Civi markup – reduce & make more accessible?At present [Civi docs recommends](https://docs.civicrm.org/dev/en/latest/framework/ui/#accordions) making an accordion interface element with `.crm-accordion-wrapper`. There's at least another seven ways accordions are implemented in Civ...At present [Civi docs recommends](https://docs.civicrm.org/dev/en/latest/framework/ui/#accordions) making an accordion interface element with `.crm-accordion-wrapper`. There's at least another seven ways accordions are implemented in Civi, as seen in #56. Some of these look/behave differently, and maybe have to be different, but perhaps some could be merged.
Furthermore, none of these use the basic [aria-labels](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-expanded) recommended in the [Bootstrap3 method](https://getbootstrap.com/docs/3.4/javascript/#collapse) (which remains in Bootstrap5), for letting screen-readers know if an accordion is open or closed, and which contents should be read or not. This is a long-standing issue - https://lab.civicrm.org/dev/core/-/issues/3294 - raised by the late accesibility expert Rachel Olivero (the Olivero theme is named after her). Sidenote: Bootstrap's accordion pattern (`.collapse`) doesn't seem to be used anywhere in Civi.
This meta issue is designed to clarify two points, to further the goals of #57 (and support #58 & #59), and follows @eileen's [question here](https://lab.civicrm.org/dev/user-interface/-/issues/59#note_151554):
- [ ] can we reduce the number of accordion markup patterns that a theme must support from 7 to anything less?
- [ ] can we amend the recommend accordion markup (and in turn civi's accordion implementations) to be more accessible (+ modern/responsive)?
#### The patterns:
1. `.crm-accordion-wrapper` - as recommended in the docs UI reference guide
2. (related) `.crm-dashlet-header` - as seen on the home dashboard. Looks the same but only the expand icon (e.g. arrow) is clickable as the rest of the header needs to be a drag-gable region.
3. `.crm-collapsible` - notably used on the field groups on the contact record main tab - it has no background for the header or body
4. (related) `.crm-collapsible` on a fieldset - as seen on event signup pages
5. `.collapsed` in a table - as seen on the extensions listing page
6. using the `.crm-ui-accordion` angular directive. This is a shorthand to generate the `.crm-accordion-wrapper` type accordion top.
7. `.af-collapsible` on a FormBuilder element - as seen in forms generated by Form Builder - a new JS/CSS/markup pattern [added in 2022](https://github.com/civicrm/civicrm-core/blob/master/ext/afform/admin/ang/afGuiEditor/afGuiMenuItemCollapsible.component.js)
8. there's another Jquery/Angular fieldset accordion used in Searchkit builder that's not in ThemeTest yet.
#### Range of characteristics
These eight variations cover 5 different visual/interaction patterns:
- click on full header to expand/close
- click only on expand/close icon to expand/close
- shaded background for header and body
- transparent background for header and body
- expand a region outside of the parent accordion wrapper (5 - maybe soon to be replaced with SK/FB)
#### Merging patterns
Initial thought is that with a bit of extra css and a tiny bit of rewriting, all of these could be done with two patterns - one based on the current recommended `wrapper > header + body`, with the full header clickable and the icon added entirely in css; and one based on an icon wrapped in an <a> tag that toggles the visibility of another region, as seen in patterns 2 and 5 above (while 5 may soon be replaced and 2 is one-off)..
- A utility class like `crm-accordion-clear` could be applied next to `.crm-accordion-wrapper` to provide 1) above with the same UI as 3)
- Likewise two new CSS selectors could allow the same pattern to be applied to 4) & 8) . Both these changes are demonstrated in a new ThemeTest branch: [Proposals](https://lab.civicrm.org/extensions/themetest/-/commits/proposals)
- I'm not sure why in 7) + 8) the new SK/FB Angular accordions diverged in markup/js/css from Civi's recommend accordion - maybe needs @colemanw to feed in.
- The extensions page 5) will be rewritten with FB/SK at some point so can maybe ignore.
- That leaves 2) - an accordion where only the icon triggers an expand/close so the rest the header is a dragable region. I think that making this use the same markup/css pattern as the others would require rewriting all the others, so it might be safest to leave this an exception for now. There is an attempt to merge the patterns in [Proposals](https://lab.civicrm.org/extensions/themetest/-/commits/proposals) but the header is doing a lot - dragging and right-floated icons. A toggle behavior is more compelling than an accordion, even if it should look like an accordion.
- But even with keeping 2), then potentially only 2 patterns left out of 8.
#### Thoughts on accessibility
[Work has been done](https://github.com/civicrm/civicrm-core/pull/11955) to implement [JQuery Accessible Accordion Aria](https://libraries.io/bower/jquery-accessible-accordion-aria) into Civi (demo of the plugin - https://a11y.nicolas-hoffmann.net/accordion/). Not sure if that is still a promising path, or there's a JQuery free methods now.
The current recommended pattern could be made more accessible with something like the following, based on Bootstrap3's collapse. There's fewer ARIA labels than the JQuery plugin, but it makes clear if the accordion is open or not, and links the header to the expand region with an id, two recommendations of [this walkthru](https://www.hassellinclusion.com/blog/accessible-accordion-pattern/) on accessible accordions.
```
<div class="crm-accordion-wrapper collapsed">
<div class="crm-accordion-header" aria-expanded="false" aria-controls="uniqueID">
Accordion Title here
</div>
<div class="crm-accordion-body" id="uniqueID">
<div class="crm-block crm-form-block crm-form-title-here-form-block">
Accordion Body here
</div>
</div>
</div>
```
This would require two changes - a unique ID added to every unique accordion on a page, and an `aria-expanded="false"` attribute that toggles true/false.
#### Questions
- why did the new angular accordions take another approach? Speed of development or something practical?
- is it worth trying to reduce these down to two recommended patterns, by swapping out the new angular patterns and adding a few new css classes into core? Or better to wait and flag this for the future?
- what's the easiest way to make civi accordions more screen reader friendly?Improve Civi's front-endhttps://lab.civicrm.org/dev/user-interface/-/issues/59Cleanup Civi markup to use the 'canonical' style-guide versions2023-11-28T12:49:34ZnicolCleanup Civi markup to use the 'canonical' style-guide versionsThe hoped-for final step of the theme project is to cleanup Civi markup to remove the multitude of patterns found in #56, repolacing them with the canonical versions specified in #57, so that the theme #58 can shrink in size/complexity.
...The hoped-for final step of the theme project is to cleanup Civi markup to remove the multitude of patterns found in #56, repolacing them with the canonical versions specified in #57, so that the theme #58 can shrink in size/complexity.
The further the project of [replacing Civi's Admin UI screens](https://github.com/civicrm/civicrm-core/pull/27422) with SearchKit and FormBuilder gets, the smaller this task becomes.Improve Civi's front-endhttps://lab.civicrm.org/dev/user-interface/-/issues/58Make a new theme to ship with Civi2024-02-28T17:20:02ZnicolMake a new theme to ship with CiviIn parallel to documenting Civi's Markup in the ThemeTest extension (#56) and agreeing the best markup patterns (#57), produce a new theme to ship with CiviCRM to replace the 15-year-old Greenwich theme.
After extensive discussion @artf...In parallel to documenting Civi's Markup in the ThemeTest extension (#56) and agreeing the best markup patterns (#57), produce a new theme to ship with CiviCRM to replace the 15-year-old Greenwich theme.
After extensive discussion @artfulrobot and I (who each produce a theme - [Aah](https://github.com/artfulrobot/aah) and [Finsbury Park](https://civicrm.org/extensions/finsbury-park-cross-cms-admin-theme)) are deliberately trying to ignore UI specific questions (fonts? colours? flat? shadows? round-corners?) but instead on making those decisions something trivial to change later (and would obviously make them in discussion with the community).
This themes' primary goal is to give Civi a theme backend that will support not just 2023/24's UI trends (shadowy, vs flat, vs skewmorphic), but the trends of the next 20 years. As well as supporting all 7 Civi versions (Backdrop, Drupal 7 with Seven, Drupal 9+ with Claro, Joomla 3, Joomla 4, Standalone, WordPress), the new theme aims to follow several principles:
### Wide use of CSS Variables
Use [CSS Custom Properties](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties) (aka CSS Variables) to make it quick to re-theme. In principle this could make it viable to have a set of Custom property declarations to make the theme look closer to Shoreditch for those whose training materials require that, or for those who need to match a CMS UI or organisation intranet design guidelines.
A test of CSS Custom Properties being used in this way is [currently shipping with the login](https://lab.civicrm.org/extensions/standaloneusers/-/blob/main/templates/CRM/Standaloneusers/Page/Login.tpl) page markup for [CiviCRM Standalone](https://civicrm.org/blog/josh/civicrm-without-cms-welcome-back-standalone). In the screengrab below you can see the three variable arrays for three different UI's
![image](/uploads/d65e77cf87c1208ab0b88af0d515dc35/image.png)
### Bootstrap Subset
Use a Bootstrap subset to continue to support the Bootstrap 3 class names & markup patterns currently in use in post-Shoreditch components (API Explorer, SearchKit, Form Builder, Mosaico, etc). This does not mean Bootstrap 3 as a whole needs to be supported/bundled; and some of Bootstrap 4/5 can be used - but the full Bootstrap 3 or 5 bundle isn't needed.
### Accessibile, responsive, small
Standards in accessibility have evolved fast. Just taking base font-size - the current standard practice is to let the browser define this, with a default of 16px and scale every page font in proportion using Rems. However, in Bootstrap 3: HTML is 10px, body is 14px, all sizes are set in pixels. WordPress and Joomla 3 are worse: both have 13px body size, same as the Seven admin theme on Drupal 7 and 8. Bootstrap 4 & 5, Backdrop, Joomla 4 and Drupal 9 Claro theme get it right: body is 1rem, inheriting pixel size from browser (aka 16px). But it’s an extra complexity for Civi's cross-CMS theming. To understand why this is so important, Rich made a demo: https://artfulrobot.uk/lil/about-rems/.
Mobile and tablet support needs to be added as far as possible.
The theme's filesize should be kept as small as possible within the various constraints described here.
### Structure
Structure the theme to separate style definitions for Style Guide approved markup patterns (#57) and the legacy support for (some of) the older patterns identified in #56, aka 'Civi hacks'. The CSS also needs a CMS Hacks section to handle CMS-specific quirks which often change with new CMS themes, e.g. Drupal 9's Claro). A possible structure below
![image](/uploads/8bd26d331c8a73c8f9f3a54059e8ee07/image.png)
### Separate front theme?
CiviCRM on the front-end has different needs to the backend. Buttons need to match the parent front-end theme style and there's a number of ways to do this, from having separate CSS Variables for front-end pages that users can configure, to having a minimalist front-end theme that inherits more from the parent theme. This will be looked at subject to time and progress of other goals, for now there is a prototype CSS Variable led, minimalist front-end theme that inherits more of a front-end theme while letting the user configure some defaults (ie button colour/size): [Front](https://lab.civicrm.org/nicol/front/-/tree/main).
Related issue: https://lab.civicrm.org/dev/user-interface/-/issues/46. Related [Wiki page](https://lab.civicrm.org/dev/user-interface/-/wikis/DINO:-New-theme(s)).Improve Civi's front-endhttps://lab.civicrm.org/dev/user-interface/-/issues/57Recommend best-practice markup for all Civi UI elements in updated UI Referen...2024-02-25T22:48:10ZnicolRecommend best-practice markup for all Civi UI elements in updated UI Reference Guide / new Civi StyleGuideCivi's [UI Reference Guide](https://docs.civicrm.org/dev/en/latest/framework/ui/) is helpful but very incomplete. As well as trying to [reduce the wide range of markup patterns](https://lab.civicrm.org/dev/user-interface/-/issues/56) in ...Civi's [UI Reference Guide](https://docs.civicrm.org/dev/en/latest/framework/ui/) is helpful but very incomplete. As well as trying to [reduce the wide range of markup patterns](https://lab.civicrm.org/dev/user-interface/-/issues/56) in use in CiviCRM, a comprehensive StyleGuide (either a new project or an update to the Reference Guide is needed to:
- Ensure new CiviCRM interfaces - in core or extensions - use consistent, and core-team/community agreed markup.
- Allows a process to improve this markup.
- Support the development of a new Theme that separates canonical 'style-guide supported' markup patterns, from legacy patterns (support for which will eventually be dropped).
- Helps the eventual process of Civi Core markup clean-up by demonstrating what all the patterns documented in [ThemeTest](https://lab.civicrm.org/extensions/themetest) should be replaced with.
In the longer run the Style Guide can support the introduction of new user experience patterns (e.g. SearchKit layouts), by documenting how to change their appearance.
The chosen patterns should prioritise:
* **accessibility**, as well as improving legibility, font scalability, descriptive icons and colour contrast ratios, to fully incorporate [ARIA attributes](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) to support screen-readers,
* **mobile responsiveness**, as well as improving smaller screen support, using [input modes](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode) to support mobile keyboards or perhaps [enterkeyhint](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/enterkeyhint).
* **usability**, such as using [HTML autocomplete](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete) to support browser-led auto-complete.
Examples of style guides (thanks Dryden@EcoPing for the list):
- [Gov.UK](https://design-system.service.gov.uk/styles/) - separates _styles_ (e.g. lists, links), _components_ (e.g. accordion, breadcrumbs) and _patterns_ (from asking for a Date, to confirm an email, create a username).
- [Shopify](https://polaris.shopify.com/getting-started) - separates more (foundations, design principles, etc) but still separates components (e.g. buttons) and patterns (e.g. confirmation screen), icons, and 'tokens' - classes that implement a quick design element.
- [Material Design](https://m3.material.io/styles) - Google's Open Source design system. Separates styles and components (no patterns).
- [Mailchimp](https://ux.mailchimp.com/) - Mailchimp's guide is called a Pattern library, and lists inside this components - its definitions for these seems different to Gov.UK and Shopify.
Lasting notes can be added to the [Wiki Page](https://lab.civicrm.org/dev/user-interface/-/wikis/DINO:-Identify-preferred-markup) for this.
Previous similar issue https://lab.civicrm.org/dev/user-interface/-/issues/24 by @bgm, & related [Wiki](https://lab.civicrm.org/dev/user-interface/-/wikis/flex-css) with @andie.Improve Civi's front-endhttps://lab.civicrm.org/dev/user-interface/-/issues/56Document all CiviCRM Markup patterns in ThemeTest Extension2024-02-08T16:04:53ZnicolDocument all CiviCRM Markup patterns in ThemeTest ExtensionCiviCRM markup is full of examples of multiple methods to create the same UI element (buttons, accordions, modals, etc). By documenting every variation we can:
- make the process of theme-writing easier as all variations can be tested qu...CiviCRM markup is full of examples of multiple methods to create the same UI element (buttons, accordions, modals, etc). By documenting every variation we can:
- make the process of theme-writing easier as all variations can be tested quickly
- support the process of agreeing a 'canonical' approach for best practice markup in a style guide
- help identify markup patterns that should be deprecated as too obscure, legacy or non-accessible.
This is being done with @artfulrobot's extension [ThemeTest](https://lab.civicrm.org/extensions/themetest), below. To contribute, take a look at the issues. Preferably run a local copy of the extension in a recent Civi setup (any CMS), and work thru open issues or add patterns you've found that aren't documentedfollowing the instructions here: https://lab.civicrm.org/extensions/themetest#adding-patterns.
![image](/uploads/30c5423a2956f2c4004fd1f8bb8c02a3/image.png)
NB: this is a work in progress extension without release numbering, use the latest Main branch.
FTR, a **distinct pattern** is one which has its own CSS assigned to it in the default Greenwich theme or in Bootstrap3.css. So, for e.g. `<span class="crm-button">` and `<button class="crm-button">` as defined by the selector `.crm-button` are the same pattern. But if there was a selector in civicrm.css targeting only `button.crm-button` (there isn't) then they would be different.
At present UX markup patterns (aka 'snippets') have been written in these categories:
- [x] Accordions
- [ ] Alerts
- [ ] Buttons
- [ ] Dialogs
- [ ] Dropdowns
- [ ] Inputs
- [ ] Notifications
- [ ] Other
- [ ] Tabs
- [ ] Radios & Checklists
- [ ] Select lists (incl. Select2)
- [ ] Tables
The main gaps are:
Notes specific to this meta-issue can be added to the [related Wiki page](https://lab.civicrm.org/dev/user-interface/-/wikis/DINO:-Document-variations).Improve Civi's front-endhttps://lab.civicrm.org/dev/user-interface/-/issues/55Clarify "Pay Later", "Execute real-time transactions"2023-09-26T12:15:02ZbgmClarify "Pay Later", "Execute real-time transactions"From [a thread](https://chat.civicrm.org/civicrm/pl/xz1pm9p31jr93ehespfnq643or) started by @guyiac
- [ ] Manage Contribution Pages: "execute real-time transactions", unchecking this really is only about free memberships, not about in-k...From [a thread](https://chat.civicrm.org/civicrm/pl/xz1pm9p31jr93ehespfnq643or) started by @guyiac
- [ ] Manage Contribution Pages: "execute real-time transactions", unchecking this really is only about free memberships, not about in-kind donations, which is a vague concept that CiviCRM never really explains. There are many scenarios where we want to use a PriceSet but the total amount will be 0$ and we still want a contribution
- [ ] Pay Later: we should clarify that this is also a suitable option when we expect the total amount to be 0$, in which case, the payment will be status=complete
- [ ] Pay Later: the instructions should be optional. Maybe it's clear enough, maybe you don't need them, maybe you want to specify it by some other means
Some of the above also applies to Manage Events, although things like "Execute real-time transactions" is called "Paid Event yes/no".https://lab.civicrm.org/dev/user-interface/-/issues/54Move Contact Delete under the Actions menu2023-08-03T12:46:53ZbgmMove Contact Delete under the Actions menuThe "Delete Contact" takes a lot of central space on the View Contact screen, for something that should not be used so often.
![image](/uploads/736e0a017da5843c05c516866ec33118/image.png)
Proposed change:
![image](/uploads/1628e25c854...The "Delete Contact" takes a lot of central space on the View Contact screen, for something that should not be used so often.
![image](/uploads/736e0a017da5843c05c516866ec33118/image.png)
Proposed change:
![image](/uploads/1628e25c85495a510c48b3ab7a3641db/image.png)
Related (closed) PR: https://github.com/civicrm/civicrm-core/pull/26903https://lab.civicrm.org/dev/user-interface/-/issues/53Remove "Save and New" buttons from most places2024-03-14T16:00:22ZbgmRemove "Save and New" buttons from most placesIt might make sense in a few places, but in a lot of places, "Save and New" is clutter.
Opening a financial batch?
![image](/uploads/c9f11710837b0deafe883eb20d08a39d/image.png)
Creating a Contribution Page?
![image](/uploads/4ed0a185...It might make sense in a few places, but in a lot of places, "Save and New" is clutter.
Opening a financial batch?
![image](/uploads/c9f11710837b0deafe883eb20d08a39d/image.png)
Creating a Contribution Page?
![image](/uploads/4ed0a1850a777b39cb0e37b7138b9982/image.png)
(ok, not "save and new", but still, what does "Done" even mean?)
~~Price Sets - Add Field:~~
![image](/uploads/190a2069aab8f49a722f3bf6d5b7e39f/image.png)
~~.. is that "Save and New" really useful? It opens in a popup, so it really only saves 0.5 seconds, but you have to think 0.5 seconds more to click the right button.~~ (edit: there was support to keep it)
And..
- New/Edit Petition
- New/Edit Survey
![image](/uploads/061033c42fbd700e4252b9f111204b07/image.png)
Make it makes sense for:
- New Contribution (in standalone mode)
- ?
![image](/uploads/56ed51a0cbd301b4211603ba1cfdbe85/image.png)https://lab.civicrm.org/dev/user-interface/-/issues/52Consistent markup/classes for status messages2023-08-02T18:26:34ZbgmConsistent markup/classes for status messagesWhile looking at the code of a popular theme, grepping for `\.status`, it made more realize how many different uses there are for the `status` class.
- Footer status
- Contribution Dashboard: when there are no events, there is `status n...While looking at the code of a popular theme, grepping for `\.status`, it made more realize how many different uses there are for the `status` class.
- Footer status
- Contribution Dashboard: when there are no events, there is `status no-popup`, without success/warning
![image](/uploads/7740b1f673e27365551dd18b13ea2230/image.png)
- Find Participants \> Cancel registrations, uses `messages status no-popup`, and the theme has to guess it's a warning:
![image](/uploads/c972b46b3c337ee8e4d2327b17a5d398/image.png)
- Upgrade messages (https://github.com/civicrm/civicrm-core/pull/25961)
- Standalone: https://github.com/civicrm/civicrm-core/pull/26965/fileshttps://lab.civicrm.org/dev/user-interface/-/issues/50Decide upon FA icons for edit/delete/etc2023-03-20T12:55:03ZnicolDecide upon FA icons for edit/delete/etcThe theming docs for the older icon system (https://docs.civicrm.org/dev/en/latest/framework/ui/#older-icon-system) says that most are 'to be decided'…
"The following non CRM-specific icons are available:"
| Icon | Replacement |
| -----...The theming docs for the older icon system (https://docs.civicrm.org/dev/en/latest/framework/ui/#older-icon-system) says that most are 'to be decided'…
"The following non CRM-specific icons are available:"
| Icon | Replacement |
| ------ | ------ |
| edit-icon | To be decided |
| delete-icon | To be decided |
| dashboard-icon | To be decided |
| user-record-icon | To be decided |
| inform-icon | [fa-info-circle](https://fontawesome.com/v4/icon/info-circle) |
| tip-icon | To be decided |
While this older icon system is being phased out – replacing these icons from JQueryUI to Font Awesome needs agreement on which FA icons should be used. If the docs specify this then extension developers can follow the same patterns.
A suggestion for these, following from the pointers [here](https://docs.civicrm.org/dev/en/latest/framework/ui/#icon-meaning-and-consistency) which covers some but not all of these:
| Icon | Replacement |
| ------ | ------ |
| edit-icon | [fa-edit](https://fontawesome.com/v4/icon/pencil-square-o) ![image](/uploads/64cc1db651ac837363050f0bf61b89c1/image.png) |
| delete-icon | [fa-trash](https://fontawesome.com/v4/icon/trash) ![image](/uploads/d3c3871445977924db064fb660c2cef7/image.png) |
| dashboard-icon | [fa-th](https://fontawesome.com/v4/icon/th) ![image](/uploads/db14af0c25bc451e52d7970bcfec7343/image.png) or [fa-home](https://fontawesome.com/v4/icon/home) ![image](/uploads/bec90931c9df85123b51776fa5ed32d7/image.png) |
| user-record-icon | [fa-id-card](https://fontawesome.com/v4/icon/id-card) ![image](/uploads/794b9c212fd3d23ee9d7b4d3f17d037a/image.png) |
| inform-icon | [fa-info-circle](https://fontawesome.com/v4/icon/info-circle) |
| tip-icon | [fa-lightbulb-o](https://fontawesome.com/v4/icon/lightbulb-o) ![image](/uploads/f16f5de3cce1c41178211d68f2da3582/image.png) |https://lab.civicrm.org/dev/user-interface/-/issues/49Search Kit builder UX improvements2023-12-21T22:33:04ZnicolSearch Kit builder UX improvementsFollowing discussion at the sprint with @gibsonoliver, @davem, @colemanw, @christhompson, @callanpaterson {please add others} – am aggregating some of the feedback.
**What this isn't**. A proposal for a UX rewrite, which would normally ...Following discussion at the sprint with @gibsonoliver, @davem, @colemanw, @christhompson, @callanpaterson {please add others} – am aggregating some of the feedback.
**What this isn't**. A proposal for a UX rewrite, which would normally start with a whole process of user feedback & profiling, workshoping, wireframing and so on which is a whole different proposal.
**What this is.** Low hanging fruit, ie optimisations that could make this interface more intuitive, especially for people not familiar with mysql builder, or more used to Drupal Views syntax.
Proposals are grouped in four areas:
1. **Language**. For e.g. changing '_Where_' to '_Filter_', and '_Having_' to '_Filter within Results_', which would make clear both do similar things (filter), but how they are different.
2. **Help tooltips**. An (i) icon that can be clicked for a quick explanation of a term, plus a link to the docs where possible (ie 'WITH is a connection to another entity, like a MySQL JOIN or Views RELATIONSHIP. Learn more >>')
3. **Pre-built Reports** as Search Kit displays in the UI out-the-box. ie recreate some common CiviReports as SK displays that people can then tweak/clone/deconstruct, and in doing so learn a bit of the interface/structure. Inspired by the comment 'Tweaking is easier than creating'.
4. **Reorder elements** of the page to make the user journey more obvious. These should be doable either through CSS grid reordering, or minimal markup tweaks. E.g. (brainstormed ideas not proposals):
- ensure all related blocks are within a parent visual container/border to keep them separate when queries get longer,
- put some elements (ie group or query info) behind an 'advanced' expanding region,
- move left column of searches and displays into top tabs to increase available page width,
- rethink two columns in favour of list of blocks, similar to advanced search.
In addition @artfulrobot raised the issue of adding descriptive class names to regions to make it easier to target them.https://lab.civicrm.org/dev/user-interface/-/issues/48Swap out CiviCRM logos2023-10-07T10:15:12Zjoshjosh@civicrm.orgSwap out CiviCRM logosRequest to replace the current logos displayed in-app and in the "empowered by" display with current CiviCRM logos. Attached files match the current logo dimensions and file names.
![civi99.svg](/uploads/a78c0fe05886784ef83ad0c4ab6c05e0...Request to replace the current logos displayed in-app and in the "empowered by" display with current CiviCRM logos. Attached files match the current logo dimensions and file names.
![civi99.svg](/uploads/a78c0fe05886784ef83ad0c4ab6c05e0/civi99.svg)
![civi99](/uploads/d629d77f01db2750813f08178c264cbb/civi99.png)
![logo_words_small](/uploads/8c5a775cba670ed1854bcf86468e282c/logo_words_small.png)