# UX Perspective on Performance in OCL

**URL:** <https://chat.openconceptlab.org/t/ux-perspective-on-performance-in-ocl/40>\
**Category:** Software\
**Tags:** ux\
**Created:** [May 26, 2023, 12:47pm UTC](https://chat.openconceptlab.org/t/ux-perspective-on-performance-in-ocl/40 "2023-05-26T12:47:42Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![rkorytkowski](https://chat.openconceptlab.org/user_avatar/chat.openconceptlab.org/rkorytkowski/32/14_2.png) [@rkorytkowski](https://chat.openconceptlab.org/u/rkorytkowski)\
**Post date:** [June 5, 2023, 12:14pm UTC](https://chat.openconceptlab.org/t/ux-perspective-on-performance-in-ocl/40/6 "2023-06-05T12:14:34Z")

</div>

Please consider these from [Performance & stability work - #4 by rkorytkowski](https://chat.openconceptlab.org/t/performance-stability-work/39/4) as well:

> [@Performance & stability work](https://chat.openconceptlab.org/t/performance-stability-work/39/1):
>
> Investigate possible UI changes to respond faster to users. Here are just some ideas that could be considered.  
> 4.1. Make adjustments to global search to limit the scope of search to what is most interesting to users. Maybe it doesn’t make sense to run 5 queries for each search if users hardly ever change tabs to Mappings, Sources, Users or Orgs.  
> 4.2. Identify long running tasks and make them asynchronous with UI supporting notifications when ready and tracking progress while continuing doing other things.

In terms of search speed it is much faster to give results back, if we don’t have to count them precisely… e.g. saying there’s 1000+ results is much faster than saying there’s 244543 results.

---

_[View the full topic](https://chat.openconceptlab.org/t/ux-perspective-on-performance-in-ocl/40)._