Dashboards: dates take up too much space on hourly graphs

macobo commented 3 years ago

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.

Screenshot from 2020-12-03 18-26-33

Describe the solution you'd like

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

Screenshot from 2020-12-03 18-27-45

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 commented 3 years ago

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

paolodamico commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

current node version: v12.19.0

Will try the docker command this weekend as well

mariusandra commented 3 years ago

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

clarkus commented 3 years ago

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.

Frame 8646

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 commented 3 years ago

for installation issue, did below things:

Installed nvm and then did nvm use 14
docker-compose -f docker-compose.dev.yml up -d redis db
./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 commented 3 years ago

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

jatin33 commented 3 years ago

@neilkakkar this is the django related error

neilkakkar commented 3 years ago

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 commented 3 years ago

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

neilkakkar commented 3 years ago

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

jatin33 commented 3 years ago

pip doesnt exist, got it, will install it

neilkakkar commented 3 years ago

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 commented 1 year ago

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

PostHog / posthog