Custom properties don't look clickable

[marcushyett-ph]

Bug description

Custom properties don't look clickable. Feedback from a customer.

If you primarily use auto capture and other PostHog events you'll see the hedgehog logo, which makes them look very interactive - for events without this logo it makes them look less interactive and confuses people as to whether they're clickable or useable in queries.

Expected behavior

Each event should look like it should be clicked on, the missing hedgehog suggests it's potentially missing something

@clarkus I feel this is a very subtle UX problem - would love to hear your ideas on how to limit confusion here, without loosing the differentiation of custom vs pre-packaged events?

How to reproduce

1. View any postHog event next to a custom event in a filter, etc.

Environment

• PostHog Cloud
• self-hosted PostHog, version/commit: please provide

Additional context

Thank you for your bug report – we love squashing them!

[clarkus]

Related #4266

[clarkus]

The solution is a default icon for all events and actions. That would make it so the items without icons look more complete and actionable. I was working on something for the related issue, but it's a longer-term change. Short term, we can use an icon based on the one we currently use to indicate events in the project navigation. If this stack represents events, then a single tile from that stack could be a reasonable placeholder icon for events.

Some of the longer term work is in figma at https://www.figma.com/file/9yWtngNb1AIuf6KmXaEPJA/?node-id=565%3A169. I will be tracking that in the related issue.

[marcushyett-ph]

This is awesome thanks @clarkus - do you suggest we also keep the hedgehog icon for "PostHog Events" or switch everything to the event icon?

Should we also give actions the same icon as events? (They're subtly different - maybe a broader Information Architecture question for later) - but they're covered by the same stacked diamond icon in the side nav - so I guess so?

Sorry to overcomplicate this further....

We also have event properties, person properties, cohorts and elements - where we see a similar distinction between "hedgehog logo" and non-"hedgehog logo" types. Perhaps we can fix the smaller issue and ignore these for now - but I'm certain the same confusion would persist there?

[clarkus]

#4266 is the long-term solution here. Short term, we can use the same icon everywhere, drop icons, or just use the generic event icon for non-posthog events. I think the option with the least risk would be to back-fill the generic, non-posthog events with the icon I shared above.

[marcushyett-ph]

Great sounds very reasonable to me.

[mariusandra]

@clarkus Where do I find a svg (or a figma link) of the <> icon? Looked around but couldn't spot it :/.

[clarkus]

Sent it directly to you via slack - github won't let me embed SVGs.

[mariusandra]

I tried to implement this <> icon today, but unfortunately this is the icon you sent in Slack:

I spent a good 10min looking for it in figma again, but could not find it. Can you link to it please?

[Twixes]

@mariusandra The recent icons are mostly Material icons, this is the "Open In New" one: https://fonts.google.com/icons?icon.query=open+in+new (SVG link)

[mariusandra]

Too bad it's not the icon that I'm after:

[Twixes]

Ha, too bad, it's a shame I can't read. The rhombus I have not seen in vector form anywhere, but I'm also not sure if that's still the solution @clarkus is thinking of, there were some new ideas

[clarkus]

I was working on this as part of #4696. I don't think we should use the icon specified previously as a placeholder. We've updated the navigation since this was initially designed, so I was trying to address the icon types again. I am trying to reuse the navigation icons, or variants of those icons when I need to be more specific. Here's a screenshot below - I don't have a ton of time into these yet. If we need a placeholder, you can see it at the bottom of the list. Thoughts?

Icons in order of appearance: cohorts, persons, events, actions, groups, and lastly a placeholder.

https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf/PostHog-App?node-id=5569%3A33023

[mariusandra]

Oh this is a much better use of an icon 👍. Can you link to the figma page directly?

I understand there's still more work to do, so just adding this as a braindump of thoughts for whenever you start that work. This definitely doesn't need an answer right now :).

---

We have a distinction between "posthog properties" and "normal properties". The main difference is that normal properties are shown $as_is, but posthog properties are Cleaned up before display.

For example:

"🦔 Feature Flag Called" is actually "$feature_flag_called". So is "$groupidentify", but that's not flagged as a posthog event, so it's awkwardly hanging out between hedgehogs and shown with a $.

I feel this "what you see is not what you get" behaviour is a strong enough reason to figure out an additional layer of taxonomy on top of the category icons themselves.

I can come up with some ways to resolve this issue:

• Add two icons, thus just padding the current situation
• Add an icon on an icon. Icons all the way!
• Use cursive text for the posthog properties
• Use monsopace font for non-posthog properties

I'm not sure in any of them...

[clarkus]

Excellent context! Thank you! I will work on this. It's almost like there is a secondary layer of "official" or "verified" icons. Other competing products call this layer "defined". This work also overlaps with #5312 and #4696. I'll post back here with an updated set.

[clarkus]

Updates for differentiating options of the same type based on status.

https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf/PostHog-App?node-id=5573%3A33304

[posthog-bot]

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.