Computing I: Academic Documents and Collaboration
GAC คอมพิวเตอร์ หัวข้อ 1 18:56 การบรรยายภาษาอังกฤษ · คำบรรยายภาษาอังกฤษ + 中文 ลอยตัวบนภาพ
บท
Transcript
A group researching school transport needs more than a finished-looking file. It needs usable tools, reliable sources, a clear argument and a record of how members worked together. This lesson follows the existing Computing I handout and adds practical work with documents, storage and shared editing. Use the centre's current brief for required tools, formats and assessment criteria. Our school-transport task is original practice. Its files and activities help you develop skills; reading the lesson does not establish that you have completed the centre's practical assessment.
First write the research question in plain language. Then identify its main concepts and useful alternative terms. The original handout illustrates narrowing an electric-vehicle search using lifecycle emissions and a government-site restriction. That can make a search more focused, but a government domain is not proof that every result answers your question. Search services differ in the operators they support. Check how your service interprets a phrase or exclusion, inspect the result itself and refine the search when its scope is wrong.
A high position in a search list does not establish that a claim is accurate. Inspect the source's author, date, methods and relevant expertise. Ask which exact claim the source supports and whether the population or situation matches your question. Distinguish original material from a later interpretation, and check whether the later writer has represented the original fairly. Keep the source details with your notes. A conclusion should reflect the evidence you found, rather than selecting only sources that agree with an early opinion.
Before writing separately, agree the outline and the purpose of each section. Give members clear responsibilities, then use comments to explain changes that need discussion. If the editor supports suggestions, use them when a proposed revision should remain visible for review. A comment is useful when it explains a problem or asks for evidence, rather than simply saying the paragraph is bad. The final group review checks that sections connect, that repeated claims agree and that the style is consistent. One shared copy still requires active coordination.
A shared online document reduces some problems with duplicate files, but it does not make version problems impossible. Offline copies, exports and parallel drafts can still differ. Check which copy is current and what history the service actually retains. Record important decisions and each member's actual contribution. A visible edit history may show activity, but it cannot by itself prove the quality or extent of someone's work. When two copies differ, compare their changed sections and preserve the intended contributions before agreeing the current version.
A project scope states what you will study and what you will leave outside the task. Break the work into manageable tasks, each with an owner and a checkpoint. A milestone should have a clear result, such as an approved question set or a reviewed first draft. Dependencies explain the order: analysis needs data, and an evidence-based slide deck needs that analysis. A team agreement also states how members will communicate, make decisions and respond to unfinished work. Review the plan when a task slips, instead of discovering the delay at submission.
The original handout's transport project works backwards from a presentation in week six. Questions are prepared in week one, responses collected in weeks two and three, analysis completed in week four, slides built in week five and rehearsal held in week six. This is a planning example, not a record of completed research. Before involving participants, obtain the required permission and check whether the questions are suitable. If permission or data collection is delayed, revise the question or schedule appropriately; do not invent responses to keep the plan looking complete.
Start a slide by deciding its main message. Use concise text as support for the speaker, and test whether the actual audience can read it from the room's viewing distance. Font size and contrast matter in both dark and light designs. A chart is useful when the pattern is the point; a table may be clearer when exact values matter. Relevant chart axes need labels and units. Give sources where the evidence appears and include the required reference list. Decoration should support understanding, rather than compete with the message.
Rehearse aloud because silent reading does not reveal awkward phrasing or the real duration. Use signposts such as first, the reason is and this result suggests to help the listener follow the argument. Test your pace with another person: too fast can lose them, while too slow can also make a talk hard to follow. Prepare questions about evidence, methods and limitations. An animation can help reveal a sequence or part of a diagram, but use it only when it supports the explanation. Check that the exported slides still behave as intended.
A storyboard describes what appears in each shot, what is said and roughly how long it lasts. The original plastic-recycling example plans eight shots for a two-minute video, with a sourced chart in one shot. Write the spoken script against that plan, then read it aloud to test timing. Record in a quiet setting and check the audio before recording everything. Use media under the required permission and give credits. Finally export the video and test sound, pictures and playback on another device. A successful export message alone is not a playback check.
Imagine that one group member works mainly on a phone, another needs offline access and another needs larger text. A tool choice must account for those needs. Compare how the software handles the document, slide or video task, rather than assuming a single application does everything well. Test a small sample with a heading, a table and a comment on the actual devices. Check access, file formats, cost and privacy. If conversion loses an important feature, resolve that before the group depends on it for the full project.
New software may promise quicker research or writing, but a claim about convenience is not a suitability test. Try a small task with non-sensitive sample information. Check who runs the service, how it handles information and whether you can export a usable copy. Keep a way to continue the work if the service becomes unavailable. Automatic text can sound convincing while misrepresenting evidence, so verify its claims against appropriate sources. Follow the centre's rules about permitted assistance and acknowledgement. Choosing a tool does not remove your responsibility for the submitted work.
A clear folder structure saves time when the group needs to locate evidence or a final file. Separate source material, working drafts and submission copies. Use filenames that identify the content and a meaningful version or date, rather than new final final. Agree the same naming approach across the group. File names are helpful labels, but they do not prove which copy contains the correct changes. Compare content when versions differ, and record which copy was actually submitted. Keep personal participant details apart from the report under the centre's requirements.
Access permission controls who can read or change information. A collaborator may need editing access, while a reviewer may need only reading or comments. Check the sharing list and understand whether a link can be opened by people outside the group. Do not assume that a link sent privately is itself a private link. Each member should use their own account, rather than sharing one password. Keep participant information only when justified by the task and authorised procedure. Before sending a report, check that it does not accidentally include private source details.
A strong unique password reduces risks created by reusing sign-in details. Multi-factor authentication adds another kind of evidence for identity, such as a separate device code where that is supported. Treat an unexpected message requesting sign-in carefully: verify it through a trusted route before opening its link or entering credentials. Keep supported software updated and lock a device when you leave it. These are practical protection steps, but the project also needs sensible information decisions. Avoid collecting identifying details that the question does not need, and follow the centre's storage and access rules.
Synchronisation aligns copies across devices. It can therefore spread an accidental deletion as well as a useful edit. A separate permitted backup gives another recovery copy. In the handout's worked case, Mei deletes a paragraph and that change reaches everyone's device. Downloading the current file again preserves the same deletion. The group checks available version history, restores the correct paragraph and verifies the result. If that history is unavailable, an earlier separate backup may help. Test recovery using a harmless sample file, because having a copy is useful only if you can restore it.
Begin the academic document with the required structure. For our transport practice, the outline includes the research question, method, findings, discussion and references. Each section has a different job: methods explain how evidence was obtained, findings report it and discussion evaluates what it means. Keep source details while researching, including author, title, date, location and the supported claim. That record makes later referencing and verification easier. The outline can change as you learn, but it should continue to serve the question rather than become a collection of unrelated paragraphs.
A heading must do more than look large. Named heading styles tell the document which paragraphs are sections and how those sections relate. Use main and subordinate levels consistently, without skipping a level just to obtain a smaller font. In LibreOffice Writer, apply the required style to the heading paragraph; changing that named style can update matching headings. Page layout is controlled separately. The distinction matters because an academic document needs both a clear reading structure and a readable appearance. Check the result after formatting changes, especially after converting the file.
Use a real table when you need rows and columns of values. Put each value in its proper cell, label the columns clearly and state relevant units. Repeated spaces can look aligned on one screen but break when fonts or page widths change. Put a figure near the text that explains its role, with the required caption and source. Choose a chart only if it helps show the pattern; a small table may be enough. During review, compare the numbers with the source record so attractive formatting does not hide a transcription error.
Use a page break when a section must begin on a new page. Repeated empty paragraphs are fragile because earlier edits can move them. Add page numbers using the program's numbering field. If the task requires a contents list, generate it from the heading structure and update it after changes. Revise the argument before polishing appearance: check the evidence, the method and the limits. Then inspect spelling, names, units and references. Automatic suggestions need your review, because a technically correct word can be replaced by an inappropriate ordinary word.
Open-source software has source code available under a licence allowing specified use, study and changes. That does not mean every hosted service is free or available to everyone. A program can be open source and still require a centre to provide hosting, accounts or support. Likewise, an online editor can allow shared work without being open-source software. Check the licence and source availability rather than judging by whether an application runs in a browser. Our practical work uses the platform actually approved and provided by the centre, not an unverified personal service.
LibreOffice Writer is an open-source desktop word processor. For joint browser editing, a centre can provide Nextcloud with a configured office editor and the required server integration. The official documentation describes supported collaborative editing solutions. Do not assume every Nextcloud installation already includes office editing. Use the editor that the centre actually enables, and practise with harmless sample text. Each member signs in with their own account. The document owner grants suitable access, the group tests editing and comments, and members confirm that everyone can perform the task on their actual devices.
Add a comment that explains the purpose of a proposed change. Another member can respond with evidence or a different suggestion. If the installed editor supports a review feature, use it appropriately; otherwise comments can keep proposals visible for discussion. Before accepting changes, compare them with the research question and sources. Record important decisions, who checked them and what remains unfinished. If offline work creates two drafts, compare changed sections and merge intended contributions. The most recent timestamp alone cannot tell you whether a copy contains everyone's correct work.
Keep the editable document so you can correct and develop it. A PDF is often useful for sharing a stable page layout, but it is a separate export. The centre may require both the source and a PDF, or a different specified format. Follow that requirement. If you correct a table in the source after sending a PDF, the recipient's existing PDF has not changed. Export a corrected copy, inspect it and follow the centre's correction procedure. Record the submitted filename and date so the group knows which copy the recipient actually received.
Inspect the exported file rather than assuming it matches the editor. Read every page for missing text, broken characters, clipped tables, empty pages and correct page numbers. Search for an expected sentence to check that text is present. Review headings, contrast, table labels and helpful image descriptions; use an accessibility check where available, then still read the document yourself. Ask a group member to open the export on their device. Check sharing access through the recipient's permitted account or the centre's approved procedure. An export that opens only on your computer is not ready.
The original practice brief asks for a short transport report and a three-minute talk. Start with a question and approved information. Choose tools against the actual group needs, set permissions and agree checkpoints. Create a structured report, revise it together and preserve the source record and decisions. Keep an editable copy and test recovery. Then build a short slide deck with clear messages, explain the evidence and state its limits. Rehearse aloud and inspect the final exports on another device. If video is required, plan its shots and sound and verify its media permissions and playback.
The practical outcomes need actual work, not a statement that you know the steps. Keep the source record, report, revisions, final exports and evidence required by the centre. Demonstrate shared editing and explain each member's contribution. Rehearse the presentation and show that the exported files work. If a recovery check is part of your practice, record what sample you restored and whether it was correct. These records help you explain the process. The lesson prepares you to do the work; it does not establish that the activity has already happened.
Pause and answer the first three practice questions. For the phone-only member, test real editing, conversion and sharing on that device before choosing a tool. Access is part of suitability. For recovery, synchronisation may spread a deletion, while a separate permitted backup can preserve an earlier copy; test restoration. For headings, named styles provide recognised structure and consistent revision, and can support navigation or a contents list. Large bold text alone does not necessarily do that. In each answer, connect the feature to a concrete problem rather than simply listing a software command.
Answer the remaining questions. Online access does not prove open-source licensing: check the licence and source availability. If two offline drafts contain different contributions, compare and merge the intended changes before agreeing a current copy. Correcting the editable source does not update a PDF already sent, so re-export, check and follow the correction procedure. To show completion, provide the source record, editable report, revisions, suitable access check, tested recovery copy, final exports and rehearsed presentation. The exact required evidence comes from the current centre brief. Preserve the original handout and use these additional notes to practise the gaps.