UX Perspective on Performance in OCL

[jamlung]

Continuing the discussion from Performance & stability work:

@paul We should use this space as a place to note where OCL TermBrowser would benefit most from performance improvements. What workflows or pages are users running into slowness? What needs to run quickly to make sure we don’t lose user interest? Let’s try to answer these questions in this thread.

Global search seems to be the most obvious one right now, but let’s try to go deeper than that.

cc: @jon @Sny @rkorytkowski

[jon]

Search (both global and repository-level) is definitely a priority here. Couple examples:

• Search should generally take <5 seconds
• Always show “in process” indicator while results are loading – e.g. grayed out skeleton view, etc.
• For long-running search (e.g. >10), show an additional long-running indicator
• Need Auto-suggestion for the search box
• Quicker, more integrated access to advanced search options – to more quickly get a user to the result they are looking for

There are tons of resources out there for building a good UX around search – would be helpful to pull those in.

@paul would love your input here (on the overall point of this ticket, not just search)

[paul]

Thanks for this @jon!

I’m in the process of applying search UX best practice to the V3 designs.

I anticipate we then dive deeper into more specific needs of our users in the Search UX project that follows.

[paul]

On the issue of general application performance, performance is UX and we should absolutely bake measures to understand this into our QA process… right down to whether certain interaction patterns are detrimental to our users UX due to poor connection etc.

It is possible to perform tasks with poor connections mimicked in the browser, so maybe we start there?

[jamlung]

A couple of notes from our OpenMRS/OCL Squad call today:

• Two search bars makes it easy to leave CIEL. I am working in the CIEL source, and I accidentally leave it and go back to the global search.
• It’s easy to outpace the TermBrowser when searching - you enter the Mappings tab, put in a search term, all before it finishes the last query, and then I don’t know what search results are appearing.

[rkorytkowski]

Please consider these from Performance & stability work - #4 by rkorytkowski as well:

@rkorytkowski

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.

[jamlung]

I am hearing that the speed/availability of Exports is also causing some problems too. PIH (Ellen Ball and others) and @gpotma are part of this discussion and might be able to add more details.

A potential fix would be to show the incremental changes that happened in a version since the last one, even if the full export itself isn’t yet available.

This should benefit a “code reviewer” who would check that the changes from one version to the next are actually correct and relevant for their implementation. Note that this does overlap with the checksum work i.e. “Compare two versions of a source/collection”