The everyday computer, internet, safety and AI skills every tech and STEM job assumes you already have.

Digital Literacy for Tech & STEM Work

## Why it matters

Cloud dashboards, lab instruments that upload results, online code editors, a smart meter on a building: almost every tool you will use at work talks over the internet. When something "won't load", knowing the steps a request goes through lets you narrow the problem down instead of guessing. It is also the foundation for later courses on networking, web development and cybersecurity.

## The core idea: a network of networks

The **internet** is millions of separate networks (homes, companies, universities, phone carriers) connected so they can pass data to each other. The **web** is one service that runs on top of it: pages and apps fetched with a protocol called **HTTP**. Email, video calls and file sync are other services on the same internet.

Four ideas explain most of what happens.

### 1. Every device has an IP address

An **IP address** is a number that identifies a device on a network, like a postal address. IPv4 addresses look like `93.184.215.14`; the newer IPv6 addresses look like `2606:2800:21f:cb07:6820:80da:af6b:8b2c`.

### 2. DNS turns names into addresses

People remember names like `codinghelp.org`; computers route by IP address. The **Domain Name System (DNS)** is the internet's phone book. Your device asks a DNS resolver "what is the address for this name?" and gets an IP back. Results are cached, so repeat visits are faster.

### 3. Data travels in packets

Data is split into small **packets**. Each packet carries the destination address and travels hop by hop through **routers**, which pass it towards its destination. Packets from the same file can take different routes. **TCP** numbers the packets, puts them back in order at the other end and asks for any lost ones to be sent again, so you get the whole file intact.

### 4. HTTP is the conversation between browser and server

Once connected, your browser sends an **HTTP request** ("please give me this page") and the server sends an **HTTP response** with a **status code** and the content. **HTTPS** is HTTP inside an encrypted connection (TLS), so nobody on the path can read or change the data. The padlock in the address bar means the connection is encrypted; it does not mean the site is honest.

## Anatomy of a URL

```text
https://www.example.com:443/docs/start?lang=en#install
\___/   \_____________/ \_/\_________/\______/\______/
scheme      host       port   path     query  fragment
```

- **Scheme:** how to talk (`https`).
- **Host:** the server's name, looked up with DNS.
- **Port:** which service on that server (443 is the default for HTTPS, so it is usually hidden).
- **Path:** which resource.
- **Query:** extra parameters, often for searches or filters.
- **Fragment:** a spot within the page; it never leaves your browser.

## Worked example: loading a page

You type `https://www.example.com/docs` and press Enter.

1. The browser checks its cache, then asks DNS for the IP address of `www.example.com`.
2. It opens a TCP connection to that IP on port 443 and sets up TLS encryption, checking the site's certificate.
3. It sends a request:

```http
GET /docs HTTP/1.1
Host: www.example.com
Accept: text/html
```

4. The request travels as packets through your router, your internet provider, and several other networks to the server.
5. The server replies:

```http
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
```

followed by the HTML of the page.

6. The browser reads the HTML, finds images, styles and scripts it also needs, and requests each of them the same way.
7. It draws the page.

All of this usually takes well under a second.

### Status codes worth knowing

- **200 OK:** it worked.
- **301 / 302:** moved; the browser follows the new address.
- **404 Not Found:** the server is fine but that path does not exist.
- **401 / 403:** you are not signed in, or not allowed.
- **500 / 503:** something went wrong on the server, or it is temporarily unavailable.

## Common mistakes

- **"The internet is down" when only DNS or one site is.** If one site fails and others work, the problem is probably that site, not your connection.
- **Trusting the padlock as proof of safety.** HTTPS protects the connection; criminals can get certificates too. Check the domain name itself.
- **Mixing up the internet and the web.** The web is one service on the internet.
- **Thinking data goes in one piece.** It travels in packets, which is why a weak connection makes pages load in bits.

## Quick recap

- The internet connects networks; the web is HTTP on top of it.
- DNS turns names into IP addresses.
- Data moves in packets through routers; TCP reassembles them reliably.
- A browser sends HTTP requests and receives responses with status codes; HTTPS encrypts them.

## Try it

Open the Do tab and take the quiz. To see real requests, open your browser's developer tools (F12, or Cmd + Option + I on a Mac), choose the Network tab and reload any page.


Trace what happens between typing a web address and seeing the page: DNS, IP addresses, packets and HTTP.

How the internet works

The Internet: IP Addresses & DNS

The Internet: HTTP & HTML

Write your question in one precise sentence, including the tool and version.

Run a plain search and note the top three results and who published each one.

Run the search again using at least two operators (for example `site:` for the vendor's documentation and quotes around an exact phrase). Note how the results change.

Open the official documentation page for the tool and find the part that answers your question.

Pick one non-official result (a blog, video or forum answer). Use lateral reading: look up the author or site in a new tab and note what you learn.

Compare the non-official answer with the official one. Write down any difference in steps, versions or warnings.

If it is safe to do so (a copy of a file, never real work data), try the answer and record whether it worked.

Write a two-line summary: the answer, and the source you trust most and why.

## Why it matters

Nobody in a technical job knows everything. Experienced engineers, analysts and technicians search constantly; what makes them effective is that they search well and they can tell a trustworthy answer from a confident wrong one. A bad source can cost you hours, or worse, lead to an unsafe setting on a machine or a wrong number in a report.

## Part 1: searching well

Search engines match your words against an index of pages and rank the results. You get better results by giving them better words.

### Use the words an expert would use

Describe the problem precisely: the tool, the version, the exact error, and what you were doing. Compare:

```text
weak:   my code doesn't work
better: python TypeError unsupported operand type(s) for +: 'int' and 'str'
```

### Search operators

Most major search engines support these (exact behaviour varies a little between them):

| Operator | Example | Effect |
|---|---|---|
| `"..."` | `"ModuleNotFoundError: No module named"` | match the exact phrase |
| `site:` | `csv encoding site:docs.python.org` | only results from one site |
| `-` | `python snake -programming` | exclude a word |
| `filetype:` | `arc flash label filetype:pdf` | only that file type |
| `OR` | `vlookup OR xlookup` | either term |

Tips for technical searches:

- **Paste the error message in quotes**, but remove things unique to you such as file paths, user names and numbers.
- **Add the version** (`python 3.12`, `excel 365`, `windows 11`). Answers for old versions can be wrong today.
- **Go to official documentation first** for how a tool is supposed to work: the vendor's docs, a standards body, a manufacturer's manual. Use forums such as Stack Overflow for "has anyone seen this problem?".
- **Check the date.** Many results pages and forum posts show when they were written. A 2014 answer about a 2026 tool is a warning sign.

## Part 2: judging what you find

Search results are not ranked by truth. You need a quick, repeatable check. A well-known method from digital literacy research is **SIFT**:

1. **Stop.** Before you use or share it, notice whether you know what this source is.
2. **Investigate the source.** Who wrote it, and what is their expertise or motive? A manufacturer's manual, a university, a government agency or a standards body usually beats an anonymous blog or a site selling something.
3. **Find better coverage.** Look for what other reliable sources say on the same point. If only one page says it, be careful.
4. **Trace claims to the original.** If an article says "a study found...", find the study. If an answer quotes documentation, open the documentation.

The key technique is **lateral reading**: instead of reading one page top to bottom to decide if it is trustworthy, open new tabs and look the source up elsewhere. Fact-checkers do this, and it is faster and more accurate than judging a site by how professional it looks.

### Signals of a reliable technical answer

- It explains *why*, not just "paste this".
- It matches the official documentation, or links to it.
- It names versions and conditions ("in Excel 365", "on Linux").
- On forums: other people confirm it worked, and comments do not point out problems.
- For safety, health, legal or licensing questions: it comes from the official body (for example OSHA, NFPA, a licensing board), not a summary of it.

## Worked example

You need to know whether Python's `round(2.5)` gives 2 or 3.

1. Search: `python round 2.5 site:docs.python.org`.
2. The official documentation for `round()` says values exactly halfway are rounded to the nearest even number ("banker's rounding"), so `round(2.5)` is `2` and `round(3.5)` is `4`.
3. A blog post claims it is always 3. Lateral reading: the official docs disagree, and you can test it yourself:

```python
print(round(2.5), round(3.5))   # 2 4
```

4. Conclusion: trust the documentation and your own test, not the blog.

Running a quick test is often the best fact check available in technical work.

## Common mistakes

- Using the first result without looking at who wrote it.
- Copying code or commands you do not understand, especially anything that deletes files, changes permissions or runs as administrator.
- Trusting a page because it looks polished or ranks first.
- Ignoring the date and version.
- Treating an AI chatbot's answer as a source (covered later in this course: it is a starting point to verify).

## Quick recap

- Search with precise words, quoted errors, versions, and operators like `site:` and `-`.
- Prefer official documentation and primary sources; use forums for real-world problems.
- Use SIFT and lateral reading to judge sources quickly.
- When you can, test the claim yourself.

## Try it

Open the Do tab to find and judge a real technical answer.


Use search operators to find technical answers fast, and judge whether a source is reliable before you rely on it.

Searching and evaluating sources

The Internet: How Search Works

Check Yourself with Lateral Reading: Crash Course Navigating Digital Information #3

Create a new document named `2026-dl-collab-practice` and write a short paragraph (for example, your learning goals for this course).

Open Version history and name the current version `first draft`.

Click Share and invite one person by email as a Commenter (not Editor). Check that general access is restricted, not 'Anyone with the link'.

Ask them to add one comment that mentions you with @ and, if your tool allows it, one suggested edit.

Reply to the comment, make the change, and resolve the comment. Accept or reject the suggestion.

Make a deliberate change: delete your whole paragraph.

Open Version history and restore the `first draft` version. Confirm your paragraph is back.

Finish by removing the other person's access in the Share settings.

## Why it matters

Project plans, lab protocols, design specs, meeting notes and course feedback are increasingly written in cloud documents that several people edit at once. Used well, cloud tools end the "which version is the latest?" problem. Used badly, they leak data to the wrong people or let one careless edit wipe out a colleague's work. Knowing the sharing and history features is a basic professional skill.

## The core idea: one copy, many people

With a traditional file, everyone has their own copy and you email versions back and forth. A **cloud document** lives on a server (for example Google Docs, Microsoft 365 / Word on the web, or similar tools). Everyone opens the *same* document through a browser or app, sees each other's changes within seconds, and the service keeps a full history of edits.

**Cloud storage** (Google Drive, OneDrive, Dropbox, iCloud Drive) is the related idea for ordinary files: a folder on your computer that syncs to the server and to your other devices.

## Sharing: who can do what

Every cloud tool has the same basic choices. Names vary slightly, but the ideas are the same.

**Who:**

- **Specific people:** only the accounts you invite. Best for most work.
- **Your organisation:** anyone signed in with your company or school account.
- **Anyone with the link:** anyone who gets the URL, including people it is forwarded to. Use with care.

**What they can do (roles):**

| Role | Can read | Can comment | Can edit |
|---|---|---|---|
| Viewer | yes | no | no |
| Commenter | yes | yes | no (in Google Docs they can suggest changes) |
| Editor | yes | yes | yes, including changing sharing in many setups |

**Least privilege** is the rule: give people the lowest role that lets them do their job. A reviewer needs comment access, not edit access. Check your employer's policy before sharing anything outside the organisation; client, patient and personal data often must never be link-shared.

## Working together

- **Comments:** select text and add a comment to ask a question or flag a problem without changing the text. Type `@` and a name (or email) to mention someone; they get notified, and in some tools you can assign the comment to them as a task.
- **Resolve:** when a comment has been dealt with, resolve it. It disappears from the margin but stays in the comment history.
- **Suggesting mode** (Google Docs) or **Track Changes** (Word): your edits show as proposals the owner can accept or reject. Use it when editing someone else's document.
- **Presence:** coloured cursors show who is editing where, so you can avoid typing over each other.

## Version history

The service saves versions automatically as people edit.

- **Google Docs:** File > Version history > See version history. You can name the current version (for example "Sent to supervisor 2026-10-20") and restore any earlier one.
- **Word / Microsoft 365:** File > Info > Version History (or the title bar's version history option) shows saved versions you can open or restore.

Naming a version at key moments (submitted, approved, sent to client) gives you a clean checkpoint. Restoring an old version does not delete the newer ones; they stay in the history.

## Worked example: a lab protocol review

Priya writes a sample-prep protocol and needs two reviewers.

1. She clicks **Share**, adds both reviewers' work emails as **Commenters**, and writes a short note: "Please review steps 4-7 by Friday."
2. Reviewer A selects step 5 and comments: "@Priya should this be 4 °C, not room temperature?" Priya checks the method, fixes it and resolves the comment.
3. Reviewer B uses suggesting mode to reword step 7. Priya accepts the suggestion.
4. Priya names the version "v1 approved 2026-10-24".
5. A week later someone accidentally deletes a section. Priya opens version history, finds "v1 approved" and restores it in seconds.

No files were emailed, nobody worked on an old copy, and there is a record of who changed what.

## Common mistakes

- **"Anyone with the link can edit"** on a document with sensitive information.
- **Downloading and emailing a copy**, which creates the version mess cloud tools exist to solve. Share the link instead.
- **Editing directly** in someone else's document when a comment or suggestion would be clearer.
- **Leaving old shares open.** Remove access when a project ends or someone leaves the team.
- **Forgetting offline limits.** Some tools need setup to work offline; do not rely on a document you cannot reach on site.

## Quick recap

- A cloud document is one shared copy with automatic history.
- Share with specific people and the lowest role that works (least privilege).
- Use comments, mentions, suggestions and resolve to collaborate cleanly.
- Name versions at milestones, and restore from history when things go wrong.

## Try it

Open the Do tab to share a document, collect a comment and restore a version.


Share a cloud document with the right permissions, work together with comments and suggestions, and use version history.

Cloud documents and collaboration

Google Drive: Sharing and Collaborating

Sharing in Google Docs

How data travels from browser to server, how to search for and judge technical sources, and how to collaborate in cloud documents.