Launch HN: Explo (YC W20) – Customer-facing dashboards and reports • Hacker News Board

Re: Launch HN: Explo (YC W20) – Customer-facing dashboards and reports

#31

Post by allyourhorses » Wed, Jun 09, 2021, 4:57 PM UTC

rnvarma wrote: post #28

allyourhorses wrote: post #25

Clicked into one of the demos, was greeted by around 10 progress spinners, possibly more. This instantly reminded me of some combination of Google Cloud's deeply mediocre console and waiting for a Jira page to render. I'd simply never prefer a tool like this or see it fit to force someone else to use it, and I don't understand why anyone would intentionally design an app to behave like this. Please kill those progres…

Hi, really appreciate the feedback! I 100% agree that the way we handle initial page load is not ideal and is an area I have been meaning to prioritize for some time. We've just been swamped with other customer requests for new UI interface and charting functionality. I am curious your thoughts on a better way to approach this. My initial thought is for a single loading state which ends when all the data is ready to…

Thanks for replying.

Precompute whatever you can I guess, but I'm guessing the app has parameterized queries and stuff like that which are hard to precompute. In that case even a cache or LRU list is fine, say precomputing the handful of most common views people will encounter most often.

Imagine even if only Jira's new ticket page and 'open tickets' search result were pre-rendered so loading them took Separately if you can reduce the workflow for a page from being a task in its own right (most of which is waiting around) to something as simple as a click, it can increase user confidence a lot. If something that took 5 seconds (+4 of which is just waiting) suddenly completes in 200/300ms, folk learn new tricks for your tool, like middle-clicking open a bunch of screens, or noticing they can open and close it much more easily. It makes the whole experience feel more agile, which definitely has an effect on loyalty

Re: Launch HN: Explo (YC W20) – Customer-facing dashboards and reports

#32

Post by jedberg » Wed, Jun 09, 2021, 4:58 PM UTC

allyourhorses wrote: post #25

Clicked into one of the demos, was greeted by around 10 progress spinners, possibly more. This instantly reminded me of some combination of Google Cloud's deeply mediocre console and waiting for a Jira page to render. I'd simply never prefer a tool like this or see it fit to force someone else to use it, and I don't understand why anyone would intentionally design an app to behave like this. Please kill those progres…

I'm curious what you would like instead of spinners? This product makes database calls that could take an unknown amount of time to complete. How should they indicate to the user that they are waiting for the data to build the chart?

Re: Launch HN: Explo (YC W20) – Customer-facing dashboards and reports

#33

Post by allyourhorses » Wed, Jun 09, 2021, 4:59 PM UTC

jedberg wrote: post #32

allyourhorses wrote: post #25

Clicked into one of the demos, was greeted by around 10 progress spinners, possibly more. This instantly reminded me of some combination of Google Cloud's deeply mediocre console and waiting for a Jira page to render. I'd simply never prefer a tool like this or see it fit to force someone else to use it, and I don't understand why anyone would intentionally design an app to behave like this. Please kill those progres…

I'm curious what you would like instead of spinners? This product makes database calls that could take an unknown amount of time to complete. How should they indicate to the user that they are waiting for the data to build the chart?

It knew which queries to run before I clicked, because those queries are baked in. Why did I have to wait for the app to do something it knew it had to do if someone clicked? Of course we can't make e.g. protein folding an instantaneous task, that doesn't mean common workflows and request patterns can't be. I guess it's the difference between "did I ask the computer a hard question?" and "did I simply ask the computer to do its job?"

In the example dashboards, I'm guessing something like 100% of requests make exactly the same queries. Maybe in a typical corporate dashboard, 70% of users will pull up the default view before leaving. These cases easy to optimize for and definitely worth optimizing for

Re: Launch HN: Explo (YC W20) – Customer-facing dashboards and reports

#34

Post by jedberg » Wed, Jun 09, 2021, 5:05 PM UTC

allyourhorses wrote: post #33

jedberg wrote: post #32

Earlier quoted context omitted.

I'm curious what you would like instead of spinners? This product makes database calls that could take an unknown amount of time to complete. How should they indicate to the user that they are waiting for the data to build the chart?

It knew which queries to run before I clicked, because those queries are baked in. Why did I have to wait for the app to do something it knew it had to do if someone clicked? Of course we can't make e.g. protein folding an instantaneous task, that doesn't mean common workflows and request patterns can't be. I guess it's the difference between "did I ask the computer a hard question?" and "did I simply ask the compute…

If you own the frontend and the database, sure. But this product hits other people's databases. The only way they can optimize this is by making queries it thinks the user might want. They can't cache the response because they have no way of knowing if it changed, since again, they don't control the data source.

If I owned the database they were getting data from, I'd be mighty upset at the insane amount of useless queries they'd have to make guessing what the user wants.

Re: Launch HN: Explo (YC W20) – Customer-facing dashboards and reports

#35

Post by sdesol » Wed, Jun 09, 2021, 5:10 PM UTC

dataviz1000 wrote: post #10

rnvarma wrote: post #5

Earlier quoted context omitted.

Thanks for the suggestion! We are mostly migrated over to Highcharts, though we have a few customers using legacy charts in some of the other libraries you mentioned. We've talked about how we want to build our own visualizations with more low level concepts (mostly haven't due to resource constraints), and visx looks like a really solid place to start. To your point, we have already had a few customers that display…

Looking at where highcharts are today, I might have jumped the gun on that comment as they have come a long way. Three years ago we were using them. After I built our React Native version of the data dashboard I was giving the hard requirement to implement charts on mobile of which there weren't any out of the box solutions for at the time. Nonetheless, if you find yourself needing to implement custom charts especial…

> I do recommend considering visx.

Just to add another recommendation to the mix. I'm an extremely happy echarts user. I recently had somebody comment about the graph that was in my product as they were surprised by how it was done, which goes to show how flexible and powerful echarts is.

If you go to https://public-001.gitsense.com/insights/github/repos?r=gith... and look at the timeline chart, you can see that it is pretty flexible. I was able to convert a scatter chart into the timeline chart which supports scrolling left and right fairly easily.

Re: Launch HN: Explo (YC W20) – Customer-facing dashboards and reports

#36

Post by allyourhorses » Wed, Jun 09, 2021, 5:10 PM UTC

jedberg wrote: post #34

allyourhorses wrote: post #33

Earlier quoted context omitted.

It knew which queries to run before I clicked, because those queries are baked in. Why did I have to wait for the app to do something it knew it had to do if someone clicked? Of course we can't make e.g. protein folding an instantaneous task, that doesn't mean common workflows and request patterns can't be. I guess it's the difference between "did I ask the computer a hard question?" and "did I simply ask the compute…

If you own the frontend and the database, sure. But this product hits other people's databases. The only way they can optimize this is by making queries it thinks the user might want. They can't cache the response because they have no way of knowing if it changed, since again, they don't control the data source. If I owned the database they were getting data from, I'd be mighty upset at the insane amount of useless q…

Easily solved by a user configurable staleness value with some reasonable default. Google don't crawl the entire web in response to every query because for the vast majority of queries it's unnecessary. For those where it might be necessary (like news), they instead crawl at a higher frequency or use some special flow (like they do for tweets), either way the result is seamless, involves no progress spinners and is well suited for the vast majority of users.

Re: Launch HN: Explo (YC W20) – Customer-facing dashboards and reports

#37

Post by jedberg » Wed, Jun 09, 2021, 5:29 PM UTC

allyourhorses wrote: post #36

jedberg wrote: post #34

Earlier quoted context omitted.

If you own the frontend and the database, sure. But this product hits other people's databases. The only way they can optimize this is by making queries it thinks the user might want. They can't cache the response because they have no way of knowing if it changed, since again, they don't control the data source. If I owned the database they were getting data from, I'd be mighty upset at the insane amount of useless q…

Easily solved by a user configurable staleness value with some reasonable default. Google don't crawl the entire web in response to every query because for the vast majority of queries it's unnecessary. For those where it might be necessary (like news), they instead crawl at a higher frequency or use some special flow (like they do for tweets), either way the result is seamless, involves no progress spinners and is w…

Funny you should bring up Google. Google is so hard on infrastructure that most big sites have special handling for Google scraper requests. At reddit we put google on their own slower server cluster just so they didn't break the website.

We only did this because of the extreme value Google brings via traffic. But most crawlers and other things that made speculative queries like that were just banned.

Re: Launch HN: Explo (YC W20) – Customer-facing dashboards and reports

#38

Post by djyaz1200 » Wed, Jun 09, 2021, 5:36 PM UTC

Very cool! We've spent a lot of time + money doing this ourselves. I'd be interested to understand the pricing model and self serve options. I'd also be interested in adding alarms so we could use this to monitor our system status. We do that now but without visuals and it would be nice to have a slick internal status page with graphs and alerts for unexpected values.

Re: Launch HN: Explo (YC W20) – Customer-facing dashboards and reports

#39

Post by rnvarma » Wed, Jun 09, 2021, 5:49 PM UTC

sirmike_ wrote: post #27

rnvarma wrote: post #13

Earlier quoted context omitted.

That makes sense. We are definitely not trying to hide an outrageous enterprise price tag. I responded to mchusma's comment with how our pricing currently works. Let me know if you have any specific questions about it and happy to dive deeper!

Would it be possible to put it in print where we could find it without iteration over the same query on a third party news aggregation website which is likely to never be found by anyone who could benefit from your services?

It definitely would be possible :) We hadn't gotten as many requests for public pricing until right now so we'll spin something up with this feedback!

Re: Launch HN: Explo (YC W20) – Customer-facing dashboards and reports

#40

Post by rnvarma » Wed, Jun 09, 2021, 5:54 PM UTC

ranman wrote: post #23

I’m excited about the possibility here but as a dev I’m waiting for that self-serve functionality. I would have paid a modest fee for a month or so to try it out and maybe converted to a prod customer if it met my needs. There was a great thread recently on developer marketing here: https://twitter.com/nickwritesit/status/1402318187299934212?... You should post again here and on producthunt when there’s self-serve si…

Super interesting (and thorough) thread of thoughts, thanks for sharing!

We are definitely hoping to launch self serve in the near future but have decided not to while we iterate on the core features and ensure things work with a qualified and controlled set of customers. However, it is helpful to understand how important self serve is to developers.