Introduction to Data Visualization

1.1 Course Overview and Approach

1.1.1 Why This Course Exists

Is data visualization a niche specialty for a few specialists, or is it becoming something everyone is expected to do? This course opens with a clear answer: data visualization is no longer niche — it is becoming the default skill set for success in almost any role, whatever the domain or industry. Every sector, from banking to engineering to public services, is producing more data than ever and expecting people to make sense of it visually. That is why the course treats data visualization not as a single tool to master but as a skill set to build across the whole 16-week journey — a skill set that keeps paying off no matter which industry you later work in.

The first class is deliberately high level. The goal of this opening session is to understand how the course works, look at the module map, talk through the evaluation scheme, and get a shared sense of what data visualization is before the detailed topics begin. Think of this session as the orientation before the expedition: you learn the route, the kit, and the grading, and then the real climbing starts in the next classes.

One practical expectation to set early: some classmates may join after the first week, so some of this material is likely to be repeated once the full batch has enrolled. That is normal for the first session of any course — a small cost that keeps late joiners from being lost.

Where this matters in the real world: banks use dashboards to watch risk positions, engineers use trend charts to monitor equipment, and government agencies publish interactive public data. The course draws examples from all of these, because visualization is now the common language of data-driven work everywhere.

1.1.2 How We Will Work Together

The working method of this course is to learn from each other. Everyone comes in with a different technology background and a different industry, and that mix is an asset: examples from one domain often make a concept click for someone in another. So the ground rule is that there is no right or wrong answer and no judgment — students are actively encouraged to give examples from their own projects and to share experiences whenever something feels relevant. The sessions try to stay use-case driven, and a discussion forum is available for ongoing conversation outside class.

The course is taught by someone with more than 25 years of corporate IT experience, mostly in IT delivery and project and program management, with primary domain expertise in banking and finance and in oil and gas — so expect a lot of examples from those two industries. Along the way there has been extensive hands-on work with databases, SQL, data visualization, and data strategy and analysis, and data visualization is something used daily. That background is also why the teaching style leans on real stories from large programs — escalations, reviews, delivery meetings — rather than only textbook definitions. When the class hears "in my review meetings we used to…", that is a lesson from the field, not a theory.

Two more expectations are worth stating up front.

First, the first module is quite theoretical, because fundamentals and industry best practices have to come before tools. It is tempting to want to build dashboards on day one, but without the foundations — what a chart is for, what clutters a view, what an audience needs — the tools only help you make bad work faster. From module two onwards the sessions get hands-on, with live demonstrations and some Python coding.

Second, the programming language is secondary: as long as the concepts of data visualization are clear, students should not feel pressured if they are not comfortable with Python yet — everyone may relate to the material in the language they know best, even though Python is the language the course itself relies on. The concept is the examinable thing; the language is just the vehicle.

1.1.3 The Class Profile

Two quick polls painted the room. On experience level, roughly half the class placed themselves at beginner level and the other half at intermediate. Among the intermediate users, Power BI was the most common tool mentioned — one student had built dashboards with Power BI at a previous company before moving into a scrum master role, another is still at an early stage with it.

On industry background, the class is heavily IT, with some mechanical engineering and banking and financial services backgrounds as well. That mix of roles and experiences is exactly what makes the learning complete: different industries bring different data problems, and the examples land differently for each person. A beginner in IT and a veteran from banking both get value — one learns the vocabulary, the other sees familiar problems from a new angle. Polls like these also tell the instructor where the floor is, so no session assumes knowledge the room does not have.

1.1.4 Course Objectives

The high-level objectives of the course are to learn the visualization techniques, the processes, and the best practices of data visualization — what is actually happening in industry and what exists today — then to solve data visualization problems using Tableau and Python, and finally to build dashboards.

The dashboard is the end goal: a dashboard is what combines everything learned during the course, so real time will be spent on dashboard design, including the do's and don'ts. Coupled with examples drawn from everyone's industries, that is the shape of the whole course.

1.2 Course Structure: Five Modules and Tools

1.2.1 The Module Map

The course is split into five modules across the 16 weeks. The map matters because it shows you the single progression the whole course follows: concepts first, then a tool, then assembled dashboards, then code.

• Module 1 — Fundamentals (theory). This module sets the foundations of the course: what visualization is, best practices, and how to think about data and audiences. Be prepared for static content and discussions rather than building things — the ideas have to land before the tools do.
• Module 2 — Tableau. Real-time exercises where what was learned in module one is actually done hands-on in Tableau; classes six, seven, and eight are the Tableau-based ones. This is where the first practical reports get built.
• Module 3 — Dashboarding. How to make dashboards, including real-time dashboards built from multiple forms. This module combines the individual charts from module two into a single decision-making screen.
• Module 4 — matplotlib. The Python flavor arrives: matplotlib is a widely used Python plotting library that gives programmatic control over charts.
• Module 5 — seaborn and bokeh. Two more data visualization packages for Python — seaborn for statistical charts and bokeh for interactive web-style visuals.

Pictured as a roadmap, the module map is a straight line with a step shape: a flat theory stretch (module 1), a climb into Tableau practice (module 2), a plateau where charts are combined into dashboards (module 3), and then two code tracks running in parallel (modules 4 and 5). Every later module assumes the earlier one, which is why the schedule does not skip ahead.

1.2.2 Language and Tools

For this course the class relies on Python, but the language is a means, not the point. The real aim is that by the end everyone is clear on what data visualization actually is. So students working in other tools should not feel pressurized; they can relate the concepts to whatever language they are most comfortable with.

A practical consequence: when a demo shows Python code, the goal is to see what the chart does, not to memorize the function call. Write the code in your head in your own tool if that helps — the insight is the same.

1.2.3 Textbooks and Resources

The course handout lists several books. There is no personal recommendation among them and no strong preference for a main book versus a reference book — the topic is so common these days that it is not bounded by one or two books. One of the textbooks in the list has been personally seen and used, but the industry is evolving fast, and content is not in short supply these days: much of it is freely available online, so students are free to use these books or any other books they have already accessed.

The practical reading advice that follows from this: pick one solid source and follow it through, rather than trying to read everything. Because the field moves fast, current online material is often more up to date than a printed chapter — so combine one structured book (for principles that do not change, like how people perceive charts) with current examples (for tools and trends, which change every year).

1.3 Course Evaluation and Exams

1.3.1 The Evaluation Scheme

The evaluation scheme has four components: a quiz, an assignment, a mid-semester test, and a comprehensive exam. These four pieces together decide your grade, so it pays to know exactly what each one covers as the semester moves.

One change is under consideration: instead of one assignment of 25 marks, it may be split into two sub-categories — one more quiz and one smaller mini assignment, possibly worth 15 marks. Nothing is finalized; all options are open, and the class will be consulted before a decision.

1.3.2 Exams

The exam dates are published by the examination cell, and the word so far is that the exams will be on-site this time — students who had heard anything confirmed that this is the plan. The mid-semester test falls somewhere around mid-March, and its syllabus is the sessions from one through eight. The comprehensive exam is in May, it is an open-book exam, and it covers the complete concept — everything learned in the course. The course concludes around mid-May or end of May.

Because the mid-semester test covers the first eight sessions, the theory-heavy early classes are not "wasted time before the tools" — they are a direct part of the exam syllabus.

1.3.3 Experiential Learning and Study Advice

A possible assignment is being planned as experiential learning: students may be given a data set and asked to prepare their own Tableau forms and dashboards from it. This is deliberate: the best way to learn dashboard design is to design one, from raw data to finished interactive report.

The course is different from a typical engineering or science course in that there are no fixed formulas to resolve; the focus is more on concepts. Where a physics problem has one right numeric answer, a visualization question is judged on judgment — is the chart right for the message, is the audience served, is the view uncluttered.

1.4 What Is Data Visualization?

1.4.1 The Opening Question

Before any definition, it is worth saying that data visualization is not something that can be bounded by one or two definitions — it is a vast and open-ended topic. The class was asked, quite deliberately, for its own understanding: what does data visualization mean, and is it just about showing some picture?

1.4.2 Student Answers

The historical note is worth slowing down on: for years, "report" meant thousands of printed pages nobody could read. Dot matrix printers hammered out payroll runs, and client-server systems replaced them with on-screen reports — but both were still static pages. Each generation made data easier to see, and interactive visualization is the current step of that same evolution.

1.4.3 What a Good Visualization Does

A good visualization is a visual representation that gives us insights and trends we cannot see with our own eyes by looking at tables of data. Beyond that, it should be interactive: most data visualization tools today are very interactive — they give filters, they give conditions, and they let the user zoom into the values.

That interactive part is what makes visualization so useful; static reports and static images are still used, but interactive components make data visualization a superior feature. Interactivity enables the user to be curious and to explore the data for themselves, which is exactly what visualization is supposed to enable.

1.4.4 Why It Matters

There are many advantages to visualization, and several matter in every work context. The information should be easily absorbable — the user should not struggle to link what one graph says to another. It should support faster decision making, as one student noted in chat. It should convey the right message: it should show what cannot be seen with the naked eye, and it must not distract from the information. When an end user can understand the visual quickly, they can take faster decisions. These are the core reasons the field keeps growing.

• Easily absorbable — the viewer takes in the message without puzzling over what each graph means or how graphs connect.
• Faster decisions — when the picture is clear, the decision comes quickly; a muddy picture delays every meeting it enters.
• The right message — the chart shows what the naked eye cannot see (a trend, a correlation, an outlier) and adds nothing that distracts from it.

The field keeps growing because these three payoffs are wanted in every industry, from banking risk reviews to hospital dashboards to public-sector reporting.

1.4.5 The Clutter Myth

One belief needs to be broken early: the idea that the more information we put on a slide, the happier the end user will be. That is a myth — the person who used to believe it admits it. Filling every slide with information does not impress stakeholders; it overwhelms them.

1.5 Types of Data Visualizations

1.5.1 Charts, Maps, Infographics, and Dashboards

Data visualizations come in several families. There are charts of many kinds; there are maps; there are infographics, which combine text and visuals to give a narrative — think of timelines, or the "plan on a page" used in IT to show how timelines are moving within months or quarters; and there is the dashboard, which is the ultimate thing: instead of building individual forms, we combine all of these into meaningful dashboards that help us take decisions. The class was also invited to suggest other types of visualization, since the list is open.

Two families deserve extra attention because they are often misunderstood. An infographic is a story told in one composed page — its job is narrative, so it is read top to bottom like an article. A dashboard, by contrast, is a working instrument — its job is monitoring and decision, so it is scanned and re-scanned, not read. Knowing which one you are building changes what you put on the page.

1.5.2 Interactive Visualization

Interactive visualization deserves its own family. These come with filters, dropdowns, and values, so the user themselves decides what they want to see. The user is not a passive reader of a finished picture; they choose the slice of data, zoom in where they like, and drive the exploration. This is the property that turns a report into a tool.

The shift is subtle but important: a static report asks "here is what I decided to show you", while an interactive view asks "what do you want to look at?" Both are legitimate — but they serve different jobs, and the interactive family is where most modern tools spend their effort, because it hands control to the person who actually knows the questions.

1.5.3 Choosing the Right Chart

Not every chart suits every message. Later classes will spend time on which chart to use for which type of information, because people sometimes pick a graph at random without realizing that some charts represent certain kinds of data far better than others. Charts can be interchangeably used in a pinch — there is no hard-and-fast rule that forbids it — but there are clear best practices and preferences.

A scatter plot, for example, has its natural territory: showing how two numeric variables relate to each other, point by point — correlation, clustering, outliers. A line graph is the natural home for change over time. A bar chart compares sizes across categories. The point is not that other charts are forbidden — it is that each has a home field where it communicates best.

The question of the pie chart will be revisited: should we really be using a pie chart, and if yes, when? The preview answer: a pie chart works only when you have a few slices of a whole and the parts really matter relative to each other — and even then, a bar chart usually communicates the sizes more accurately, because people compare lengths far more reliably than angles. This is the first taste of the "which chart for which job" theme. There are cheat sheets and guidelines of this kind that will be shared in subsequent classes.

1.6 Data Visualization Best Practices

1.6.1 Choose the Chart Deliberately

The first best practice is to be very careful with chart choice, because charts are not freely interchangeable. A line graph comes with a purpose, a bar graph has its own advantage, and a pie chart probably has its own usage.

1.6.2 Keep It Simple

From direct experience: filling a dashboard with many controls and many widgets makes it very difficult for the user — they get confused about whether to look left, right, or at the top of the form. Keep it simple. Less information is usually better, because it gives the user room to process the data instead of facing a sea of multi-color graphs.

A useful self-check before placing anything on a form: is this really adding value, or is it making the decision harder for the user? If it is the latter, it should not be there. This is the first class's clutter lesson applied to controls: a filter no one uses, a widget that duplicates another chart, a decorative panel with no job — all of these are decision noise, not content.

1.6.3 Highlight What Matters

Wherever possible, highlight what we want the users to focus on. In IT delivery, delivery heads used to review financials every month, and there was always a variance figure: every project or program was supposed to stay within a tolerance of, say, plus or minus 2.5 percent. Any program beyond that tolerance was immediately flagged by color — the scale of the color instantly showed that a project had gone out of variance.

Because no one can review 50 or 60 programs every month, the review always went by the color-coded highlight first, and the flagged programs — those under-running or over-running the variance — were exactly the ones discussed. That is the power of deliberate highlighting: the viewer's eye lands where the decision is. The color did not add data; it routed attention to the data that needed a decision.

1.6.4 Tell a Story

Storytelling is an over-used term, and still it is so useful that it is close to a must-have for any role: we should be able to say what we are doing and what our data is telling. Storytelling is an art — it cannot be taught in eight slides — but it can be practiced. Think about what data to start with.

Notice what makes the sequence a story rather than a dump: it has a present state ("where we are"), a tension ("our challenges"), a resolution effort ("what we have done"), and an ask ("where we need help"). The data is organized so the listener is carried from problem to next step, instead of being dropped into a pile of charts.

1.6.5 Label Clearly and Choose Colors Deliberately

Labels must be clear: anyone with reporting experience knows that labels should tell, without ambiguity, what exactly is being represented and what others are looking at. Color selection deserves the same care. Many people ignore it and accept whatever default color palette the tool offers.

Instead, think about who the audience is and select colors accordingly — a palette that works for one audience can mislead another. The classic case: red and green carry meaning in finance (red = loss, green = gain in many Western conventions), but the same pair is a classic colorblind trap, and in some cultures the meaning is reversed entirely. A default palette does not know your audience; you do. These small choices are what separate a report people trust from one people struggle to read.

1.6.6 Use Relevant Tools and Keep Growing

Use tools that are relevant to the problem; it is not possible to just take any tool and build well with it. This list of best practices is not exhaustive — it is only the most commonly used six or seven, and the course will keep adding to it gradually as the journey progresses.

1.7 Real-World Use Cases

1.7.1 Finance and Markets

Real-world: real-time heat maps now appear on almost every TV channel, showing which stock is gaining and which is losing, refreshed continuously. A heat map encodes a value (here, the day's gain or loss) as a color on a grid of stocks — one glance tells you the market's shape without reading a single number.

Candlestick charts and moving averages — once a rarity used only by fund managers — are now given freely by every application and every trading site. A candlestick chart packs four numbers per period (open, high, low, close) into one visual mark: a thin line shows the period's high and low, and a filled body shows the open-to-close move, with color saying "up" or "down". A moving average is a line that smooths the day-to-day noise by averaging recent prices, so the underlying trend becomes visible. What used to be a niche tool set is now the default presentation of market data — the specialized vocabulary of fund managers became the everyday screen of millions of investors.

1.7.2 Portfolio Management

Real-world: portfolio management is a common area where visualization does heavy lifting. Users can see how each stock is moving, and increasingly can see correlations — if one stock in a portfolio is correlated with another, how will the pair behave together? All of these portfolio drill-downs and analyses happen through data visualization these days.

The correlation idea is the deeper point: two stocks may each look fine alone, yet move together — when one falls, the other tends to fall too, so the pair does not diversify the portfolio the way a glance at either chart suggests. Visualization makes that joint behavior visible (for example, two time series overlaid, or a scatter of one stock's returns against the other's), which is exactly the kind of insight a table of numbers hides. Modern portfolio tools let the user click from portfolio overview down to a single instrument's history — a drill-down chain that is now expected, not exceptional.

1.7.3 Supply Chains and Exit Polls

Real-world: supply chain is one more domain saturated with visualization — shipment tracking, inventory levels, and logistics performance are all monitored through dashboards because the volume of moving data is far too large for anyone to read row by row.

And in public life, exit polls are the standout example: earlier there used to be paper counting that took days before results came out, and today exit polls are drilled down in real time to the district level and even to the gender level. That depth of live drill-down would be impossible without interactive visualization — the underlying dataset is the same, but the interactivity is what lets millions of viewers each choose their own slice (a state, a district, a demographic) the moment the data arrives.

1.7.4 Research and the Road Ahead

Real-world: researchers use visualization for their own work — it helps them identify patterns and then come up with hypotheses. Notice the sequence: visualization does not only confirm what is already known; it suggests what might be worth testing. A pattern seen in a scatter plot becomes a hypothesis the researcher can then test with statistics — visualization at the front of the scientific workflow, not just the end.

The use cases are endless and only growing; there is no looking back. Visualization is becoming so fundamental that primary-school students will learn and talk about it in the future.

1.8 Interactive Visualization in Action: A Tableau Demonstration

1.8.1 A Live Tableau Report

A real-time Tableau report (a stock, out-of-the-box sample, not something built for the class) showed exactly what interactivity means in practice. The report has tooltips; regions can be selected; the view can be drilled down; there is a scale; and clicking on the top of the report updates the bottom of the report — the sub-reports are linked to each other.

This is what makes the user curious: the data can be picked, filtered, and explored live. The tool presents the fields and folders of the data, and fields are dragged around to build views — for example, "show me only 2013 data", "show me only arts and science data", "only show me for a specific gender". What to explore is entirely up to the user's domain knowledge, and that freedom is the power of data visualization.

1.8.2 Dashboards Are Collections of Sheets

The sample was in fact a dashboard, and a dashboard is a collection of individual forms: sheets are prepared individually, then brought into the dashboard and connected. Filters on top can link two forms — or sheets — together, so interacting with one updates the other.

1.8.3 Building a Heat Map on the Fly

A heat map was then built from scratch in front of the class. The starting screen of Tableau offers a choice of data source — a text file, for instance, or an Excel file — and the moment the data is selected, the tool shows what fields it contains.

On the sheet, dragging a field immediately renders a chart: for example, pick a symbol and a gain/loss field and a graph appears at once. It can be sorted with a click, and coloring can be based on a field by dragging it into place, and the map updates automatically. There are six or seven default chart graph types that appear the moment a chart type like "heat map" is requested — Tableau builds the default automatically from simple Excel data.

Students were told not to be scared by fonts and screen resolution issues in the demo; the point is how simple drag-and-drop report building is. The demo's imperfections were the projector's, not the method's.

1.8.4 Desktop vs Cloud

The version showed was the local desktop copy, which must be downloaded; the cloud version may not give all these features — it comes with limitations and does not offer everything the desktop screens can do.

Until then the excitement has to be held, because fundamentals come first. And there is no pressure: the tools are not rocket science. As long as one has a fundamental understanding of the data — what the common keys are, what data makes sense at the row level — drag and drop is enough to build reports that serve most stakeholders. Complex reports full of formulas need a different approach, but straightforward reports are not difficult to make.

1.8.5 Student Questions and Answers

The answer draws a small map of the workflow that is worth keeping: upload data → fix what needs fixing (number formats, dropped columns) → visualize. Cleaning exists in Tableau, but it is a between-step, not a full data-preparation suite — so the realistic expectation is to do the heavy preparation elsewhere and use Tableau's options for light fixes. This preparation step matters for later modules, where every report starts from raw files.

1.9 Visualization in the Digital Age

1.9.1 A Discovery Tool

With so much data around us and so many data sources, visualization is becoming more important and easier to use every day. One way to think about it is as a discovery tool: in the live Tableau sample, end users themselves decided what to filter, what to look at, and what to zoom into. That self-driven exploration is why visualization keeps getting called a discovery tool — the features that enable it are what the next classes cover.

1.9.2 Free and Accessible Tools

Different organizations are making visualization more accessible. Tableau now offers a free cloud version; Google Data Studio, as far as is known, also allows free use. There is a competition among these data companies — each wants its tool to be more successful and more used — and the user benefits: free tiers, better features, and constant improvements are how that competition shows up.

On the tool rankings, Gartner consistently places Tableau and Power BI as the top two tools in use. Power BI comes from the Microsoft framework and is generally considered easier to integrate; Google Data Studio is picking up as well. There is no winner and no right or wrong: both tools have their pluses and both have their own user bases, and the class's own poll showed Power BI as the most-used tool in the room.

1.9.3 Rising Data Literacy and Communication Skills

Two trends are converging. First, data literacy is increasing — more tools are available, more people can use them, and visualization is becoming so obvious that it will become a by-default thing going forward. It is already visible at school level, in healthcare systems where everybody tracks trends, in how businesses make decisions, and in government digitization with medical cards and similar initiatives.

Second, communication skills — storytelling and the design of overviews — are gaining more popularity, which is exactly why the storytelling topic matters. Data visualization skill is spreading to the masses; the expectations on anyone entering the workforce will keep rising with it. The two trends feed each other: more people able to read charts raises the bar for how well charts must be made, and better-made charts raise expectations of everyone else.

1.9.4 The Identical Statistics Example

A single example captures why visualization matters for interpretation. Consider a table of numbers with pairs of x and y values — there is x1, y1; x2, y2; and so on up to x4, y4 — a set of x and y values. Looked at the table level, the mean is the same, the variance is the same, and the correlation is there: statistically, in any test, these numbers look as if they are identical. But the moment the numbers are plotted, the true nature and behavior of each data set is visible. Raw numbers are good, but they are very difficult to interpret; the plots reveal what the statistics hide.

The moment the numbers are plotted, the true nature and behavior of each data set is visible. When the numbers look identical in every statistical test but the pictures tell different stories, interpretation requires the picture. That is exactly how visualization helps us take these decisions and understand data better.

1.10 Visualization Methodology and Common Pitfalls

1.10.1 Where We Usually Go Wrong

Visualization methodology is the steps and process of producing a data visualization, and it is worth seeing where people typically go wrong before learning the right sequence. Learning the failure modes first is deliberate: a pitfall you can name is a pitfall you can check for.

The usual failures:

1. Unclear audience. We are not clear who we are building for, which makes everything downstream difficult — chart choice, level of detail, and even the data shown all depend on who reads the view.
2. Unclear goal. We are not clear what exactly we want to achieve from the visualization. A view without a job cannot be judged, and it cannot be improved.
3. Wrong chart. We end up taking a wrong chart — we wanted to show a trend analysis and took a bar graph (the same failure the best-practices section flagged).
4. No thought to color. Most people never think about coloring, which makes it harder to understand and convey the message.
5. Design inconsistency. There can be design inconsistency across views — different scales, styles, and layouts from one screen to the next, so the reader must re-learn the visual language on every screen.
6. Skipping iteration. One more process failure is common: data visualization is an iteration process — we build something, we go to the user, we get feedback, and we incorporate it — and that loop is not given enough importance.

1.10.2 What to Consider Instead

The fixes follow from the failures. Be very clear about the audience: you cannot carry a detailed week-wise project status report into a review with an executive or a delivery head. A weekly status report tracks very different things — what task was given to whom, whether the task is finished, the burn on a DevOps board, as a scrum master in the class would see it — while an executive review wants the data that matters at that level. The same data cannot serve both meetings.

The data itself should be clean. Choose the right chart for the message. Take time to design the visualization: do not sit straight away in front of the laptop and start designing — it is always good to sketch on paper first, deciding what tools or controls the view should have. Finally, test and refine the visualization with users. These habits help far more than any single tool feature.

1.10.3 No One-Size-Fits-All

There is never a fixed formula where doing A, B, and C produces a foolproof visualization — that will never happen. There are so many permutations and combinations of the data, the audience, and the maturity level of the stakeholders that a one-size-fits-all approach does not exist. It comes with experience, and experience is exactly what the career journey builds.

1.11 Exploratory vs Explanatory Analysis

1.11.1 The Two Stages

Exploratory and explanatory analysis are two distinct stages of the data analysis process, and they are seen more in scientific or research projects.

1.11.2 The Hiking Analogy

Where the analogy breaks, it breaks usefully: a real forest map is neutral about why you chose the route. A good explanatory visualization carries the reasoning too — not just the path, but the finding at the end of it ("this is what we found, this is why it matters"). The map shows the way; the explanation says what the way revealed.

1.11.3 The Oyster and Pearl Story

Here is another way to see the same split. Suppose you are walking on a beach and opening oysters. Not every oyster has a pearl. You may open hundreds of oysters and get a pearl out of one or two.

Then you move to the explanatory phase: what actually was the difference between the oysters that had pearls and the ones that did not? The exploration is the search itself, and the explanation is the account of what differed. The two support each other — and in fact explanatory analysis becomes much easier once the exploratory work has been done.

1.11.4 How They Compare

The goals are different: one is to explore, the other is to confirm the initial hypothesis. The visualizations are different. In exploratory analysis the visualization is mostly interactive, because you are exploring: "show me this filter with that, exclude this data, show me that." Exploratory charts, then, are interactive and flexible — scatter plots, histograms, box plots are the natural instruments. In explanatory analysis you come up with a clear and crisp outcome — "this is how we achieved it, and this is the final outcome" — so you may use more of a bar or a line or a heat map, because the exploration is already done.

The audiences are different too: for exploratory analysis the audience is the analyst themselves — a niche audience still exploring whether things are concluded — while for explanatory analysis the audience is broader; you are now explaining to a wider audience what has been achieved and what the outcome is. Audience, visualization, and goal all differ between the two stages. When to pick which: explore in private, explain in public — the moment the audience changes from "me" to "them", the visualization style changes with it.

1.11.5 Why Both Matter

Neither phase is more useful than the other; both are very useful, and they really help each other. It is not possible to do explanatory analysis without having done exploratory analysis first. The approach, the audience, and the purpose are simply different, and recognizing which phase you are in tells you which kind of chart to build and who you are building it for.

Exam Guidance Summary

The evaluation scheme for this course is a quiz, an assignment, a mid-semester test, and a comprehensive exam. A possible change: the 25-mark assignment may be split into a second quiz and a smaller mini assignment, possibly 15 marks — the class will be consulted before anything is decided.

• Mid-semester test: around mid-March, covering the sessions from one through eight.
• Comprehensive exam: in May, open book, covering the complete concept of the course; the course wraps up around mid-May or end of May.
• Exams will be on-site this time, per the examination cell.
• Possible experiential assignment: take a given data set and prepare your own Tableau forms and dashboards.

Study advice for the weeks ahead:

• Expect repetition of this first class in the next session, since more students may join; the plan was to revisit concepts of this class while still covering some next-class topics.
• The next topics on the schedule are clutter and the pre-attentive attributes, plus the topic of context — how understanding our audience and purpose helps users understand context in data visualization.
• The first five or six classes are theory-heavy; hands-on work comes gradually, so do not expect to build much before the Tableau module.
• Participate in the discussion forum and ask questions freely — there is no right or wrong answer in this class.
• On tool skills: fundamentals matter more than any single tool; straightforward reports that serve most stakeholders are not difficult to build once the data fundamentals are clear.

Key Industry Applications

Real-world connections from across the session, collected in one place:

• Finance — live market dashboards: real-time stock heat maps on TV channels — which stocks are gaining and losing, refreshed live.
• Markets — retail investing tools: candlestick charts and moving averages — once used only by fund managers, now given freely by every trading app and site.
• Finance — portfolio management: seeing how each stock moves, and the correlation between stocks in the same portfolio, with drill-downs and impact analysis.
• Operations — supply chains: supply chain monitoring and analysis.
• Public life and politics — elections: real-time exit polls drilled down to district level and gender level, replacing days of paper counting.
• Science and research: identifying patterns and forming hypotheses.
• Public sector and healthcare: healthcare trend tracking, business decision making, and government digitization such as medical cards — visualization spreading to the masses.
• Tool landscape: Tableau and Power BI consistently top the Gartner rankings, with Google Data Studio picking up; the Python ecosystem (matplotlib, seaborn, bokeh) covers the programmatic side.