User Interface issueshttps://lab.civicrm.org/dev/user-interface/-/issues2023-09-19T15:37:34Zhttps://lab.civicrm.org/dev/user-interface/-/issues/24Create a style guide for new CiviCRM components2023-09-19T15:37:34ZbgmCreate a style guide for new CiviCRM componentsc.f. [PR 17775](https://github.com/civicrm/civicrm-core/pull/17775), let's:
* document the classes used by the new CiviCRM extensions (api4, search, afform, mosaico, contact layout editor)
* create a style guide based on that
* start wr...c.f. [PR 17775](https://github.com/civicrm/civicrm-core/pull/17775), let's:
* document the classes used by the new CiviCRM extensions (api4, search, afform, mosaico, contact layout editor)
* create a style guide based on that
* start writing CSS that would make Bootstrap optional
I started a wiki page here that lists the main classes found in afform and search:
https://lab.civicrm.org/dev/user-interface/-/wikis/flex-css
It would also be nice to have something equivalent to the [Shoreditch Styleguide](https://github.com/civicrm/org.civicrm.styleguide) - i.e. an extension to demo the documented CSS?
What else do we need? @nicolhttps://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.