Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: Re-design probe selection when creating / editing checks #973

Merged
merged 21 commits into from
Nov 11, 2024

Conversation

VikaCep
Copy link
Contributor

@VikaCep VikaCep commented Oct 25, 2024

Closes #822

Implements option 2 from #822 (comment) where we display the probe locations in checkbox lists separated in columns according to whether they're private or the region they belong to.

image
image

@VikaCep VikaCep self-assigned this Oct 25, 2024
@VikaCep VikaCep force-pushed the 822-probe-selection-redesign branch from 37eff0a to ec9a959 Compare October 28, 2024 21:23
@VikaCep VikaCep marked this pull request as ready for review October 28, 2024 21:32
@VikaCep VikaCep requested a review from a team as a code owner October 28, 2024 21:32
@VikaCep VikaCep requested a review from ckbedwell October 28, 2024 21:33
return (
<Alert
title="You haven't set up any private probes yet."
severity="info"
Copy link
Contributor Author

@VikaCep VikaCep Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original design used a different color and icon for this message, but with the intention of reusing and not modifying the elements we get from grafana/ui for consistency with other parts of the app, I've used the Alert component with info severity which displays in light blue. Happy to adapt it to the original design if you think that's better though.

image

image
(edit: changed content text after Chris comments)

const searchValue = event.target.value.toLowerCase();

const filteredProbes = probes.filter(
(probe) => probe.region.toLowerCase().includes(searchValue) || probe.name.toLowerCase().includes(searchValue)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the original design it's suggested to search by more fields, but we don't have all that probes's info in the frontend, so I've limited to what we have available.

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, on that note, let's create our own internal mapping of it and make a tech-debt ticket that we would rather the api provides us this info at some point in the future. Our probes are static enough (despite the current migrations...) that I feel comfortable we can hard-code this in our repo as it gives a huge UX boost to the user.

As a user I'd just be confused why the docs website provides this level of info but the app doesn't.

A table of Public Probes in the Americas. It shows the Location, Country and Cloud Provider.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. Addressed in c4a5d42 and 32e4775

@VikaCep VikaCep requested a review from w1kman October 29, 2024 15:35
Copy link
Contributor

@ckbedwell ckbedwell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔥 🔥 🔥 Awesome job so far. Few comments I've left inline.

Two slightly more general comments.

There actually is a third (!) state that a checkbox can have and we do utilise at Grafana: indeterminate so we could add that in situations where not all the locations are used in a region.

Grafana Dashboard page showing indeterminate state with folder selection versus The Probe region state which shows an unticked state.

We'll have to check this one with @majavojnoska but I wasn't sure if the brackets beside the region header were supposed to be showing how many regions are available or how many you have selected currently?

So in the following example it would be: Private Probes (1) - AMER (1) - EMEA (0)
The Private probe selection component. The region headers have an accompanying number which shows the number of available probes rather than what is selected.

Comment on lines 23 to 24
Probes are automated tools that test websites and apps. They act like users by sending requests and checking the
responses.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's update the copy here as it isn't too specific to private probes but probes on a whole. @heitortsergent any thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

src/components/CheckEditor/CheckProbes/ProbesList.tsx Outdated Show resolved Hide resolved
src/components/CheckForm/CheckForm.tsx Outdated Show resolved Hide resolved
src/components/CheckForm/checkForm.utils.ts Show resolved Hide resolved
@VikaCep VikaCep requested a review from ckbedwell October 31, 2024 19:07
@VikaCep
Copy link
Contributor Author

VikaCep commented Oct 31, 2024

I believe I addressed all your comments @ckbedwell 🕺 Let me know otherwise, thanks!

@majavojnoska
Copy link

We'll have to check this one with @majavojnoska but I wasn't sure if the brackets beside the region header were supposed to be showing how many regions are available or how many you have selected currently?

So in the following example it would be: Private Probes (1) - AMER (1) - EMEA (0) The Private probe selection component. The region headers have an accompanying number which shows the number of available probes rather than what is selected.

At first, I thought it would be good to show how many probes are available. But now that you've asked, I think it makes more sense to show how many probes you've actually chosen.

Copy link
Contributor

@w1kman w1kman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't care so much about the comments. Overall I love it! 🤩

The checkbox and probe identifier are not aligned
image

Have we considered including private probes in their respective region (including the fact that a private prove can have no region) (there is no indication of what region a private probe belongs to)?

The count feels like a bug
image

expectations
image

It's a bit

src/components/CheckEditor/CheckProbes/CheckProbes.tsx Outdated Show resolved Hide resolved
src/components/CheckEditor/CheckProbes/CheckProbes.tsx Outdated Show resolved Hide resolved
src/components/CheckEditor/CheckProbes/CheckProbes.tsx Outdated Show resolved Hide resolved
src/components/CheckEditor/CheckProbes/ProbesList.tsx Outdated Show resolved Hide resolved
src/components/CheckEditor/CheckProbes/ProbesList.tsx Outdated Show resolved Hide resolved
src/components/CheckEditor/ProbesMetadata.ts Outdated Show resolved Hide resolved
src/hooks/useLocalStorage.ts Outdated Show resolved Hide resolved
@@ -0,0 +1,20 @@
import { useEffect, useState } from 'react';

export const useLocalStorage = <T>(key: string, initialValue: T): [T, (value: T) => void] => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not super keen on this hook.

  • This hook will always set a default value. Even if we change the default value at some point, the user will still be stuck on the old default (without making an active choice).

  • The hook has no context/listeners to sync value change between components.
    Recording 2024-11-05 102209

I'd rather see us using usehooks-ts.
Note: even if we'd use usehooks-ts, I'd suggest to use the option initializeWithValue: false

I could live with this hook existing if:

  • keys were namespace (eg grafana.syntheticMonitoring[<instanceId>].<key>)
  • There were comments (pref JSDoc) clearly stating that state is not synced
  • initialValue changed name to defaultValue, with an option {setDefaultValue: Boolean = false} (which would return the default value without writing it to localStorage).
  • (feature request 😅) if the hook would would allow the developer to select local|session storage with an option/param eg. useClientStorage<T>(key: string, defaultValue?: T, options?: ClientStorageOptions)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added usehooks-ts instead, love the set of hooks it provides!

@w1kman
Copy link
Contributor

w1kman commented Nov 5, 2024

I wasn't expecting the check to be updated/created when I pressed Enter in the filter input
image

@VikaCep
Copy link
Contributor Author

VikaCep commented Nov 5, 2024

Thanks for the review @w1kman! Really good suggestions 🎖️
I believe I've addressed all of them.

Have we considered including private probes in their respective region (including the fact that a private prove can have no region) (there is no indication of what region a private probe belongs to)?

Regarding this, we could do that as the API provides us with the region. But I also think it's good to be able to differentiate them from all other public locations in a separate column as a private probe for easy access. We don't have the provider or the country name as shown in the designs (https://www.figma.com/design/WXbmUSpCMlJHG8fpjvmGT1/%F0%9F%8F%97%EF%B8%8F-Synthetics-%5BDEV-READY%5D?node-id=2244-15776&node-type=frame&m=dev) but I wanted to respect the intention of showing them separately from all other probes. What do you think about Thomas idea, @majavojnoska?

@VikaCep VikaCep requested a review from w1kman November 5, 2024 19:24
@ckbedwell
Copy link
Contributor

I need to re-review the code but wanted to leave a quick comment with two things I noticed UX-wise:

Can we add some sort of clear or x button when the search input has a value? This is a screenshot below when I've just put a space, so it's hidden a load of the probes but it isn't clear there are more probes and/or why they are hidden:

Screenshot of the new probe selection UI. The search input and two probe regions with their respective probes are present.

And on a similar note, if you search for something and no probes match, can we have a zero state mentioning no probes match that criteria or some such?

Screenshot of the new probe selection UI. The search input is present with the text "no matches" and nothing else probe-related is rendered beneath it.

@VikaCep
Copy link
Contributor Author

VikaCep commented Nov 8, 2024

Improved the filter input by adding a Clear button when it has value and a message when there are no results:

Screen.Recording.2024-11-08.at.12.06.01.mov

@VikaCep VikaCep requested a review from ckbedwell November 8, 2024 15:08
Copy link
Contributor

@ckbedwell ckbedwell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 👏 🔥 🌶️

@majavojnoska
Copy link

What do you think about Thomas idea, @majavojnoska?

I'm unsure if Thomas's proposal is to categorize public probes by region or to mix public and private probes within the same regional groups. I was hesitant to add regions to private probes because it seemed overly granular and because of:

User flexibility: As Chris explained to me, users can input any coordinates they desire, which may not align with specific regions.

Usage patterns: The data shows that users primarily create a small number of private probes (average of 1.66 per user). Assigning regions to these could clutter the UI and potentially hide the private probes.

Promotional opportunity: A dedicated section for private probes can serve as a valuable promotional space for this feature.

Some usage stats for private probes:

  • Total users with private probes: 9.60%
  • Number of private probes per user:
    • 1 probe: 7.64% (895 users)
    • 2 probes: 0.89% (105 users)
    • 3-5 probes: 0.58% (63 users)
    • 5-10 probes: 0.34% (40 users)
    • 10-15 probes: 0.06% (8 users)
    • More than 16 probes: 0.06% (8 users)
  • Average private probes per user:
    • For users with private probes: 1.66
    • For all users: 0.15

Usage stats for public probes: 98.32%

  • Total users with public probes: %
  • Number of public probes per user:
    • 0 probes: 1.67% ( 196 users)
    • 1 probe: 34.74% ( 4 608 users)
    • 2 probes: 14.54% ( 1 703 users)
    • 3-5 probes: 22.73% ( 2 662 users)
    • 5-10 probes: 8.05% ( 943 users)
    • 10-15 probes: 2.04% ( 240 users)
    • More than 16 probes: 11.58% ( 1 356 users)
  • Average public probes per user: 4.85

@VikaCep VikaCep merged commit 60b2a78 into main Nov 11, 2024
5 checks passed
@VikaCep VikaCep deleted the 822-probe-selection-redesign branch November 11, 2024 14:00
@VikaCep VikaCep changed the title Re-design probe selection when creating / editing checks Feat: Re-design probe selection when creating / editing checks Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Re-design probe selection when creating / editing checks
4 participants