Dashboards: dates take up too much space on hourly graphs

[macobo]

Is your feature request related to a problem?

Currently on dashboards date labels take up 30-40% of the available area for hourly graphs of the past day.

Describe the solution you'd like

Here's how a similar graph looks like on grafana:

I think using shorter or no date formats here would make sense?

As in grafana we could show the full date in the tooltip as well.

Describe alternatives you've considered

Making the graphs full-width - still takes up unreasonable amount of space.

Additional context

I didn't discover until now you can resize graphs! It might also be worth making graphs wider by default, since that removes at least part of the issue.

Thank you for your feature request – we love each and every one!

[jatin33]

@mariusandra @paolodamico I would like to solve this, let me know what kind of design would be suitable?

[paolodamico]

Thanks for the interest in contributing @jatin33! I think we would ideally have something like what we recently introduced for dates (see screenshots below). I wonder if you prefer we whip up a specific design for you or prefer to take some creative license with it (whatever you feel most comfortable with). Tagging @clarkus for any thoughts too.

You may also want to check out the DateDisplay component that we have to make sure your solution is consistent.

[clarkus]

I think this would be a good change to make. Some things to consider when changing axis formatting:

• What is the larger context? Most of our views have a time control in the page that can set the context for the current year. If the year is prominently communicated outside the chart, it'd be OK to simplify time axis labels to drop dates. Note that this can become difficult in comparison scenarios where a primary range is one year, and the comparison range is in another.
• Does every point on the time axis require a label? Given we have tool tips for describing a point in time, it might be acceptable to skip a few labels between points on the axis.
• This axis also allows for notes / annotations to be included. Whatever solution is pursued should take that into consideration.

I'm happy to make time to put together a design for this. I will take a bit of time to ensure that we're tracking the requirements across all insight types with a time axis. @jatin33 are you interesting in implementing a solution, or do you want to try designing something as well? Appreciate you making time to contribute!!! Thank you.

[jatin33]

I will be interested in implementing the solution, as for design I may miss some scenarios you mentioned. So please let me know when you get back to designs

[paolodamico]

Re 1. We actually don't show the year anymore unless you're comparing MoM. You can play around with the new tooltips in PostHog Cloud and see how we're actually showing dates today.
Re 2. Agreed, we can remove a few in-between labels if you have too many data points, let's consider that!
Re 3. 👍

Awesome @jatin33, thanks! We'll keep you posted on a design.

[jatin33]

Hey guys,
I am trying to setup posthog locally using this doc: https://posthog.com/docs/developing-locally
and I am facing issues while starting workers.
Basically this command: DEBUG=1 ./bin/start-worker is failing with below output

yarn run v1.22.10
$ posthog-plugin-server
/Users/jatinpanjwani/opensource/posthog/plugins/node_modules/@posthog/plugin-server/dist/config/config.js:150
        newConfig[key] = env[key]?.indexOf('.') ? parseFloat(env[key]) : parseInt(env[key]);
                     ^
SyntaxError: Unexpected token '.'
  at wrapSafe (internal/modules/cjs/loader.js:931:16)
  at Module._compile (internal/modules/cjs/loader.js:979:27)
  at Object.Module._extensions..js (internal/modules/cjs/loader.js:1035:10)
  at Module.load (internal/modules/cjs/loader.js:879:32)
  at Function.Module._load (internal/modules/cjs/loader.js:724:14)
  at Module.require (internal/modules/cjs/loader.js:903:19)
  at require (internal/modules/cjs/helpers.js:74:18)
  at Object.<anonymous> (/Users/jatinpanjwani/opensource/posthog/plugins/node_modules/@posthog/plugin-server/dist/index.js:3:18)
  at Module._compile (internal/modules/cjs/loader.js:1015:30)
  at Object.Module._extensions..js (internal/modules/cjs/loader.js:1035:10)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
:boom: Plugin server crashed!
:hourglass:️ Waiting 2 seconds before restarting...
any ideas on how to address this?

any ideas on how to solve this?

[macobo]

@jatin33 the issue might be with the version of node.js you're using. What does node --version say?

Also - since you won't be touching the plugin server, feel free to start it with docker: docker-compose -f docker-compose.dev.yml up -d worker

[jatin33]

current node version: v12.19.0

Will try the docker command this weekend as well

[mariusandra]

You need at least v14 for the plugin server to work.

[clarkus]

I put together an example axis mockup today while working on some related issues. This demonstrates the general changes we could make depending on the context for the visualization.

General changes we can make to simplify axis labels:

• Organize the x-axis around the units used to organize the data. For example, if we're charting over hours of time, we only want to label those hours. Including other attributes such as the day of the week, whether it's a weekday or weekend, etc while still accurate don't do much to make the axis easier to scan.
• Remove duplicated values. - We don't need to repeat the full date across every hour point on the axis. We just need to indicate when a new date starts. This same could be extended to the time of day - feasible AM / PM values could be removed.
• Format values for succinctness, while still maintaining meaningful values. For example, "Thursday, December 24th, 2021 at 09:00AM" versus "12/24/2021 · 9:00AM". We will need to settle on some meaningful international standard for dates, or possibly introduce a configuration option to localize date formats for the current user.
• The y axis can benefit from these guidelines as well. Note how I don't repeat the unit "events" for every point on the y axis. It can be labeled on the maximum 7 value and then implied for the rest of the set.

[jatin33]

for installation issue, did below things:

1. Installed nvm and then did nvm use 14
2. docker-compose -f docker-compose.dev.yml up -d redis db
3. ./bin/start

Only able to see Fetched all actions from DB anew as per below pic
Post that unable to start localhost, any suggestions on how to move ahead?

[neilkakkar]

Hey @jatin33 if you scroll up in these logs, there should be a django related error, can you mention what it was?

[jatin33]

@neilkakkar this is the django related error

[neilkakkar]

Ah, do you have python3.8 installed, and did you run pip install -r requirements.txt before running? (steps 2,3,4 here: https://posthog.com/docs/contribute/developing-locally#running-posthog )

[jatin33]

yes, i did but only once.
Do we need to run this each time before starting local dev server?

[neilkakkar]

Nope, once is good enough! What do python --version and pip list commands say?

[jatin33]

pip doesnt exist, got it, will install it

[neilkakkar]

Hmm, if you followed the instructions in a virtual environment, remember to activate it before developing :) (since the python version as well shows 2.7 instead of 3.8)

[mehulshetty]

I created a solution to this feature request. Here are some photos from the Month, Week, and Hour intervals. Thoughts?

[annaszell]

While I think this improved compared to the original message, I would still simplify this as our current solution feels cluttered and overwhelming.