215 karma · joined September 5, 2015
What would you suggest as a better title?
R and RMarkdown were big inspirations for what we're building at evidence.dev now, so very grateful to everyone involved in the R community
I'm one of the maintainers of Evidence (open source tool based on markdown + SQL) and working on a similar approach to creating presentation tables configurable in code.
Some examples here for any SQL + table enthusiasts: https://docs.evidence.dev/components/data-table
Here's an example project with some filter components and custom styling: https://ecommerce.evidence.app/
This is still a static app - the data warehouse was only hit during the app's build process
https://github.com/evidence-dev/evidence
Previous HN discussions:
https://news.ycombinator.com/item?id=35645464 (97 comments)
https://news.ycombinator.com/item?id=28304781 (91 comments)
Previous HN discussion: https://news.ycombinator.com/item?id=35645464 (97 comments)
We started with D3 and a few other tools, but felt that we get a lot more out of the box with ECharts, like interactivity and an events API. ECharts is also a lot more extensible than people give it credit for.
If anyone is curious, we documented the process of selecting a charting library after assessing several options: https://github.com/evidence-dev/evidence/issues/136
Previous HN discussions:
https://news.ycombinator.com/item?id=35645464 (97 comments)
https://news.ycombinator.com/item?id=28304781 (91 comments)
In our team’s experience, the most important factor in getting engagement from users is including the right context directly within the report - definitions, caveats, annotations, narrative. This pre-empts a lot of questions about the report, but more importantly builds trust in what the data is showing (vs having a user self-serve, nervous that they’re making a decision with bad data - ultimately they’ll reach out to an analyst to get them to do the analysis for them).
The second most important factor was loading speed - we noticed that after around 8 seconds of waiting, business users would disengage with a report, or lose trust in the system presenting the information (“I think it’s broken”). Most often this resulted in people not logging in to look at reports - they were busy with tons of other things, so once they expected reports to take a while to load, they stopped coming back.
The third big finding was giving people data where they already are, in a format they understand. A complicated filter interface would drive our users nuts and turned into many hours of training and technical support. For this reason, we always wanted a simple UI with great mobile support for reports - our users were on the go and could already do most other things on their phones.
We couldn’t achieve these things in BI tools, so for important decisions, we had to move the work to tools that could offer text support, instant report loading, and a familiar and accessible format: PowerPoint, PDF, and email. Of course this is a difficult workflow to automate and maintain, but for us it was crucial to get engagement on the work we were producing, and it worked.
This experience inspired my colleague and I to start an open source BI tool which could achieve these things with a more maintainable, version controlled workflow. The tool is called Evidence (https://evidence.dev) if anyone is interested.
We can help you figure out if it's feasible - let me know and we can set up some time to chat: sean at evidence.dev
"Containerized" approaches with evidence are also quite interesting - lets you combine several tools and use evidence as the last mile. Here's a great example: https://github.com/matsonj/nba-monte-carlo
We also think that reporting outputs should have a very high bar for visual appearance, and it takes quite a bit of work in Quarto to get charts up to that standard of quality. It sounds like a nice-to-have feature, but in our experience, publication quality data viz is a very important way to build trust with businesspeople who read the reports. We spend a ton of effort thinking through design choices at Evidence and want to give data teams a library of components they can pull off the shelf and write in a simple, declarative syntax.
Thanks for the feedback. There’s some info under Data Sources in the Core Concepts section, but maybe we should make the db support more prominent in the docs: https://docs.evidence.dev/core-concepts/data-sources/
The db connections are set up in the Settings page when you spin up an Evidence project, so we’ve also left a lot of the documentation in the product itself.
Airplane looks to have some great form-building and interactive app features, so I think it just depends on the problems you're trying to solve
For HN readers who are interested, we are currently building a hosting, deployment and auth service for Evidence projects - Evidence Cloud.
Evidence Cloud is currently onboarding customers in private beta - for early access, join the waitlist here: https://du3tapwtcbi.typeform.com/to/kwp7ZD3q
There are also a few other great ways to keep up to date (Slack, Twitter, and Github) - links here: https://docs.evidence.dev/community
When you try it out, please reach out - would love to hear any feedback
We've had similar experiences with BI consumers in the past. In our experience, it's really hard to make self-serve work for business users. Initially, we're starting with ways to make it easy for end users to get information out of Evidence (things like CSV download, smooth copy-paste into docs/email/PPT/etc).
Over time we'll be putting more effort into features that will let people explore data from within Evidence (which we call "best of BI" internally). We're thinking very carefully about it so we can hit a few of our key principles: maintainable/version controllable by data team, very fast - no waiting time for users, intuitive for end users - limited if any training required.