Obviously jargon is a thing, we all deal with it, but when you put something up like this to a more general audience, you’ve got to give some thought to presentation, otherwise you end up with apparent word salad.
We shouldn't have to guess.
Sometimes that data is stored in a variety of places (excel files, a smattering of disconnected databases, sometimes enriching the data with more data pulled from an API...).
Extracting that data to a common location (historically called a data warehouse) tends to be the work of a data pipeline, and the tool used to join, display, filter, dynamically aggregate, and visualize the data has been historically categorized as a "Business Intelligence" tool. Normally these BI tools provide data caching and allow temporary integration of multiple data sources.
The intent is to make it easy for business users to explore, analyze, visualize, share, and present datasets or results.
The biggest examples off the top of my head would be PowerBI, Tableau, and Apache Superset, but "data reporting tool" is a competitive market with many entrants.
If there is ever a project that needed an electron app it’s this one. I’d love to have a Perspective.app that efficiently loads local data style files.
Electron is discouraged nowadays in favor of lightweight solutions like Sciter[0], Tauri[1] or even WebView2[2].
--
[0]: https://sciter.com/
[1]: https://tauri.app/
[2]: https://learn.microsoft.com/en-us/microsoft-edge/webview2/
WebView2 has further optimizations as claimed by Microsoft in their recent blog post about Microsoft Teams[0]: "The key benefits observed from the transition from Electron to WebView2 include reduced memory usage and a lowered disk footprint as resources are shared with Edge. Additionally, we have been able to take greater advantage of the native capabilities provided by WebView2 and ensure support for more up-to-date versions of Chromium (latest performance and security updates)."
So, I'd assume WebView2 is better than Electron.
> What you'd get is significantly smaller binary size but most people don't care much about that.
In the case of Sciter (quoted in my parent comment), Sciter is a bit different: The frontend is HTML, CSS and JS, but the app's local backend is whatever you want it to be: C#, C++, Python, Assembly, etc. That's why it's popular among performance-critical software such as malware scanners, where you need native performance but as well as a you know customers that like a nice UI.
Any kind of software could benefit from Sciter's approach, if just companies liked to drop a bit more of budget at their shipped products.
--
[0]: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
The main area with the sparkgrid has good horizontal and vertical scrollbars, but they are nearly invisible, being dark grey on slightly lighter dark grey, and only visible if you hover in the area they scroll. Also the vertical scroll bar doesn't take you to the very bottom.
Then there's the top right area, which has a normal looking scrollbar (good), but once you scroll it changes the size of the entire right panel (weird), and if you drag it past the point where it has reached the bottom (really easy to do accidentally) it starts spasming uncontrollably. If you instead use the scroll wheel, you can scroll to the bottom, but if you scroll a bit further you are back on the top? None of the other scrollbars has either of those issues.
Then there's the bottom right, where the scrollbar is visible, takes you all the way to the bottom, and neither spasms nor resets, but just to be special in its own way it starts out as a big bar as if there was little content below the fold, but the further you scroll the smaller the bar gets. As you scroll up, it grows again. It's also stuttering a bit while making these size changes.
Another example besides scroll bars is the lack of tool tips on the UI (they do exist on data though!), which makes for a weird toolbar that moves its content all over the place on hover. And I guess you're supposed to guess that check boxes are delete buttons.
This doesn't take away from the app, it's still cool and useful, but little annoyances like that add up to make it feel weird and un-native (I guess foreign is the word).
I have a recent MacBook Pro and current generation iPhone and they're often indistinguishable from native apps for me - once they've loaded at least.
(my previous comment regarding this issue: https://news.ycombinator.com/item?id=35441337#35454074)
As a Firefox user I definitely want to see better FF support here!
The first step is to get a good test suite. Currently our tests only run on Chrome. So after we get tests running on Firefox, we can move to better support it.
Edit: I see the other commenter and yes, the "treemap" is broken for me as well. Not something a noticed but you are correct.
Firefox 111.0.1 on macOS 12.5.1
They look amazing but I'm a bit puzzled to why in 2023, a11y would not be a priority.
Even this landing page itself isn't keyboard friendly.
Some patterns to help you get started with ARIA: https://www.w3.org/WAI/ARIA/apg/patterns/
Designing for a11y: https://www.w3.org/WAI/tips/designing/
No doubt I have poor a11y on my own projects - but if you are going to launch into critique of the landing page, at least do it from a position of authority :)
TBH, I am not sure how a charting lib could effectively be accessible to any great extent. Its not covered in the resources you linked, and in my experience with other charting libs this seems to be commonplace. I would be interested if you have any insights or suggestions on that, as I use charts extensively on one of my projects.
I do it from a position of support, which I had the chance of developing by observing the users of the apps I created, and I made a giant software suit (more than 1000 views) pass an accessibility audit in my current company.
This is not just a charting library, see the examples down the page. Also, see: https://www.highcharts.com/blog/tutorials/best-chart-accessi...
It was in a thread specifically discussing browser support for the guys project where he stated he only has the ability to test on chrome/firefox on fedora: https://news.ycombinator.com/item?id=35448674
> a criteria that was set way later than I built that site
That criterion has been there since 1999.
> Also, see: https://www.highcharts.com/blog/tutorials/best-chart-accessi...
It is highcharts that I use extensively, and I completely disagree that a11y is a solved problem there. Ironically on the referenced page they make the same mistake as you regarding color shades.
I can do this all day. Stop being so hostile.
A specific report on the GitHub for issues you find would be much appreciated!
[1](https://www.w3.org/WAI/ARIA/apg/patterns/table/examples/tabl...)
In this example: https://perspective.finos.org/block/?example=superstore
I can't use the tree with the keyboard. From the patterns page I linked, you can see an implementation example for an accessible tree element.
I mean, I can continue. I'm not saying this to devalue your work, and I wish I had the time to go in depth and analyze all the components and give you more feedback, but I don't. So I humbly suggest you do a bit research about the topic and improve the product some.
Perhaps my original comment sounded too dismissive and therefore got many negative feedback, but I'm sincerely concerned. I wanted to hint at this as this is a tool that may be used by businesses and some people cannot do their job because of inaccessible tooling.
I do like what you are doing and the components do look cool - nothing to take away from that. Please take my comment as constructive as you can take it to be because I was trying to go for that, and perhaps my frustration in the last few years with this topic made me also whine a little bit :)
* Some of these (keyboard nav, focus) we test for and sounds like a specific issue with your browser/OS setup, which we'd very much like to fix. GitHub Issues allow us to ask these followup context questions.
* Some of these are vague, I'm not aware of any label+input in the component, e.g., nor how column selection is related to accessibility. The venue for this discovery is GitHub Issues - just because they are obvious to you does not make them obvious to us such that RTFM is a suitable correction, humbly or otherwise.
The project has relatively wide financial industry usage (and some of the code was originally developed at JPMC), and we're very interested in fixing real issues!
To the downvoters: Do you really think I should open issues for every critic I place to open source projects here and otherwise not mention anything? I also love and contribute to open-source but this feels like too demanding.
