Design Datascience’s Post

#1 𝗔𝗡𝗦𝗪𝗘𝗥 𝗢𝗡 𝗧𝗛𝗘 𝗕𝗢𝗔𝗥𝗗 😉 𝘉𝘛𝘞 𝘪𝘵'𝘴 𝘯𝘰𝘵 𝘫𝘶𝘴𝘵 𝘗𝘰𝘸𝘦𝘳𝘉𝘐, 𝘪𝘵'𝘴 𝘢𝘭𝘭 𝘧𝘰𝘳𝘮𝘴 𝘰𝘧 𝘉𝘐. Seriously though, this is the most often expressed symptom that we hear from our customers. And we've heard it - consistently - 𝘧𝘰𝘳 𝘺𝘦𝘢𝘳𝘴. It's not that they don't like their BI tooling -> They do. They use it for a great many different things. {That's why #PowerBI Tableau #Looker #Grafana Retool Sigma Computing etc have such large user bases.} It's just that BI tooling can't do everything they want it to do, and so they investigate #python Plotly #Dash (and Dash Enterprise) when they want more #interactivity #flexibility #customizability #scaleability #integratability for 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻-𝗴𝗿𝗮𝗱𝗲 𝗱𝗮𝘁𝗮 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀 such as those profiled per: plotly.com/user-stories BUT what then? BUT ... 'We need more than a "dashboard" 𝘧𝘰𝘳 𝘵𝘩𝘪𝘴 𝘱𝘢𝘳𝘵𝘪𝘤𝘶𝘭𝘢𝘳 𝘶𝘴𝘦 𝘤𝘢𝘴𝘦' BUT ... 'We need more than a simple "data app"' Here they're needing a sophisticated analytics & viz focused application/tool/UI with capabilities (𝘸𝘩𝘪𝘤𝘩 𝘵𝘩𝘦𝘺'𝘳𝘦 𝘖𝘒 𝘵𝘰 𝘥𝘦𝘷𝘦𝘭𝘰𝘱 𝘪𝘯 𝘱𝘺𝘵𝘩𝘰𝘯) including some/all of: • editing/annotating/writeback • N-dimensional and/or dynamic cascading cross-filtering • customized branding (for externally facing discerning audiences) • integration with multiple data sources (in the same app) • interactive/scheduled/event-driven pixel-perfect reporting • RBAC, differential data access security controls, etc • working w un-structured data (e.g. imaging, scientific visualizations) • highly customized charts/maps This further extends to enabling dynamic calculations driven by the user of the application where they iteratively parameterize and run - from the UI (vs in a notebook / at code level) - multiple simulations or (ML) models on some backend compute (e.g. Databricks Snowflake #BigQuery Amazon Web Services (AWS) #Azure Google Cloud Platform etc) i.e. These are interactive, actionable, user interfaces Oh ... one more thing. They don't want to go hire a full stack dev team to do it. They want to do it themselves, and relatively quickly. So who are "they"? "They" are analytics types who know python (e.g. quants, computational biologists, data scientists, mechanical engineers, etc.) and are doing advanced analytics. ∴ Plotly COMPLEMENTS BI ... we don't replace BI.

Sometimes it's the simple things that bug me. Like default color legends. Out with the defaults and in with the customization! Check out my latest blog post on how to create custom dynamic legends in #Tableau. #dataviz #learntoviz #vizzendata https://lnkd.in/eSU2CykC

I wrote a tutorial on how to create a [good] pie chart in #Tableau. https://lnkd.in/dPrYJYqn

Tableau can revolutionize data science by transforming raw data into actionable insights with intuitive and interactive dashboards, uncovering patterns, trends and correlations effortlessly. For data scientists, Tableau goes beyond basic charting by integrating with R and Python, enabling advanced analytics within the platform. Its real-time data connectivity ensures you have the latest information for quick, informed decisions, whether you're working with big data, streaming data, or static reports. Collaboration is seamless with Tableau. Share your findings securely with team members and stakeholders through Tableau Server and Tableau Online, ensuring everyone can access the insights they need anytime, anywhere. This article will delve into how Tableau can empower data professionals and how freelancers can thrive by offering services in data visualization, advanced analytics, and data storytelling. #Tableau #DataScience #DataVisualization #AdvancedAnalytics

In #datastorytelling, color is a powerful communication tool. Sadly, it is misunderstood and abused. I know, harsh words. Let’s look at how even Tableau gets it wrong 👇 Tableau Software includes several pre-built dashboards called Accelerators. Simply connect your data and customize the framework to your business. They are great for learning how features work. Accelerators also have the responsibility to reinforce best practices so story authors increase their data literacy, and in turn, lift the data literacy of their organization. Authors will follow Tableau’s lead. However, while reviewing the Budget Controlling Accelerator, I discovered a common mistake. I cover this problem in my Design To Act ® workshops and never expected Tableau would stumble in this area. 😯 I am curious about their design decisions and hope they will weigh in on this post. For now, let’s examine each issue and how you can avoid them. 1️⃣ The color legends were not displayed on the dashboard. Place each legend where it will be most useful to the reader. Don’t leave them in the default position on the right. 2️⃣ Coloring the text is useful at times to emphasize your message; here it’s overwhelming and seems more like “eye candy.” Stick with black or gray text. 3️⃣ Here’s the BIG mistake. 🔥 The same gradient is used for multiple measures. The two “Actuals vs Budget” represent the difference between Actual and Budget, but the ranges are inconsistent. 4️⃣ The color is the same as the chart values. This confuses the reader because they think there is a relationship, as there is on the bar graphs. It's redundant and slows down analysis. I encourage you to review your dashboards and update them as needed. This is a common problem that you can fix easily and dramatically improve the data literacy of your work. TL;DR * Use different colors for each measure or dimension. Follow the same rule for size, shape, etc.   * Place legends where they are most helpful to understand the visual. * Use color sparingly. Especially avoid using color as “window dressing.” Have you seen these problems or maybe done your work this way? ⤵️ Leave a comment; I’ll share my thoughts. If you’d like to talk about storytelling or data products, drop time on my calendar » decisionviz.pro/lee30 #tableau #powerbi #dataculture #dataliteracy #datastorytelling #datavisualization #analytics #storytellingwithdata #analyticstory #businessintelligence #dataproduct 

🤔 Tableau's "Multi-fact Relationship Data Models" - More Hype Than Help? Tableau recently launched "Multi-fact Relationship Data Models" with the promise of seamlessly blending data from multiple sources. The idea? Effortlessly combine metrics from different fact tables in a single visualization using common dimensions. Sounds amazing, right? 🤯 Well, in theory, yes! But our initial experiences have been a bit bumpy. 🚧 We're encountering some unexpected errors and roadblocks, especially when working with more than two fact tables. Has anyone else had a chance to experiment with this new feature? We're curious to hear your thoughts and experiences. Let's compare notes! 👇 #Tableau #DataVisualization #DataModeling #DataAnalysis #MultiFactRelationships

My initial impressions of Tableau's new 'Multi-fact Relationship Data Models' feature As a long-time Tableau user, I've always been eager to explore new features that promise to enhance the platform's functionality. So, when Tableau announced the "Multi-fact Relationship Data Models" feature last June, I was thrilled. This feature was supposed to revolutionize how we work with complex datasets, allowing for more nuanced relationships between multiple fact tables. However, after spending hours trying to make this feature work, I find myself deeply disappointed. Lack of Retro Compatibility: A Major Setback One of the most frustrating aspects of the new Multi-fact Relationship Data Models is its lack of retro compatibility. If you've already created dashboards using Tableau's older data modeling capabilities, don't expect a seamless transition. The new feature simply doesn't integrate well with existing dashboards, forcing you to start from scratch if you want to take advantage of its promised benefits. This is a significant oversight, as it essentially means that any work done previously is rendered obsolete unless you're willing to rebuild it all over again. Creating a New Data Source and Dashboard: More Frustration Despite the retro compatibility issues, I decided to give the new feature a fair chance by creating a new data source and dashboard from scratch. Unfortunately, the experience was far from seamless. Although the feature is designed to manage complex data relationships with ease, I ran into problems almost immediately when working with more than two measure values. Tableau appeared to have difficulty processing the relationships, leading to errors, such as filters not loading correctly unless the ‘Only relevant values’ option was used. While I managed to get it to work with two fact tables, I was not able to get it working with 3 or 4. A Promising Feature, But Not Ready Yet Tableau's Multi-fact Relationship Data Models feature has the potential to be a game-changer, but in its current state, it's not living up to expectations. The lack of retro compatibility, combined with the practical challenges of creating new data models, makes it more of a headache than a help. As much as I wanted to embrace this feature, I'll be shelving it for now and waiting for future updates to stabilize the functionality. In the meantime, I'll stick with no more than 2 fact models. Here's hoping that Tableau addresses these issues soon so that the feature can finally deliver on its promise. For now, though, it remains a disappointing letdown. #Tableau #DataVisualization #DataModeling #DataAnalysis

Another great session yesterday by Siavash Kanani on #LookerStudio - introducing us to the basics of data transformations using Looker Studio. Looker Studio is a lightweight data visualization tool, does not require a lot of “infrastructure”, and because of this, it can often be a good choice for marketing use cases or as an “entry point to BI”. One interesting feature is the concept of “data source”, which is essentially a metadata object on top of the actual data source (which can be a platform like #GoogleAnalytics or #GoogleAds through an API connection, or a data store like #BigQuery, another cloud or on-prem database, or a spreadsheet like #GoogleSheets). The “data source” object describes what columns the actual data source contains, and this is where we can create transformations and derived fields. A data source can be embedded into the report, or can be reusable across reports - i.e. the same data source object (pointing to one particular source file, database or platform) can serve multiple dashboards. This is all good and well, but what happens when you need to create another very similar report, and you don’t want to start from scratch? Looker Studio offers a way to duplicate the report and then you just have to modify the bits you want in the new dashboard. When you copy the report, it asks you to specify the new data sources instead of the old ones. It is easy to overlook or skip over, so if you’re using reusable data sources, the new report will show data from the original data source. Then when you repoint the new dashboard to a new data source (e.g. new client), suddenly the old dashboard also starts showing the new data. This can get awkward when one client starts seeing the other one’s data, but it looks like it’s a frequent novice mistake (has happened to me too). The solution is to create the new data source first and specify the new one there and then when the report is being copied (or to only use "embedded" data sources). Looker Studio is a great prototyping tool, and it can also serve proper BI purposes for a company, with no direct cost or infrastructure investment, but not everything about it is obvious. This is why it’s great to have learning material such as the Looker Studio Masterclass! – Follow me for updates on #digitalmarketing #data #analytics, #BigQuery and #eprivacy, and hit the bell on my profile to receive updates. For more information on Looker Studio though, it is best to follow Siavash instead!

🚀 Day 21 of diving deeper into Data Analytics and learning Concept of tableau! 🚀 Certainly, here’s a concise LinkedIn post about converting strings to numbers in Tableau without losing data ("Nulls"): --- Converting Strings to Numbers in Tableau Without Losing Data "Nulls📊 Today, I tackled a common challenge in data preparation: converting strings to numbers in Tableau without losing data to "Nulls." The Challenge: When working with datasets, numerical data is sometimes stored as strings. Converting these strings to numbers is essential for accurate calculations and visualizations. However, this process can lead to "Null" values if not handled carefully. Solution Steps: 1. Use the `INT()` or `FLOAT()` Functions🔄   - These functions convert string fields to integers or floats. For example, `INT([String Field])` converts a string to an integer. 2. Handle Non-Numeric Values 🛠️   - Ensure that non-numeric values are handled to avoid "Nulls." Use `IF` or `IIF` statements to manage these cases:    ```     IIF(ISNULL(INT([String Field])), 0, INT([String Field]))     ```    This converts valid numbers and replaces non-numeric values with a default (e.g., 0). 3. Check for Nulls 🔍   - Use the `ISNULL()` function to identify and address null values. Combine it with `ZN()` to replace nulls with zeros:    ```    ZN(INT([String Field]))    ``` Practical Tip: Always inspect your data after conversion to ensure accuracy and completeness. Proper handling of nulls maintains data integrity and prevents errors in your analysis. Mastering this conversion process enhances data reliability and analysis accuracy in Tableau. #DataAnalytics #Tableau #DataPreparation #LearningJourney --- #DataAnalytics #Tableau #Metadata #LearningJourney #Tableau #DataAnalytics #DataVisualization #Joins #Relationships #Unions #DataBlending #DataScienc #DataAnalytics #Tableau #LearningJourney #DataVisualization #BusinessIntelligence #DataAnalytics #Tableau #DataVisualization #ContinuousLearning #DataVisualization #Tableau #BusinessIntelligence #DataAnalytics #Tableau #LearningJourney 💻💡 Baraa Khatib Salkini,KultureHire,Codebasics,Dhaval Patel,Aditi Gupta ,Hemanand Vadivel,Munna Das,Swapnjeet S, #learnwidgigs#dataanalytics

To create a chart from JSON data in Node.js, you can use libraries like Chart.js (for charting) in combination with Canvas or QuickChart (for rendering). I'll show you a basic example using QuickChart, which is simple and lets you generate chart images directly from JSON without needing to manually set up a canvas in Node. Here’s how you can do it: 1. Install Dependencies In your Node.js project directory, install quickchart-js: npm install quickchart-js 2. Generate a Chart from JSON Data Here’s an example code snippet to create a chart image based on JSON data using quickchart-js: // Import the QuickChart library const QuickChart = require('quickchart-js'); // Your JSON data const jsonData = { labels: ['January', 'February', 'March', 'April', 'May'], datasets: [ { label: 'Sales', data: [10, 20, 30, 40, 50], backgroundColor: 'rgba(75, 192, 192, 0.2)', borderColor: 'rgba(75, 192, 192, 1)', borderWidth: 1, }, ], }; // Create a new QuickChart instance const chart = new QuickChart(); // Set the chart configuration based on your JSON data chart.setConfig({ type: 'bar', // Chart type (e.g., 'bar', 'line', 'pie') data: jsonData, options: { responsive: true, scales: { y: { beginAtZero: true, }, }, }, }); // Generate the chart as an image URL const chartUrl = chart.getUrl(); console.log('Chart URL:', chartUrl); Explanation QuickChart: It lets you generate chart URLs by providing a configuration similar to Chart.js. jsonData: This contains the data in JSON format, defining labels and datasets (you can modify this JSON for different data or chart types). getUrl(): This generates a URL you can open in a browser or embed in HTML, which renders the chart as an image. Optional: Save the Image to a File To save the chart image locally, you can use axios to download the image from the URL generated: npm install axios const axios = require('axios'); const fs = require('fs'); async function saveChartImage() { const response = await axios.get(chartUrl, { responseType: 'arraybuffer' }); fs.writeFileSync('chart.png', response.data); console.log('Chart saved as chart.png'); } saveChartImage(); This approach generates the chart as a