aiMOOC

Networks, web services and online collaboration - Computing Year 6

QR-Code

Introduction

Opening a shared document feels simple, but several things must work together: a device, a network connection, a service and appropriate permissions. Learn to explain those roles and plan a small collaborative project without sharing more information or access than necessary.

Starting point: The internet connects networks; the World Wide Web is one service that uses it. The earlier Computer networks, the internet and the World Wide Web - Computing Year 5 is useful revision. This Year 6 sequence is editorial within England's key stage 2 networking and responsible-use expectations.

Your product: A labelled request-and-response diagram, an access-permission plan and a record of a small collaboration test. Use invented names and content. Practical work must take place only in a teacher-approved school workspace with supervised test accounts or an authorised demonstration. Do not create public accounts, change school permissions or publish a real class list for this exercise.

An offline card model can teach the ideas when devices are unavailable. Record clearly whether you simulated the exchange or actually observed a school-approved shared service; a paper model does not prove that a real online permission was tested.

Explain a shared service as requests and responses

Separate the connection from the service. A local network links devices so they can communicate. The internet connects many networks. A service is something offered through those connections, such as delivering a web page, sending email or storing a shared document. A Wi-Fi connection describes a local wireless link; its presence alone does not prove that an internet service is reachable.

The web consists of linked resources that browsers can request. Email and video calls are other examples of services using network communication; an online tool may combine several services. A shared document opened in a browser uses web technologies, but the document is not the entire internet.

Identify client and server roles

A client requests a service. A server provides or coordinates a service and sends responses. These are roles of software and systems, not a rule that all clients are small or all servers look like tall metal cupboards. A tablet's browser can be a client; the document service may use several server computers behind the scenes.

For our simplified shared-document model, follow this sequence:

The client requests a named document through a network connection.
The service checks the requesting account and its permission for that document.
If access is permitted, the service returns the permitted content or editing interface.
The client displays the result; a later edit is sent back for the service to process.

Real services can involve several requests, cached information and additional components. Our arrow model captures the roles; it is not a packet-by-packet description of a particular provider. A server response may report that access is unavailable rather than return the document.

Diagram challenge: Draw two devices, a network cloud and a shared-document service. Label one arrow Request document and the return arrow Permitted document response. Add a separate arrow Send proposed edit. Explain why a request arrow does not guarantee that the requested edit is authorised.

Observe a web request explanation

Code.org's original film explains HTTP and HTML. Pause when the browser requests information and identify the client, the request and the server response. HTTP is a protocol used for web exchanges; HTML describes web-page structure. You do not need to memorise every technical term or build a website. Connect the request-response idea to the shared-document model, while remembering that the film does not document your school's particular service or settings.

Choose access for the task and audience

A shared link is not automatically permission to edit. A link points towards a resource; the service's access settings decide what an account can do. In our class-project scenario, View means read only, Comment means leave a review without changing the main text, and Edit means change the content. Real tools may use different names or combine capabilities, so verify the teacher-approved service's actual behaviour.

The fictional Riverbank class is preparing a guide to its imaginary reading corner. It uses no real pupil names, photographs, contact details or private information. The teacher manages the workspace. Three roles are needed:

Intended participant	Needed action	Suitable starting permission in this model
Two assigned authors	Draft and revise the guide	Edit in the restricted project workspace
Assigned reviewer	Suggest a clearer heading	Comment, if the service supports it
Class audience	Read the teacher-approved final guide	View
Uninvited visitor	No project role	No access

Choose the least access needed for the agreed job. An audience member who only needs to read does not need editing permission. A trusted author still needs to respect the team's plan; technical access does not grant permission to replace other people's work without discussion.

Plan access before testing

Name the intended audience and the content's purpose.
Use fictional content and teacher-approved roles; do not copy a real class register into a test file.
Record who should view, comment or edit and who should have no access.
Ask the teacher to configure or demonstrate those settings in an authorised workspace.
Observe what each permitted test role can actually do; compare it with the plan.

Do not test by trying strangers' files, guessing passwords or forwarding an invitation to a personal account. If the wrong person can access or edit the document, stop the sharing exercise and tell the teacher. Do not widen access to make a failing test appear successful.

Worked decision: A reviewer needs to suggest a change, but must not directly replace the guide's text. Comment is a suitable starting choice if that feature exists. If the available tool has only View and Edit, the teacher can use View and collect feedback through an approved separate route. A particular permission label is not more important than the required behaviour.

Collaborate without losing or exposing work

Collaboration needs a process as well as a connection. Two people can have valid editing access and still overwrite, duplicate or contradict one another's work. Agree on roles, a shared goal and a review step before editing. Use clear headings and short, descriptive comments so another learner can follow the reasoning.

In the fictional reading-corner project, Author A drafts a section about choosing a book; Author B drafts a section about returning it; Reviewer C checks whether an unfamiliar reader can follow the instructions. The team uses invented details and teacher-assigned labels, not personal profiles.

Follow a controlled change

Save or identify the agreed starting version according to the approved tool's workflow.
Author A changes the unclear heading Books to Choose a book.
Reviewer C comments that the first instruction needs a location, rather than rewriting the entire section.
The authors discuss the comment and revise the fictional instruction.
The reviewer checks the change against the original purpose; the teacher approves any final audience copy.

Some services save edits continuously and keep a version history; others need explicit saves or have limited history. Verify rather than assume. A local filename such as guide-final-newest-really-final is not by itself evidence that the service has stored the agreed version. A synchronisation indicator, actual reload or supervised second-device check may provide useful evidence, depending on the tool.

Conflict scenario: Both authors separately download a copy. One adds a new heading; the other corrects a return instruction. Uploading the second file over the first can lose the heading change. Compare both versions and merge the intended changes in an authorised copy. Do not resolve the conflict by silently discarding one contributor's work.

Distinguish local work from synchronised work

A document may remain visible after a connection is lost because a copy is already on the device. That does not prove a new edit has reached the service. If an approved tool shows an unsynchronised edit, follow its teacher-provided recovery procedure and preserve the work; do not repeatedly open conflicting copies or assume that refreshing is always safe.

Think about the model: The diagram's web of lines is not the same thing as the World Wide Web. Lines model connections, while the web is a service using network infrastructure. Our request-response arrows simplify a particular task; neither diagram shows all permissions, stored copies or human collaboration decisions.

Test the plan and reason from observations

Use observations to narrow a problem. A failed page load does not prove that the entire internet is broken. A denied edit does not prove that the Wi-Fi has failed. Different parts of the system can produce different symptoms. Record what happened and ask a teacher for help rather than changing network or account settings yourself.

Observation in an authorised test	Reasonable interpretation	Safe next step
An approved page opens but the project document denies access	Some communication is working; the document or account permission needs checking	Confirm the intended school account with the teacher
The document opens in View but cannot be edited	Read-only behaviour may match the assigned role	Compare the role with the access plan
Several approved services fail on one device while others can use them	A device or connection issue is possible; evidence is not conclusive	Record the symptom and ask the teacher or authorised support
The draft is visible but a new edit is marked unsynchronised	The visible copy may be local and the update may not yet be stored remotely	Follow the approved recovery process and preserve the edit

These are hypotheses, not remote diagnoses. Do not disable security tools, bypass school filtering, share passwords or alter router settings to test an idea. Your job is to explain the evidence and use the authorised support route.

Run a small collaboration test

In a teacher-approved workspace, use a dummy document with a harmless title and an invented sentence. First write the expected actions for the author, reviewer and audience roles. With teacher-authorised test roles or a supervised demonstration, check only those actions. Do not attempt unauthorised access. Record whether the actual behaviour matches the planned role; note features that the service does not offer.

Make one agreed text improvement. Confirm that the intended collaborator sees the accepted version through the tool's normal save or synchronisation process. If version history is available, identify the relevant change with the teacher; do not restore or delete other people's work. Remove or close the test sharing only through the teacher-approved process.

Evidence table: Test role, intended action, expected result, observed result and conclusion. Add a simple client-server diagram explaining where the request and response fit. A completed role table without an actual observation remains a plan, not a proven permission test.

Evaluate a tool for the job

Choose between two fictional options. Tool P supports restricted author editing, reviewer comments and a teacher-approved read-only final copy. Tool Q supplies only a publicly editable link with no suitable restriction for this task. P better matches the declared class-project requirements; Q's convenience does not justify unintended access. This conclusion concerns the stated options, not a claim about a real named product.

Explain one limitation even for P: it still needs correct setup, agreed behaviour and a tested save process. Responsible collaboration combines technical access, clear communication, suitable content and human review. A shared link alone provides none of those guarantees.

Interactive Tasks

Quiz: Test Your Knowledge

Which statement correctly relates the internet and the World Wide Web? (The web is one service using internet infrastructure) (!The web is the physical cable inside every device) (!The internet is one document stored in a browser) (!The two names always mean exactly the same thing)

In the shared-document model, which role requests the document? (The client) (!The printed classroom notice) (!The document title alone) (!The permission label without any software)

What does the server role do in the simplified model? (Checks the request and permissions and returns an appropriate response) (!Guarantees that every link recipient can edit) (!Changes all viewers into authors) (!Removes the need for a network connection)

A class audience needs only to read the approved guide. Which permission best matches that need in the model? (View) (!Edit for everyone on the internet) (!Full workspace administration) (!Permission to change all account settings)

A reviewer should suggest improvements without directly replacing the main text. Which starting role fits if the tool supports it? (Comment) (!Unrestricted public editing) (!Owner of every school file) (!Automatic deletion of earlier versions)

What can you conclude from a shared link alone? (It points towards a resource but does not by itself establish editing permission) (!Every recipient must be an authorised author) (!The whole document is safe to publish publicly) (!No access settings need checking)

A draft remains visible after the connection fails. What must you avoid assuming? (That a new edit has already synchronised to the service) (!That a local copy can sometimes remain on a device) (!That the teacher may provide a recovery procedure) (!That the observed symptom should be recorded)

Two downloaded copies contain different useful edits. What is the responsible next action? (Compare the changes and merge the agreed ones in an authorised copy) (!Overwrite one copy without checking what will be lost) (!Publish both with real class details) (!Give every visitor editing access to resolve the conflict)

An approved page opens but one document denies access. Which conclusion is best supported? (Some communication works and the document or account access needs checking) (!The entire internet has certainly stopped working) (!The pupil should bypass school security settings) (!The document must allow anonymous editing)

Which evidence demonstrates more than an offline collaboration plan? (An authorised observed role test with expected and actual actions recorded) (!Only a diagram with no observation) (!A guess that every school service has identical settings) (!A public link containing private pupil records)

Memory Game

Client	Requests a service through a connection
Server	Provides or coordinates responses to service requests
View	Read the content without editing it in this model
Comment	Suggest a change without replacing the main text in this model
Edit	Change content within the authorised project role
Synchronisation	Brings a local change into agreement with the shared service

Drag and Drop

Author	Needs restricted access to draft and revise the agreed section
Reviewer	Needs an approved route to give feedback
Audience	Needs the approved final version for reading
Uninvited visitor	Has no project role and should not receive access
Teacher	Manages the approved workspace and sharing demonstration

Crossword Puzzle

CLIENT	The requesting role in the service model
SERVER	The role that provides a service response
NETWORK	Connected devices that can communicate
PERMISSION	A rule controlling an account's allowed actions
REVIEW	Check a proposed change against the agreed purpose
VERSION	An identifiable state of a document or program

LearningApps

Optional extra practice. Choose an appropriate activity with your teacher. If the external collection is unavailable, use the native activities and independent tasks in this course.

Cloze Text

Open Tasks

Easy

Network and service distinction: Explain why a Wi-Fi connection and a shared-document service are different things. Solution: Wi-Fi is a local wireless connection; the document service provides a particular function using communication and access rules.
Client-server arrows: Draw a client requesting a document and a server responding. Solution guide: label both roles and arrows, include the network, and explain that the response depends on the request and permissions.
Reading permission choice: Choose a role for the class audience that only needs the approved guide. Solution: View in this model; editing is unnecessary for that declared purpose.
Web service examples: Give a web example and another internet-service example. Solution guide: a browser requesting a page is a web example; email or a video-call service also uses network communication and is not the entire web.

Standard

Collaboration permission plan: Plan roles for two authors, a reviewer, the class audience and an uninvited visitor in the fictional reading-corner project. Solution: restricted Edit for authors, Comment if supported for the reviewer, View for the audience, no access for the visitor; the teacher manages setup.
Follow an authorised document request: Explain what happens when a read-only test role opens the document and tries to edit. Solution: the service should allow the permitted reading response but prevent content editing. Observe only in a teacher-authorised demonstration and record actual behaviour separately.
Merge two useful edits: One downloaded copy improves a heading and another corrects an instruction. Describe a safe merge. Solution: compare versions, retain both agreed improvements in an authorised copy, review the result and avoid silently overwriting another contributor's work.
Connection symptom evidence: A document is visible but a new edit is marked unsynchronised. Explain what is known and the next action. Solution: a local copy may be visible while the update is not yet shared; preserve work and follow the teacher-approved recovery procedure rather than assume it is saved remotely.

Advanced

Observed permission test: With teacher-approved dummy content and authorised roles, record a view test and an edit test against your plan. Solution guide: include expected and actual actions, the role and conclusion. If observation is unavailable, label the evidence as a plan or simulation, not a completed live access test.
Collaboration tool evaluation: Compare fictional Tool P with restricted roles and Tool Q with only a publicly editable link for this project. Solution: P better fits the stated access needs; still check setup, synchronisation and human review. Do not generalise the invented comparison to a named real product.
Review without comment support: The approved service offers View and Edit but no Comment role. Plan feedback without unnecessary editing. Solution: keep the reviewer read-only and use another teacher-approved feedback route, or a supervised review process matched to the need.
Explain model limitations: Compare the historical internet diagram with the request-response diagram. Solution: the former is an old partial connection visualisation, the latter simplifies one service exchange; neither proves current routes, permissions or whether a particular edit synchronised.

Learning Check

Shared-service roles assessment: Explain client, network and server roles when an authorised viewer opens a shared document.
Access choice assessment: Assign suitable model permissions to an author, reviewer, reading audience and uninvited visitor.
Synchronisation evidence assessment: Explain why a visible local edit is not conclusive proof that another collaborator received it.
Conflict resolution assessment: Two separate copies have useful different changes. Explain how to avoid losing work.
Practical collaboration assessment: Provide a labelled exchange diagram, role plan and results from a teacher-approved dummy-document test.
Safe fault reasoning assessment: One approved page loads but a project document denies access. Give a cautious explanation and next action.

Worked checks and assessment guidance

The client requests the resource; the network carries communication; the service checks the request and relevant permissions and returns a permitted response. The model simplifies what may be several real exchanges.
Use restricted Edit for the agreed author task, Comment if available for review, View for the reading audience and no access for the uninvited visitor. Real tool capabilities must be checked; labels alone do not prove behaviour.
The device may show a cached or unsynchronised copy. Check the approved save or synchronisation workflow and observe the intended collaborator's view through an authorised test. Preserve work and follow teacher guidance if the connection fails.
Identify the versions, compare the changes, discuss which to retain and merge them in an authorised copy. Review the accepted version and do not silently overwrite the other contribution.
Check technical roles, justified least-needed access, expected versus observed actions and confirmation of an agreed change. Practical observation is separate from a paper simulation. Do not require real pupil details, new public accounts or unauthorised permission changes.
Some communication is working; the document, account or permission may need checking. Record the symptom and use the teacher or authorised support route. Do not claim the whole internet is broken or bypass security controls.

Learning evidence

Knowledge: Distinguish a connection from a service and explain client, server, request, response and access permissions.

Model and plan: Submit a labelled shared-document exchange and a justified view/comment/edit plan for the invented project.

Practical observation: In a teacher-approved demonstration with dummy content and authorised test roles, compare planned with observed actions and confirm an agreed change. Do not create accounts or alter a real school workspace without authorisation.

Review: Explain a version conflict, a synchronisation uncertainty and a safe support route.

Completion distinction: A diagram or quiz can show understanding; it does not prove an online access test. Label unplugged models honestly. No real pupil data, credentials, public sharing or administrative bypass is required.

OER and Wikipedia

Department for Education: Computing programmes of study, key stage 2. Networks, services, collaboration and responsible use inform this route; the particular Year 6 allocation is editorial. Riverbank, its guide, Tool P and Tool Q are invented teaching scenarios, not named school systems or product evaluations.

Technical background: MDN: How does the Internet work?. The request-response diagrams simplify service roles and do not claim to show every packet, request or backend component. Permission labels in this course define the teaching model; use the approved provider's own guidance for actual controls.

Diagram, unmodified: Computernetwork, Joshap, public domain as declared on the file page.

Historical visualisation, unmodified: Internet map 1024, The Opte Project, CC BY 2.5, partial connections based on 2005 data. It is not a current or complete internet map.

Video: The Internet: HTTP and HTML, Code.org / CodeAI, embedded from the original publisher. Pause for client requests and server responses; the film is not a setup guide for a school service and is not copied or redistributed.